From: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com> To: "robh+dt@kernel.org" <robh+dt@kernel.org> Cc: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>, "mcoquelin.stm32@gmail.com" <mcoquelin.stm32@gmail.com>, "alexandre.torgue@st.com" <alexandre.torgue@st.com>, "linus.walleij@linaro.org" <linus.walleij@linaro.org>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "tomase@xilinx.com" <tomase@xilinx.com>, "benjamin.gaignard@st.com" <benjamin.gaignard@st.com>, "broonie@kernel.org" <broonie@kernel.org>, "arnd@arndb.de" <arnd@arndb.de>, "shawnguo@kernel.org" <shawnguo@kernel.org>, "fabio.estevam@nxp.com" <fabio.estevam@nxp.com>, "loic.pallardy@st.com" <loic.pallardy@st.com>, "mark.rutland@arm.com" <mark.rutland@arm.com>, Sudeep Holla <sudeep.holla@arm.com>, Cristian Marussi <cristian.marussi@arm.com>, Stefano Stabellini <sstabellini@kernel.org>, "a.fatoum@pengutronix.de" <a.fatoum@pengutronix.de>, "peng.fan@oss.nxp.com" <peng.fan@oss.nxp.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller Date: Thu, 10 Nov 2022 08:57:26 +0000 [thread overview] Message-ID: <cover.1668070216.git.oleksii_moisieiev@epam.com> (raw) Introducing the feature domain controller provider/consumenr bindngs which allow to divided system on chip into multiple feature domains that can be used to select by who hardware blocks could be accessed. A feature-domain could be a cluster of CPUs, a group of hardware blocks or the set of devices, passed-through to the Guest in the virtualized systems. Feature domains controllers are typically used to set the permissions of the hardware block. The contents of the feature domain configuration properties are defined by the binding for the individual feature domain controller device. The feature device controller conception in the virtualized systems is to set the device configuration for SCMI (System Control and Management Interface) which controls clocks/power-domains/resets etc from the Firmware. This configuratio sets the device_id to set the device permissions for the Firmware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]). There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to determine device_id is not covered by the specification. Device permissions management described in DEN 0056, Section 4.2.2.10 [0]. Given parameter should set the device_id, needed to set device permissions in the Firmware. This property is used by trusted Agent (which is hypervisor in our case) to set permissions for the devices, passed-through to the non-trusted Agents. Trusted Agent will use device-perms to set the Device permissions for the Firmware (See Section 4.2.2.10 [0] for details). Agents concept is described in Section 4.2.1 [0]. Feature-Domains in Device-tree node example: usb@e6590000 { feature-domains = <&scmi 19>; //Set domain id 19 to usb node feature-domain-names = "scmi"; clocks = <&scmi_clock 3>, <&scmi_clock 2>; resets = <&scmi_reset 10>, <&scmi_reset 9>; power-domains = <&scmi_power 0>; }; &scmi { feature-domain-controller; #feature-domain-cells = <1>; } All mentioned bindings are going to be processed by XEN SCMI mediator feature, which is responsible to redirect SCMI calls from guests to the firmware, and not going be passed to the guests. Feature-domain-controller provider/consumenr concept was taken from the bus controller framework patch series, provided in the following thread: [1]. I think we can cooperate with the bus controller framework developers and produce the common binding, which will fit the requirements of both features Also, I think that binding can also be used for STM32 ETZPC bus controller feature, proposed in the following thread: [2]. Looking forward for your thoughts and ideas. [0] https://developer.arm.com/documentation/den0056/latest [1] https://lore.kernel.org/all/20190318100605.29120-1-benjamin.gaignard@st.com/ [2] https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/ --- Changes v1 -> V2: - update parameter name, made it xen-specific - add xen vendor bindings Changes V2 -> V3: - update parameter name, make it generic - update parameter format, add link to controller - do not include xen vendor bindings as already upstreamed Changes V3 -> V4: - introduce domain controller provider/consumer device tree bindings - making scmi node to act as domain controller provider when the device permissions should be configured Changes V4 -> V5: - rename domain-controller to feature-domain-controller - feature-domains format fixes Changes V5 -> V6: - formatting fixes Oleksii Moisieiev (2): dt-bindings: Update scmi node description dt-bindings: Document common device controller bindings .../feature-domain-controller.yaml | 84 +++++++++++++++++++ .../bindings/firmware/arm,scmi.yaml | 28 +++++++ MAINTAINERS | 6 ++ 3 files changed, 118 insertions(+) create mode 100644 Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml -- 2.25.1
WARNING: multiple messages have this Message-ID (diff)
From: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com> To: "robh+dt@kernel.org" <robh+dt@kernel.org> Cc: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>, "mcoquelin.stm32@gmail.com" <mcoquelin.stm32@gmail.com>, "alexandre.torgue@st.com" <alexandre.torgue@st.com>, "linus.walleij@linaro.org" <linus.walleij@linaro.org>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "tomase@xilinx.com" <tomase@xilinx.com>, "benjamin.gaignard@st.com" <benjamin.gaignard@st.com>, "broonie@kernel.org" <broonie@kernel.org>, "arnd@arndb.de" <arnd@arndb.de>, "shawnguo@kernel.org" <shawnguo@kernel.org>, "fabio.estevam@nxp.com" <fabio.estevam@nxp.com>, "loic.pallardy@st.com" <loic.pallardy@st.com>, "mark.rutland@arm.com" <mark.rutland@arm.com>, Sudeep Holla <sudeep.holla@arm.com>, Cristian Marussi <cristian.marussi@arm.com>, Stefano Stabellini <sstabellini@kernel.org>, "a.fatoum@pengutronix.de" <a.fatoum@pengutronix.de>, "peng.fan@oss.nxp.com" <peng.fan@oss.nxp.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: [PATCH v4 0/2] dt-bindings: Intorduce domain-controller Date: Thu, 10 Nov 2022 08:57:26 +0000 [thread overview] Message-ID: <cover.1668070216.git.oleksii_moisieiev@epam.com> (raw) Introducing the feature domain controller provider/consumenr bindngs which allow to divided system on chip into multiple feature domains that can be used to select by who hardware blocks could be accessed. A feature-domain could be a cluster of CPUs, a group of hardware blocks or the set of devices, passed-through to the Guest in the virtualized systems. Feature domains controllers are typically used to set the permissions of the hardware block. The contents of the feature domain configuration properties are defined by the binding for the individual feature domain controller device. The feature device controller conception in the virtualized systems is to set the device configuration for SCMI (System Control and Management Interface) which controls clocks/power-domains/resets etc from the Firmware. This configuratio sets the device_id to set the device permissions for the Firmware using BASE_SET_DEVICE_PERMISSIONS message (see 4.2.2.10 of [0]). There is no BASE_GET_DEVICE_PERMISSIONS call in SCMI and the way to determine device_id is not covered by the specification. Device permissions management described in DEN 0056, Section 4.2.2.10 [0]. Given parameter should set the device_id, needed to set device permissions in the Firmware. This property is used by trusted Agent (which is hypervisor in our case) to set permissions for the devices, passed-through to the non-trusted Agents. Trusted Agent will use device-perms to set the Device permissions for the Firmware (See Section 4.2.2.10 [0] for details). Agents concept is described in Section 4.2.1 [0]. Feature-Domains in Device-tree node example: usb@e6590000 { feature-domains = <&scmi 19>; //Set domain id 19 to usb node feature-domain-names = "scmi"; clocks = <&scmi_clock 3>, <&scmi_clock 2>; resets = <&scmi_reset 10>, <&scmi_reset 9>; power-domains = <&scmi_power 0>; }; &scmi { feature-domain-controller; #feature-domain-cells = <1>; } All mentioned bindings are going to be processed by XEN SCMI mediator feature, which is responsible to redirect SCMI calls from guests to the firmware, and not going be passed to the guests. Feature-domain-controller provider/consumenr concept was taken from the bus controller framework patch series, provided in the following thread: [1]. I think we can cooperate with the bus controller framework developers and produce the common binding, which will fit the requirements of both features Also, I think that binding can also be used for STM32 ETZPC bus controller feature, proposed in the following thread: [2]. Looking forward for your thoughts and ideas. [0] https://developer.arm.com/documentation/den0056/latest [1] https://lore.kernel.org/all/20190318100605.29120-1-benjamin.gaignard@st.com/ [2] https://lore.kernel.org/all/20200701132523.32533-1-benjamin.gaignard@st.com/ --- Changes v1 -> V2: - update parameter name, made it xen-specific - add xen vendor bindings Changes V2 -> V3: - update parameter name, make it generic - update parameter format, add link to controller - do not include xen vendor bindings as already upstreamed Changes V3 -> V4: - introduce domain controller provider/consumer device tree bindings - making scmi node to act as domain controller provider when the device permissions should be configured Changes V4 -> V5: - rename domain-controller to feature-domain-controller - feature-domains format fixes Changes V5 -> V6: - formatting fixes Oleksii Moisieiev (2): dt-bindings: Update scmi node description dt-bindings: Document common device controller bindings .../feature-domain-controller.yaml | 84 +++++++++++++++++++ .../bindings/firmware/arm,scmi.yaml | 28 +++++++ MAINTAINERS | 6 ++ 3 files changed, 118 insertions(+) create mode 100644 Documentation/devicetree/bindings/feature-controllers/feature-domain-controller.yaml -- 2.25.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2022-11-10 8:58 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-10 8:57 Oleksii Moisieiev [this message] 2022-11-10 8:57 ` [PATCH v4 0/2] dt-bindings: Intorduce domain-controller Oleksii Moisieiev 2022-11-10 8:57 ` [PATCH v6 1/2] dt-bindings: Update scmi node description Oleksii Moisieiev 2022-11-10 8:57 ` Oleksii Moisieiev 2022-11-10 8:57 ` [PATCH v6 2/2] dt-bindings: Document common device controller bindings Oleksii Moisieiev 2022-11-10 8:57 ` Oleksii Moisieiev 2022-11-10 14:01 ` [PATCH v6 0/2] dt-bindings: Intorduce domain-controller Oleksii Moisieiev 2022-11-10 14:01 ` Oleksii Moisieiev -- strict thread matches above, loose matches on Subject: below -- 2022-07-07 10:25 [PATCH v4 " Oleksii Moisieiev 2022-07-11 12:49 ` Linus Walleij 2022-07-20 21:32 ` Rob Herring 2022-07-26 7:45 ` Linus Walleij 2022-08-15 16:37 ` Ahmad Fatoum 2022-08-17 7:09 ` Loic PALLARDY 2022-08-18 9:31 ` Oleksii Moisieiev 2022-08-18 9:05 ` Oleksii Moisieiev 2022-08-30 7:34 ` Ahmad Fatoum 2022-09-06 9:27 ` Oleksii Moisieiev 2022-09-01 9:28 ` Peng Fan 2023-04-04 6:02 ` Peng Fan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=cover.1668070216.git.oleksii_moisieiev@epam.com \ --to=oleksii_moisieiev@epam.com \ --cc=a.fatoum@pengutronix.de \ --cc=alexandre.torgue@st.com \ --cc=arnd@arndb.de \ --cc=benjamin.gaignard@st.com \ --cc=broonie@kernel.org \ --cc=cristian.marussi@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=fabio.estevam@nxp.com \ --cc=gregkh@linuxfoundation.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=loic.pallardy@st.com \ --cc=mark.rutland@arm.com \ --cc=mcoquelin.stm32@gmail.com \ --cc=peng.fan@oss.nxp.com \ --cc=robh+dt@kernel.org \ --cc=shawnguo@kernel.org \ --cc=sstabellini@kernel.org \ --cc=sudeep.holla@arm.com \ --cc=tomase@xilinx.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.