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
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 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
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
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 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
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
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
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
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
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
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 :)
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
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 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
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
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:
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
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
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
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
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
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'm
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 unique.
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 3:07 PM, Mark Brown
broo...@opensource.wolfsonmicro.com 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
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
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
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
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
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
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
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
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 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
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
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
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
> >
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
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
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
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
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*
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 -
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
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
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
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
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
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 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
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
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
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
1 - 100 of 128 matches
Mail list logo
