On 21/08/2024 18:34, Md Sadre Alam wrote: > > > On 8/17/2024 2:38 PM, Krzysztof Kozlowski wrote: >> On 15/08/2024 10:57, Md Sadre Alam wrote: >>> BAM having pipe locking mechanism. The Lock and Un-Lock bit >>> should be set on CMD descriptor only. Upon encountering a >>> descriptor with Lock bit set, the BAM will lock all other >>> pipes not related to the current pipe group, and keep >>> handling the current pipe only until it sees the Un-Lock >>> set. >> >> Please wrap commit message according to Linux coding style / submission >> process (neither too early nor over the limit): >> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597 > Ok , will update in next patch. >> >>> >>> Signed-off-by: Md Sadre Alam <quic_mdalam@xxxxxxxxxxx> >>> --- >>> >>> Change in [v2] >>> >>> * Added initial support for dt-binding >>> >>> Change in [v1] >>> >>> * This patch was not included in [v1] >>> >>> Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml >>> index 3ad0d9b1fbc5..91cc2942aa62 100644 >>> --- a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml >>> +++ b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml >>> @@ -77,6 +77,12 @@ properties: >>> Indicates that the bam is powered up by a remote processor but must be >>> initialized by the local processor. >>> >>> + qcom,bam_pipe_lock: >> >> Please follow DTS coding style. > Ok >> >>> + type: boolean >>> + description: >>> + Indicates that the bam pipe needs locking or not based on client driver >>> + sending the LOCK or UNLOK bit set on command descriptor. >> >> You described the desired Linux feature or behavior, not the actual >> hardware. The bindings are about the latter, so instead you need to >> rephrase the property and its description to match actual hardware >> capabilities/features/configuration etc. > Ok, will update in next patch. >> >>> + >>> reg: >>> maxItems: 1 >>> >>> @@ -92,6 +98,8 @@ anyOf: >>> - qcom,powered-remotely >>> - required: >>> - qcom,controlled-remotely >>> + - required: >>> + - qcom,bam_pipe_lock >> >> Why is it here? What do you want to achieve? > This property added to achieve locking/unlocking > of BAM pipe groups for mutual exclusion of resources > that can be used across multiple EE's This explains me nothing. I am questioning the anyOf block. Why this is the fourth method of controlling BAM? Anyway, if it is, then explain this in commit msg. Best regards, Krzysztof
