| Message ID | 20211011141733.3999-2-stephan@gerhold.net (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: wwan: Add Qualcomm BAM-DMUX WWAN network driver | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Series has a cover letter |
| netdev/fixes_present | success | Fixes tag not required for -next series |
| 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 | Signed-off-by tag matches author and committer |
| 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 | No Fixes tag |
| 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 | No static functions without inline keyword in header files |
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@gerhold.net> > --- > 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 > > 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..6e9a5497b3f2 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,powered-remotely : 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 > -- > 2.33.0
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@gerhold.net> > > --- > > 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@gerhold.net/ Thanks! Stephan
Hi Stephan, On Mon, 11 Oct 2021 at 20:12, Stephan Gerhold <stephan@gerhold.net> 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@gerhold.net> > --- > 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@linaro.org/ 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@linaro.org/T/#t Regards, Bhupesh > --- > 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..6e9a5497b3f2 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,powered-remotely : 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 > -- > 2.33.0 >
On Mon, Oct 18, 2021 at 05:04:31PM +0530, Bhupesh Sharma wrote: > On Mon, 11 Oct 2021 at 20:12, Stephan Gerhold <stephan@gerhold.net> 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@gerhold.net> > > --- > > 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@linaro.org/ > > 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@linaro.org/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
Hi, On Mon, 18 Oct 2021 at 18:26, Stephan Gerhold <stephan@gerhold.net> wrote: > > On Mon, Oct 18, 2021 at 05:04:31PM +0530, Bhupesh Sharma wrote: > > On Mon, 11 Oct 2021 at 20:12, Stephan Gerhold <stephan@gerhold.net> 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@gerhold.net> > > > --- > > > 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@linaro.org/ > > > > 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@linaro.org/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. Sure, let's wait for Vinod's comments. Regards, Bhupesh
diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt index cf5b9e44432c..6e9a5497b3f2 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,powered-remotely : 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,powered-remotely" property to describe that configuration. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> --- 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@linaro.org/ --- Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 2 ++ 1 file changed, 2 insertions(+)