linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Drew Fustini <drew@beagleboard.org>
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: Tue, 9 Jun 2020 11:04:04 -0700	[thread overview]
Message-ID: <20200609180404.GR37466@atomide.com> (raw)
In-Reply-To: <20200608202218.GA2891935@x1>

* Drew Fustini <drew@beagleboard.org> [200608 20:23]:
> 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?

Yes sounds about right to me. On write the driver would just write
the register based on mux and conf and orr the values together
using configured shifts.

Not sure if #pinctrl-cells would ever be more than 2 in this
case, but having things generic where possible makes sense.

For example, the omap padconf wakeirq specific bits could
potentially configured with #pinctrl-cells = <3>. We now
handle them automatically as interrupts so there's really
nothing to configure there.

I don't if other SoCs might need to configure other options
beyond conf and mux in the dts. I guess it's safe to assume
nothing else needs to be configured and have the folks needing
more support add it as needed.

Regards,

Tony

  reply	other threads:[~2020-06-09 18:04 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
2020-06-09 18:04               ` Tony Lindgren [this message]
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=20200609180404.GR37466@atomide.com \
    --to=tony@atomide.com \
    --cc=drew@beagleboard.org \
    --cc=haojian.zhuang@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-omap@vger.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).