All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 00/22] SH pinctrl and pinmux implementation
Date: Tue, 08 Jan 2013 17:58:37 +0000	[thread overview]
Message-ID: <135769355.UnjMLfJSta@avalon> (raw)
In-Reply-To: <1357237073-15600-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Hi Linus,

On Tuesday 08 January 2013 10:49:32 Linus Walleij wrote:
> On Mon, Jan 7, 2013 at 2:27 PM, Laurent Pinchart wrote:
> > Would you have time to share your thoughts about the following issue
> > (copied from the cover letter of this patch series) ?
> > 
> > I ran into an issue when trying to port the bonito board (the only other
> > r8a7740 board in mainline) to the pinmux API. My board patches use system
> > pin control hogging to apply the initial pinmux configuration. This
> > mechanism requires registering the pinctrl mappings before registering
> > the pinctrl device, as the default states are selected when the pinctrl
> > device is registered. However, the mappings vary depending on board
> > configuration read through GPIOs, and the GPIOs are implemented by the
> > pinctrl driver. One possible solution would be to apply updates to the
> > selected state as mappings are registered, but that looks pretty complex
> > at first sight. Other ideas (or, better, patches :-)) are welcome.
> 
> Hm, yes today we require that mappings be in place before the pinctrl driver
> is registered in order for hogs to work.
> 
> With device tree I guess the problem goes away.
> 
> But I guess for those not using device tree it'd be nice to modify the map
> registration function to check if something needs to be hogged by an already
> existing device at that point. If you write a patch for this we can discuss
> it...
>
> There is another issue making it desireable to have mappings registered as
> early as possible, and that is my patch moving default pinctrl grabbing into
> the device core, but generally of course all devices need their maps in
> place before probing anyway.

That's exactly what I need :-) With that patch in place I can register the 
pinctrl device before registering the mappings, as long as the mappings are 
registered before their associated device.

Is there a chance the patch will make it to v3.9 ?

-- 
Regards,

Laurent Pinchart


      parent reply	other threads:[~2013-01-08 17:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-03 18:17 [PATCH 00/22] SH pinctrl and pinmux implementation Laurent Pinchart
2013-01-04 15:53 ` Linus Walleij
2013-01-07 13:27 ` Laurent Pinchart
2013-01-08  9:49 ` Linus Walleij
2013-01-08 17:58 ` Laurent Pinchart [this message]

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=135769355.UnjMLfJSta@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=linux-sh@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 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.