| Message ID | 20241210174554.18869-2-johnliu@nvidia.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Support host1x actmon | expand |
On Tue, Dec 10, 2024 at 09:45:50AM -0800, Johnny Liu wrote: > An activity monitor (actmon) is used to measure the device runtime > utilization to help drive software power management policies. > > Extend the reg space to include actmon aperture for actmon configuration > through host1x. We kind of see that from the diff. Say what we do not see, e.g. ABI impact or why this is flexible/optional for existing devices. Best regards, Krzysztof
> On Tue, Dec 10, 2024 at 09:45:50AM -0800, Johnny Liu wrote: > > An activity monitor (actmon) is used to measure the device runtime > > utilization to help drive software power management policies. > > > > Extend the reg space to include actmon aperture for actmon configuration > > through host1x. > > We kind of see that from the diff. Say what we do not see, e.g. ABI > impact or why this is flexible/optional for existing devices. Since actmon is not well-supported for the previous chips (e.g. T210, T186, T194, and etc) in this patch series, it's essential to make the specification of regs property optional for the previous chips. Enablement/Disablement of actmon won't affect the host1x main functionality. Its main job is to monitor the engines behind the host1x and serve for telemetry purpose. I could update the commit message to include the above reason. Please let me know if more information is required. Thanks, Johnny
On 14/12/2024 00:29, Johnny Liu wrote: >> On Tue, Dec 10, 2024 at 09:45:50AM -0800, Johnny Liu wrote: >>> An activity monitor (actmon) is used to measure the device runtime >>> utilization to help drive software power management policies. >>> >>> Extend the reg space to include actmon aperture for actmon configuration >>> through host1x. >> >> We kind of see that from the diff. Say what we do not see, e.g. ABI >> impact or why this is flexible/optional for existing devices. > > Since actmon is not well-supported for the previous chips (e.g. T210, > T186, T194, and etc) in this patch series, it's essential to make the > specification of regs property optional for the previous chips. Then your schema should express it. > > Enablement/Disablement of actmon won't affect the host1x main functionality. > Its main job is to monitor the engines behind the host1x and serve for > telemetry purpose. > > I could update the commit message to include the above reason. Please > let me know if more information is required. And fix the schema to make it optional only for older variants. Best regards, Krzysztof
> On 14/12/2024 00:29, Johnny Liu wrote: > >> On Tue, Dec 10, 2024 at 09:45:50AM -0800, Johnny Liu wrote: > >>> An activity monitor (actmon) is used to measure the device runtime > >>> utilization to help drive software power management policies. > >>> > >>> Extend the reg space to include actmon aperture for actmon configuration > >>> through host1x. > >> > >> We kind of see that from the diff. Say what we do not see, e.g. ABI > >> impact or why this is flexible/optional for existing devices. > > > > Since actmon is not well-supported for the previous chips (e.g. T210, > > T186, T194, and etc) in this patch series, it's essential to make the > > specification of regs property optional for the previous chips. > > Then your schema should express it. Could you explicitly point out which part doesn't express it well? Considering old variant T194, the schema in this patch already made the specification of actmon related properties optional. If users specify actmon clock handle in clocks/clock-names properties: host1x@13e00000 { compatible = "nvidia,tegra194-host1x"; // ... clocks = <&bpmp TEGRA194_CLK_HOST1X>, <&bpmp TEGRA194_CLK_ACTMON>; clock-names = "host1x", "actmon"; // ... } Running the dtbs_check will report error WITHOUT this patch will have the following error: $ make O=out ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml /out/arch/arm64/boot/dts/nvidia/tegra194-p3509-0000+p3668-0000.dtb: host1x@13e00000: clocks: [[5, 46], [5, 1]] is too long /out/arch/arm64/boot/dts/nvidia/tegra194-p3509-0000+p3668-0000.dtb: host1x@13e00000: clock-names: ['host1x', 'actmon'] is too long > > > > Enablement/Disablement of actmon won't affect the host1x main functionality. > > Its main job is to monitor the engines behind the host1x and serve for > > telemetry purpose. > > > > I could update the commit message to include the above reason. Please > > let me know if more information is required. > > And fix the schema to make it optional only for older variants. To maintain backward compatibility, shouldn't we keep the newly added feature optional for all the variants? Thanks, Johnny
On 17/12/2024 02:08, Johnny Liu wrote: >> On 14/12/2024 00:29, Johnny Liu wrote: >>>> On Tue, Dec 10, 2024 at 09:45:50AM -0800, Johnny Liu wrote: >>>>> An activity monitor (actmon) is used to measure the device runtime >>>>> utilization to help drive software power management policies. >>>>> >>>>> Extend the reg space to include actmon aperture for actmon configuration >>>>> through host1x. >>>> >>>> We kind of see that from the diff. Say what we do not see, e.g. ABI >>>> impact or why this is flexible/optional for existing devices. >>> >>> Since actmon is not well-supported for the previous chips (e.g. T210, >>> T186, T194, and etc) in this patch series, it's essential to make the >>> specification of regs property optional for the previous chips. >> >> Then your schema should express it. > > Could you explicitly point out which part doesn't express it well? > You said it should be optional for previous chip, while this is not made optional for previous chips. You made it optional for newest chips. > Considering old variant T194, the schema in this patch already made the > specification of actmon related properties optional. > > If users specify actmon clock handle in clocks/clock-names properties: > > host1x@13e00000 { > compatible = "nvidia,tegra194-host1x"; > // ... > clocks = <&bpmp TEGRA194_CLK_HOST1X>, > <&bpmp TEGRA194_CLK_ACTMON>; > clock-names = "host1x", "actmon"; > // ... > } > > Running the dtbs_check will report error WITHOUT this patch will have > the following error: > > $ make O=out ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml > > /out/arch/arm64/boot/dts/nvidia/tegra194-p3509-0000+p3668-0000.dtb: host1x@13e00000: clocks: [[5, 46], [5, 1]] is too long > /out/arch/arm64/boot/dts/nvidia/tegra194-p3509-0000+p3668-0000.dtb: host1x@13e00000: clock-names: ['host1x', 'actmon'] is too long This is not the meaning of word "optional". > > >>> >>> Enablement/Disablement of actmon won't affect the host1x main functionality. >>> Its main job is to monitor the engines behind the host1x and serve for >>> telemetry purpose. >>> >>> I could update the commit message to include the above reason. Please >>> let me know if more information is required. >> >> And fix the schema to make it optional only for older variants. > > To maintain backward compatibility, shouldn't we keep the newly added > feature optional for all the variants? Yes, but it is about driver. Is it optional in the driver? Your binding says optional but driver says required and will fail. This does not make any sense in the context of this patch and even less in the context of your explanation. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml index 3563378a01af4..46e1d27ddef8b 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml @@ -32,11 +32,11 @@ properties: reg: minItems: 1 - maxItems: 3 + maxItems: 4 reg-names: minItems: 1 - maxItems: 3 + maxItems: 4 interrupts: minItems: 1 @@ -60,12 +60,12 @@ properties: maxItems: 1 clocks: - description: Must contain one entry, for the module clock. See - ../clocks/clock-bindings.txt for details. + minItems: 1 + maxItems: 2 clock-names: - items: - - const: host1x + minItems: 1 + maxItems: 2 resets: minItems: 1 # MC reset is optional on Tegra186 and later @@ -132,6 +132,15 @@ allOf: items: - const: syncpt - const: host1x + + clocks: + items: + - description: host1x clock + + clock-names: + items: + - const: host1x + required: - resets - reset-names @@ -170,6 +179,14 @@ allOf: - const: syncpt - const: host1x + clocks: + items: + - description: host1x clock + + clock-names: + items: + - const: host1x + iommu-map: description: Specification of stream IDs available for memory context device use. Should be a mapping of IDs 0..n to IOMMU entries corresponding to @@ -195,16 +212,20 @@ allOf: then: properties: reg-names: + minItems: 3 items: - const: common - const: hypervisor - const: vm + - const: actmon reg: + minItems: 3 items: - description: region used by host1x server - description: region used by the hypervisor - description: region assigned to the virtual machine + - description: region used for configuring actmon for host1x clients interrupts: items: @@ -230,6 +251,18 @@ allOf: - const: syncpt7 - const: host1x + clocks: + minItems: 1 + items: + - description: host1x clock + - description: actmon clock + + clock-names: + minItems: 1 + items: + - const: host1x + - const: actmon + iommu-map: description: Specification of stream IDs available for memory context device use. Should be a mapping of IDs 0..n to IOMMU entries corresponding to
An activity monitor (actmon) is used to measure the device runtime utilization to help drive software power management policies. Extend the reg space to include actmon aperture for actmon configuration through host1x. Extend the number of clocks to include actmon clock, which is shared between unit actmons for different host1x clients. Signed-off-by: Johnny Liu <johnliu@nvidia.com> --- .../display/tegra/nvidia,tegra20-host1x.yaml | 45 ++++++++++++++++--- 1 file changed, 39 insertions(+), 6 deletions(-)