From: "Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
To: linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
max.schwarz-BGeptl67XyCzQB+pC5nmwQ@public.gmane.org,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Subject: [RFC/PATCH 0/8] pinctrl-rockchip: Change wrong initial assumptions
Date: Wed, 30 Apr 2014 00:07:12 +0200 [thread overview]
Message-ID: <1414506.B4e2jZujVm@diego> (raw)
>From the "wet behind the ears" files:
Initially due to lack of documentation and (personal) understanding
I assumed that the area holding the iomux settings would be separate
from everything else, while in fact the grf registers contain not only
pinctrl stuff but also dma, usb-phy and general soc-status settings.
Also things like drive-strength we do not support currently are intermixed.
The same is true for the pmu, which does not only contain power domains
but also the system reset as well as well as general registers surviving
system-resets. Additionally the rk3188 moved parts of the pull-setting
registers into the pmu space.
While this wasn't a problem until now, the upcoming rk3288 introduces
additional changes to both the grf and pmu areas. On it even part of
the pinmux registers move into the pmu space.
For this my current gut-feeling is, that providing both the grf and pmu
as syscons to the pinctrl driver might be more future proof for the next
socs. But as I'm not sure on this, I'd like of course comments :-)
The code in it's current form supports both the old as well as the
changed binding.
The other option would be to leave the grf as it is and create separate
syscons for real small individual parts like the soc-conf and usb-phys.
But apart from creating these real small syscons that would
also make it necessary to introduce another register map for the
drive-strength settings of the pin-controller, which are sitting in the
middle of everything at least on rk3066 and rk3188.
So I'd really like comments here :-)
@Max: sorry to come up with this now, but I feel this should be resolved
(in whatever direction) before we introduce any grf syscon. Because due
to dt being an API we will be tied for a long time to it.
Heiko Stuebner (8):
pinctrl: rockchip: do not require 2nd register area
pinctrl: rockchip: use regmaps instead of raw mappings
pinctrl: rockchip: rockchip_pinctrl in rockchip_get_bank_data
pinctrl: rockchip: let pmu registers be supplied by a syscon
pinctrl: rockchip: only map bank0-pull-region when pmu regmap missing
pinctrl: rockchip: base regmap supplied by a syscon
dt-bindings: adapt rockchip-pinctrl documentation to changed bindings
ARM: dts: rockchip: convert pinctrl nodes to new bindings
.../bindings/pinctrl/rockchip,pinctrl.txt | 28 +++-
arch/arm/boot/dts/rk3066a.dtsi | 2 +-
arch/arm/boot/dts/rk3188.dtsi | 9 +-
arch/arm/boot/dts/rk3xxx.dtsi | 9 +-
drivers/pinctrl/pinctrl-rockchip.c | 178 +++++++++++++++------
5 files changed, 164 insertions(+), 62 deletions(-)
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2014-04-29 22:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 22:07 Heiko Stübner [this message]
2014-04-29 22:07 ` [PATCH 1/8] pinctrl: rockchip: do not require 2nd register area Heiko Stübner
2014-04-29 22:08 ` [PATCH 2/8] pinctrl: rockchip: use regmaps instead of raw mappings Heiko Stübner
2014-05-04 13:31 ` Max Schwarz
2014-04-29 22:08 ` [PATCH 3/8] pinctrl: rockchip: rockchip_pinctrl in rockchip_get_bank_data Heiko Stübner
2014-04-29 22:09 ` [PATCH 4/8] pinctrl: rockchip: let pmu registers be supplied by a syscon Heiko Stübner
2014-04-29 22:09 ` [PATCH 5/8] pinctrl: rockchip: only map bank0-pull-region when pmu regmap missing Heiko Stübner
2014-04-29 22:10 ` [PATCH 6/8] pinctrl: rockchip: base regmap supplied by a syscon Heiko Stübner
2014-04-29 22:10 ` [PATCH 7/8] dt-bindings: adapt rockchip-pinctrl doc to changed bindings Heiko Stübner
2014-04-29 22:10 ` [PATCH 8/8] ARM: dts: rockchip: convert pinctrl nodes to new bindings Heiko Stübner
2014-05-01 10:43 ` [RFC/PATCH 0/8] pinctrl-rockchip: Change wrong initial assumptions Max Schwarz
2014-05-01 13:21 ` syscon or memory mappings (was: Re: [RFC/PATCH 0/8] pinctrl-rockchip: Change wrong initial assumptions) Heiko Stübner
2014-05-02 13:59 ` Max Schwarz
2014-05-02 23:45 ` Heiko Stübner
2014-05-03 12:40 ` Max Schwarz
2014-05-05 12:11 ` Heiko Stübner
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=1414506.B4e2jZujVm@diego \
--to=heiko-4mtyjxux2i+zqb+pc5nmwq@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=max.schwarz-BGeptl67XyCzQB+pC5nmwQ@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@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 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).