From: "Heiko Stübner" <heiko@sntech.de>
To: Shawn Lin <shawn.lin@rock-chips.com>
Cc: kishon@ti.com, linux-rockchip@lists.infradead.org,
linux-kernel@vger.kernel.org, ykk@rock-chips.com,
devicetree@vger.kernel.org, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org
Subject: Re: [PATCH 2/2] phy: rockchip-emmc: should be a child device of the GRF
Date: Thu, 24 Mar 2016 16:35:16 +0100 [thread overview]
Message-ID: <3125740.3yK6gzbokn@diego> (raw)
In-Reply-To: <56F3ED45.40107@rock-chips.com>
Hi Shawn,
Am Donnerstag, 24. März 2016, 21:36:05 schrieb Shawn Lin:
> 在 2016/3/24 21:22, Heiko Stuebner 写道:
> > The emmc-phy is fully enclosed in the general register files (GRF).
> > Therefore as seen from the device-tree it shouldn't be a separate
> > platform-
> > device but instead a sub-device of the GRF - using the simply-mfd
> > mechanism.
> >
> > The driver entered the kernel in the current merge-window, so we can still
> > adapt the binding without needing a fallback, as the binding hasn't been
> > released with a full kernel yet.
> >
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> > Hi Shawn, Kishon,
> >
> > I didn't see this new phy driver until now, so I'd really like to get
> > this sorted before the old binding solidifies :-).
> >
> > I'll convert the usbphy as well, but that has to have the fallback for
> > the old binding, so is not as urgent as these two.
> >
> > As mentioned in the patch description above, this is meant as a fixup for
> > kernel 4.6.
> >
> >
> > One thing I noticed, the emmc phy is occupying the range 0xf780-0xf7a0,
> > so shouldn't the reg property reflect that, like
> >
> > reg = <0xf780 0x20>;
> >
> > to stay with common conventions?
>
> yes, and I had a fix[0] for it waiting for Kishon's reviewing.
please try to always include both me and the linux-rockchip list for Rockchip
specific changes in the future :-) .
In any case, I do think going with a reg property might be more standard
conformant, once it is under the GRF. Of course only for sub-devices that
actually occupy a real block inside the GRF like your emmc phy or the new
usbphy blocks.
So I guess the dts should probably look like:
grf: syscon@ff770000 {
compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
#address-cells = <1>;
#size-cells = <1>;
emmcphy: phy@f780 {
compatible = "rockchip,rk3399-emmc-phy";
reg = <0xf780 0x20>;
#phy-cells = <0>;
};
};
> [0]:
> http://lkml.org/lkml/2016/3/8/114
>
> > .../devicetree/bindings/phy/rockchip-emmc-phy.txt | 19
> > ++++++++++++------- drivers/phy/phy-rockchip-emmc.c
> > | 5 ++++-
> > 2 files changed, 16 insertions(+), 8 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> > b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt index
> > 61916f1..d711259 100644
> > --- a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> > +++ b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> > @@ -3,17 +3,22 @@ Rockchip EMMC PHY
> >
> > Required properties:
> > - compatible: rockchip,rk3399-emmc-phy
> >
> > - - rockchip,grf : phandle to the syscon managing the "general
> > - register files"
> >
> > - #phy-cells: must be 0
> > - reg: PHY configure reg address offset in "general
> >
> > register files"
> >
> > Example:
> > -emmcphy: phy {
> > - compatible = "rockchip,rk3399-emmc-phy";
> > - rockchip,grf = <&grf>;
> > - reg = <0xf780>;
> > - #phy-cells = <0>;
> > +
> > +grf: syscon@ff770000 {
> > + compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
> > +
> > +...
> > +
> > + emmcphy: phy@f780 {
> > + compatible = "rockchip,rk3399-emmc-phy";
> > + rockchip,grf = <&grf>;
I just saw I missed to remove that now obsolete rockchip,grf property.
> > + reg = <0xf780>;
> > + #phy-cells = <0>;
> > + };
> >
> > };
> >
> > diff --git a/drivers/phy/phy-rockchip-emmc.c
> > b/drivers/phy/phy-rockchip-emmc.c index 887b4c2..6ebcf3e 100644
> > --- a/drivers/phy/phy-rockchip-emmc.c
> > +++ b/drivers/phy/phy-rockchip-emmc.c
> > @@ -176,7 +176,10 @@ static int rockchip_emmc_phy_probe(struct
> > platform_device *pdev)>
> > struct regmap *grf;
> > unsigned int reg_offset;
> >
> > - grf = syscon_regmap_lookup_by_phandle(dev->of_node, "rockchip,grf");
> > + if (!dev->parent || !dev->parent->of_node)
> > + return -ENODEV;
> > +
> > + grf = syscon_node_to_regmap(dev->parent->of_node);
> >
> > if (IS_ERR(grf)) {
> >
> > dev_err(dev, "Missing rockchip,grf property\n");
> > return PTR_ERR(grf);
prev parent reply other threads:[~2016-03-24 15:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-24 13:22 [PATCH 1/2] phy: rockchip-dp: should be a child device of the GRF Heiko Stuebner
[not found] ` <1458825774-9957-1-git-send-email-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
2016-03-24 13:22 ` [PATCH 2/2] phy: rockchip-emmc: " Heiko Stuebner
[not found] ` <1458825774-9957-2-git-send-email-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
2016-03-24 13:36 ` Shawn Lin
2016-03-24 15:35 ` 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=3125740.3yK6gzbokn@diego \
--to=heiko@sntech.de \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=kishon@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=shawn.lin@rock-chips.com \
--cc=ykk@rock-chips.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