From: "Heiko Stübner" <heiko@sntech.de>
To: Johan Jonker <jbx6244@gmail.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
devicetree@vger.kernel.org, robh+dt@kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH] arm64: dts: rockchip: remove bus-width from mmc nodes in rk3308.dtsi
Date: Tue, 14 Apr 2020 14:01:19 +0200 [thread overview]
Message-ID: <2038198.JSHZf9jCco@diego> (raw)
In-Reply-To: <f19b6b48-2950-abca-7dee-31c24118c3ef@gmail.com>
Hi Johan,
Am Dienstag, 14. April 2020, 13:45:00 CEST schrieb Johan Jonker:
> Hi Robin, Heiko,
>
> If the Rockchip DT maintainers(= Heiko) agree that the new line for the
> 'bus-width' properties is that it should be placed in dtsi I'll produce
> a version 2. Please advise what should be done with the other Rockchip
> SoCs. Change them too?
(1) as Robin pointed out bus-width and pinctrl containing the bus-pins
should be in the same file, as they describe parts of the same property
(2) essentially it is ok for pinctrl-defaults to live in the dtsi, when there
are no pin variants ... (like the uartX_mY pin variants), so if you enable
a node and only have essentially one pin variant to enable, this should
live in the soc dtsi (like essentially all boards using 4-pin sdmmc
and 8-pin emmc)
(3) Fixing other devicetrees is optional, so I won't oppose it of course
but it's also not something "that must be done" ;-)
Heiko
> On 4/14/20 12:02 PM, Robin Murphy wrote:
> > On 2020-04-13 8:36 pm, Johan Jonker wrote:
> >> The 'bus-width' property for mmc nodes is defined both in
> >> 'rk3308.dtsi' and 'rk3308-roc-cc.dts'.
> >> In line with the other Rockchip SoCs define that in a user dts only,
> >> so remove all entries from mmc nodes in 'rk3308.dtsi'.
> >
> > Judging by the pinctrl entries, these represent the number of pins
> > provided by the SoC itself. Obviously boards need to override that if
> > for some reason they don't wire up all the available data lines, but it
> > seems backwards to have every board restate the SoC's default value.
> >
> > In fact, having brought it up, for this particular case the pinctrl
> > setting is inherently related to the bus width, so having one without
> > the other in either place doesn't smell right.
> >
> > Robin.
> >
> >> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> >> ---
> >> arch/arm64/boot/dts/rockchip/rk3308.dtsi | 3 ---
> >> 1 file changed, 3 deletions(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> >> b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> >> index a9b98555d..130771ede 100644
> >> --- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> >> +++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> >> @@ -587,7 +587,6 @@
> >> compatible = "rockchip,rk3308-dw-mshc",
> >> "rockchip,rk3288-dw-mshc";
> >> reg = <0x0 0xff480000 0x0 0x4000>;
> >> interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
> >> - bus-width = <4>;
> >> clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>,
> >> <&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
> >> clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> >> @@ -602,7 +601,6 @@
> >> compatible = "rockchip,rk3308-dw-mshc",
> >> "rockchip,rk3288-dw-mshc";
> >> reg = <0x0 0xff490000 0x0 0x4000>;
> >> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
> >> - bus-width = <8>;
> >> clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>,
> >> <&cru SCLK_EMMC_DRV>, <&cru SCLK_EMMC_SAMPLE>;
> >> clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> >> @@ -615,7 +613,6 @@
> >> compatible = "rockchip,rk3308-dw-mshc",
> >> "rockchip,rk3288-dw-mshc";
> >> reg = <0x0 0xff4a0000 0x0 0x4000>;
> >> interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
> >> - bus-width = <4>;
> >> clocks = <&cru HCLK_SDIO>, <&cru SCLK_SDIO>,
> >> <&cru SCLK_SDIO_DRV>, <&cru SCLK_SDIO_SAMPLE>;
> >> clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> >>
>
>
prev parent reply other threads:[~2020-04-14 12:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-13 19:36 [PATCH] arm64: dts: rockchip: remove bus-width from mmc nodes in rk3308.dtsi Johan Jonker
2020-04-14 10:02 ` Robin Murphy
2020-04-14 10:16 ` Heiko Stübner
2020-04-14 11:45 ` Johan Jonker
2020-04-14 12:01 ` Heiko Stübner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2038198.JSHZf9jCco@diego \
--to=heiko@sntech.de \
--cc=devicetree@vger.kernel.org \
--cc=jbx6244@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).