* [PATCH v2 0/4] SDM670 GPI DMA support @ 2022-09-23 21:09 Richard Acayan 2022-09-23 21:09 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible Richard Acayan ` (3 more replies) 0 siblings, 4 replies; 12+ messages in thread From: Richard Acayan @ 2022-09-23 21:09 UTC (permalink / raw) To: linux-arm-msm Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Vinod Koul, Rob Herring, Krzysztof Kozlowski, dmaengine, devicetree, Richard Acayan Changes since v1: - add fallback compatible This patch series adds the compatible string for GPI DMA, needed for the GENI interface, on Snapdragon 670. Richard Acayan (4): dt-bindings: dma: qcom: gpi: add fallback compatible dt-bindings: dma: qcom: gpi: add compatible for sdm670 arm64: dts: qcom: add gpi-dma fallback compatible dmaengine: qcom: gpi: drop redundant of_device_id entries .../devicetree/bindings/dma/qcom,gpi.yaml | 18 ++++++++++-------- arch/arm64/boot/dts/qcom/sc7280.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sm6350.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sm8150.dtsi | 6 +++--- arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 +++--- arch/arm64/boot/dts/qcom/sm8350.dtsi | 6 +++--- arch/arm64/boot/dts/qcom/sm8450.dtsi | 6 +++--- drivers/dma/qcom/gpi.c | 4 +--- 9 files changed, 29 insertions(+), 29 deletions(-) -- 2.37.3 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible 2022-09-23 21:09 [PATCH v2 0/4] SDM670 GPI DMA support Richard Acayan @ 2022-09-23 21:09 ` Richard Acayan 2022-09-23 21:26 ` Krzysztof Kozlowski 2022-09-23 21:09 ` [PATCH v2 2/4] dt-bindings: dma: qcom: gpi: add compatible for sdm670 Richard Acayan ` (2 subsequent siblings) 3 siblings, 1 reply; 12+ messages in thread From: Richard Acayan @ 2022-09-23 21:09 UTC (permalink / raw) To: linux-arm-msm Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Vinod Koul, Rob Herring, Krzysztof Kozlowski, dmaengine, devicetree, Richard Acayan The drivers are transitioning from matching against lists of specific compatible strings to matching against smaller lists of more generic compatible strings. Add a fallback compatible string in the schema to support this change. Signed-off-by: Richard Acayan <mailingradian@gmail.com> --- .../devicetree/bindings/dma/qcom,gpi.yaml | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml index eabf8a76d3a0..25bc1a6de794 100644 --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -18,14 +18,15 @@ allOf: properties: compatible: - enum: - - qcom,sc7280-gpi-dma - - qcom,sdm845-gpi-dma - - qcom,sm6350-gpi-dma - - qcom,sm8150-gpi-dma - - qcom,sm8250-gpi-dma - - qcom,sm8350-gpi-dma - - qcom,sm8450-gpi-dma + - enum: + - qcom,sc7280-gpi-dma + - qcom,sdm845-gpi-dma + - qcom,sm6350-gpi-dma + - qcom,sm8150-gpi-dma + - qcom,sm8250-gpi-dma + - qcom,sm8350-gpi-dma + - qcom,sm8450-gpi-dma + - const: qcom,gpi-dma reg: maxItems: 1 -- 2.37.3 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible 2022-09-23 21:09 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible Richard Acayan @ 2022-09-23 21:26 ` Krzysztof Kozlowski 2022-09-23 22:20 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback Richard Acayan 2022-09-29 7:39 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible Vinod Koul 0 siblings, 2 replies; 12+ messages in thread From: Krzysztof Kozlowski @ 2022-09-23 21:26 UTC (permalink / raw) To: Richard Acayan, linux-arm-msm Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Vinod Koul, Rob Herring, Krzysztof Kozlowski, dmaengine, devicetree On 23/09/2022 23:09, Richard Acayan wrote: > The drivers are transitioning from matching against lists of specific > compatible strings to matching against smaller lists of more generic > compatible strings. Add a fallback compatible string in the schema to > support this change. Thanks for the patch. I wished we discussed it a bit more. :) qcom,gpi-dma does not look like specific enough to be correct fallback, at least not for all of the devices. I propose either a IP block version (which is tricky without access to documentation) or just one of the SoC IP blocks. > > Signed-off-by: Richard Acayan <mailingradian@gmail.com> > --- > .../devicetree/bindings/dma/qcom,gpi.yaml | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > index eabf8a76d3a0..25bc1a6de794 100644 > --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > @@ -18,14 +18,15 @@ allOf: Best regards, Krzysztof ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback 2022-09-23 21:26 ` Krzysztof Kozlowski @ 2022-09-23 22:20 ` Richard Acayan 2022-09-26 23:12 ` Rob Herring 2022-09-29 7:39 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible Vinod Koul 1 sibling, 1 reply; 12+ messages in thread From: Richard Acayan @ 2022-09-23 22:20 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, Konrad Dybcio, Vinod Koul, Rob Herring, dmaengine, devicetree, Richard Acayan > On 23/09/2022 23:09, Richard Acayan wrote: > > The drivers are transitioning from matching against lists of specific > > compatible strings to matching against smaller lists of more generic > > compatible strings. Add a fallback compatible string in the schema to > > support this change. > > Thanks for the patch. I wished we discussed it a bit more. :) Ah, sorry for not replying to your original suggestion. I didn't see the opportunity for discussion as this new series wasn't that hard to come up with. > qcom,gpi-dma does not look like specific enough to be correct fallback, > at least not for all of the devices. I propose either a IP block version > (which is tricky without access to documentation) or just one of the SoC > IP blocks. Solution 1: Yes, I could use something like qcom,sdm845-gpi-dma. It would be weird to see the compatible strings for that, though: compatible = "qcom,sdm670-gpi-dma", "qcom,sdm845-gpi-dma"; // This would need to be valid in dt schema, suggesting solution 2 compatible = "qcom,sdm845-gpi-dma"; // This just doesn't make sense compatible = "qcom,sdm845-gpi-dma", "qcom,sdm845-gpi-dma"; compatible = "qcom,sm8150-gpi-dma", "qcom,sdm845-gpi-dma"; compatible = "qcom,sm8250-gpi-dma", "qcom,sdm845-gpi-dma"; Solution 2: I could stray from the "soc-specific compat", "fallback compat" and just have "qcom,sdm845-gpi-dma" for every SoC. Solution 3: I found the original mailing list archive for this driver: https://lore.kernel.org/linux-arm-msm/20200824084712.2526079-1-vkoul@kernel.org/ https://lore.kernel.org/linux-arm-msm/20200918062955.2095156-1-vkoul@kernel.org/ It seems like the author originally handled the ee_offset as a dt property and removed it. It was removed because it was a Qualcomm-specific property. One option would be to bring this back against the author's wishes (or ask the author about it, since they are a recipient). Solution 4: You mentioned there being an xPU3 block here: https://lore.kernel.org/linux-arm-msm/e3bfa28a-ecbc-7a57-a996-042650043514@linaro.org/ Maybe it's fine to have qcom,gpi-dma-v3? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback 2022-09-23 22:20 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback Richard Acayan @ 2022-09-26 23:12 ` Rob Herring 2022-09-27 1:53 ` Richard Acayan 0 siblings, 1 reply; 12+ messages in thread From: Rob Herring @ 2022-09-26 23:12 UTC (permalink / raw) To: Richard Acayan Cc: Krzysztof Kozlowski, linux-arm-msm, Andy Gross, Bjorn Andersson, Konrad Dybcio, Vinod Koul, dmaengine, devicetree On Fri, Sep 23, 2022 at 06:20:28PM -0400, Richard Acayan wrote: > > On 23/09/2022 23:09, Richard Acayan wrote: > > > The drivers are transitioning from matching against lists of specific > > > compatible strings to matching against smaller lists of more generic > > > compatible strings. Add a fallback compatible string in the schema to > > > support this change. > > > > Thanks for the patch. I wished we discussed it a bit more. :) > > Ah, sorry for not replying to your original suggestion. I didn't see the > opportunity for discussion as this new series wasn't that hard to come up > with. > > > qcom,gpi-dma does not look like specific enough to be correct fallback, > > at least not for all of the devices. I propose either a IP block version > > (which is tricky without access to documentation) or just one of the SoC > > IP blocks. > > Solution 1: > > Yes, I could use something like qcom,sdm845-gpi-dma. It would be weird to > see the compatible strings for that, though: Why is it weird? That's how 'compatible' works. You are saying a new implementation is compatible with an older implementation. > compatible = "qcom,sdm670-gpi-dma", "qcom,sdm845-gpi-dma"; > > // This would need to be valid in dt schema, suggesting solution 2 > compatible = "qcom,sdm845-gpi-dma"; > // This just doesn't make sense > compatible = "qcom,sdm845-gpi-dma", "qcom,sdm845-gpi-dma"; Is your question how to get the first one to work, but not the second one? You need 'oneOf' with at least an entry for each case with different number of compatible strings (1 and 2 entries). There are lot's of examples in the tree. > > compatible = "qcom,sm8150-gpi-dma", "qcom,sdm845-gpi-dma"; > > compatible = "qcom,sm8250-gpi-dma", "qcom,sdm845-gpi-dma"; > > Solution 2: > > I could stray from the "soc-specific compat", "fallback compat" and just > have "qcom,sdm845-gpi-dma" for every SoC. No. > Solution 3: > > I found the original mailing list archive for this driver: > > https://lore.kernel.org/linux-arm-msm/20200824084712.2526079-1-vkoul@kernel.org/ > https://lore.kernel.org/linux-arm-msm/20200918062955.2095156-1-vkoul@kernel.org/ > > It seems like the author originally handled the ee_offset as a dt property > and removed it. It was removed because it was a Qualcomm-specific property. > One option would be to bring this back against the author's wishes (or ask > the author about it, since they are a recipient). No. > > Solution 4: > > You mentioned there being an xPU3 block here: > > https://lore.kernel.org/linux-arm-msm/e3bfa28a-ecbc-7a57-a996-042650043514@linaro.org/ > > Maybe it's fine to have qcom,gpi-dma-v3? I don't like made up version numbers. QCom does or did have very specific version numbers, but in the end they it tended to be 1 or maybe 2 SoCs per version. So not really beneficial. Rob ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback 2022-09-26 23:12 ` Rob Herring @ 2022-09-27 1:53 ` Richard Acayan 2022-09-28 7:57 ` Krzysztof Kozlowski 0 siblings, 1 reply; 12+ messages in thread From: Richard Acayan @ 2022-09-27 1:53 UTC (permalink / raw) To: robh Cc: Krzysztof Kozlowski, linux-arm-msm, Andy Gross, Bjorn Andersson, Konrad Dybcio, Vinod Koul, dmaengine, devicetree > On Fri, Sep 23, 2022 at 06:20:28PM -0400, Richard Acayan wrote: > > > On 23/09/2022 23:09, Richard Acayan wrote: > > > > The drivers are transitioning from matching against lists of specific > > > > compatible strings to matching against smaller lists of more generic > > > > compatible strings. Add a fallback compatible string in the schema to > > > > support this change. > > > > > > Thanks for the patch. I wished we discussed it a bit more. :) > > > > Ah, sorry for not replying to your original suggestion. I didn't see the > > opportunity for discussion as this new series wasn't that hard to come up > > with. > > > > > qcom,gpi-dma does not look like specific enough to be correct fallback, > > > at least not for all of the devices. I propose either a IP block version > > > (which is tricky without access to documentation) or just one of the SoC > > > IP blocks. > > > > Solution 1: > > > > Yes, I could use something like qcom,sdm845-gpi-dma. It would be weird to > > see the compatible strings for that, though: > > Why is it weird? That's how 'compatible' works. You are saying a new > implementation is compatible with an older implementation. Oh, I didn't think of it like that. I found it weird how I need to specify both sm8150 and sdm845 in the same dts, but now it makes sense. I guess I thought fallback needed to be generic, and didn't think it could just specify an older version of the hardware. > > > > compatible = "qcom,sdm670-gpi-dma", "qcom,sdm845-gpi-dma"; > > > > > // This would need to be valid in dt schema, suggesting solution 2 > > compatible = "qcom,sdm845-gpi-dma"; > > // This just doesn't make sense > > compatible = "qcom,sdm845-gpi-dma", "qcom,sdm845-gpi-dma"; > > Is your question how to get the first one to work, but not the second > one? You need 'oneOf' with at least an entry for each case with > different number of compatible strings (1 and 2 entries). There are > lot's of examples in the tree. No, I thought it would be tempting to use the first one for other device trees, but you maintainers know not to allow that so it doesn't matter as much. > > > > > compatible = "qcom,sm8150-gpi-dma", "qcom,sdm845-gpi-dma"; > > > > compatible = "qcom,sm8250-gpi-dma", "qcom,sdm845-gpi-dma"; > > > > Solution 2: > > > > I could stray from the "soc-specific compat", "fallback compat" and just > > have "qcom,sdm845-gpi-dma" for every SoC. > > No. > > > Solution 3: > > > > I found the original mailing list archive for this driver: > > > > https://lore.kernel.org/linux-arm-msm/20200824084712.2526079-1-vkoul@kernel.org/ > > https://lore.kernel.org/linux-arm-msm/20200918062955.2095156-1-vkoul@kernel.org/ > > > > It seems like the author originally handled the ee_offset as a dt property > > and removed it. It was removed because it was a Qualcomm-specific property. > > One option would be to bring this back against the author's wishes (or ask > > the author about it, since they are a recipient). > > No. Ah, simple rejections with one word. You don't have to elaborate, I see why these aren't a good fit. > > > > > Solution 4: > > > > You mentioned there being an xPU3 block here: > > > > https://lore.kernel.org/linux-arm-msm/e3bfa28a-ecbc-7a57-a996-042650043514@linaro.org/ > > > > Maybe it's fine to have qcom,gpi-dma-v3? > > I don't like made up version numbers. QCom does or did have very > specific version numbers, but in the end they it tended to be 1 or maybe > 2 SoCs per version. So not really beneficial. I got this from using the number in xPU3, because I thought xPU3 was the specific hardware that had ee_offset = 0. This might not be what Krzysztof meant and perhaps I just wasn't reading properly. Thank you for your response. You cleared up a lot of thoughts that I had about the presented solution. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback 2022-09-27 1:53 ` Richard Acayan @ 2022-09-28 7:57 ` Krzysztof Kozlowski 0 siblings, 0 replies; 12+ messages in thread From: Krzysztof Kozlowski @ 2022-09-28 7:57 UTC (permalink / raw) To: Richard Acayan, robh Cc: Krzysztof Kozlowski, linux-arm-msm, Andy Gross, Bjorn Andersson, Konrad Dybcio, Vinod Koul, dmaengine, devicetree On 27/09/2022 03:53, Richard Acayan wrote: >> On Fri, Sep 23, 2022 at 06:20:28PM -0400, Richard Acayan wrote: >>>> On 23/09/2022 23:09, Richard Acayan wrote: >>>>> The drivers are transitioning from matching against lists of specific >>>>> compatible strings to matching against smaller lists of more generic >>>>> compatible strings. Add a fallback compatible string in the schema to >>>>> support this change. >>>> >>>> Thanks for the patch. I wished we discussed it a bit more. :) >>> >>> Ah, sorry for not replying to your original suggestion. I didn't see the >>> opportunity for discussion as this new series wasn't that hard to come up >>> with. >>> >>>> qcom,gpi-dma does not look like specific enough to be correct fallback, >>>> at least not for all of the devices. I propose either a IP block version >>>> (which is tricky without access to documentation) or just one of the SoC >>>> IP blocks. >>> >>> Solution 1: >>> >>> Yes, I could use something like qcom,sdm845-gpi-dma. It would be weird to >>> see the compatible strings for that, though: >> >> Why is it weird? That's how 'compatible' works. You are saying a new >> implementation is compatible with an older implementation. > > Oh, I didn't think of it like that. I found it weird how I need to specify both > sm8150 and sdm845 in the same dts, but now it makes sense. I guess I thought > fallback needed to be generic, and didn't think it could just specify an older > version of the hardware. It's all over the tree. One big user of such pattern is iMX. > >> >> >>> compatible = "qcom,sdm670-gpi-dma", "qcom,sdm845-gpi-dma"; >>> >> >>> // This would need to be valid in dt schema, suggesting solution 2 >>> compatible = "qcom,sdm845-gpi-dma"; >>> // This just doesn't make sense >>> compatible = "qcom,sdm845-gpi-dma", "qcom,sdm845-gpi-dma"; >> >> Is your question how to get the first one to work, but not the second >> one? You need 'oneOf' with at least an entry for each case with >> different number of compatible strings (1 and 2 entries). There are >> lot's of examples in the tree. > > No, I thought it would be tempting to use the first one for other device trees, > but you maintainers know not to allow that so it doesn't matter as much. > >> >>> >>> compatible = "qcom,sm8150-gpi-dma", "qcom,sdm845-gpi-dma"; >>> >>> compatible = "qcom,sm8250-gpi-dma", "qcom,sdm845-gpi-dma"; >>> >>> Solution 2: >>> >>> I could stray from the "soc-specific compat", "fallback compat" and just >>> have "qcom,sdm845-gpi-dma" for every SoC. >> >> No. >> >>> Solution 3: >>> >>> I found the original mailing list archive for this driver: >>> >>> https://lore.kernel.org/linux-arm-msm/20200824084712.2526079-1-vkoul@kernel.org/ >>> https://lore.kernel.org/linux-arm-msm/20200918062955.2095156-1-vkoul@kernel.org/ >>> >>> It seems like the author originally handled the ee_offset as a dt property >>> and removed it. It was removed because it was a Qualcomm-specific property. >>> One option would be to bring this back against the author's wishes (or ask >>> the author about it, since they are a recipient). >> >> No. > > Ah, simple rejections with one word. You don't have to elaborate, I see why > these aren't a good fit. > >> >>> >>> Solution 4: >>> >>> You mentioned there being an xPU3 block here: >>> >>> https://lore.kernel.org/linux-arm-msm/e3bfa28a-ecbc-7a57-a996-042650043514@linaro.org/ >>> >>> Maybe it's fine to have qcom,gpi-dma-v3? >> >> I don't like made up version numbers. QCom does or did have very >> specific version numbers, but in the end they it tended to be 1 or maybe >> 2 SoCs per version. So not really beneficial. > > I got this from using the number in xPU3, because I thought xPU3 was the > specific hardware that had ee_offset = 0. This might not be what Krzysztof meant > and perhaps I just wasn't reading properly. We could go here with the versions, because indeed Qualcomm versions them a lot. But as Rob pointed, sometimes these versions change with every release of the SoC, so then easier for everyone is to use the SoC number. Mapping to versions can be always mentioned in commit msg. That's even more confusing with few IP blocks which in Qualcomm downstream sources have a version (e.g. bwmon v4, bwmon v5) but it's nowhere to be found in documentation of the blocks. Then another point are people without access to Qualcomm documentation. They cannot verify the version numbering, which one is where. Even when I had access to Samsung SoC documentation (kind of extract of it, not the one for hardware engineers) the versions were pretty often not explained and even we could not figure out which block is what. So based on that, just easier/better/readable is to use SoC numbers. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible 2022-09-23 21:26 ` Krzysztof Kozlowski 2022-09-23 22:20 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback Richard Acayan @ 2022-09-29 7:39 ` Vinod Koul 2022-09-29 7:47 ` Krzysztof Kozlowski 1 sibling, 1 reply; 12+ messages in thread From: Vinod Koul @ 2022-09-29 7:39 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Richard Acayan, linux-arm-msm, Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, dmaengine, devicetree On 23-09-22, 23:26, Krzysztof Kozlowski wrote: > On 23/09/2022 23:09, Richard Acayan wrote: > > The drivers are transitioning from matching against lists of specific > > compatible strings to matching against smaller lists of more generic > > compatible strings. Add a fallback compatible string in the schema to > > support this change. > > Thanks for the patch. I wished we discussed it a bit more. :) > qcom,gpi-dma does not look like specific enough to be correct fallback, > at least not for all of the devices. I propose either a IP block version > (which is tricky without access to documentation) or just one of the SoC You should have access :-) > IP blocks. So knowing this IP we have two versions, one was initial sdm845 that should be the base compatible. Then second should be sm8350 which was the version we need ee_offset to be added, so these two can be the base ones for future... My 0.02 Thanks -- ~Vinod ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible 2022-09-29 7:39 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible Vinod Koul @ 2022-09-29 7:47 ` Krzysztof Kozlowski 0 siblings, 0 replies; 12+ messages in thread From: Krzysztof Kozlowski @ 2022-09-29 7:47 UTC (permalink / raw) To: Vinod Koul Cc: Richard Acayan, linux-arm-msm, Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, dmaengine, devicetree On 29/09/2022 09:39, Vinod Koul wrote: > On 23-09-22, 23:26, Krzysztof Kozlowski wrote: >> On 23/09/2022 23:09, Richard Acayan wrote: >>> The drivers are transitioning from matching against lists of specific >>> compatible strings to matching against smaller lists of more generic >>> compatible strings. Add a fallback compatible string in the schema to >>> support this change. >> >> Thanks for the patch. I wished we discussed it a bit more. :) >> qcom,gpi-dma does not look like specific enough to be correct fallback, >> at least not for all of the devices. I propose either a IP block version >> (which is tricky without access to documentation) or just one of the SoC > > You should have access :-) But Richard and many other community members do not... > >> IP blocks. > > So knowing this IP we have two versions, one was initial sdm845 that > should be the base compatible. Then second should be sm8350 which was > the version we need ee_offset to be added, so these two can be the base > ones for future... > > My 0.02 Or just use SoC versions, not IP block versions :) Best regards, Krzysztof ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 2/4] dt-bindings: dma: qcom: gpi: add compatible for sdm670 2022-09-23 21:09 [PATCH v2 0/4] SDM670 GPI DMA support Richard Acayan 2022-09-23 21:09 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible Richard Acayan @ 2022-09-23 21:09 ` Richard Acayan 2022-09-23 21:09 ` [PATCH v2 3/4] arm64: dts: qcom: add gpi-dma fallback compatible Richard Acayan 2022-09-23 21:09 ` [PATCH v2 4/4] dmaengine: qcom: gpi: drop redundant of_device_id entries Richard Acayan 3 siblings, 0 replies; 12+ messages in thread From: Richard Acayan @ 2022-09-23 21:09 UTC (permalink / raw) To: linux-arm-msm Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Vinod Koul, Rob Herring, Krzysztof Kozlowski, dmaengine, devicetree, Richard Acayan The Snapdragon 670 uses GPI DMA for its GENI interface. Add a compatible string for it in the documentation. Signed-off-by: Richard Acayan <mailingradian@gmail.com> --- Documentation/devicetree/bindings/dma/qcom,gpi.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml index 25bc1a6de794..6be3c99a73ec 100644 --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -20,6 +20,7 @@ properties: compatible: - enum: - qcom,sc7280-gpi-dma + - qcom,sdm670-gpi-dma - qcom,sdm845-gpi-dma - qcom,sm6350-gpi-dma - qcom,sm8150-gpi-dma -- 2.37.3 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v2 3/4] arm64: dts: qcom: add gpi-dma fallback compatible 2022-09-23 21:09 [PATCH v2 0/4] SDM670 GPI DMA support Richard Acayan 2022-09-23 21:09 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible Richard Acayan 2022-09-23 21:09 ` [PATCH v2 2/4] dt-bindings: dma: qcom: gpi: add compatible for sdm670 Richard Acayan @ 2022-09-23 21:09 ` Richard Acayan 2022-09-23 21:09 ` [PATCH v2 4/4] dmaengine: qcom: gpi: drop redundant of_device_id entries Richard Acayan 3 siblings, 0 replies; 12+ messages in thread From: Richard Acayan @ 2022-09-23 21:09 UTC (permalink / raw) To: linux-arm-msm Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Vinod Koul, Rob Herring, Krzysztof Kozlowski, dmaengine, devicetree, Richard Acayan The dt schema for gpi-dma has been updated with a new fallback compatible string. Add the compatible strings to existing device trees. Signed-off-by: Richard Acayan <mailingradian@gmail.com> --- arch/arm64/boot/dts/qcom/sc7280.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sm6350.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sm8150.dtsi | 6 +++--- arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 +++--- arch/arm64/boot/dts/qcom/sm8350.dtsi | 6 +++--- arch/arm64/boot/dts/qcom/sm8450.dtsi | 6 +++--- 7 files changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi index 8d807b7bf66a..4f8728958898 100644 --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi @@ -919,7 +919,7 @@ opp-384000000 { gpi_dma0: dma-controller@900000 { #dma-cells = <3>; - compatible = "qcom,sc7280-gpi-dma"; + compatible = "qcom,sc7280-gpi-dma", "qcom,gpi-dma"; reg = <0 0x00900000 0 0x60000>; interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>, @@ -1418,7 +1418,7 @@ uart7: serial@99c000 { gpi_dma1: dma-controller@a00000 { #dma-cells = <3>; - compatible = "qcom,sc7280-gpi-dma"; + compatible = "qcom,sc7280-gpi-dma", "qcom,gpi-dma"; reg = <0 0x00a00000 0 0x60000>; interrupts = <GIC_SPI 279 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 280 IRQ_TYPE_LEVEL_HIGH>, diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi index d761da47220d..741b4f200bd0 100644 --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi @@ -1151,7 +1151,7 @@ opp-128000000 { gpi_dma0: dma-controller@800000 { #dma-cells = <3>; - compatible = "qcom,sdm845-gpi-dma"; + compatible = "qcom,sdm845-gpi-dma", "qcom,gpi-dma"; reg = <0 0x00800000 0 0x60000>; interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>, @@ -1638,7 +1638,7 @@ uart7: serial@89c000 { gpi_dma1: dma-controller@0xa00000 { #dma-cells = <3>; - compatible = "qcom,sdm845-gpi-dma"; + compatible = "qcom,sdm845-gpi-dma", "qcom,gpi-dma"; reg = <0 0x00a00000 0 0x60000>; interrupts = <GIC_SPI 279 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 280 IRQ_TYPE_LEVEL_HIGH>, diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi index c39de7d3ace0..346775610ef9 100644 --- a/arch/arm64/boot/dts/qcom/sm6350.dtsi +++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi @@ -521,7 +521,7 @@ opp-384000000 { }; gpi_dma0: dma-controller@800000 { - compatible = "qcom,sm6350-gpi-dma"; + compatible = "qcom,sm6350-gpi-dma", "qcom,gpi-dma"; reg = <0 0x00800000 0 0x60000>; interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>, @@ -594,7 +594,7 @@ i2c2: i2c@888000 { }; gpi_dma1: dma-controller@900000 { - compatible = "qcom,sm6350-gpi-dma"; + compatible = "qcom,sm6350-gpi-dma", "qcom,gpi-dma"; reg = <0 0x00900000 0 0x60000>; interrupts = <GIC_SPI 645 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 646 IRQ_TYPE_LEVEL_HIGH>, diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi index cef8c4f4f0ff..0eea0e6f6611 100644 --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi @@ -887,7 +887,7 @@ gcc: clock-controller@100000 { }; gpi_dma0: dma-controller@800000 { - compatible = "qcom,sm8150-gpi-dma"; + compatible = "qcom,sm8150-gpi-dma", "qcom,gpi-dma"; reg = <0 0x800000 0 0x60000>; interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>, @@ -1222,7 +1222,7 @@ spi7: spi@89c000 { }; gpi_dma1: dma-controller@a00000 { - compatible = "qcom,sm8150-gpi-dma"; + compatible = "qcom,sm8150-gpi-dma", "qcom,gpi-dma"; reg = <0 0xa00000 0 0x60000>; interrupts = <GIC_SPI 279 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 280 IRQ_TYPE_LEVEL_HIGH>, @@ -1471,7 +1471,7 @@ spi16: spi@a94000 { }; gpi_dma2: dma-controller@c00000 { - compatible = "qcom,sm8150-gpi-dma"; + compatible = "qcom,sm8150-gpi-dma", "qcom,gpi-dma"; reg = <0 0xc00000 0 0x60000>; interrupts = <GIC_SPI 588 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 589 IRQ_TYPE_LEVEL_HIGH>, diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi index a5b62cadb129..8b42f7cf289b 100644 --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi @@ -936,7 +936,7 @@ rng: rng@793000 { }; gpi_dma2: dma-controller@800000 { - compatible = "qcom,sm8250-gpi-dma"; + compatible = "qcom,sm8250-gpi-dma", "qcom,gpi-dma"; reg = <0 0x00800000 0 0x70000>; interrupts = <GIC_SPI 588 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 589 IRQ_TYPE_LEVEL_HIGH>, @@ -1187,7 +1187,7 @@ spi19: spi@894000 { }; gpi_dma0: dma-controller@900000 { - compatible = "qcom,sm8250-gpi-dma"; + compatible = "qcom,sm8250-gpi-dma", "qcom,gpi-dma"; reg = <0 0x00900000 0 0x70000>; interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>, @@ -1505,7 +1505,7 @@ spi7: spi@99c000 { }; gpi_dma1: dma-controller@a00000 { - compatible = "qcom,sm8250-gpi-dma"; + compatible = "qcom,sm8250-gpi-dma", "qcom,gpi-dma"; reg = <0 0x00a00000 0 0x70000>; interrupts = <GIC_SPI 279 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 280 IRQ_TYPE_LEVEL_HIGH>, diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi index cd5503642a23..82d97e5607ad 100644 --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi @@ -678,7 +678,7 @@ ipcc: mailbox@408000 { }; gpi_dma2: dma-controller@800000 { - compatible = "qcom,sm8350-gpi-dma"; + compatible = "qcom,sm8350-gpi-dma", "qcom,gpi-dma"; reg = <0 0x00800000 0 0x60000>; interrupts = <GIC_SPI 588 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 589 IRQ_TYPE_LEVEL_HIGH>, @@ -904,7 +904,7 @@ spi19: spi@894000 { }; gpi_dma0: dma-controller@900000 { - compatible = "qcom,sm8350-gpi-dma"; + compatible = "qcom,sm8350-gpi-dma", "qcom,gpi-dma"; reg = <0 0x09800000 0 0x60000>; interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>, @@ -1209,7 +1209,7 @@ spi7: spi@99c000 { }; gpi_dma1: dma-controller@a00000 { - compatible = "qcom,sm8350-gpi-dma"; + compatible = "qcom,sm8350-gpi-dma", "qcom,gpi-dma"; reg = <0 0x00a00000 0 0x60000>; interrupts = <GIC_SPI 279 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 280 IRQ_TYPE_LEVEL_HIGH>, diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi index d32f08df743d..10f1655a4626 100644 --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi @@ -730,7 +730,7 @@ gcc: clock-controller@100000 { }; gpi_dma2: dma-controller@800000 { - compatible = "qcom,sm8450-gpi-dma"; + compatible = "qcom,sm8450-gpi-dma", "qcom,gpi-dma"; #dma-cells = <3>; reg = <0 0x800000 0 0x60000>; interrupts = <GIC_SPI 588 IRQ_TYPE_LEVEL_HIGH>, @@ -1058,7 +1058,7 @@ spi21: spi@898000 { }; gpi_dma0: dma-controller@900000 { - compatible = "qcom,sm8450-gpi-dma"; + compatible = "qcom,sm8450-gpi-dma", "qcom,gpi-dma"; #dma-cells = <3>; reg = <0 0x900000 0 0x60000>; interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>, @@ -1394,7 +1394,7 @@ uart7: serial@99c000 { }; gpi_dma1: dma-controller@a00000 { - compatible = "qcom,sm8450-gpi-dma"; + compatible = "qcom,sm8450-gpi-dma", "qcom,gpi-dma"; #dma-cells = <3>; reg = <0 0xa00000 0 0x60000>; interrupts = <GIC_SPI 279 IRQ_TYPE_LEVEL_HIGH>, -- 2.37.3 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v2 4/4] dmaengine: qcom: gpi: drop redundant of_device_id entries 2022-09-23 21:09 [PATCH v2 0/4] SDM670 GPI DMA support Richard Acayan ` (2 preceding siblings ...) 2022-09-23 21:09 ` [PATCH v2 3/4] arm64: dts: qcom: add gpi-dma fallback compatible Richard Acayan @ 2022-09-23 21:09 ` Richard Acayan 3 siblings, 0 replies; 12+ messages in thread From: Richard Acayan @ 2022-09-23 21:09 UTC (permalink / raw) To: linux-arm-msm Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Vinod Koul, Rob Herring, Krzysztof Kozlowski, dmaengine, devicetree, Richard Acayan The drivers are transitioning from matching against lists of specific compatible strings to matching against smaller lists of more generic compatible strings. Continue the transition in the GPI DMA driver. Signed-off-by: Richard Acayan <mailingradian@gmail.com> --- drivers/dma/qcom/gpi.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c index 89839864b4ec..f38c3d6ef11e 100644 --- a/drivers/dma/qcom/gpi.c +++ b/drivers/dma/qcom/gpi.c @@ -2286,11 +2286,9 @@ static int gpi_probe(struct platform_device *pdev) } static const struct of_device_id gpi_of_match[] = { + { .compatible = "qcom,gpi-dma", .data = (void *)0x0 }, { .compatible = "qcom,sc7280-gpi-dma", .data = (void *)0x10000 }, - { .compatible = "qcom,sdm845-gpi-dma", .data = (void *)0x0 }, { .compatible = "qcom,sm6350-gpi-dma", .data = (void *)0x10000 }, - { .compatible = "qcom,sm8150-gpi-dma", .data = (void *)0x0 }, - { .compatible = "qcom,sm8250-gpi-dma", .data = (void *)0x0 }, { .compatible = "qcom,sm8350-gpi-dma", .data = (void *)0x10000 }, { .compatible = "qcom,sm8450-gpi-dma", .data = (void *)0x10000 }, { }, -- 2.37.3 ^ permalink raw reply related [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-09-29 7:47 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-23 21:09 [PATCH v2 0/4] SDM670 GPI DMA support Richard Acayan 2022-09-23 21:09 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible Richard Acayan 2022-09-23 21:26 ` Krzysztof Kozlowski 2022-09-23 22:20 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback Richard Acayan 2022-09-26 23:12 ` Rob Herring 2022-09-27 1:53 ` Richard Acayan 2022-09-28 7:57 ` Krzysztof Kozlowski 2022-09-29 7:39 ` [PATCH v2 1/4] dt-bindings: dma: qcom: gpi: add fallback compatible Vinod Koul 2022-09-29 7:47 ` Krzysztof Kozlowski 2022-09-23 21:09 ` [PATCH v2 2/4] dt-bindings: dma: qcom: gpi: add compatible for sdm670 Richard Acayan 2022-09-23 21:09 ` [PATCH v2 3/4] arm64: dts: qcom: add gpi-dma fallback compatible Richard Acayan 2022-09-23 21:09 ` [PATCH v2 4/4] dmaengine: qcom: gpi: drop redundant of_device_id entries Richard Acayan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).