On Mon, Dec 09, 2013 at 11:22:44AM +0100, Linus Walleij wrote:
> On Thu, Dec 5, 2013 at 4:07 PM, Mark Brown wrote:
> > Or should we be going and applying the default state to all devices on
> > init without worrying about a driver appearing?
> That doesn't really work: if you have an unused
On Fri, Dec 6, 2013 at 12:54 AM, Stephen Warren wrote:
> On 12/03/2013 02:29 AM, Linus Walleij wrote:
(skipped the conversation on weak hogs, we are on the same page
here, just waiting for someone to start working on it ...)
> Related, I prefer to put /all/ static pinctrl configuration into the
On Thu, Dec 5, 2013 at 4:07 PM, 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
On Thu, Dec 5, 2013 at 4:07 PM, Mark Brown broo...@kernel.org 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
On Fri, Dec 6, 2013 at 12:54 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 12/03/2013 02:29 AM, Linus Walleij wrote:
(skipped the conversation on weak hogs, we are on the same page
here, just waiting for someone to start working on it ...)
Related, I prefer to put /all/ static pinctrl
On Mon, Dec 09, 2013 at 11:22:44AM +0100, Linus Walleij wrote:
On Thu, Dec 5, 2013 at 4:07 PM, Mark Brown broo...@kernel.org wrote:
Or should we be going and applying the default state to all devices on
init without worrying about a driver appearing?
That doesn't really work: if you have
On 12/03/2013 02:29 AM, Linus Walleij wrote:
...
> So I guess what you're after is a kind of hog that will be pushed
> aside and ignored if a struct device with an associated state appears
> that will use the same pin?
That probably would be useful. Perhaps we should just make all hogs not
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
On Thu, Dec 05, 2013 at 04:11:15PM +0100, Tomasz Figa wrote:
> On Thursday 05 of December 2013 15:07:47 Mark Brown wrote:
> > 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
On Thursday 05 of December 2013 18:49:56 Kevin Bracey wrote:
> 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
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
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
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
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
On Thursday 05 of December 2013 18:49:56 Kevin Bracey wrote:
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
On Thu, Dec 05, 2013 at 04:11:15PM +0100, Tomasz Figa wrote:
On Thursday 05 of December 2013 15:07:47 Mark Brown wrote:
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
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
On 12/03/2013 02:29 AM, Linus Walleij wrote:
...
So I guess what you're after is a kind of hog that will be pushed
aside and ignored if a struct device with an associated state appears
that will use the same pin?
That probably would be useful. Perhaps we should just make all hogs not
On Tuesday 03 of December 2013 10:31:12 Linus Walleij wrote:
> On Tue, Nov 26, 2013 at 1:30 AM, Tomasz Figa wrote:
>
> > IMHO a way to specify a default safe state of all pins (with lowest power
> > consumption, without possibility of glitching external devices, etc.)
> > would be really useful
On Tue, Nov 26, 2013 at 1:30 AM, Tomasz Figa wrote:
> IMHO a way to specify a default safe state of all pins (with lowest power
> consumption, without possibility of glitching external devices, etc.)
> would be really useful for Samsung platforms (and probably Renesas ones
> as Kevin wrote).
On Mon, Nov 25, 2013 at 9:01 PM, Kevin Bracey wrote:
> 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
On Mon, Nov 25, 2013 at 9:01 PM, Kevin Bracey ke...@bracey.fi wrote:
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
On Tue, Nov 26, 2013 at 1:30 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
IMHO a way to specify a default safe state of all pins (with lowest power
consumption, without possibility of glitching external devices, etc.)
would be really useful for Samsung platforms (and probably Renesas ones
as
On Tuesday 03 of December 2013 10:31:12 Linus Walleij wrote:
On Tue, Nov 26, 2013 at 1:30 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
IMHO a way to specify a default safe state of all pins (with lowest power
consumption, without possibility of glitching external devices, etc.)
would be
On Monday 25 of November 2013 22:01:42 Kevin Bracey wrote:
> On 25/11/2013 16:34, Linus Walleij wrote:
> > On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park wrote:
> >> On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren
> >> wrote:
> >>> I think that last point should be addressed by having a driver
On 25/11/2013 16:34, Linus Walleij wrote:
On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park wrote:
On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren 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
On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park wrote:
> On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren 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
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
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
On Monday 25 of November 2013 22:01:42 Kevin Bracey wrote:
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
On Tuesday 19 of November 2013 10:59:39 Doug Anderson wrote:
> On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren
> wrote:
> > On 11/19/2013 10:15 AM, Tomasz Figa wrote:
> >> This patch extends the range of settings configurable via pinfunc API
> >> to cover pin value as well. This allows
Hi Stephen,
On Tuesday 19 of November 2013 11:46:10 Stephen Warren wrote:
> On 11/19/2013 10:15 AM, Tomasz Figa wrote:
> > This patch extends the range of settings configurable via pinfunc API
> > to cover pin value as well. This allows configuration of default values
> > of pins.
>
> Shouldn't
On Tue, Nov 19, 2013 at 05:07:04PM -0700, Stephen Warren wrote:
> On 11/19/2013 05:02 PM, Kyungmin Park wrote:
> > 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.
On Tue, Nov 19, 2013 at 05:07:04PM -0700, Stephen Warren wrote:
On 11/19/2013 05:02 PM, Kyungmin Park wrote:
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.
Hmm.
Hi Stephen,
On Tuesday 19 of November 2013 11:46:10 Stephen Warren wrote:
On 11/19/2013 10:15 AM, Tomasz Figa wrote:
This patch extends the range of settings configurable via pinfunc API
to cover pin value as well. This allows configuration of default values
of pins.
Shouldn't there be
On Tuesday 19 of November 2013 10:59:39 Doug Anderson wrote:
On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 11/19/2013 10:15 AM, Tomasz Figa wrote:
This patch extends the range of settings configurable via pinfunc API
to cover pin value as well. This
On 11/19/2013 05:02 PM, Kyungmin Park wrote:
> On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren wrote:
>> On 11/19/2013 11:59 AM, Doug Anderson wrote:
>>> On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren
>>> wrote:
On 11/19/2013 10:15 AM, Tomasz Figa wrote:
> This patch extends the
On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren wrote:
> On 11/19/2013 11:59 AM, Doug Anderson wrote:
>> On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren
>> wrote:
>>> On 11/19/2013 10:15 AM, Tomasz Figa wrote:
This patch extends the range of settings configurable via pinfunc API
to
On 11/19/2013 11:59 AM, Doug Anderson wrote:
> On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren
> wrote:
>> On 11/19/2013 10:15 AM, Tomasz Figa wrote:
>>> This patch extends the range of settings configurable via pinfunc API
>>> to cover pin value as well. This allows configuration of default
On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren wrote:
> On 11/19/2013 10:15 AM, Tomasz Figa wrote:
>> This patch extends the range of settings configurable via pinfunc API
>> to cover pin value as well. This allows configuration of default values
>> of pins.
>
> Shouldn't there be a driver that
On 11/19/2013 10:15 AM, Tomasz Figa wrote:
> This patch extends the range of settings configurable via pinfunc API
> to cover pin value as well. This allows configuration of default values
> of pins.
Shouldn't there be a driver that acquires the GPIO that's output to the
pin, and configures the
This patch extends the range of settings configurable via pinfunc API
to cover pin value as well. This allows configuration of default values
of pins.
Signed-off-by: Tomasz Figa
Acked-by: Kyungmin Park
---
Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 1 +
This patch extends the range of settings configurable via pinfunc API
to cover pin value as well. This allows configuration of default values
of pins.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
On 11/19/2013 10:15 AM, Tomasz Figa wrote:
This patch extends the range of settings configurable via pinfunc API
to cover pin value as well. This allows configuration of default values
of pins.
Shouldn't there be a driver that acquires the GPIO that's output to the
pin, and configures the
On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 11/19/2013 10:15 AM, Tomasz Figa wrote:
This patch extends the range of settings configurable via pinfunc API
to cover pin value as well. This allows configuration of default values
of pins.
Shouldn't there be a
On 11/19/2013 11:59 AM, Doug Anderson wrote:
On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 11/19/2013 10:15 AM, Tomasz Figa wrote:
This patch extends the range of settings configurable via pinfunc API
to cover pin value as well. This allows configuration of
On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 11/19/2013 11:59 AM, Doug Anderson wrote:
On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 11/19/2013 10:15 AM, Tomasz Figa wrote:
This patch extends the range of settings
On 11/19/2013 05:02 PM, Kyungmin Park wrote:
On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 11/19/2013 11:59 AM, Doug Anderson wrote:
On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 11/19/2013 10:15 AM, Tomasz Figa wrote:
48 matches
Mail list logo