All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Bracey <kevin@bracey.fi>
To: Tomasz Figa <t.figa@samsung.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"Kyungmin Park" <kmpark@infradead.org>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Stephen Warren" <swarren@wwwdotorg.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Doug Anderson" <dianders@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Mark Brown" <broonie@kernel.org>,
	"Thomas Abraham" <thomas.abraham@linaro.org>,
	"Kukjin Kim" <kgene.kim@samsung.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
Date: Thu, 05 Dec 2013 18:49:56 +0200	[thread overview]
Message-ID: <52A0AEB4.7090909@bracey.fi> (raw)
In-Reply-To: <1502243.eRBlCfUhTO@amdc1227>

On 05/12/2013 17:11, Tomasz Figa wrote:
> On Thursday 05 of December 2013 15:07:47 Mark Brown wrote:
>> On Tue, Dec 03, 2013 at 10:29:42AM +0100, Linus Walleij wrote:
>>
>>> So a suggested patch to support weak hogs would be interesting
>>> to look at. Can you provide details on how you think this would
>>> work?
>> Or should we be going and applying the default state to all devices on
>> init without worrying about a driver appearing?
> If a device isn't used, then it's often better to configure the pins for
> a different function, such as GPIO, to minimize leakage current.
>

And there can also be mutually-exclusive drivers choosing different 
default states for the same pin. I think you do need a separate "safe" 
indicator.

My current thought is that  a late-init "make safe all unclaimed pins" 
pass would make sense - you can't really mess with pins in an automated 
fashion on init, as it can mess up bootloader->driver handover.   There 
already exist late-init "turn off all unclaimed clocks" (at least on 
shmobile) and "turn off all unclaimed regulators", and it would fit that 
model.

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: kevin@bracey.fi (Kevin Bracey)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
Date: Thu, 05 Dec 2013 18:49:56 +0200	[thread overview]
Message-ID: <52A0AEB4.7090909@bracey.fi> (raw)
In-Reply-To: <1502243.eRBlCfUhTO@amdc1227>

On 05/12/2013 17:11, Tomasz Figa wrote:
> On Thursday 05 of December 2013 15:07:47 Mark Brown wrote:
>> On Tue, Dec 03, 2013 at 10:29:42AM +0100, Linus Walleij wrote:
>>
>>> So a suggested patch to support weak hogs would be interesting
>>> to look at. Can you provide details on how you think this would
>>> work?
>> Or should we be going and applying the default state to all devices on
>> init without worrying about a driver appearing?
> If a device isn't used, then it's often better to configure the pins for
> a different function, such as GPIO, to minimize leakage current.
>

And there can also be mutually-exclusive drivers choosing different 
default states for the same pin. I think you do need a separate "safe" 
indicator.

My current thought is that  a late-init "make safe all unclaimed pins" 
pass would make sense - you can't really mess with pins in an automated 
fashion on init, as it can mess up bootloader->driver handover.   There 
already exist late-init "turn off all unclaimed clocks" (at least on 
shmobile) and "turn off all unclaimed regulators", and it would fit that 
model.

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Bracey <kevin@bracey.fi>
To: Tomasz Figa <t.figa@samsung.com>
Cc: "Mark Brown" <broonie@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Kyungmin Park" <kmpark@infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Stephen Warren" <swarren@wwwdotorg.org>,
	"Doug Anderson" <dianders@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Kukjin Kim" <kgene.kim@samsung.com>,
	"Thomas Abraham" <thomas.abraham@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
Date: Thu, 05 Dec 2013 18:49:56 +0200	[thread overview]
Message-ID: <52A0AEB4.7090909@bracey.fi> (raw)
In-Reply-To: <1502243.eRBlCfUhTO@amdc1227>

On 05/12/2013 17:11, Tomasz Figa wrote:
> On Thursday 05 of December 2013 15:07:47 Mark Brown wrote:
>> On Tue, Dec 03, 2013 at 10:29:42AM +0100, Linus Walleij wrote:
>>
>>> So a suggested patch to support weak hogs would be interesting
>>> to look at. Can you provide details on how you think this would
>>> work?
>> Or should we be going and applying the default state to all devices on
>> init without worrying about a driver appearing?
> If a device isn't used, then it's often better to configure the pins for
> a different function, such as GPIO, to minimize leakage current.
>

And there can also be mutually-exclusive drivers choosing different 
default states for the same pin. I think you do need a separate "safe" 
indicator.

My current thought is that  a late-init "make safe all unclaimed pins" 
pass would make sense - you can't really mess with pins in an automated 
fashion on init, as it can mess up bootloader->driver handover.   There 
already exist late-init "turn off all unclaimed clocks" (at least on 
shmobile) and "turn off all unclaimed regulators", and it would fit that 
model.

Kevin


  reply	other threads:[~2013-12-05 16:49 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19 17:15 [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc Tomasz Figa
2013-11-19 17:15 ` Tomasz Figa
2013-11-19 18:46 ` Stephen Warren
2013-11-19 18:46   ` Stephen Warren
2013-11-19 18:59   ` Doug Anderson
2013-11-19 18:59     ` Doug Anderson
2013-11-19 19:16     ` Stephen Warren
2013-11-19 19:16       ` Stephen Warren
2013-11-20  0:02       ` Kyungmin Park
2013-11-20  0:02         ` Kyungmin Park
2013-11-20  0:07         ` Stephen Warren
2013-11-20  0:07           ` Stephen Warren
2013-11-20 12:51           ` Mark Brown
2013-11-20 12:51             ` Mark Brown
2013-11-25 14:34         ` Linus Walleij
2013-11-25 14:34           ` Linus Walleij
2013-11-25 20:01           ` Kevin Bracey
2013-11-25 20:01             ` Kevin Bracey
2013-11-25 20:01             ` Kevin Bracey
2013-11-26  0:30             ` Tomasz Figa
2013-11-26  0:30               ` Tomasz Figa
2013-12-03  9:31               ` Linus Walleij
2013-12-03  9:31                 ` Linus Walleij
2013-12-03  9:33                 ` Tomasz Figa
2013-12-03  9:33                   ` Tomasz Figa
2013-12-03  9:29             ` Linus Walleij
2013-12-03  9:29               ` Linus Walleij
2013-12-05 15:07               ` Mark Brown
2013-12-05 15:07                 ` Mark Brown
2013-12-05 15:11                 ` Tomasz Figa
2013-12-05 15:11                   ` Tomasz Figa
2013-12-05 16:49                   ` Kevin Bracey [this message]
2013-12-05 16:49                     ` Kevin Bracey
2013-12-05 16:49                     ` Kevin Bracey
2013-12-05 17:03                     ` Tomasz Figa
2013-12-05 17:03                       ` Tomasz Figa
2013-12-05 18:00                   ` Mark Brown
2013-12-05 18:00                     ` Mark Brown
2013-12-09 10:22                 ` Linus Walleij
2013-12-09 10:22                   ` Linus Walleij
2013-12-09 17:04                   ` Mark Brown
2013-12-09 17:04                     ` Mark Brown
     [not found]               ` <CACRpkdYrPd9tnO48bA_5n+-k=KEDyhY7czkCNhTZfpgF3ar+LQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-05 23:54                 ` Stephen Warren
2013-12-05 23:54                   ` Stephen Warren
2013-12-05 23:54                   ` Stephen Warren
2013-12-09 12:57                   ` Linus Walleij
2013-12-09 12:57                     ` Linus Walleij
2013-11-20 14:57     ` Tomasz Figa
2013-11-20 14:57       ` Tomasz Figa
2013-11-20 13:38   ` Tomasz Figa
2013-11-20 13:38     ` Tomasz Figa

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=52A0AEB4.7090909@bracey.fi \
    --to=kevin@bracey.fi \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=kgene.kim@samsung.com \
    --cc=kmpark@infradead.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=swarren@wwwdotorg.org \
    --cc=t.figa@samsung.com \
    --cc=thomas.abraham@linaro.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.