All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Nilsson <jesper.nilsson@axis.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Jesper Nilsson <jespern@axis.com>, Lars Persson <larper@axis.com>,
	Niklas Cassel <niklass@axis.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"David S. Miller" <davem@davemloft.net>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	chris.paterson@linux.pieboy.co.uk,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	linux-arm-kernel@axis.com
Subject: Re: [PATCH 2/3] pinctrl: Add pincontrol driver for ARTPEC-6 SoC
Date: Thu, 30 Mar 2017 16:23:32 +0200	[thread overview]
Message-ID: <20170330142332.GI29118@axis.com> (raw)
In-Reply-To: <CACRpkda_o9nU9jyHAEJxoownO-DXw72fr3yuxf2zGJkJvPbW7g@mail.gmail.com>

On Thu, Mar 30, 2017 at 02:07:33PM +0200, Linus Walleij wrote:
> On Thu, Mar 30, 2017 at 1:33 PM, Jesper Nilsson <jesper.nilsson@axis.com> wrote:
> 
> > Add pinctrl driver support for the Axis ARTPEC-6 SoC.
> > There are only some pins that actually have different
> > functions available, but all can control bias (pull-up/-down)
> > and drive strength.
> > Code originally written by Chris Paterson.
> >
> > Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
> 
> Very good start, but look at this:
> 
> > +#define ARTPEC6_PINMUX_P0_0_CTRL       0x000
> > +#define ARTPEC6_PINMUX_P0_1_CTRL       0x004
> > +#define ARTPEC6_PINMUX_P0_2_CTRL       0x008
> > +#define ARTPEC6_PINMUX_P0_3_CTRL       0x00C
> > +#define ARTPEC6_PINMUX_P0_4_CTRL       0x010
> > +#define ARTPEC6_PINMUX_P0_5_CTRL       0x014
> > +#define ARTPEC6_PINMUX_P0_6_CTRL       0x018
> > +#define ARTPEC6_PINMUX_P0_7_CTRL       0x01C
> > +#define ARTPEC6_PINMUX_P0_8_CTRL       0x020
> > +#define ARTPEC6_PINMUX_P0_9_CTRL       0x024
> > +#define ARTPEC6_PINMUX_P0_10_CTRL      0x028
> > +#define ARTPEC6_PINMUX_P0_11_CTRL      0x02C
> > +#define ARTPEC6_PINMUX_P0_12_CTRL      0x030
> > +#define ARTPEC6_PINMUX_P0_13_CTRL      0x034
> > +#define ARTPEC6_PINMUX_P0_14_CTRL      0x038
> > +#define ARTPEC6_PINMUX_P0_15_CTRL      0x03C
> 
> It's pretty clear that the stride is always 4 bytes is it not.

Agreed.

> > +static const unsigned int pin_regs[] = {
> > +       ARTPEC6_PINMUX_P0_0_CTRL,       /* Pin 0 */
> > +       ARTPEC6_PINMUX_P0_1_CTRL,
> > +       ARTPEC6_PINMUX_P0_2_CTRL,
> > +       ARTPEC6_PINMUX_P0_3_CTRL,
> > +       ARTPEC6_PINMUX_P0_4_CTRL,
> > +       ARTPEC6_PINMUX_P0_5_CTRL,
> > +       ARTPEC6_PINMUX_P0_6_CTRL,
> > +       ARTPEC6_PINMUX_P0_7_CTRL,
> > +       ARTPEC6_PINMUX_P0_8_CTRL,
> > +       ARTPEC6_PINMUX_P0_9_CTRL,
> > +       ARTPEC6_PINMUX_P0_10_CTRL,
> > +       ARTPEC6_PINMUX_P0_11_CTRL,
> > +       ARTPEC6_PINMUX_P0_12_CTRL,
> > +       ARTPEC6_PINMUX_P0_13_CTRL,
> > +       ARTPEC6_PINMUX_P0_14_CTRL,
> > +       ARTPEC6_PINMUX_P0_15_CTRL,
> 
> The oceans of redundant information are rising ;)
> 
> > +static const unsigned int uart0_regs0[] = {
> > +       ARTPEC6_PINMUX_P1_0_CTRL,
> > +       ARTPEC6_PINMUX_P1_1_CTRL,
> > +       ARTPEC6_PINMUX_P1_2_CTRL,
> > +       ARTPEC6_PINMUX_P1_3_CTRL,
> > +       ARTPEC6_PINMUX_P1_4_CTRL,
> > +       ARTPEC6_PINMUX_P1_5_CTRL,
> > +       ARTPEC6_PINMUX_P1_6_CTRL,
> > +       ARTPEC6_PINMUX_P1_7_CTRL,
> > +       ARTPEC6_PINMUX_P1_8_CTRL,
> > +       ARTPEC6_PINMUX_P1_9_CTRL,
> > +};
> 
> And rising.

:-)

> > +       {
> > +               .name = "uart0grp0",
> > +               .pins = uart0_pins0,
> > +               .num_pins = ARRAY_SIZE(uart0_pins0),
> > +               .reg_offsets = uart0_regs0,
> > +               .num_regs = ARRAY_SIZE(uart0_regs0),
> > +               .config = ARTPEC6_CONFIG_1,
> > +       },
> 
> So what if the struct artpec6_pin_group...
> 
> > +struct artpec6_pin_group {
> > +       const char         *name;
> > +       const unsigned int *pins;
> > +       const unsigned int num_pins;
> > +       const unsigned int *reg_offsets;
> > +       const unsigned int num_regs;
> > +       unsigned char      config;
> > +};
> 
> Instead of reg_offsets had reg_offset_base, and you just
> calculate it with base + pin * 4 when you need it?

Yes, that would be much clearer.

> I also highly suspect that num_pins and num_regs above
> are exactly the same number in all cases, correct? You
> probably only need num_pins.

Agreed.

> > +static struct artpec6_pmx_func artpec6_pmx_functions[] = {
> 
> Needs const
> 
> > +static void artpec6_pmx_select_func(struct pinctrl_dev *pctldev,
> > +                                   unsigned int function, unsigned int group,
> > +                                   bool enable)
> > +{
> > +       unsigned int regval, val;
> > +       int i;
> > +       const unsigned int *pmx_regs;
> > +       struct artpec6_pmx *pmx = pinctrl_dev_get_drvdata(pctldev);
> > +
> > +       pmx_regs = artpec6_pin_groups[group].reg_offsets;
> > +
> > +       for (i = 0; i < artpec6_pin_groups[group].num_regs; i++) {
> > +               /* Ports 4-8 do not have a SEL field and are always selected */
> > +               if (pmx_regs[i] >= ARTPEC6_PINMUX_P4_0_CTRL)
> > +                       continue;
> > +
> > +               if (!strcmp(artpec6_pmx_get_fname(pctldev, function), "gpio")) {
> > +                       /* GPIO is always config 0 */
> > +                       val = ARTPEC6_CONFIG_0 << ARTPEC6_PINMUX_SEL_SHIFT;
> > +               } else {
> > +                       if (enable)
> > +                               val = artpec6_pin_groups[group].config
> > +                                       << ARTPEC6_PINMUX_SEL_SHIFT;
> > +                       else
> > +                               val = ARTPEC6_CONFIG_0
> > +                                       << ARTPEC6_PINMUX_SEL_SHIFT;
> > +               }
> > +
> > +               regval = readl(pmx->base + pmx_regs[i]);
> > +               regval &= ~ARTPEC6_PINMUX_SEL_MASK;
> > +               regval |= val;
> > +               writel(regval, pmx->base + pmx_regs[i]);
> > +       }
> 
> So thus look can be different and include something like +=4 for the registers
> for each iteration.
> 
> > --- /dev/null
> > +++ b/drivers/pinctrl/pinctrl-artpec6.h
> 
> You don't need to have these defines in their own file, just copy it into
> the top of the driver file.

Ok.

> > +/* Pinmux control register offset definitions */
> > +
> > +#define ARTPEC6_PINMUX_P1_0_CTRL       0x040
> > +#define ARTPEC6_PINMUX_P1_1_CTRL       0x044
> (...)
> 
> So for these defines you only need the first one.
> 
> With these things fixes I'm pretty sure it is close to finished.

Thanks for the feedback, will rework and resend. :-)

> Yours,
> Linus Walleij

/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson@axis.com

  reply	other threads:[~2017-03-30 14:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-30 11:33 [PATCH 2/3] pinctrl: Add pincontrol driver for ARTPEC-6 SoC Jesper Nilsson
2017-03-30 12:07 ` Linus Walleij
2017-03-30 14:23   ` Jesper Nilsson [this message]
2017-04-03 12:47   ` [PATCH 2/3 v2] " Jesper Nilsson
2017-04-07  9:50     ` 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=20170330142332.GI29118@axis.com \
    --to=jesper.nilsson@axis.com \
    --cc=chris.paterson@linux.pieboy.co.uk \
    --cc=davem@davemloft.net \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=jespern@axis.com \
    --cc=larper@axis.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@axis.com \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=niklass@axis.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 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.