On Thu, Nov 1, 2012 at 3:01 PM, Linus Walleij wrote:
> On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown
> wrote:
>> On Thu, Nov 01, 2012 at 09:54:00AM +0100, Linus Walleij wrote:
>
>> For the pin hogging I'd actually been thinking separately that we should
>> just have the device core do a devm_pinctrl
On Tue, Oct 30, 2012 at 10:51:11PM +0100, Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
> > More seriously the amount of time we seem to have been spending recently
> > on changes which end up requiring us to go through essentially every
> > driver and add code to them (often
On Thu, Nov 01, 2012 at 03:01:28PM +0100, Linus Walleij wrote:
> On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown
>
> > For the pin hogging I'd actually been thinking separately that we should
> > just have the device core do a devm_pinctrl_get_set_default() prior to
> > probing the device and store the
On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown
wrote:
> On Thu, Nov 01, 2012 at 09:54:00AM +0100, Linus Walleij wrote:
> For the pin hogging I'd actually been thinking separately that we should
> just have the device core do a devm_pinctrl_get_set_default() prior to
> probing the device and store the
On Thu, Nov 1, 2012 at 12:42 PM, Kevin Hilman
wrote:
> [Me]
>> Well, the pinctrl grabbers in these drivers are using these states also
>> for platforms that do not even select CONFIG_PM. For example
>> mach-nomadik is quite happy that the PL011 driver is thusly
>> muxing in its pins. And would re
On Thu, Nov 01, 2012 at 09:54:00AM +0100, Linus Walleij wrote:
> Well, the pinctrl grabbers in these drivers are using these states also
> for platforms that do not even select CONFIG_PM. For example
> mach-nomadik is quite happy that the PL011 driver is thusly
> muxing in its pins. And would req
Linus Walleij writes:
> On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman
> wrote:
>
>> Linus Walleij writes:
>
>
>>
>> > piece of hardware, this would be the right thing to do,
>> > and I think the in-kernel examples are all "simple",
>> > e.g. arch/arm/mach-omap2/powerdomain* is all about
>> > po
On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman
wrote:
> Linus Walleij writes:
>
> > piece of hardware, this would be the right thing to do,
> > and I think the in-kernel examples are all "simple",
> > e.g. arch/arm/mach-omap2/powerdomain* is all about
> > power domains and nothing else,
>
> FYI
Linus Walleij writes:
> On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
> wrote:
>> On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
>
>>> Moving this handling to bus code or anywhere else
>>> invariably implies that resource acquisition/release order
>>> does not matter, and my point
On 21:12 Sun 28 Oct , Linus Walleij wrote:
> On Wed, Oct 24, 2012 at 7:28 PM, Dmitry Torokhov
> wrote:
>
> >> drivers/spi/spi-pl022.c
> >
> > Default/sleep transitions could be moved into bus code.
>
> No that's not a good idea as long as we have both the platform bus
> and the AMBA bus doin
On Tuesday, October 30, 2012 10:51:11 PM Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
> wrote:
>
> > More seriously the amount of time we seem to have been spending recently
> > on changes which end up requiring us to go through essentially every
> > driver and add code to t
On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
wrote:
> More seriously the amount of time we seem to have been spending recently
> on changes which end up requiring us to go through essentially every
> driver and add code to them (often several times) doesn't seem like
> we're doing a good job here.
Hi,
On Tue, Oct 30, 2012 at 11:20:07AM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> > On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
> > >
> > > But then this comes round to the mindless code that ought to be factored
> > > out :) O
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
> > But then this comes round to the mindless code that ought to be factored
> > out :) Only the more interesting cases that do something unusual really
> > register here.
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
> >
> > But then this comes round to the mindless code that ought to be factored
> > out :) Only the more interesting cases that do something unusual really
> > register her
Hi,
On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
> > > > and this is one of the issues we're all trying to solve today so we have
> > > > single zImage approach for the ARM port.
>
> > > I don't see the relevance of single zImage here; device tree is supposed
> > > to solve that on
On Tue, Oct 30, 2012 at 05:16:42PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 02:07:15PM +, Mark Brown wrote:
> > > and all of that SoC-specific detail is already hidden behind power
> > > domains, runtime PM, pinctrl, clk API, regulator framework, etc.
> > That's all getting rather
Hi,
On Tue, Oct 30, 2012 at 02:07:15PM +, Mark Brown wrote:
> On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote:
> > On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
>
> > > We need some place to put the SoC integration; power domains seem like
> > > the obvious place to
On Tue, Oct 30, 2012 at 03:16:02PM +0100, Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 3:07 PM, Mark Brown
> > Essentially all the patches I'm seeing adding pinctrl are totally
> > mindless, most of them are just doing the initial setup on boot and not
> > doing any active management at runtime
On Tue, Oct 30, 2012 at 03:02:23PM +0100, Linus Walleij wrote:
> I worry that we will end up with power/resource domain
> code that start to look like this:
> suspend()
> switch (device.id) {
> case DEV_FOO:
> clk_disable();
> pinctrl_set_state();
> power_domain_off();
> case DEV_BAR:
Well
On Tue, Oct 30, 2012 at 3:07 PM, Mark Brown
wrote:
> Essentially all the patches I'm seeing adding pinctrl are totally
> mindless, most of them are just doing the initial setup on boot and not
> doing any active management at runtime at all.
None of the Ux500 pinctrl patches are like that.
I co
On Tue, Oct 30, 2012 at 12:49 PM, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
>> We need some place to put the SoC integration; power domains seem like
>> the obvious place to me but YMMV. Nothing about having this out of the
>
> except that pin muxing has n
On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
> > We need some place to put the SoC integration; power domains seem like
> > the obvious place to me but YMMV. Nothing about having this out of the
> except that pin muxi
On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
wrote:
> On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
>> Moving this handling to bus code or anywhere else
>> invariably implies that resource acquisition/release order
>> does not matter, and my point is that it does.
>
> Doing this
Hi,
On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
> > This is why I think hiding things from drivers makes no sense. Also
> > consider the situations Linus W exposed on another subthread. If you
> > change ordering of certain calls, you will really break the
> > functionality of the
On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
> The answer is that it does not know. Because drivers have
> different needs. Depending on how the hardware and
> system is done.
...
> I'm not making this up, it is a very real phenomenon on the
> Ux500 and I don't think we are uni
On Mon, Oct 29, 2012 at 09:49:01PM +0200, Felipe Balbi wrote:
> On Fri, Oct 26, 2012 at 05:03:16PM +0100, Mark Brown wrote:
> > You could have the driver explicitly set the flag, it would just be one
> > extra line, but it seems marginally nicer to just do it.
> You didn't get the whole picture I
Hi,
On Fri, Oct 26, 2012 at 05:03:16PM +0100, Mark Brown wrote:
> On Fri, Oct 26, 2012 at 09:20:36AM +0300, Felipe Balbi wrote:
> > On Thu, Oct 25, 2012 at 09:59:01PM +0100, Mark Brown wrote:
>
> > > I suspect that's not actually a big deal and that if we went down this
> > > route we'd have the
On Wed, Oct 24, 2012 at 7:28 PM, Dmitry Torokhov
wrote:
>> drivers/spi/spi-pl022.c
>
> Default/sleep transitions could be moved into bus code.
No that's not a good idea as long as we have both the platform bus
and the AMBA bus doing essentially the same thing. We will then be
having two copies o
On Fri, Oct 26, 2012 at 09:20:36AM +0300, Felipe Balbi wrote:
> On Thu, Oct 25, 2012 at 09:59:01PM +0100, Mark Brown wrote:
> > I suspect that's not actually a big deal and that if we went down this
> > route we'd have the driver take over control from the core code during
> > probe() with the cor
Hi,
On Thu, Oct 25, 2012 at 09:59:01PM +0100, Mark Brown wrote:
> On Wed, Oct 24, 2012 at 09:58:19PM +0300, Felipe Balbi wrote:
>
> > need a way to tell drivers/base "hey, don't touch pinctrl at all because
> > I know what I'm doing" and that has to happen before probe() too,
> > otherwise it's a
On Wed, Oct 24, 2012 at 09:58:19PM +0300, Felipe Balbi wrote:
> need a way to tell drivers/base "hey, don't touch pinctrl at all because
> I know what I'm doing" and that has to happen before probe() too,
> otherwise it's already too late and, according to what you suggest,
> drivers/base will alr
Hi,
On Wed, Oct 24, 2012 at 12:38:44PM -0700, Dmitry Torokhov wrote:
> On Wednesday, October 24, 2012 10:10:42 PM Felipe Balbi wrote:
> > >
> > >
> > > That is a valid concern and we'll need to find a compromise here. As I
> > > said,
> > WHAT ?? Silicon erratas are not a valid concern ? Power wa
On Wednesday, October 24, 2012 10:10:42 PM Felipe Balbi wrote:
> >
> >
> > That is a valid concern and we'll need to find a compromise here. As I
> > said,
> WHAT ?? Silicon erratas are not a valid concern ? Power waste isn't a
> valid concern ? Tell that to the millions of devices shipped with Li
Hi,
On Wed, Oct 24, 2012 at 10:58:53AM -0700, Dmitry Torokhov wrote:
> On Wednesday, October 24, 2012 07:57:49 PM Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote:
> > > On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> > > > On Tu
Hi,
On Wed, Oct 24, 2012 at 10:28:46AM -0700, Dmitry Torokhov wrote:
> > for more complex pinctrl use cases. These are my dogfood drivers ...
> > Most of these will request more than one state and switch the driver
> > between these different states at runtime, in these examples for power
> > savi
On Wednesday, October 24, 2012 07:57:49 PM Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote:
> > On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> > > On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
> > >
> > > wrote:
> > > > I have s
Hi Dmitry,
On 10/24/2012 06:14 PM, Dmitry Torokhov wrote:
> On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote:
>> Hi,
>>
>> On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote:
>>> On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
Hi Dimitry,
On
On Wednesday, October 24, 2012 07:52:16 PM Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 24, 2012 at 09:14:29AM -0700, Dmitry Torokhov wrote:
>
>
>
> > > > No, I guess we ihave different understanding of what "directly use"
> > > > means.
> > > > This particular driver does directly use interrupts:
On Wednesday, October 24, 2012 06:51:47 PM Linus Walleij wrote:
> On Wed, Oct 24, 2012 at 6:14 PM, Dmitry Torokhov
>
> wrote:
> > On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote:
> >> - we ask another layer to allocate memory for us
> >> - we ask another layer to call our ISR once th
On Wed, Oct 24, 2012 at 6:57 PM, Felipe Balbi wrote:
> On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote:
>> OK, so with drivers/base/, have you considered doing default pinctrl
>> selection in bus's probe() methods? Yo would select the default
>> configuration before starting probin
On Wed, Oct 24, 2012 at 6:52 PM, Felipe Balbi wrote:
> On Wed, Oct 24, 2012 at 09:14:29AM -0700, Dmitry Torokhov wrote:
>> All of _their_ resources, exactly. They do not own nor control pins so
>> they should not be bothered with them either. Look, when you see that
>
> except that they *own* the
Hi,
On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> > On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
> > wrote:
> >
> > > I have seen just in a few days 3 or 4 drivers having exactly the same
> > > change - ca
On Wed, Oct 24, 2012 at 6:18 PM, Dmitry Torokhov
wrote:
> On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
>>
>> A third alternative as outlined is to use notifiers and some
>> resource core in drivers/base/*
>
> OK, so with drivers/base/, have you considered doing default pinctrl
>
Hi,
On Wed, Oct 24, 2012 at 09:14:29AM -0700, Dmitry Torokhov wrote:
> > > No, I guess we ihave different understanding of what "directly use" means.
> > > This particular driver does directly use interrupts: it requests it and
> > > performs some actions when interrupt arrives. Same goes for I
On Wed, Oct 24, 2012 at 6:14 PM, Dmitry Torokhov
wrote:
> On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote:
>> - we ask another layer to allocate memory for us
>> - we ask another layer to call our ISR once the IRQ line is asserted
>> - we ask another layer to handle the input events
On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
> wrote:
>
> > I have seen just in a few days 3 or 4 drivers having exactly the same
> > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > receive the same p
On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote:
> > On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
> > > Hi Dimitry,
> > >
> > > On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> > > > Hi Sour
On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
wrote:
> I have seen just in a few days 3 or 4 drivers having exactly the same
> change - call to devm_pinctrl_get_select_default(), and I guess I will
> receive the same patches for the rest of input drivers shortly.
> This suggests that the oper
Hi,
On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
> > Hi Dimitry,
> >
> > On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> > > Hi Sourav,
> > >
> > > On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote
On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
> Hi Dimitry,
>
> On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> > Hi Sourav,
> >
> > On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> >> Adapt keypad to use pinctrl framework.
> >>
> >> Tested on omap4430 sdp with
Hi,
(please don't top-post)
On Tue, Oct 23, 2012 at 07:51:22AM -1000, Mitch Bradley wrote:
> Perhaps I misunderstood what you were suggesting. I thought that, when
> you said "explicitly manage all their resources", you meant that the
> driver should know the platform-specific details about cloc
Perhaps I misunderstood what you were suggesting. I thought that, when
you said "explicitly manage all their resources", you meant that the
driver should know the platform-specific details about clocks and power
domains. That is one possible interpretation of the word "explicit".
Now I see that
HI,
On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
> On 10/23/2012 12:03 AM, Felipe Balbi wrote:
> > Hi,
> >
> > I much prefer having drivers explicitly manage all their resources,
> > which would mean that pinctrl calls need to be done on probe() and, if
> > necessary, during sus
On 10/23/2012 12:03 AM, Felipe Balbi wrote:
> Hi,
>
> I much prefer having drivers explicitly manage all their resources,
> which would mean that pinctrl calls need to be done on probe() and, if
> necessary, during suspend()/resume().
Per-driver resource management is certainly convenient when y
On Tue, 23 Oct 2012 12:45:33 +0200, Linus Walleij wrote:
> Hm so I have had this idea of runtime PM core helping out
> with pins, so I could add something like
>
> pm_pins_fetch()
> pm_pins_default()
> pm_pins_idle()
> pm_pins_sleep()
>
> So if one is using the pin states defined in
> then the
Hi,
On Tue, Oct 23, 2012 at 12:45:33PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi wrote:
> > On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
>
> >> So the biggest implementation of the notifier approach to resource
> >> handling is the SH clock th
On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi wrote:
> On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
>> So the biggest implementation of the notifier approach to resource
>> handling is the SH clock thing:
>> drivers/base/power/clock_ops.c
>
> that's different right ? It's just
Hi,
On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
> wrote:
> >
> > On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
> >
> >> > But it appears that shmobile prefer to get all resources using
> >> > bus notifiers.
> >> >
>
On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
wrote:
>
> On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
>
>> > But it appears that shmobile prefer to get all resources using
>> > bus notifiers.
>> >
>> > So we need to form some kind of consensus ... or live with
>> > the fact that di
On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
> > But it appears that shmobile prefer to get all resources using
> > bus notifiers.
> >
> > So we need to form some kind of consensus ... or live with
> > the fact that different systems do it different ways. Which will
> > explode the da
Hi,
On Tue, Oct 23, 2012 at 12:04:01PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson wrote:
> > On 10/23/2012 11:13 AM, Linus Walleij wrote:
>
> >> So Sourav, please tell us a bit about your plans for this
> >> and other drivers!
> >
> > Yeah, this idea is to han
On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson wrote:
> On 10/23/2012 11:13 AM, Linus Walleij wrote:
>> So Sourav, please tell us a bit about your plans for this
>> and other drivers!
>
> Yeah, this idea is to handle pinctrl from all the drivers, and
> potentially change the mode during suspend
Hi Linus,
On 10/23/2012 11:13 AM, Linus Walleij wrote:
> On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
> wrote:
>> Hi Sourav,
>>
>> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>>> Adapt keypad to use pinctrl framework.
>>>
>>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>>
>
Hi Dimitry,
On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> Hi Sourav,
>
> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>> Adapt keypad to use pinctrl framework.
>>
>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>
> I do not see anything in the driver that would directly use p
On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
wrote:
> Hi Sourav,
>
> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>> Adapt keypad to use pinctrl framework.
>>
>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>
> I do not see anything in the driver that would directly use pinctr
Hi Sourav,
On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> Adapt keypad to use pinctrl framework.
>
> Tested on omap4430 sdp with 3.7-rc1 kernel.
I do not see anything in the driver that would directly use pinctrl. Is
there a better place to select default pin configuration; may
Adapt keypad to use pinctrl framework.
Tested on omap4430 sdp with 3.7-rc1 kernel.
Cc: Felipe Balbi
Cc: Dmitry Torokhov
Signed-off-by: Sourav Poddar
---
v1->v2
- Added "PROBE_DEFER" check
drivers/input/keyboard/omap4-keypad.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions
68 matches
Mail list logo
