On 8/17/2024 2:38 PM, Krzysztof Kozlowski wrote:
On 15/08/2024 10:57, Md Sadre Alam wrote:bam having locking and unlocking mechanism of bam pipes. 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 , then it will release all locked pipes. The actual locking is done on the new descriptor fetching for publishing, i.e. locked pipe will not fetch new descriptors even if it got event/events adding more descriptors for this pipe. Adding the bam_pipe_lock flag in bam driver to handle Lock and Un-Lock bit set on command descriptor. Signed-off-by: Md Sadre Alam <quic_mdalam@xxxxxxxxxxx> --- Change in [v2] * Added bam_pipe_lock dt property Change in [v1] * This patch was not included in [v1] drivers/dma/qcom/bam_dma.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c index 5e7d332731e0..1ac7e250bdaa 100644 --- a/drivers/dma/qcom/bam_dma.c +++ b/drivers/dma/qcom/bam_dma.c @@ -389,6 +389,7 @@ struct bam_device { u32 ee; bool controlled_remotely; bool powered_remotely; + bool bam_pipe_lock;There is no user of this property. It's just no-op. Split your code into logical chunks, but logical chunk is not "I add field to structure which is not used".
Ok ,will squash this patch accordingly.
Best regards, Krzysztof
