| Message ID | 20210719145317.79692-2-stephan@gerhold.net (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: wwan: Add Qualcomm BAM-DMUX WWAN network driver | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Link |
| netdev/fixes_present | success | Link |
| netdev/patch_count | success | Link |
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/subject_prefix | success | Link |
| netdev/cc_maintainers | success | CCed 7 of 7 maintainers |
| netdev/source_inline | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Link |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/verify_fixes | success | Link |
| netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 8 lines checked |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
| netdev/header_inline | success | Link |
On Mon, Jul 19, 2021 at 04:53:14PM +0200, 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,remote-power-collapse" property to describe that configuration. > > Signed-off-by: Stephan Gerhold <stephan@gerhold.net> > --- > 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@linaro.org/ > --- > Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt > index cf5b9e44432c..362a4f0905a8 100644 > --- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt > +++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt > @@ -15,6 +15,8 @@ Required properties: > the secure world. > - qcom,controlled-remotely : optional, indicates that the bam is controlled by > remote proccessor i.e. execution environment. > +- qcom,remote-power-collapse : optional, indicates that the bam is powered up by > + a remote processor but must be initialized by the local processor. Wouldn't 'qcom,remote-power' or 'qcom,remote-powered' be sufficient? I don't understand what 'collapse' means here. Doesn't sound good though. Rob
On Thu, Jul 29, 2021 at 01:36:31PM -0600, Rob Herring wrote: > On Mon, Jul 19, 2021 at 04:53:14PM +0200, 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,remote-power-collapse" property to describe that configuration. > > > > Signed-off-by: Stephan Gerhold <stephan@gerhold.net> > > --- > > 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@linaro.org/ > > --- > > Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt > > index cf5b9e44432c..362a4f0905a8 100644 > > --- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt > > +++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt > > @@ -15,6 +15,8 @@ Required properties: > > the secure world. > > - qcom,controlled-remotely : optional, indicates that the bam is controlled by > > remote proccessor i.e. execution environment. > > +- qcom,remote-power-collapse : optional, indicates that the bam is powered up by > > + a remote processor but must be initialized by the local processor. > > Wouldn't 'qcom,remote-power' or 'qcom,remote-powered' be sufficient? I > don't understand what 'collapse' means here. Doesn't sound good though. > Yeah I can't think of any significant meaning of the "collapse" part for the bindings, I probably just picked it up somewhere while trying to find some information about how the BAM DMUX setup works. :) Just one question, would you prefer "qcom,remote-powered" or rather "qcom,powered-remotely" for consistency with the existing "qcom,controlled-remotely"? Both sounds fine to me. Thanks! Stephan
diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt index cf5b9e44432c..362a4f0905a8 100644 --- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt +++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt @@ -15,6 +15,8 @@ Required properties: the secure world. - qcom,controlled-remotely : optional, indicates that the bam is controlled by remote proccessor i.e. execution environment. +- qcom,remote-power-collapse : optional, indicates that the bam is powered up by + a remote processor but must be initialized by the local processor. - num-channels : optional, indicates supported number of DMA channels in a remotely controlled bam. - qcom,num-ees : optional, indicates supported number of Execution Environments
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,remote-power-collapse" property to describe that configuration. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> --- 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@linaro.org/ --- Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 2 ++ 1 file changed, 2 insertions(+)