* omap3: regulator_get() failure in ads7846
@ 2010-09-07 11:46 Premi, Sanjeev
2010-09-07 11:56 ` Mark Brown
2010-09-07 12:16 ` Igor Grinberg
0 siblings, 2 replies; 7+ messages in thread
From: Premi, Sanjeev @ 2010-09-07 11:46 UTC (permalink / raw)
To: linux-omap@vger.kernel.org, linux-input@vger.kernel.org
Hi all,
While booting the latest kernel (from linux-omap) on omap3evm,
I came across this error.
[ 3.202575] ads7846 spi1.0: unable to get regulator: -19
[ 3.208190] ------------[ cut here ]------------
[ 3.212890] WARNING: at drivers/gpio/gpiolib.c:1258 gpio_free+0x114/0x140()
[ 3.219940] Modules linked in:
[ 3.223083] [<c004e57c>] (unwind_backtrace+0x0/0xec) from [<c007e5d8>] (warn_slowpath_common+0x4c/0x64)
...
...
[ 3.342529] ---[ end trace 1b75b31a2719ed1f ]---
In drivers/input/touchscreen/ads7846.c, we attempt to get the
regulator as:
ts->reg = regulator_get(&spi->dev, "vcc");
This regulator isn't defined for omap3evm. And I suspect - once
defined - the name will be different than "vcc".
Looking at pointers on how this should be handled.
Best regard,
Sanjeev
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: omap3: regulator_get() failure in ads7846
2010-09-07 11:46 omap3: regulator_get() failure in ads7846 Premi, Sanjeev
@ 2010-09-07 11:56 ` Mark Brown
2010-09-07 13:26 ` Premi, Sanjeev
2010-09-07 12:16 ` Igor Grinberg
1 sibling, 1 reply; 7+ messages in thread
From: Mark Brown @ 2010-09-07 11:56 UTC (permalink / raw)
To: Premi, Sanjeev; +Cc: linux-omap@vger.kernel.org, linux-input@vger.kernel.org
On Tue, Sep 07, 2010 at 05:16:44PM +0530, Premi, Sanjeev wrote:
> ts->reg = regulator_get(&spi->dev, "vcc");
> This regulator isn't defined for omap3evm. And I suspect - once
> defined - the name will be different than "vcc".
What makes you say this? The names for regulator supplies are defined
in terms of the chip being supplied, not in terms of the board.
> Looking at pointers on how this should be handled.
The best thing to do is to define the mapping for the regulator. You
can work around it by enabling REGULATOR_DUMMY.
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: omap3: regulator_get() failure in ads7846
2010-09-07 11:56 ` Mark Brown
@ 2010-09-07 13:26 ` Premi, Sanjeev
2010-09-07 14:18 ` Mark Brown
0 siblings, 1 reply; 7+ messages in thread
From: Premi, Sanjeev @ 2010-09-07 13:26 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-omap@vger.kernel.org, linux-input@vger.kernel.org
> -----Original Message-----
> From: linux-input-owner@vger.kernel.org
> [mailto:linux-input-owner@vger.kernel.org] On Behalf Of Mark Brown
> Sent: Tuesday, September 07, 2010 5:27 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org; linux-input@vger.kernel.org
> Subject: Re: omap3: regulator_get() failure in ads7846
>
> On Tue, Sep 07, 2010 at 05:16:44PM +0530, Premi, Sanjeev wrote:
>
> > ts->reg = regulator_get(&spi->dev, "vcc");
>
> > This regulator isn't defined for omap3evm. And I suspect - once
> > defined - the name will be different than "vcc".
>
> What makes you say this? The names for regulator supplies are defined
> in terms of the chip being supplied, not in terms of the board.
[sp] The name "vcc" is too generic name for the regulator supply. If
there were more than one supplies as in case of the omap3evm, it
would be difficult to name the supply as "vcc".
Assuming there is another (different) driver which uses "vcc"
(as ads7846 uses currently) but uses different supply, what is
expected behavior?
If, however, the name here was something like "vcc_ts", then
the supplies could be defined for any board as:
static struct regulator_consumer_supply my_board_ts_supply = {
.supply = "vcc_ts",
};
This would be more portable for other boards as well.
OR
Does regulator_get() searches by "device_name-supply_id" pair?
Then, my comments above don't hold... And I would try the
mapping you mentioned below.
>
> > Looking at pointers on how this should be handled.
>
> The best thing to do is to define the mapping for the regulator. You
> can work around it by enabling REGULATOR_DUMMY.
[sp] Yes, this would be a workaround; but it comes with another
warning on console.
Best regards,
Sanjeev
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: omap3: regulator_get() failure in ads7846
2010-09-07 13:26 ` Premi, Sanjeev
@ 2010-09-07 14:18 ` Mark Brown
0 siblings, 0 replies; 7+ messages in thread
From: Mark Brown @ 2010-09-07 14:18 UTC (permalink / raw)
To: Premi, Sanjeev; +Cc: linux-omap@vger.kernel.org, linux-input@vger.kernel.org
On Tue, Sep 07, 2010 at 06:56:47PM +0530, Premi, Sanjeev wrote:
> > From: linux-input-owner@vger.kernel.org
> > [mailto:linux-input-owner@vger.kernel.org] On Behalf Of Mark Brown
> > What makes you say this? The names for regulator supplies are defined
> > in terms of the chip being supplied, not in terms of the board.
> [sp] The name "vcc" is too generic name for the regulator supply. If
> there were more than one supplies as in case of the omap3evm, it
> would be difficult to name the supply as "vcc".
As I said above: these are defined in terms of the *chip* being
supplied. The name of the pin on the device does not change depending
on which board they're soldered down on and is orthogonal to both the
name of the supply on the regulator and both are orthogonal to the name
the rail is given on a given board.
> Assuming there is another (different) driver which uses "vcc"
> (as ads7846 uses currently) but uses different supply, what is
> expected behavior?
The expected behaviour is that both devices request the supplies under
the names that they are given by the chip.
> If, however, the name here was something like "vcc_ts", then
> the supplies could be defined for any board as:
> static struct regulator_consumer_supply my_board_ts_supply = {
> .supply = "vcc_ts",
> };
> This would be more portable for other boards as well.
Using strings like this doesn't scale - you may have two devices of a
given type with different supply arrangements on a board, for example.
> Does regulator_get() searches by "device_name-supply_id" pair?
> Then, my comments above don't hold... And I would try the
> mapping you mentioned below.
Yes, this is the reason why we require the struct device in get().
> > > Looking at pointers on how this should be handled.
> > The best thing to do is to define the mapping for the regulator. You
> > can work around it by enabling REGULATOR_DUMMY.
> [sp] Yes, this would be a workaround; but it comes with another
> warning on console.
Yes, you're not really supposed to use it in production.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: omap3: regulator_get() failure in ads7846
2010-09-07 11:46 omap3: regulator_get() failure in ads7846 Premi, Sanjeev
2010-09-07 11:56 ` Mark Brown
@ 2010-09-07 12:16 ` Igor Grinberg
2010-09-07 12:51 ` Mark Brown
2010-09-07 12:53 ` Premi, Sanjeev
1 sibling, 2 replies; 7+ messages in thread
From: Igor Grinberg @ 2010-09-07 12:16 UTC (permalink / raw)
To: Premi, Sanjeev; +Cc: linux-omap@vger.kernel.org, linux-input@vger.kernel.org
Hi,
I think, this can help:
http://www.spinics.net/lists/arm-kernel/msg94759.html
Seems like there were not enough interest and it is still floating.
May be a little ping can help ;)
On 09/07/10 14:46, Premi, Sanjeev wrote:
> Hi all,
>
> While booting the latest kernel (from linux-omap) on omap3evm,
> I came across this error.
>
> [ 3.202575] ads7846 spi1.0: unable to get regulator: -19
> [ 3.208190] ------------[ cut here ]------------
> [ 3.212890] WARNING: at drivers/gpio/gpiolib.c:1258 gpio_free+0x114/0x140()
> [ 3.219940] Modules linked in:
> [ 3.223083] [<c004e57c>] (unwind_backtrace+0x0/0xec) from [<c007e5d8>] (warn_slowpath_common+0x4c/0x64)
> ...
> ...
> [ 3.342529] ---[ end trace 1b75b31a2719ed1f ]---
>
>
> In drivers/input/touchscreen/ads7846.c, we attempt to get the
> regulator as:
>
> ts->reg = regulator_get(&spi->dev, "vcc");
>
> This regulator isn't defined for omap3evm. And I suspect - once
> defined - the name will be different than "vcc".
>
> Looking at pointers on how this should be handled.
>
> Best regard,
> Sanjeev
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: omap3: regulator_get() failure in ads7846
2010-09-07 12:16 ` Igor Grinberg
@ 2010-09-07 12:51 ` Mark Brown
2010-09-07 12:53 ` Premi, Sanjeev
1 sibling, 0 replies; 7+ messages in thread
From: Mark Brown @ 2010-09-07 12:51 UTC (permalink / raw)
To: Igor Grinberg
Cc: Premi, Sanjeev, linux-omap@vger.kernel.org,
linux-input@vger.kernel.org
On Tue, Sep 07, 2010 at 03:16:21PM +0300, Igor Grinberg wrote:
> I think, this can help:
> http://www.spinics.net/lists/arm-kernel/msg94759.html
> Seems like there were not enough interest and it is still floating.
> May be a little ping can help ;)
This is a really bad idea unless the supplies genuinely are optional -
we shouldn't be doing this sort of bodge in the drivers, that's just
going to lead to lots of repetitive code adding complexity every time
the regulator API is used. It also makes the error handling rather more
obscure since systems that genuinely need the regulator won't be
reporting problems clearly.
The regulator API has facilties on several levels to deal with systems
that have problems here: it provides fixed voltage regulators, it
provides the option to substitute in dummy regulators automatically and
if the regulator API is disabled then the stub functions provided will
report success.
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: omap3: regulator_get() failure in ads7846
2010-09-07 12:16 ` Igor Grinberg
2010-09-07 12:51 ` Mark Brown
@ 2010-09-07 12:53 ` Premi, Sanjeev
1 sibling, 0 replies; 7+ messages in thread
From: Premi, Sanjeev @ 2010-09-07 12:53 UTC (permalink / raw)
To: Igor Grinberg; +Cc: linux-omap@vger.kernel.org, linux-input@vger.kernel.org
> -----Original Message-----
> From: Igor Grinberg [mailto:grinberg@compulab.co.il]
> Sent: Tuesday, September 07, 2010 5:46 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org; linux-input@vger.kernel.org
> Subject: Re: omap3: regulator_get() failure in ads7846
>
> Hi,
>
> I think, this can help:
> http://www.spinics.net/lists/arm-kernel/msg94759.html
>
> Seems like there were not enough interest and it is still floating.
> May be a little ping can help ;)
>
[sp] Will review this patch...
[snip]...[snip]
> --
> Regards,
> Igor.
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-09-07 14:18 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-07 11:46 omap3: regulator_get() failure in ads7846 Premi, Sanjeev
2010-09-07 11:56 ` Mark Brown
2010-09-07 13:26 ` Premi, Sanjeev
2010-09-07 14:18 ` Mark Brown
2010-09-07 12:16 ` Igor Grinberg
2010-09-07 12:51 ` Mark Brown
2010-09-07 12:53 ` Premi, Sanjeev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).