All of lore.kernel.org
 help / color / mirror / Atom feed
From: Drew Fustini <drew@beagleboard.org>
To: Tony Lindgren <tony@atomide.com>
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-omap@vger.kernel.org
Subject: Re: pinctrl-single: num_maps in generic pinconf support?
Date: Mon, 8 Jun 2020 22:22:18 +0200	[thread overview]
Message-ID: <20200608202218.GA2891935@x1> (raw)
In-Reply-To: <20200608180543.GA2825296@x1>

On Mon, Jun 08, 2020 at 08:05:43PM +0200, Drew Fustini wrote:
> On Fri, May 29, 2020 at 10:40:37AM -0700, Tony Lindgren wrote:
> > * Drew Fustini <drew@beagleboard.org> [200528 12:54]:
> > > Would you be able to describe what you think AM33XX_PADCONF would look
> > > like if the mux and conf are seperated?
> > 
> > Yes it would just slightly change, see your example below.
> > 
> > > Is there an example you know of for another SoC?
> > 
> > I think the other driver already keep the padconf and mux separate.
> > 
> > So not sure where all #pinctrl-cells could be used. It would make
> > pinctrl-single.c a bit nicer though, and probably would make it
> > easier to implement further features.
> > 
> > Some hardware may need it to have #pinctrl-cells = <3> if GPIO
> > features are there too, ideally pinctrl-single would not even
> > care but just work for what is configured for the hardware.
> > 
> > > Currently, the macro takes dir and mux:
> > > 
> > > include/dt-bindings/pinctrl/omap.h:
> > > #define AM33XX_PADCONF(pa, dir, mux) OMAP_IOPAD_OFFSET((pa), 0x0800) ((dir) | (mux))
> > 
> > So after fixing up pinctrl-single.c, and changing the SoC dts
> > to have #pinctrl-cells = <2> instead of <1>, the macro would
> > then need to be:
> > 
> > #define AM33XX_PADCONF(pa, dir, mux) OMAP_IOPAD_OFFSET((pa), 0x0800) (dir), (mux))
> > 
> > > For example, in arch/arm/boot/dts/am335x-bone-common.dtsi:
> > > AM33XX_PADCONF(AM335X_PIN_I2C0_SDA, PIN_INPUT_PULLUP, MUX_MODE0)
> > 
> > Yeah so no change needed for the use.
> > 
> > > I think it might be more accurate to rename 'dir' to 'conf'.
> > 
> > Sure makes sense to rename it in the macro.
> > 
> > Regards,
> > 
> > Tony
> 
> Tony - would this be how the macro would need to be changed?
> 
> diff --git a/include/dt-bindings/pinctrl/omap.h b/include/dt-bindings/pinctrl/omap.h
> index 625718042413..2d2a8c737822 100644
> --- a/include/dt-bindings/pinctrl/omap.h
> +++ b/include/dt-bindings/pinctrl/omap.h
> @@ -65,7 +65,7 @@
>  #define DM814X_IOPAD(pa, val)          OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
>  #define DM816X_IOPAD(pa, val)          OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
>  #define AM33XX_IOPAD(pa, val)          OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
> -#define AM33XX_PADCONF(pa, dir, mux)   OMAP_IOPAD_OFFSET((pa), 0x0800) ((dir) | (mux))
> +#define AM33XX_PADCONF(pa, conf, mux)  OMAP_IOPAD_OFFSET((pa), 0x0800) (conf) (mux)
> 
>  /*
>   * Macros to allow using the offset from the padconf physical address

I've been looking at pinctrl-single.c further and now I am wondering if
it makes sense to modify pcs_parse_one_pinctrl_entry() or create a new
function.  Currently it does:

1020                 /* Index plus one value cell */
1021                 offset = pinctrl_spec.args[0];
1022                 vals[found].reg = pcs->base + offset;
1023                 vals[found].val = pinctrl_spec.args[1];

I believe it will need something similar to what is done in
pcs_parse_bits_in_pinctrl_entry():

1136                 /* Index plus two value cells */
1137                 offset = pinctrl_spec.args[0];
1138                 val = pinctrl_spec.args[1];
1139                 mask = pinctrl_spec.args[2];

So using #pinctrl-cells = <2> would require would require:

offset = pinctrl_spec.args[0];
vals[found].reg = pcs->base + offset;
vals[found].conf = pinctrl_spec.args[1];
vals[found].mux = pinctrl_spec.args[2];

However, the type of vals:

struct pcs_func_vals {
	void __iomem *reg;
	unsigned val;
	unsigned mask;
};

represents the combined mux + conf value in the register, so I think
pcs_conf_vals would need to used:

struct pcs_conf_vals {
	enum pin_config_param param;
	unsigned val;
	unsigned enable;
	unsigned disable;
	unsigned mask;
};

Thoughts?

thanks,
drew

  reply	other threads:[~2020-06-08 20:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26 12:21 pinctrl-single: num_maps in generic pinconf support? Drew Fustini
2020-05-27 16:51 ` Tony Lindgren
2020-05-27 22:19   ` Drew Fustini
2020-05-27 22:41     ` Tony Lindgren
2020-05-28 12:53       ` Drew Fustini
2020-05-29 17:40         ` Tony Lindgren
2020-06-08 18:05           ` Drew Fustini
2020-06-08 20:22             ` Drew Fustini [this message]
2020-06-09 18:04               ` Tony Lindgren
2020-06-09 17:55             ` Tony Lindgren
2020-05-29 17:55 ` Drew Fustini
2020-05-31  0:17   ` Drew Fustini
2020-06-08 12:09     ` Linus Walleij
2020-06-08 12:40       ` Drew Fustini

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=20200608202218.GA2891935@x1 \
    --to=drew@beagleboard.org \
    --cc=haojian.zhuang@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.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.