Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

[Kevin Bracey]

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

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.

[Kevin Bracey]

On 25/11/2013 16:34, Linus Walleij wrote:

On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park kmp...@infradead.org wrote:

On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote:

I think that last point should be addressed by having a driver that owns
the GPIO set it to the desired output level, and the implementation of

Some pins are not connected (NC). At that cases, there's no drivers to
handle it. To reduce power leakage, it sets proper configuration with
values instead of reset values.

This is correspondant to the PIN_CONFIG_OUTPUT from
include/linux/pinctrl/pinconf-generic.h


Indeed it is - I was waiting for someone to point that out. Now we've 
got there...


I've been working on extending the shmobile PFC driver to provide 
gpio-mode and implement PIN_CONFIG_OUTPUT as described by 
Documentation/pinctrl.txt, primarily to handle sleep states, but I have 
begun to wonder about the initial state problem, as discussed here.


As far as I can see, we can't currently specify fallback states for 
pins, which is one of Tomasz' key requirements.


We can specify hog states, and we can specify default for a driver, 
but not default before/in absence of a driver or sleep in absence of 
a driver. Having a hog precludes any finer driver control, AFAICT.


Some of our existing pre-pinconf board files have a unused pins table 
which is used to claim and pull GPIOs. I've converted that to hog 
pinconf, but that only works because the table omits all pins used by 
drivers. And, unsurprisingly, that's been error-prone; if those tables 
originally covered all unused pins, they don't any more.


I'd like confidence that we can get every pin into the correct state by 
having a fully-populated table containing all pins, that can be used 
regardless of which drivers start. I think what we're lacking is a weak 
hog. Whatever you call that. :)


That would also specify the state to fallback to when a group is 
released (where we currently do pinmux_disable_setting).


Thoughts?

Kevin


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html