On Mon, Oct 18, 2021 at 05:04:31PM +0530, Bhupesh Sharma wrote: > On Mon, 11 Oct 2021 at 20:12, Stephan Gerhold <stephan@xxxxxxxxxxx> wrote: > > > > In some configurations, the BAM DMA controller is set up by a remote > > processor and the local processor can simply start making use of it > > without setting up the BAM. This is already supported using the > > "qcom,controlled-remotely" property. > > > > However, for some reason another possible configuration is that the > > remote processor is responsible for powering up the BAM, but we are > > still responsible for initializing it (e.g. resetting it etc). Add > > a "qcom,powered-remotely" property to describe that configuration. > > > > Signed-off-by: Stephan Gerhold <stephan@xxxxxxxxxxx> > > --- > > Changes since RFC: > > - Rename qcom,remote-power-collapse -> qcom,powered-remotely > > for consistency with "qcom,controlled-remotely" > > > > NOTE: This is *not* a compile-time requirement for the BAM-DMUX driver > > so this could also go through the dmaengine tree. > > > > Also note that there is an ongoing effort to convert these bindings > > to DT schema but sadly there were not any updates for a while. :/ > > https://lore.kernel.org/linux-arm-msm/20210519143700.27392-2-bhupesh.sharma@xxxxxxxxxx/ > > Seems you missed the latest series posted last week - [1]. Sorry I got > a bit delayed posting it due to being caught up in other patches. > > Maybe you can rebase your patch on the same and use the YAML bindings > for the qcom,bam_dma controller. > > [1]. https://lore.kernel.org/linux-arm-msm/20211013105541.68045-1-bhupesh.sharma@xxxxxxxxxx/T/#t > Ah, you're right sorry! Seems like you sent it two days after I sent the v2 of this patch. Thanks a lot for continuing work on this! :) Since I already sent v3 of this patch earlier, I think it is best if I wait a bit first and see if Vinod has any comments or still wants to take it for 5.16. Should be simple to rebase either of our patches on the other one. Thanks! Stephan
