On Fri, Apr 27, 2012 at 11:28:28AM -0400, Mark Asselstine wrote:
On April 26, 2012 22:52:58 Russell King - ARM Linux wrote:
What is the effect when the supplied IRQ does not have a mapping to a
GPIO - or it _does_ by way of a badly coded irq_to_gpio() function
but that GPIO is not the
On Thu, Apr 26, 2012 at 10:52:58PM +0100, Russell King - ARM Linux wrote:
The real answer is to fix SPI et.al. so that its possible to pass the
_GPIO_ number into this driver (that's what the driver wants for its
interrupt line after all). To fix that, SPI folk need to get involved
(added
On Wed, May 18, 2011 at 07:23:20PM +0200, Antonio Ospite wrote:
So you mean something like the following:
mmc_regulator_set_power(...)
{
Yes.
2. Add a proper function with all the needed parameters to abstract
the actual var names, this would be something like:
On Wed, May 11, 2011 at 12:39:39PM +0200, Antonio Ospite wrote:
Add support for powering up SD cards driven by regulators.
This makes the mmc_spi driver work also with the Motorola A910 phone.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
Reviwed-by: Mark Brown broo
On Tue, May 10, 2011 at 10:02:14PM +0200, Antonio Ospite wrote:
So, I am going to remove the ifdefs anyway but use IS_ERR_OR_NULL();
how does that sound? Am I still missing anything?
Looks good to me.
Or changing the regulator_get() stub to return an error (-ENOSYS?) might
be worth it?
No,
On Mon, May 09, 2011 at 09:23:25PM +0100, Russell King - ARM Linux wrote:
NAK. This has been proposed before, and rejected. See the comments
against the original proposal:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6525/1
Hrm, this looks like the bodge we're doing for
On Thu, Apr 21, 2011 at 02:27:53PM +0200, Antonio Ospite wrote:
+#ifdef CONFIG_REGULATOR
+ host-vcc = regulator_get(mmc_dev(host-mmc), vmmc);
+
+ if (IS_ERR(host-vcc)) {
+ host-vcc = NULL;
+ } else {
+ host-mmc-ocr_avail =
On Thu, Apr 14, 2011 at 12:39:12PM +0200, Antonio Ospite wrote:
Johannes Berg johan...@sipsolutions.net wrote:
Should remove do platform_set_drvdata(pdev, NULL)?
AFAICS this is not strictly necessary because we never check for NULL
here and we are setting drvdata again in _probe() each time
On Tue, Apr 12, 2011 at 05:23:01PM +0200, Johannes Berg wrote:
On Tue, 2011-04-12 at 08:15 -0700, Mark Brown wrote:
No, if you're passing supply names through platform data something has
gone wrong - that's a big no no.
Ok. The comment seems a little wrong still though, maybe leftover bits
On Tue, Apr 12, 2011 at 01:44:02PM +0200, Johannes Berg wrote:
On Tue, 2011-04-12 at 13:41 +0200, Johannes Berg wrote:
+ if (pdata-name == NULL || pdata-type == 0) {
+ dev_err(pdev-dev, invalid name or type in platform data\n);
+ return -EINVAL;
+ }
+ vcc =
at insmod time, and this made impossible to ever
disable the regulator.
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
NOTE: initially I thought about CC-ing sta...@kernel.org as well on
this, as it is an actual fix, but then I checked that there are
currently no users of the driver
using the pcap-regulator driver services.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
Looks OK to me.
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
On Fri, Dec 04, 2009 at 01:57:57PM +0100, Antonio Ospite wrote:
This is the incremental change I have in mind; if it's ok, then
a v2 is on its way.
Yes, this looks reasonable I think.
On Fri, Dec 04, 2009 at 01:39:43PM +0100, Antonio Ospite wrote:
Mark Brown broo...@opensource.wolfsonmicro.com wrote:
You almost certainly want regulator_get_exclusive() here; this driver
can't function properly if something else is using the regulator and
holding the LED on or off without
On Wed, Dec 02, 2009 at 06:40:25PM +0100, Antonio Ospite wrote:
A doubt I had was about leaving the 'supply' variable configurable from
platform data, or relying on some fixed value like vled, but leaving it
configurable covers the case when we have different regulators used for
different
On Wed, Dec 02, 2009 at 09:25:21PM +0100, Antonio Ospite wrote:
Mark Brown broo...@opensource.wolfsonmicro.com wrote:
There's no need to do this since the regulator API matches consumers
based on struct device as well as name so you can have as many LEDs as
you like all using the same
On Wed, Dec 02, 2009 at 09:31:31PM +0100, Antonio Ospite wrote:
Liam Girdwood l...@slimlogic.co.uk wrote:
Some regulators may not support voltage change (via hw design or
constraints) so set_voltage() will fail. We probably want to handle this
regulator type so we don't call set_voltage().
On Mon, Oct 26, 2009 at 09:58:52AM -0700, Greg KH wrote:
On Fri, Oct 23, 2009 at 11:18:06AM +0100, Russell King - ARM Linux wrote:
On Fri, Oct 23, 2009 at 11:50:28AM +0200, Antonio Ospite wrote:
A little more background: we need pxamci to be a child of SPI because
our PMIC is connected
On Wed, Jul 22, 2009 at 02:03:07PM -0700, David Brownell wrote:
/* that this simple idiom would finally work */
if (regulator_is_enabled(r))
regulator_disable(r);
For the avoidance of future disappointment please note that an exclusive
access request does not remove
On Tue, Jun 30, 2009 at 07:36:20PM -0700, David Brownell wrote:
On Monday 29 June 2009, Mark Brown wrote:
At the minute the regulator API actually copes pretty well with this -
the only problem I'm aware of is with drivers like the MMC driver which
require exclusive control
On Mon, Jun 29, 2009 at 11:00:38AM +0800, Eric Miao wrote:
This looks to be running into the same issue as clocks - where for power
savings the clocks are assumed to be off as many as possible, leaving only
those essential ones enabled, yet the assumption of the boot loader does
this
On Sat, Jun 27, 2009 at 02:09:52PM -0300, Daniel Ribeiro wrote:
This is a driver for misc input events for the PCAP2 PMIC, it handles
the power button, headphone insertion/removal and the headphone button.
Depending on the power management capabilities of the CODEC it may be
better to support
On Mon, Jun 29, 2009 at 07:27:24PM +0300, Ilya Petrov wrote:
2009/6/29 Mark Brown broo...@opensource.wolfsonmicro.com:
Depending on the power management capabilities of the CODEC it may be
better to support at laest the headphone insert/removal via the audio
driver as a jack to allow
On Fri, Jun 26, 2009 at 08:08:41PM -0300, Daniel Ribeiro wrote:
Changed: Removed workaround for regulator use_count issues.
The usual place for these comments is after the --- with the diffstat
(the tools can then deal automatically with them). Incidentally, the
code you had would only help
On Sun, Jun 07, 2009 at 02:49:11AM -0300, Daniel Ribeiro wrote:
Replace the remaining unsigned shorts with unsigned ints.
Tested with pcap2 codec (25 bits registers).
Signed-off-by: Daniel Ribeiro drw...@gmail.com
Thanks, I've applied this. Given that the merge window is *very* close
and
On Wed, Apr 08, 2009 at 10:51:24AM -0300, Daniel Ribeiro wrote:
From the pxa27x developers manual, Table 8-8 SSPSP Bit Definitions:
SCMODE(0): Data Driven (Falling), Data Sampled (Rising), Idle State (Low)
SCMODE(1): Data Driven (Rising), Data Sampled (Falling), Idle State (Low)
SCMODE(2):
On Wed, Apr 08, 2009 at 10:51:24AM -0300, Daniel Ribeiro wrote:
This patch also adds all possible NF/IF, NB/IB combinations to the DSP_A and
DSP_B modes.
Thanks - it'll be tomorrow or possibly Monday before I get a chance to
test this.
On Wed, Jul 16, 2008 at 10:05:21PM -0300, Daniel Ribeiro wrote:
Is there any reason to this limit? I am currently faking
the registers to always fit 16 bits, but this looks ugly.
No reason other than nobody needed it before.
Would a patch to soc-core/dapm to extend this limit to
28 matches
Mail list logo
