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 devi
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 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
exclusi
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?
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
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 int
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 ab
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 f
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).
I'm
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 stat
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 t
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 o
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 (NC)
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 configura
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 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 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 range
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 co
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 val
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 ou
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 +
drivers/pinctrl/pinc
24 matches
Mail list logo
