| Message ID | 20230113201038.267449-1-bhupesh.sharma@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | dt-bindings: qcom: geni-se: Fix '#address-cells' & '#size-cells' related dt-binding error | expand |
On 13/01/2023 21:10, Bhupesh Sharma wrote: > Fix the following '#address-cells' & '#size-cells' related > dt-binding error: > > $ make dtbs_check > > From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml > arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000: > #address-cells:0:0: 2 was expected > From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml Don't we want rather to unify the soc address range? Best regards, Krzysztof
On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 13/01/2023 21:10, Bhupesh Sharma wrote: > > Fix the following '#address-cells' & '#size-cells' related > > dt-binding error: > > > > $ make dtbs_check > > > > From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml > > arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000: > > #address-cells:0:0: 2 was expected > > From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml > > Don't we want rather to unify the soc address range? Well, the assumption in the original dt-bindings was that every reg variable is 4 * u32 wide (as most new qcom SoCs set #address- and #size-cells to <2>). However, that is not the case for all of the SoCs. So, ideally we shouldn't set the "#address-cells" and "#size-cells": as const: 2 in the bindings. See as an example: https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-device.yaml Thanks.
On 15/01/2023 22:33, Bhupesh Sharma wrote: > On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: >> >> On 13/01/2023 21:10, Bhupesh Sharma wrote: >>> Fix the following '#address-cells' & '#size-cells' related >>> dt-binding error: >>> >>> $ make dtbs_check >>> >>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >>> arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000: >>> #address-cells:0:0: 2 was expected >>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >> >> Don't we want rather to unify the soc address range? > > Well, the assumption in the original dt-bindings was that every reg > variable is 4 * u32 wide (as most new qcom SoCs set #address- and > #size-cells to <2>). However, that is not the case for all of the > SoCs. Hm, which device of that SoC cannot be used with address/size cells 2? > > So, ideally we shouldn't set the "#address-cells" and "#size-cells": > as const: 2 in the bindings. > > See as an example: > https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-device.yaml How USB device - so entirely different device, not MMIO! - is related here? Best regards, Krzysztof
On 16.01.2023 16:43, Bhupesh Sharma wrote: > On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: >> >> On 15/01/2023 22:33, Bhupesh Sharma wrote: >>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski >>> <krzysztof.kozlowski@linaro.org> wrote: >>>> >>>> On 13/01/2023 21:10, Bhupesh Sharma wrote: >>>>> Fix the following '#address-cells' & '#size-cells' related >>>>> dt-binding error: >>>>> >>>>> $ make dtbs_check >>>>> >>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >>>>> arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000: >>>>> #address-cells:0:0: 2 was expected >>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >>>> >>>> Don't we want rather to unify the soc address range? >>> >>> Well, the assumption in the original dt-bindings was that every reg >>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and >>> #size-cells to <2>). However, that is not the case for all of the >>> SoCs. >> >> Hm, which device of that SoC cannot be used with address/size cells 2? > > As noted in the git log already the geniqup on sm6115 / sm4250 cannot > be used with address/size cells 2 (See: > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795) SM6115 (and pretty much every other arm64 msm platform newer than 8916) should be using addr/size-cells = 2 along with (dma-)ranges of 36 bit, as that's what their smmus use and otherwise some addresses may get cut off in translation, or so the story went with 845 N years ago.. We can either pursue this patch or I can submit the 2-cell-ification if you don't plan on adding more nodes shortly Konrad > >>> So, ideally we shouldn't set the "#address-cells" and "#size-cells": >>> as const: 2 in the bindings. >>> >>> See as an example: >>> https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-device.yaml >> >> >> How USB device - so entirely different device, not MMIO! - is related here? >> >> Best regards, >> Krzysztof >>
On 16.01.2023 17:02, Bhupesh Sharma wrote: > > On 1/16/23 9:24 PM, Konrad Dybcio wrote: >> >> >> On 16.01.2023 16:43, Bhupesh Sharma wrote: >>> On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski >>> <krzysztof.kozlowski@linaro.org> wrote: >>>> >>>> On 15/01/2023 22:33, Bhupesh Sharma wrote: >>>>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski >>>>> <krzysztof.kozlowski@linaro.org> wrote: >>>>>> >>>>>> On 13/01/2023 21:10, Bhupesh Sharma wrote: >>>>>>> Fix the following '#address-cells' & '#size-cells' related >>>>>>> dt-binding error: >>>>>>> >>>>>>> $ make dtbs_check >>>>>>> >>>>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >>>>>>> arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000: >>>>>>> #address-cells:0:0: 2 was expected >>>>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >>>>>> >>>>>> Don't we want rather to unify the soc address range? >>>>> >>>>> Well, the assumption in the original dt-bindings was that every reg >>>>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and >>>>> #size-cells to <2>). However, that is not the case for all of the >>>>> SoCs. >>>> >>>> Hm, which device of that SoC cannot be used with address/size cells 2? >>> >>> As noted in the git log already the geniqup on sm6115 / sm4250 cannot >>> be used with address/size cells 2 (See: >>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795) >> SM6115 (and pretty much every other arm64 msm platform newer than 8916) >> should be using addr/size-cells = 2 along with (dma-)ranges of 36 bit, as >> that's what their smmus use and otherwise some addresses may get cut off >> in translation, or so the story went with 845 N years ago.. We can either >> pursue this patch or I can submit the 2-cell-ification if you don't plan on >> adding more nodes shortly > > > Have you tested this combination on SM6115 like SoCs with various IPs? I have tried a few experiments in the past and not all IPs work well with 36-bit DMA ranges (atleast not on the boards I have). Can you list any specific examples? I've been using it for quite some time now and I see nothing wrong.. > > So, I think it might lead to more breakage (unless we are sure of a well-tested fix). A simpler patch to fix the dt-bindings looks more useful IMO. I'm not saying no, you just have to convince Krzysztof :D Konrad > > Thanks, > Bhupesh
On 16.01.2023 17:18, bhupesh.sharma@linaro.org wrote: > > On 1/16/23 9:35 PM, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: >> >> >> On 16.01.2023 17:02, Bhupesh Sharma wrote: >> > >> > On 1/16/23 9:24 PM, Konrad Dybcio wrote: >> >> >> >> >> >> On 16.01.2023 16:43, Bhupesh Sharma wrote: >> >>> On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski >> >>> <krzysztof.kozlowski@linaro.org> wrote: >> >>>> >> >>>> On 15/01/2023 22:33, Bhupesh Sharma wrote: >> >>>>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski >> >>>>> <krzysztof.kozlowski@linaro.org> wrote: >> >>>>>> >> >>>>>> On 13/01/2023 21:10, Bhupesh Sharma wrote: >> >>>>>>> Fix the following '#address-cells' & '#size-cells' related >> >>>>>>> dt-binding error: >> >>>>>>> >> >>>>>>> $ make dtbs_check >> >>>>>>> >> >>>>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >> >>>>>>> arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000: >> >>>>>>> #address-cells:0:0: 2 was expected >> >>>>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >> >>>>>> >> >>>>>> Don't we want rather to unify the soc address range? >> >>>>> >> >>>>> Well, the assumption in the original dt-bindings was that every reg >> >>>>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and >> >>>>> #size-cells to <2>). However, that is not the case for all of the >> >>>>> SoCs. >> >>>> >> >>>> Hm, which device of that SoC cannot be used with address/size cells 2? >> >>> >> >>> As noted in the git log already the geniqup on sm6115 / sm4250 cannot >> >>> be used with address/size cells 2 (See: >> >>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795) >> >> SM6115 (and pretty much every other arm64 msm platform newer than 8916) >> >> should be using addr/size-cells = 2 along with (dma-)ranges of 36 bit, as >> >> that's what their smmus use and otherwise some addresses may get cut off >> >> in translation, or so the story went with 845 N years ago.. We can either >> >> pursue this patch or I can submit the 2-cell-ification if you don't plan on >> >> adding more nodes shortly >> > >> > >> > Have you tested this combination on SM6115 like SoCs with various IPs? I have tried a few experiments in the past and not all IPs work well with 36-bit DMA ranges (atleast not on the boards I have). >> Can you list any specific examples? I've been using it for >> quite some time now and I see nothing wrong.. > > I remember seeing some issues with SDHC controller booting (uSD card use case) with sm6115, but I cannot find the appropriate dmesg right now. FWIW it works completely fine for me, in fact I'm booting from uSD most of the time. Konrad > >> > >> > So, I think it might lead to more breakage (unless we are sure of a well-tested fix). A simpler patch to fix the dt-bindings looks more useful IMO. >> I'm not saying no, you just have to convince Krzysztof :D > > :) > > Thanks, > Bhupesh
On 16/01/2023 16:43, Bhupesh Sharma wrote: > On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: >> >> On 15/01/2023 22:33, Bhupesh Sharma wrote: >>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski >>> <krzysztof.kozlowski@linaro.org> wrote: >>>> >>>> On 13/01/2023 21:10, Bhupesh Sharma wrote: >>>>> Fix the following '#address-cells' & '#size-cells' related >>>>> dt-binding error: >>>>> >>>>> $ make dtbs_check >>>>> >>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >>>>> arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000: >>>>> #address-cells:0:0: 2 was expected >>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >>>> >>>> Don't we want rather to unify the soc address range? >>> >>> Well, the assumption in the original dt-bindings was that every reg >>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and >>> #size-cells to <2>). However, that is not the case for all of the >>> SoCs. >> >> Hm, which device of that SoC cannot be used with address/size cells 2? > > As noted in the git log already the geniqup on sm6115 / sm4250 cannot > be used with address/size cells 2 (See: > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795) That's not relevant and not answering to my question. Address/size cells affect children, so not geniqup. address-cells 2 means you have everywhere 64 bit addresses, so which devices cannot work with such DTS? If you claim that geniqup and its children has some troubles - please point what troubles. The DTS and existing address/size cells have nothing to do with it. Best regards, Krzysztof
On Mon, Jan 16, 2023 at 08:10:40PM +0100, Krzysztof Kozlowski wrote: > On 16/01/2023 16:43, Bhupesh Sharma wrote: > > On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski > > <krzysztof.kozlowski@linaro.org> wrote: > >> > >> On 15/01/2023 22:33, Bhupesh Sharma wrote: > >>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski > >>> <krzysztof.kozlowski@linaro.org> wrote: > >>>> > >>>> On 13/01/2023 21:10, Bhupesh Sharma wrote: > >>>>> Fix the following '#address-cells' & '#size-cells' related > >>>>> dt-binding error: > >>>>> > >>>>> $ make dtbs_check > >>>>> > >>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml > >>>>> arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000: > >>>>> #address-cells:0:0: 2 was expected > >>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml > >>>> > >>>> Don't we want rather to unify the soc address range? > >>> > >>> Well, the assumption in the original dt-bindings was that every reg > >>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and > >>> #size-cells to <2>). However, that is not the case for all of the > >>> SoCs. > >> > >> Hm, which device of that SoC cannot be used with address/size cells 2? If 1 cell does the job, then it should be allowed. I'd go a step farther and say # of cells should only be as big as needed and that's the address size of the children. > > > > As noted in the git log already the geniqup on sm6115 / sm4250 cannot > > be used with address/size cells 2 (See: > > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795) Why can't they use 2? Is it because you forgot 'dma-ranges' and you want to implicitly limit DMA to 32-bits? Unfortunately 'dma-ranges' is frequently omitted so we treat missing as 1:1 dma-ranges (i.e. empty). > > That's not relevant and not answering to my question. Address/size cells > affect children, so not geniqup. address-cells 2 means you have > everywhere 64 bit addresses, so which devices cannot work with such DTS? > If you claim that geniqup and its children has some troubles - please > point what troubles. The DTS and existing address/size cells have > nothing to do with it. > > Best regards, > Krzysztof >
On Mon, Jan 16, 2023 at 09:13:12PM +0530, Bhupesh Sharma wrote: > On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: > > > > On 15/01/2023 22:33, Bhupesh Sharma wrote: > > > On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski > > > <krzysztof.kozlowski@linaro.org> wrote: > > >> > > >> On 13/01/2023 21:10, Bhupesh Sharma wrote: > > >>> Fix the following '#address-cells' & '#size-cells' related > > >>> dt-binding error: > > >>> > > >>> $ make dtbs_check > > >>> > > >>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml > > >>> arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000: > > >>> #address-cells:0:0: 2 was expected > > >>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml > > >> > > >> Don't we want rather to unify the soc address range? > > > > > > Well, the assumption in the original dt-bindings was that every reg > > > variable is 4 * u32 wide (as most new qcom SoCs set #address- and > > > #size-cells to <2>). However, that is not the case for all of the > > > SoCs. > > > > Hm, which device of that SoC cannot be used with address/size cells 2? > > As noted in the git log already the geniqup on sm6115 / sm4250 cannot > be used with address/size cells 2 (See: > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795) > I'm not able to find the reasoning you're referring to. We do have cells of 2 for these nodes on all other platforms. If there is a specific problem, that can be documented and you can probably use ranges to reduce keep the cells of 1 in the geni wrappers. The reason why we have cells = 2 on most platforms is because the SMMU reports that it's capable of more address bits than the buses will handle. So without cells = 2, we can't describe dma-ranges appropriately and you get page faults due to truncated addresses on the bus when the iommu iova has been picking addresses for you. Regards, Bjorn > > > So, ideally we shouldn't set the "#address-cells" and "#size-cells": > > > as const: 2 in the bindings. > > > > > > See as an example: > > > https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-device.yaml > > > > > > How USB device - so entirely different device, not MMIO! - is related here? > > > > Best regards, > > Krzysztof > >
Hi Bjorn, On 1/19/23 8:53 AM, Bjorn Andersson wrote: > On Mon, Jan 16, 2023 at 09:13:12PM +0530, Bhupesh Sharma wrote: >> On Mon, 16 Jan 2023 at 13:23, Krzysztof Kozlowski >> <krzysztof.kozlowski@linaro.org> wrote: >>> >>> On 15/01/2023 22:33, Bhupesh Sharma wrote: >>>> On Sun, 15 Jan 2023 at 20:57, Krzysztof Kozlowski >>>> <krzysztof.kozlowski@linaro.org> wrote: >>>>> >>>>> On 13/01/2023 21:10, Bhupesh Sharma wrote: >>>>>> Fix the following '#address-cells' & '#size-cells' related >>>>>> dt-binding error: >>>>>> >>>>>> $ make dtbs_check >>>>>> >>>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >>>>>> arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000: >>>>>> #address-cells:0:0: 2 was expected >>>>>> From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml >>>>> >>>>> Don't we want rather to unify the soc address range? >>>> >>>> Well, the assumption in the original dt-bindings was that every reg >>>> variable is 4 * u32 wide (as most new qcom SoCs set #address- and >>>> #size-cells to <2>). However, that is not the case for all of the >>>> SoCs. >>> >>> Hm, which device of that SoC cannot be used with address/size cells 2? >> >> As noted in the git log already the geniqup on sm6115 / sm4250 cannot >> be used with address/size cells 2 (See: >> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/sm6115.dtsi#L795) >> > > I'm not able to find the reasoning you're referring to. We do have cells > of 2 for these nodes on all other platforms. If there is a specific > problem, that can be documented and you can probably use ranges to > reduce keep the cells of 1 in the geni wrappers. > > > The reason why we have cells = 2 on most platforms is because the SMMU > reports that it's capable of more address bits than the buses will > handle. So without cells = 2, we can't describe dma-ranges appropriately > and you get page faults due to truncated addresses on the bus when the > iommu iova has been picking addresses for you. Consolidating the replies to your, Krzysztof's and Rob's observations / suggestions here.. Yes, the original background to the problem was that I observed that for the sm6115 based Qualcomm board with me, if I was using 36-bit DMA configuration with a few IP blocks (like SDHC), I was seeing some issues. But, Konrad observed in [1] that it works fine for me on the sm6115 based Lenovo tab, so I agree to his suggestions and may be he can help send the '2-cell-ification' patch he has working, in which case I think we can drop this patch. @Konrad, please feel free to share the patch you were mentioning and I can help test it as well. [1]. https://lore.kernel.org/linux-arm-msm/09fe3e93-328b-13a3-540b-4ca47224b176@linaro.org/ Thanks, Bhupesh
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index ab4df02052853..7ffce3b676641 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -36,10 +36,10 @@ properties: maxItems: 2 "#address-cells": - const: 2 + enum: [ 1, 2 ] "#size-cells": - const: 2 + enum: [ 1, 2 ] ranges: true
Fix the following '#address-cells' & '#size-cells' related dt-binding error: $ make dtbs_check From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dtb: geniqup@4ac0000: #address-cells:0:0: 2 was expected From schema: Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> --- Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)