All of lore.kernel.org
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: An extremely simplified pinctrl bindings proposal
Date: Mon, 6 Feb 2012 15:57:33 -0800	[thread overview]
Message-ID: <20120206235733.GY1426@atomide.com> (raw)
In-Reply-To: <CACRpkdYrbD3PpJ3wb69yb3Ya8SeZJnPpgJdtttjWTkS5xsD-4g@mail.gmail.com>

* Linus Walleij <linus.walleij@linaro.org> [120206 14:44]:
> On Mon, Feb 6, 2012 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
> 
> >> I actually had something like unnamed pins in the early patches
> >> to register a bunch of anonymous pins ranges, so why not bring
> >> it back in.
> >
> > Yeah it seems that the mux registers should be listed, it might
> > require a little bit of thinking for cases where one register
> > controls multiple pins. So maybe we need just a new entry for
> > mux registers?
> 
> I'm not sure if I'm following completely, if this is inside the devicetree-based
> driver file, would it work to just add a struct dentry * to the
> pinctrl_desc where you put a per-driver file?

I was thinking generic debufs entries for all drivers.
 
> Or maybe add extern void pinctrl_add_debugfs(struct dentry *) that adds
> a new file to the existing per-driver directory through the core and then
> have this add that file?

Sounds like you've thought it further than me already :)

Maybe that's the way to go to solve the one register for
multiple pins issue.
 
> Or did you mean that the core.c should be register-aware?

I was just thinking string name ignoring core.c, so that would
be the pinctrl_add_debugfs() option then. Do you see problems
with this approach?

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org"
	<cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>,
	Dong Aisheng <dongas86-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
	<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
	"Sascha Hauer (s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org)"
	<s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org"
	<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	"kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org"
	<kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: An extremely simplified pinctrl bindings proposal
Date: Mon, 6 Feb 2012 15:57:33 -0800	[thread overview]
Message-ID: <20120206235733.GY1426@atomide.com> (raw)
In-Reply-To: <CACRpkdYrbD3PpJ3wb69yb3Ya8SeZJnPpgJdtttjWTkS5xsD-4g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

* Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [120206 14:44]:
> On Mon, Feb 6, 2012 at 10:04 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> 
> >> I actually had something like unnamed pins in the early patches
> >> to register a bunch of anonymous pins ranges, so why not bring
> >> it back in.
> >
> > Yeah it seems that the mux registers should be listed, it might
> > require a little bit of thinking for cases where one register
> > controls multiple pins. So maybe we need just a new entry for
> > mux registers?
> 
> I'm not sure if I'm following completely, if this is inside the devicetree-based
> driver file, would it work to just add a struct dentry * to the
> pinctrl_desc where you put a per-driver file?

I was thinking generic debufs entries for all drivers.
 
> Or maybe add extern void pinctrl_add_debugfs(struct dentry *) that adds
> a new file to the existing per-driver directory through the core and then
> have this add that file?

Sounds like you've thought it further than me already :)

Maybe that's the way to go to solve the one register for
multiple pins issue.
 
> Or did you mean that the core.c should be register-aware?

I was just thinking string name ignoring core.c, so that would
be the pinctrl_add_debugfs() option then. Do you see problems
with this approach?

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Stephen Warren <swarren@nvidia.com>,
	Dong Aisheng <dongas86@gmail.com>,
	Shawn Guo <shawn.guo@linaro.org>,
	Dong Aisheng-B29396 <B29396@freescale.com>,
	"Sascha Hauer (s.hauer@pengutronix.de)" <s.hauer@pengutronix.de>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"cjb@laptop.org" <cjb@laptop.org>,
	"Simon Glass (sjg@chromium.org)" <sjg@chromium.org>,
	Thomas Abraham <thomas.abraham@linaro.org>,
	"Grant Likely (grant.likely@secretlab.ca)" 
	<grant.likely@secretlab.ca>,
	"devicetree-discuss@lists.ozlabs.org" 
	<devicetree-discuss@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: An extremely simplified pinctrl bindings proposal
Date: Mon, 6 Feb 2012 15:57:33 -0800	[thread overview]
Message-ID: <20120206235733.GY1426@atomide.com> (raw)
In-Reply-To: <CACRpkdYrbD3PpJ3wb69yb3Ya8SeZJnPpgJdtttjWTkS5xsD-4g@mail.gmail.com>

* Linus Walleij <linus.walleij@linaro.org> [120206 14:44]:
> On Mon, Feb 6, 2012 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
> 
> >> I actually had something like unnamed pins in the early patches
> >> to register a bunch of anonymous pins ranges, so why not bring
> >> it back in.
> >
> > Yeah it seems that the mux registers should be listed, it might
> > require a little bit of thinking for cases where one register
> > controls multiple pins. So maybe we need just a new entry for
> > mux registers?
> 
> I'm not sure if I'm following completely, if this is inside the devicetree-based
> driver file, would it work to just add a struct dentry * to the
> pinctrl_desc where you put a per-driver file?

I was thinking generic debufs entries for all drivers.
 
> Or maybe add extern void pinctrl_add_debugfs(struct dentry *) that adds
> a new file to the existing per-driver directory through the core and then
> have this add that file?

Sounds like you've thought it further than me already :)

Maybe that's the way to go to solve the one register for
multiple pins issue.
 
> Or did you mean that the core.c should be register-aware?

I was just thinking string name ignoring core.c, so that would
be the pinctrl_add_debugfs() option then. Do you see problems
with this approach?

Regards,

Tony

  reply	other threads:[~2012-02-06 23:57 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-05  5:31 An extremely simplified pinctrl bindings proposal Stephen Warren
2012-02-05  5:31 ` Stephen Warren
2012-02-05  5:31 ` Stephen Warren
2012-02-05  6:07 ` Richard Zhao
2012-02-05  6:07   ` Richard Zhao
2012-02-05  6:07   ` Richard Zhao
2012-02-06  3:07 ` Thomas Abraham
2012-02-06  3:07   ` Thomas Abraham
2012-02-06  5:44   ` Stephen Warren
2012-02-06  5:44     ` Stephen Warren
2012-02-06  4:20 ` Linus Walleij
2012-02-06  4:20   ` Linus Walleij
2012-02-06  5:53   ` Stephen Warren
2012-02-06  5:53     ` Stephen Warren
2012-02-06  5:53     ` Stephen Warren
2012-02-06 17:29     ` Linus Walleij
2012-02-06 17:29       ` Linus Walleij
2012-02-06 19:03       ` Tony Lindgren
2012-02-06 19:03         ` Tony Lindgren
2012-02-06 19:03         ` Tony Lindgren
2012-02-06 19:56         ` Linus Walleij
2012-02-06 19:56           ` Linus Walleij
2012-02-06 19:56           ` Linus Walleij
2012-02-06 21:04           ` Tony Lindgren
2012-02-06 21:04             ` Tony Lindgren
2012-02-06 21:04             ` Tony Lindgren
2012-02-06 23:15             ` Linus Walleij
2012-02-06 23:15               ` Linus Walleij
2012-02-06 23:57               ` Tony Lindgren [this message]
2012-02-06 23:57                 ` Tony Lindgren
2012-02-06 23:57                 ` Tony Lindgren
2012-02-07  1:07                 ` Linus Walleij
2012-02-07  1:07                   ` Linus Walleij
2012-02-07  1:07                   ` Linus Walleij
2012-02-07  5:28         ` Stephen Warren
2012-02-07  5:28           ` Stephen Warren
2012-02-06 19:41     ` Mark Brown
2012-02-06 19:41       ` Mark Brown
2012-02-06 19:41       ` Mark Brown
2012-02-06 18:57 ` Tony Lindgren
2012-02-06 18:57   ` Tony Lindgren
2012-02-06 18:57   ` Tony Lindgren
2012-02-06 19:05 ` Mitch Bradley
2012-02-06 19:05   ` Mitch Bradley
2012-02-06 19:05   ` Mitch Bradley
2012-02-06 19:26   ` Linus Walleij
2012-02-06 19:26     ` Linus Walleij
2012-02-06 21:24     ` Mitch Bradley
2012-02-06 21:24       ` Mitch Bradley
2012-02-06 21:24       ` Mitch Bradley
2012-02-07  5:33   ` Stephen Warren
2012-02-07  5:33     ` Stephen Warren
2012-02-07  5:33     ` Stephen Warren
2012-02-07  7:07     ` Mitch Bradley
2012-02-07  7:07       ` Mitch Bradley
2012-02-07  7:07       ` Mitch Bradley

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=20120206235733.GY1426@atomide.com \
    --to=tony@atomide.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 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.