linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: b29396@freescale.com (Dong Aisheng)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] pinctrl: pinctrl-imx: add support for set bits for general purpose registers
Date: Mon, 9 Jul 2012 15:10:21 +0800	[thread overview]
Message-ID: <20120709071019.GA28527@shlinux2.ap.freescale.net> (raw)
In-Reply-To: <4FF709D1.40903@wwwdotorg.org>

On Fri, Jul 06, 2012 at 11:52:49PM +0800, Stephen Warren wrote:
> On 07/06/2012 03:09 AM, Dong Aisheng wrote:
> > From: Dong Aisheng <dong.aisheng@linaro.org>
> > 
> > The General Purpose Registers (GPR) is used to select operating modes for
> > general features in the SoC, usually not related to the IOMUX itself,
> > but it does belong to IOMUX controller.
> > We simply provide an convient API for driver to call to set the general purpose
> > register bits if needed.
> 
> > +static struct imx_pinctrl *imx_pinctrl;
> > +/*
> > + * Set bits for general purpose registers
> > + */
> > +void imx_pinctrl_set_gpr_register(u8 gpr, u8 start_bit, u8 num_bits, u32 value)
> > +{
> > +	u32 reg;
> > +
> > +	/* general purpose register is 32 bits size */
> > +	WARN_ON(!imx_pinctrl || start_bit > 31 || num_bits > 32);
> 
> Hmmm. It's going to be very hard to control the probe() order to ensure
> that this WARN doesn't fire all the time.
> 
Correct, if this api is used by client driver before the pinctrl driver is
registered, the warning will show.
To avoid it, the current pinctrl driver register priority is arch_initcall.
But maybe you're right, this may not be so sufficient since i'm afraid there
are still possible some devices may register earlier than pinctrl since it's not
controlled by pinctrl driver.
Then it's true that we need to resolve it.

> I think it would be better to pass in a struct imx_pinctrl* or DT node
> to this function. The DT node for the device that's using this function
> should contain a phandle to the pinctrl device node, which it uses to
> get that handle. Or in a non-DT case, the client driver needs to be
> given the provider driver handle using some other mechanism.
> 
> For example, look at how the Tegra30 SMMU uses services from the Tegra30
> AHB; see arch/arm/boot/dts/tegra30.dtsi node "smmu" (client) and node
> "ahb" (provider), drivers/iommu/tegra-smmu.c functions probe() (saves
> smmu->ahb) and smmu_setup_regs() (calls tegra_ahb_enable_smmu() with
> this handle) and drivers/amba/tegra-ahb.c function
> tegra_ahb_enable_smmu() (implements the deferred probe checking to
> correctly order the client/provider driver probing)
> 
Yes, i learned the code but i'm not sure it also fits for imx.
I have a few concerns:
1) i'm not sure if we really need the client to provide pinctrl device
node as parameter to set gpr registers since there is only one pinctrl device
for each imx soc. Client devices may also not want to care that parameter.
2) if passing device node to the api, that means every client driver
needs to define a phandle of pinctrl device in dts file and parsing it
in each driver respectively.
There're several client devices for imx6q, i'm not sure if it's worth to do that
considering this overhead.

I think either passing device node or not passing, the goal is the same,
guarantee this api to be used properly without being affected by driver
loading sequence.

If that, how about change to:
int imx_pinctrl_set_gpr_register(u8 gpr, u8 start_bit, u8 num_bits, u32 value)
{
        u32 reg;

	if (!imx_pinctrl)
		return -EDEFER_PROBE;

        /* general purpose register is 32 bits size */
        WARN_ON(start_bit > 31 || num_bits > 32);
...
}
EXPORT_SYMBOL_GPL(imx_pinctrl_set_gpr_register);

Then it looks to me it may be able to solve the same issue.

Regards
Dong Aisheng

  reply	other threads:[~2012-07-09  7:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-06  9:09 [PATCH 1/2] pinctrl: pinctrl-imx: add support for set bits for general purpose registers Dong Aisheng
2012-07-06  9:09 ` [PATCH 2/2] pinctrl: pinctrl-imx6q: add missed mux function for USBOTG_ID Dong Aisheng
2012-07-14 19:59   ` Linus Walleij
2012-07-06 15:52 ` [PATCH 1/2] pinctrl: pinctrl-imx: add support for set bits for general purpose registers Stephen Warren
2012-07-09  7:10   ` Dong Aisheng [this message]
2012-07-11  9:33     ` Richard Zhao
2012-07-11 11:35       ` Dong Aisheng
2012-07-14 20:24 ` Linus Walleij
2012-07-17  2:41   ` Dong Aisheng

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=20120709071019.GA28527@shlinux2.ap.freescale.net \
    --to=b29396@freescale.com \
    --cc=linux-arm-kernel@lists.infradead.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).