On Thu, Nov 1, 2012 at 3:01 PM, Linus Walleij linus.wall...@linaro.org wrote:
On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
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 Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Linus Walleij linus.wall...@linaro.org 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
Linus Walleij linus.wall...@linaro.org writes:
On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Linus Walleij linus.wall...@linaro.org writes:
piece of hardware, this would be the right thing to do,
and I think the in-kernel examples are all simple,
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
On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
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 result
On 21:12 Sun 28 Oct , Linus Walleij wrote:
On Wed, Oct 24, 2012 at 7:28 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
Linus Walleij linus.wall...@linaro.org writes:
On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
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 IP.
On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
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 muxing
On Tue, Oct 30, 2012 at 12:49 PM, Felipe Balbi ba...@ti.com 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
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, if
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 at
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 me but
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 open
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 one.
DT is
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 here.
fair
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 :) Only the
On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
On Tuesday, October 30, 2012 10:51:11 PM Linus Walleij wrote:
On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
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 driver
On Wed, Oct 24, 2012 at 7:28 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
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 already
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 core
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 already
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:
Adapt
On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
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 Sourav,
On
On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
On Wed, Oct 24, 2012 at 6:14 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
Hi,
On Wed, Oct 24, 2012 at 09:14:29AM -0700, Dmitry Torokhov wrote:
snip
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 IO
On Wed, Oct 24, 2012 at 6:18 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
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
dmitry.torok...@gmail.com wrote:
I have seen just in a few days 3 or 4 drivers having exactly the same
On Wed, Oct 24, 2012 at 6:52 PM, Felipe Balbi ba...@ti.com 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
On Wed, Oct 24, 2012 at 6:57 PM, Felipe Balbi ba...@ti.com 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
On Wednesday, October 24, 2012 06:51:47 PM Linus Walleij wrote:
On Wed, Oct 24, 2012 at 6:14 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
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:
snip
No, I guess we ihave different understanding of what directly use
means.
This particular driver does directly use interrupts: it requests it
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 10/22/2012 05:50 PM,
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
dmitry.torok...@gmail.com wrote:
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
saving
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 Tue, Oct 23,
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 Linux
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 waste isn't a
On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
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 pinctrl. Is
Hi Linus,
On 10/23/2012 11:13 AM, Linus Walleij wrote:
On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
dmitry.torok...@gmail.com 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
On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson b-cous...@ti.com 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
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 b-cous...@ti.com 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
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 day we need
On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
thomas.petazz...@free-electrons.com 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
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
thomas.petazz...@free-electrons.com 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
On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi ba...@ti.com 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
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 ba...@ti.com 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
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
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 you
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
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 you
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 clocks
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 3.7-rc1 kernel.
Adapt keypad to use pinctrl framework.
Tested on omap4430 sdp with 3.7-rc1 kernel.
Cc: Felipe Balbi ba...@ti.com
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
v1-v2
- Added PROBE_DEFER check
drivers/input/keyboard/omap4-keypad.c | 11
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; maybe
64 matches
Mail list logo
