From: Heiko Stuebner <heiko@sntech.de>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Ezequiel Garcia <ezequiel@collabora.com>,
robh+dt@kernel.org, vicencb@gmail.com, shawn.lin@rock-chips.com,
enric.balletbo@collabora.com, pbrobinson@gmail.com,
tom@vamrs.com, dev@vamrs.com, stephen@vamrs.com,
amit.kucheria@linaro.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/4] arm64: dts: rockchip: Split out common nodes for Rock960 based boards
Date: Wed, 12 Sep 2018 16:05:28 +0200 [thread overview]
Message-ID: <2062942.2GzzSlpOsc@phil> (raw)
In-Reply-To: <20180912082244.GA16509@Mani-XPS-13-9360>
Am Mittwoch, 12. September 2018, 10:22:44 CEST schrieb Manivannan Sadhasivam:
> On Wed, Sep 12, 2018 at 09:26:12AM +0200, Heiko Stübner wrote:
> > Am Mittwoch, 12. September 2018, 05:12:48 CEST schrieb Manivannan Sadhasivam:
> > > Hi Ezequiel,
> > >
> > > On Tue, Sep 11, 2018 at 04:40:29PM -0300, Ezequiel Garcia wrote:
> > > > On Tue, 2018-09-11 at 08:00 +0530, Manivannan Sadhasivam wrote:
> > > > > Since the same family members of Rock960 boards (Rock960 and Ficus)
> > > > > share the same configuration, split out the common nodes into a common
> > > > > dtsi file for reducing code duplication. The board specific nodes for
> > > > > Ficus boards are then placed in corresponding board DTS file.
> > > >
> > > > I think it should be possible to move the common USB nodes to the dtsi
> > > > file, and keep the board-specific (phy-supply property) in the dts files:
> > > >
> > > > &u2phy0_host {
> > > >
> > > > phy-supply = <&vcc5v0_host>;
> > > >
> > > > };
> > > >
> > > > &u2phy1_host {
> > > >
> > > > phy-supply = <&vcc5v0_host>;
> > > >
> > > > };
> > >
> > > We can do that but my intention was to entirely partition the nodes
> > > which are not common. So that it would be less confusing when someone
> > > looks at it (please correct me if I'm wrong).
> >
> > The supply is actually named the same on both boards, so you could move
> > all the usb-nodes to the main dtsi, including the reference to vcc5v0_host
> > which would then get defined itself in the two board dts.
> >
> > Then again, seeing that the vcc5v0_host also only differs in the actually
> > used gpio another option would be to move the whole regulator node
> > to the dtsi and just define the gpio properties in the board dts files.
> >
>
> Hmm, if that's the preferred option then I guess this applies to pcie
> nodes also. At the end, usb and pcie nodes will be shrinked to below in
> board dts:
>
> &pinctrl {
> pcie {
> pcie_drv: pcie-drv {
> rockchip,pins =
> <2 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
> };
> };
>
> usb2 {
> host_vbus_drv: host-vbus-drv {
> rockchip,pins =
> <4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
> };
> };
> };
>
> &pcie0 {
> ep-gpios = <&gpio2 RK_PA2 GPIO_ACTIVE_HIGH>;
> status = "okay";
> };
>
> &vcc3v3_pcie {
> gpio = <&gpio2 5 GPIO_ACTIVE_HIGH>;
> };
>
> &vcc5v0_host {
> gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
> };
yep, ideally we could go that way. It's way easier to determine the
actual differences between boards that way as well.
Heiko
next prev parent reply other threads:[~2018-09-12 14:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-11 2:30 [PATCH v2 0/4] Add 96Boards Rock960 CE board support Manivannan Sadhasivam
2018-09-11 2:30 ` [PATCH v2 1/4] arm64: dts: rockchip: Split out common nodes for Rock960 based boards Manivannan Sadhasivam
2018-09-11 19:40 ` Ezequiel Garcia
2018-09-12 3:12 ` Manivannan Sadhasivam
2018-09-12 7:26 ` Heiko Stübner
2018-09-12 8:22 ` Manivannan Sadhasivam
2018-09-12 14:05 ` Heiko Stuebner [this message]
2018-09-11 2:30 ` [PATCH v2 2/4] dt-bindings: arm: rockchip: Add binding for Rock960 board Manivannan Sadhasivam
2018-09-11 2:30 ` [PATCH v2 3/4] arm64: boot: dts: rockchip: Add support " Manivannan Sadhasivam
2018-09-11 2:30 ` [PATCH v2 4/4] arm64: dts: rockchip: Enable SD card detection for Rock960 boards Manivannan Sadhasivam
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=2062942.2GzzSlpOsc@phil \
--to=heiko@sntech.de \
--cc=amit.kucheria@linaro.org \
--cc=dev@vamrs.com \
--cc=devicetree@vger.kernel.org \
--cc=enric.balletbo@collabora.com \
--cc=ezequiel@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=pbrobinson@gmail.com \
--cc=robh+dt@kernel.org \
--cc=shawn.lin@rock-chips.com \
--cc=stephen@vamrs.com \
--cc=tom@vamrs.com \
--cc=vicencb@gmail.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).