[lkml]   [2021]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH net-next v2 1/4] dt-bindings: dmaengine: bam_dma: Add "powered remotely" mode
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 <>
> > ---
> > 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:


 \ /
  Last update: 2021-10-18 12:30    [W:0.058 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site