On Mon, Oct 18, 2021 at 11:47:06AM +0530, Vinod Koul wrote: > On 11-10-21, 16:17, Stephan Gerhold 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. > > Can we split that this to dmaengine & net series if there is not > dependency on the two... I think I skipped rev1 when I saw net-next > Sure, I have now sent a v3 for the dmaengine changes without the BAM-DMUX driver. The original reason for having them in one series was to better see how the dmaengine changes are used together with the design of the BAM-DMUX driver. I discussed some alternative approaches in the original RFC which only made sense in combination with the BAM-DMUX driver: https://lore.kernel.org/dmaengine/20210719145317.79692-3-stephan@xxxxxxxxxxx/ Thanks! Stephan
