From: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
To: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
xzy.xu-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
groeck-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org
Subject: Re: [PATCH v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy
Date: Wed, 29 Jun 2016 16:27:19 +0200 [thread overview]
Message-ID: <2624359.mbyKrcyvqy@phil> (raw)
In-Reply-To: <5773D7DC.9050902-l0cyMroinI0@public.gmane.org>
Hi Kishon,
Am Mittwoch, 29. Juni 2016, 19:44:52 schrieb Kishon Vijay Abraham I:
> On Friday 17 June 2016 10:16 PM, Heiko Stübner wrote:
> > Am Freitag, 17. Juni 2016, 17:24:46 schrieb Kishon Vijay Abraham I:
> > [...]
> >
> >>> + /* find out a proper config which can be matched with dt. */
> >>> + index = 0;
> >>> + while (phy_cfgs[index].reg) {
> >>> + if (phy_cfgs[index].reg == reg) {
> >>
> >> Why not pass these config values from dt? Moreover finding the config
> >> using register offset is bound to break.
> >
> > As you have probably seen, this phy block is no stand-alone
> > (mmio-)device, but gets controlled through special register/bits in the
> > so called "General Register Files" syscon.
> >
> > The values stored and accessed here, are the location and layout of
> > those
> > control registers. Bits in those phy control registers at times move
> > between phy-versions in different socs (rk3036, rk3228, rk3366, rk3368,
> > rk3399) and some are even missing. So I don't really see a nice way to
> > describe that in dt without describing the register and offset of each
> > of those 22 used bits individually.
> >
> >
> > I'm also not sure where you expect it to break? The reg-offset is the
> > offset of the phy inside the GRF and the Designware-phy also already
> > does something similar to select some appropriate values.
>
> I'm concerned the phy can be placed in the different reg-offset within GRF
> (like in the next silicon revision) and this driver can't be used.
That is something that has not happened with all Rockchip SoCs I have had in
my hands so far.
While the GRF is some sort-of wild-west area with settings for vastly
different blocks in there and always changes between different socs (rk3288
[4-core A17] <-> rk3366 <-> rk3368 [8-core A53] <-> rk3399 etc) there
haven't been such changes (different register offsets) between soc-revisions
of the same soc that I know off.
The GRF also includes such important things like the whole pinctrl handling,
so if there were such offset changes in the GRF a lot of drivers (and
maintainers) would get very unhappy - me included :-) .
Heiko
WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Frank Wang <frank.wang@rock-chips.com>,
dianders@chromium.org, linux@roeck-us.net, groeck@chromium.org,
jwerner@chromium.org, robh+dt@kernel.org, pawel.moll@arm.com,
mark.rutland@arm.com, ijc+devicetree@hellion.org.uk,
galak@codeaurora.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
linux-rockchip@lists.infradead.org, xzy.xu@rock-chips.com,
kever.yang@rock-chips.com, huangtao@rock-chips.com,
william.wu@rock-chips.com
Subject: Re: [PATCH v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy
Date: Wed, 29 Jun 2016 16:27:19 +0200 [thread overview]
Message-ID: <2624359.mbyKrcyvqy@phil> (raw)
In-Reply-To: <5773D7DC.9050902@ti.com>
Hi Kishon,
Am Mittwoch, 29. Juni 2016, 19:44:52 schrieb Kishon Vijay Abraham I:
> On Friday 17 June 2016 10:16 PM, Heiko Stübner wrote:
> > Am Freitag, 17. Juni 2016, 17:24:46 schrieb Kishon Vijay Abraham I:
> > [...]
> >
> >>> + /* find out a proper config which can be matched with dt. */
> >>> + index = 0;
> >>> + while (phy_cfgs[index].reg) {
> >>> + if (phy_cfgs[index].reg == reg) {
> >>
> >> Why not pass these config values from dt? Moreover finding the config
> >> using register offset is bound to break.
> >
> > As you have probably seen, this phy block is no stand-alone
> > (mmio-)device, but gets controlled through special register/bits in the
> > so called "General Register Files" syscon.
> >
> > The values stored and accessed here, are the location and layout of
> > those
> > control registers. Bits in those phy control registers at times move
> > between phy-versions in different socs (rk3036, rk3228, rk3366, rk3368,
> > rk3399) and some are even missing. So I don't really see a nice way to
> > describe that in dt without describing the register and offset of each
> > of those 22 used bits individually.
> >
> >
> > I'm also not sure where you expect it to break? The reg-offset is the
> > offset of the phy inside the GRF and the Designware-phy also already
> > does something similar to select some appropriate values.
>
> I'm concerned the phy can be placed in the different reg-offset within GRF
> (like in the next silicon revision) and this driver can't be used.
That is something that has not happened with all Rockchip SoCs I have had in
my hands so far.
While the GRF is some sort-of wild-west area with settings for vastly
different blocks in there and always changes between different socs (rk3288
[4-core A17] <-> rk3366 <-> rk3368 [8-core A53] <-> rk3399 etc) there
haven't been such changes (different register offsets) between soc-revisions
of the same soc that I know off.
The GRF also includes such important things like the whole pinctrl handling,
so if there were such offset changes in the GRF a lot of drivers (and
maintainers) would get very unhappy - me included :-) .
Heiko
next prev parent reply other threads:[~2016-06-29 14:27 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-13 2:10 [PATCH v5 0/2] Add a new Rockchip usb2 phy driver Frank Wang
2016-06-13 2:10 ` Frank Wang
2016-06-13 2:10 ` [PATCH v5 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY Frank Wang
[not found] ` <1465783810-18756-2-git-send-email-frank.wang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-06-13 8:38 ` Heiko Stübner
2016-06-13 8:38 ` Heiko Stübner
2016-06-14 13:28 ` Heiko Stübner
2016-06-14 13:28 ` Heiko Stübner
2016-06-15 1:24 ` Frank Wang
2016-06-15 1:24 ` Frank Wang
2016-06-14 22:26 ` Rob Herring
2016-06-14 22:26 ` Rob Herring
2016-06-13 2:10 ` [PATCH v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy Frank Wang
2016-06-14 14:52 ` Guenter Roeck
[not found] ` <57601A1D.9020803-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2016-06-14 15:20 ` Heiko Stübner
2016-06-14 15:20 ` Heiko Stübner
[not found] ` <1465783810-18756-3-git-send-email-frank.wang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-06-14 13:27 ` Heiko Stübner
2016-06-14 13:27 ` Heiko Stübner
2016-06-14 13:50 ` Guenter Roeck
2016-06-14 13:50 ` Guenter Roeck
[not found] ` <CABXOdTfzDeg3KOmEkJkeUWs76wFind89D-bSrs=7-jSxmdhSHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-06-14 14:00 ` Heiko Stübner
2016-06-14 14:00 ` Heiko Stübner
2016-06-15 1:14 ` Frank Wang
2016-06-15 1:14 ` Frank Wang
2016-06-15 15:47 ` Guenter Roeck
[not found] ` <CABXOdTdD-DFjzZszvTBoxviwsdu=HZSRy5iTzrkgOjg5qae05Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-06-16 1:47 ` Frank Wang
2016-06-16 1:47 ` Frank Wang
2016-06-16 13:12 ` Guenter Roeck
[not found] ` <5762A5AE.5030400-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2016-06-17 0:57 ` Frank Wang
2016-06-17 0:57 ` Frank Wang
2016-06-15 3:23 ` Frank Wang
2016-06-15 3:23 ` Frank Wang
2016-06-15 9:04 ` Heiko Stübner
2016-06-15 10:58 ` Frank Wang
2016-06-15 18:49 ` Heiko Stübner
2016-06-17 11:54 ` Kishon Vijay Abraham I
2016-06-17 11:54 ` Kishon Vijay Abraham I
[not found] ` <5763E506.1060500-l0cyMroinI0@public.gmane.org>
2016-06-17 16:46 ` Heiko Stübner
2016-06-17 16:46 ` Heiko Stübner
2016-06-29 14:14 ` Kishon Vijay Abraham I
2016-06-29 14:14 ` Kishon Vijay Abraham I
[not found] ` <5773D7DC.9050902-l0cyMroinI0@public.gmane.org>
2016-06-29 14:27 ` Heiko Stuebner [this message]
2016-06-29 14:27 ` Heiko Stuebner
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=2624359.mbyKrcyvqy@phil \
--to=heiko-4mtyjxux2i+zqb+pc5nmwq@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=groeck-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=kishon-l0cyMroinI0@public.gmane.org \
--cc=linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=xzy.xu-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.