From: Linus Walleij <linus.walleij@linaro.org>
To: Moritz Fischer <moritz.fischer@ettus.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Paweł Moll" <pawel.moll@arm.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
"Kumar Gala" <galak@codeaurora.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [RFC 2/3] pinctrl: e3xx: Adding support for NI Ettus Research USRP E3xx pinconf
Date: Mon, 9 Nov 2015 11:21:22 +0100 [thread overview]
Message-ID: <CACRpkdaX8JyxMq_peUyXMfMq4xDzKiCWv62UbfKFxM_TyM-_wg@mail.gmail.com> (raw)
In-Reply-To: <1446766883-25703-3-git-send-email-moritz.fischer@ettus.com>
On Fri, Nov 6, 2015 at 12:41 AM, Moritz Fischer
<moritz.fischer@ettus.com> wrote:
> The USRP E3XX series requires pinctrl to configure the idle state
> FPGA image for minimizing power consumption.
> This is required since different daughtercards have different uses
> for pins on a common connector.
>
> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
(...)
> +static const struct pinctrl_pin_desc e3xx_pins[] = {
> + /* pin0 doesn't exist */
> + PINCTRL_PIN(1, "DB_1"),
> + PINCTRL_PIN(2, "DB_2"),
(...)
> + PINCTRL_PIN(119, "DB_119"),
> + PINCTRL_PIN(120, "DB_120"),
> +};
These should be the names on the data sheet for the balls/pins on the ASIC.
Is this the case? I saw some discussion with Arnd that indicated it was
rather rail names for a certain board and that is not OK.
> +static int e3xx_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
> +{
> + return 0;
> +}
> +
> +static const char *e3xx_pinctrl_get_group_name(struct pinctrl_dev *pctldev,
> + unsigned selector)
> +{
> + return NULL;
> +}
> +
> +static int e3xx_pinctrl_get_group_pins(struct pinctrl_dev *pctldev,
> + unsigned selector,
> + const unsigned **pins,
> + unsigned *num_pins)
> +{
> + return -ENOTSUPP;
> +}
Hm maybe we should make these group callbacks optional
in the pinctrl core?
> +static int e3xx_pinconf_cfg_set(struct pinctrl_dev *pctldev,
> + unsigned pin,
> + unsigned long *configs,
> + unsigned num_configs)
> +{
> + u32 reg, mask;
> + int i;
> + struct e3xx_pinctrl *pctrl;
> + unsigned int param, arg;
> +
> + if (pin >= E3XX_NUM_DB_PINS)
> + return -ENOTSUPP;
> + mask = BIT(pin % E3XX_PINS_PER_REG);
> +
> + pctrl = pinctrl_dev_get_drvdata(pctldev);
> +
> + clk_enable(pctrl->clk);
Have you considered using pm_runtime_get_sync() etc with
callbacks instead of hammering clk_enable/disable all the
time? See
drivers/hwtracing/coresight/coresight-replicator.c
for an example of how to do it in the runtime PM ops
callbacks. It requires some tweaks (look closely at all setup
there) but it pays off.
> +static int e3xx_pinconf_group_set(struct pinctrl_dev *pctldev,
> + unsigned selector,
> + unsigned long *configs,
> + unsigned num_configs)
> +{
> + return -EAGAIN;
> +}
Maybe you should group this with the other group callbacks.
Apart from these remarks it looks pretty nice.
Yours,
Linus Walleij
next prev parent reply other threads:[~2015-11-09 10:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 23:41 [RFC 0/3] Adding support for NI Ettus Research USRP E3XX pinconf Moritz Fischer
2015-11-05 23:41 ` [RFC 1/3] Documentation: dt: Add devicetree bindings for NI USRP E3xx pinconf Moritz Fischer
2015-11-06 8:56 ` Arnd Bergmann
2015-11-05 23:41 ` [RFC 2/3] pinctrl: e3xx: Adding support for NI Ettus Research " Moritz Fischer
2015-11-06 20:56 ` Andy Shevchenko
2015-11-09 10:21 ` Linus Walleij [this message]
2015-11-10 3:55 ` Moritz Fischer
2015-11-05 23:41 ` [RFC 3/3] ARM: e3xx: Add header file for pinctrl constants Moritz Fischer
2015-11-06 8:54 ` Arnd Bergmann
2015-11-06 16:01 ` Moritz Fischer
2015-11-06 16:42 ` Arnd Bergmann
2015-11-06 17:55 ` Moritz Fischer
2015-11-06 20:28 ` Arnd Bergmann
2015-11-17 10:55 ` [RFC 0/3] Adding support for NI Ettus Research USRP E3XX pinconf Linus Walleij
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=CACRpkdaX8JyxMq_peUyXMfMq4xDzKiCWv62UbfKFxM_TyM-_wg@mail.gmail.com \
--to=linus.walleij@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=moritz.fischer@ettus.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.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).