On Sun, Dec 04, 2011 at 06:51:23PM +0530, Thomas Abraham wrote:
For regulators that are not turned on by bootloader, and which require
'apply_uV' constraint, is there any alternative for turning on the
regulator when using dt?
If the regulator isn't software managed then always_on covers this
On Sun, Dec 04, 2011 at 11:50:02AM +, Ashish Jangam wrote:
You should fix your mailer to word wrap at less than 80 columns, I've
reflowed your text for legibility.
regmap-irq has a opaque struct regmap_irq_chip_data which has a member
irq_base and this is required for non-primary irqs
On Thu, Dec 01, 2011 at 11:30:16AM -0700, Paul Walmsley wrote:
So for example, if you had a driver that did:
c = clk_get(dev, clk_name);
clk_enable(c);
clk_set_rate(c, clk_rate);
and c was currently not enabled by any other driver on the system, and
nothing else had called
On Mon, Nov 28, 2011 at 08:01:01PM -0600, Kurt Taylor wrote:
The idea is fairly simple, play a sine wave and test the audio stack by
sampling/testing the sine back in via loopback cable. The app is called
testfreq and is driven by a script called e2eaudiotest. It opens and
Might be worth
On Fri, Nov 18, 2011 at 02:49:54PM +0530, Ashish Jangam wrote:
There's still a few issues in here. It'd be very much easier to review
this stuff if you split the patch down into smaller patches, for example
having the ADC, SPI and I2C as separate patches. The bigger each
individual e-mail is
On Tue, Oct 25, 2011 at 10:17:19AM +0200, Grant Likely wrote:
I've got no issue with a debugfs interface, although it would probably
a good idea to put a big scary warning into klog when userspace starts
manipulating pinctrl setting. Maybe should taint the kernel too.
Yes, we really should
On Thu, Oct 20, 2011 at 04:04:47PM +0200, Linus Walleij wrote:
I think (and of course this may be completely wrong, but it's my
working hypthesis) that the things that software wants to do to
pins are:
The other question is if it's worth bouncing through too much of an
abstraction layer when
On Wed, Oct 19, 2011 at 07:39:16PM +0530, Ashish Jangam wrote:
+static struct regmap_config da9052_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+static int da9052_spi_probe(struct spi_device *spi)
So, as I think I mentioned last time based on the previous non-regmap
On Mon, Oct 17, 2011 at 04:48:52PM +0800, Richard Zhao wrote:
For example, devices that possible access to on-chip RAM, depend on OCRAM
clock.
On imx53, VPU depends on OCRAM clock, even when VPU does not use OCRAM.
So if the VPU depends on OCRAM the VPU should be enabling the OCRAM
clock.
work on it your jack detection patch seems like the way forward for the
jack detection.
I don't know if Feng Wei will be at Prague for ELCE/LinuxCon/GstConf,
but perhaps this is something we can take up at one of the BoFs.
Since both I and Feng (and possibly Mark Brown as well? He was present
On Fri, Oct 14, 2011 at 10:57:08AM +0200, David Henningsson wrote:
There is also the Use Case concept in UCM, Is there always exactly
one verb for every use case? If not, one might wonder if Use Case
or Verb is what should correspond to the Profile concept.
Yes, pretty much.
As for ports,
On Fri, Oct 14, 2011 at 04:10:26PM +0800, Richard Zhao wrote:
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
snip essentially Mike's entire mail - *please* delete irrelevant quotes
from your replies, it makes it very much easier to find the new text in
your mail and is much more
On Fri, Oct 14, 2011 at 12:00:54PM +0200, David Henningsson wrote:
On 10/14/2011 11:39 AM, Mark Brown wrote:
On Fri, Oct 14, 2011 at 10:57:08AM +0200, David Henningsson wrote:
As for ports, this again depends on what is mutually exclusive and
what could be used in parallel, I vaguely remember
On Fri, Oct 14, 2011 at 12:19:53PM +0200, David Henningsson wrote:
On 10/14/2011 11:42 AM, Feng Wei wrote:
Actually we must map the concepts because ucm is designed for abstract
the complicated kcontrol. In my mind, if we use ucm in pa, the
original profile configuration files and mixer
On Fri, Oct 14, 2011 at 12:57:39PM +0200, David Henningsson wrote:
Have you had a look at the patches for UCM already posted several
months ago, and that I spent quite some time reviewing? Or are you
planning to start over from scratch?
Yeah, what's the status on those? There didn't seem to
On Fri, Oct 07, 2011 at 12:43:02PM -0300, Christian Robottom Reis wrote:
On Thu, Oct 06, 2011 at 06:44:43PM +0100, Mark Brown wrote:
Note that there's already an API from Intel which people are relatively
happy with, it mostly just needs some fettling for kernel integration -
after
On Thu, Oct 06, 2011 at 11:38:35AM -0300, Christian Robottom Reis wrote:
On Wed, Oct 05, 2011 at 05:45:00PM -0500, Kurt Taylor wrote:
There are only 3 left from the list that are bounded enough to consider:
1) Compressed data api into ALSA - driver specific kernel work and ALSA/ASoC
On Tue, Oct 04, 2011 at 12:18:18PM -0600, Grant Likely wrote:
On Mon, Sep 26, 2011 at 10:38:58AM +0100, Mark Brown wrote:
No, that's not helpful. The issue isn't the device probe code itself,
the issue is things like module unload not doing what they're supposed
to do and leaving
On Mon, Oct 03, 2011 at 09:17:30AM -0500, Rob Herring wrote:
On 09/22/2011 05:26 PM, Mike Turquette wrote:
A lot of stuff that should really have been cut plus...
+ if (clk-ops-get_parent)
+ /* We don't to lock against prepare/enable here, as
+* the clock is not
On Mon, Oct 03, 2011 at 10:24:52AM -0500, Rob Herring wrote:
On 10/03/2011 09:25 AM, Mark Brown wrote:
This isn't in any way specific to clocks, right now the likely solution
looks to be Grant's changes for retrying probe() as new devices come on
line. With that devices can return a code
On Mon, Oct 03, 2011 at 05:43:09PM +0100, Russell King - ARM Linux wrote:
On Mon, Oct 03, 2011 at 05:31:08PM +0100, Mark Brown wrote:
[Not being many off-SoC clocks]
I dunno, I get the impression that some of this is due to the current
limitations of the clock API rather than due to a lack
On Thu, Sep 29, 2011 at 01:03:13AM -0700, Dmitry Torokhov wrote:
Please feel free to merge with the rest of your patches (I assume
through MFD tree).
Actually for new MFDs it's usually OK to merge via the subsystem trees -
the dependency on the core driver prevents build breakage by ensuring
On Mon, Sep 26, 2011 at 03:07:52PM +0200, Alexander Sack wrote:
https://linaro-public.papyrs.com/public/4157/MMWG2011-2/#
In this one the first bullet point needs to be changed to refer to
TinyHardware, at least for the time being - nay use case stuff needs to
be layered on top of TinyALSA (I
On Thu, Sep 22, 2011 at 03:26:55PM -0700, Mike Turquette wrote:
more thought. I also dropped Mark's change to append a device's name to
a clk name since device tree might solve this neatly. Again more
discussion around that would be good.
Some of that was for debugfs type stuff - if we end
On Sat, Sep 24, 2011 at 10:08:36PM -0600, Grant Likely wrote:
On Thu, Sep 22, 2011 at 03:27:01PM -0700, Mike Turquette wrote:
+ ret = platform_driver_register(wm831x_clk_driver);
+ if (ret != 0)
+ pr_err(Failed to register WM831x clock driver: %d\n, ret);
+
+ return
On Mon, Sep 19, 2011 at 06:03:16PM +0530, ashishj3 wrote:
The DA9052/53 is a highly integrated PMIC subsystem with supply domain
flexibility
to support wide range of high performance application.
It provides voltage regulators, GPIO controller, Touch Screen, RTC, Battery
control and other
On Sat, Sep 10, 2011 at 10:37:15PM +0200, Arnd Bergmann wrote:
On Friday 09 September 2011, Russell King - ARM Linux wrote:
That's just twisted and utterly insane - adding more code for precisely
zero benefit what so ever. Think about it - the device tree is already
creating platform
On Fri, Sep 09, 2011 at 08:01:35PM +0100, Russell King - ARM Linux wrote:
Well, with DT, there won't be any 'board type' anymore. There won't be
any 'machine_is_xxx()' to sort it out anymore. Using DT, all that will
be history - it's all got to be sorted out by either devices or device
On Thu, Sep 08, 2011 at 04:05:53PM +0100, Mans Rullgard wrote:
+static struct platform_device omap_soc_audio = {
+ .name = omap-soc-audio,
+ .id = -1,
+};
+
This isn't really accomplishing anything as you're using the same device
name for all boards, it's essentially the same
On Thu, Sep 08, 2011 at 04:41:30PM +0100, Mans Rullgard wrote:
On 8 September 2011 16:15, Lars-Peter Clausen l...@metafoo.de wrote:
Use different device driver names for different drivers.
I guess this worked by accident on my system.
Are there any other changes needed?
Check the N810
On Thu, Sep 08, 2011 at 11:47:16PM +0530, Jassi Brar wrote:
Can't we do by having omap_init_audio() in arch/arm/mach-omap2/devices.c
generate a platform device of name depending upon machine_is_* ?
That's not a bad idea. If we were going to do that it shouldn't be OMAP
specific, any platform
On Thu, 2011-09-08 at 22:28 +0200, Arnd Bergmann wrote:
On Thursday 08 September 2011 20:05:48 Mans Rullgard wrote:
I had the same thought, but I couldn't find a suitable string anywhere.
Are you suggesting an if(machine_is_foo()) cascade in omap_init_audio()?
I'll be the first to agree
On Thu, Sep 08, 2011 at 11:37:20PM +0100, Russell King - ARM Linux wrote:
With DT of course, all devices get instantiated from the device tree,
so there should not be any more platform specific chunks of code in
these locations (ha, it couldn't be solved with platform data so I
suspect it
On Thu, Aug 18, 2011 at 07:23:22PM +0530, ashishj3 wrote:
+int da9052_reg_read(struct da9052 *da9052, unsigned char reg)
+{
+ int val, ret;
+
+ if (reg DA9052_MAX_REG_CNT) {
+ dev_err(da9052-dev, invalid reg %x\n, reg);
+ return -EINVAL;
+ }
+
+
On Tue, Aug 09, 2011 at 08:45:47AM +, Ashish Jangam wrote:
Could do with blank lines between blocks. Though looking at the code
here I don't understand why these are compile options at all, or if they
need to be compile options for some reason why they're not independantly
On Fri, Aug 05, 2011 at 07:23:44PM +0530, ashishj3 wrote:
Patch v3 seems a little low, we've had *slightly* more versions than
that...
+choice
+ prompt Chip Type
+ depends on MFD_DA9053_SPI || MFD_DA9053_I2C
+config PMIC_DA9053AA
+ bool Support Dialog Semiconductor DA9053 AA
On Thu, Aug 04, 2011 at 06:15:02PM +0530, ashishj3 wrote:
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -350,6 +350,7 @@ config MFD_DA9052_SPI
bool Support Dialog Semiconductor DA9052 PMIC with SPI
select MFD_CORE
select PMIC_DA9052
+ select REGMAP_SPI
On Tue, Jul 05, 2011 at 08:07:00PM +0530, ashishj3 wrote:
+int da9052_set_bits(struct da9052 *da9052, unsigned char reg,
+ unsigned char bit_mask)
+{
+ unsigned char val;
+ int ret;
+
+ if (reg DA9052_MAX_REG_CNT) {
+ dev_err(da9052-dev, invalid
On Sat, Jul 23, 2011 at 11:50:30AM +0200, Arnd Bergmann wrote:
Yes, that makes sense. There are also cases where a mutex should really
be a spinlock (which is by definition not interruptible), or vice
versa. I don't know if this is one of them.
We would be using spinlocks except the
On Thu, Jul 21, 2011 at 11:46:32PM +0800, Shawn Guo wrote:
On Tue, Jul 05, 2011 at 08:07:00PM +0530, ashishj3 wrote:
+ mutex_lock_interruptible(da9052-io_lock);
Compile warning as below.
warning: ignoring return value of ‘mutex_lock_interruptible’,
declared with attribute
On Thu, Jul 14, 2011 at 02:27:08PM +0530, ashishj3 wrote:
+static inline int volt_reg_to_mV(int value)
+ { return ((value*1000) / 512) + 2500; }
+static inline int ichg_reg_to_mA(int value)
+ { return ((value * 3900) / 1000); }
It'd be better to use the standard
On Mon, Jul 11, 2011 at 12:27:46PM +0530, Ashish Jangam wrote:
-Original Message-
From: Arnd Bergmann [mailto:a...@arndb.de]
Sent: Tuesday, July 05, 2011 8:25 PM
Can anyone ack this patch?
You've only left it about a week for a response. You cannot demand any
particular response
On Mon, Jun 13, 2011 at 01:57:36PM -0600, Grant Likely wrote:
On Mon, Jun 13, 2011 at 10:58 AM, Linus Walleij
+This get/enable/disable/put sequence can just as well be handled by bus
drivers
+if you don't want each and every driver to handle it and you know the
+arrangement on your bus.
On Wed, Jul 06, 2011 at 04:06:50PM +0530, ashishj3 wrote:
The DA9052 PMIC has below featured regulators:-
4 DVS Buck converters 0.5V - 3.6V upto 1Amp.
10 Programmable LDO's High PSSR, 1% accuracy.
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
On Wed, Jul 06, 2011 at 10:36:56AM -0600, Grant Likely wrote:
It looks like this needs to be merged via the MFD tree since it
depends on the core da9052 driver patch.
Actually that's not such an issue for new MFDs - since the function
drivers all depend on the core driver they can't be enabled
On Wed, Jun 29, 2011 at 06:46:03PM +0530, ashishj3 wrote:
+static int verify_range(struct da9052_regulator_info *info,
+ int min_uV, int max_uV)
+{
+ if (min_uV info-min_uV || min_uV info-max_uV)
+ return -EINVAL;
+ if (max_uV info-min_uV ||
On Tue, Jun 28, 2011 at 07:46:49PM +0530, ashishj3 wrote:
+static int da9052_add_subdevs(struct da9052 *da9052)
+{
+ struct da9052_pdata *pdata = da9052-dev-platform_data;
+ int ret;
+
+ static struct mfd_cell __initdata da9052_subdev_info[] = {
+ {da9052-onkey,
On Mon, Jun 27, 2011 at 02:12:37PM +0530, ashishj3 wrote:
+static int da9052_dcdc_set_current_limit(struct regulator_dev *rdev, int
min_uA,
+ int max_uA)
+{
+ struct da9052_regulator *regulator = rdev_get_drvdata(rdev);
+ int offset =
calls to regulator_register.
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Mon, Jun 20, 2011 at 10:43:50AM -0600, Grant Likely wrote:
I think I've commented on this before, but I do try to avoid direct
coding registers into the DT. That said, sometimes there really isn't
a nice human-friendly way of encoding things and direct register
values is the best
On Mon, Jun 20, 2011 at 05:33:12PM +0530, ashishj3 wrote:
--- a/drivers/regulator/da9052-regulator.c
+++ b/drivers/regulator/da9052-regulator.c
@@ -24,7 +24,7 @@
#include linux/mfd/da9052/reg.h
#include linux/mfd/da9052/pdata.h
-/* Buck step size Macros */
+/* Buck step size */
On Fri, Jun 10, 2011 at 11:51:02AM +0800, Ying-Chun Liu (PaulLiu) wrote:
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
Add DA9052 regulator driver from Dialog.
Modify Kconfig/Makefile for DA9052 regulator driver.
This has *many* of the serious shortcomings that were present in the
On Fri, Jun 10, 2011 at 11:51:00AM +0800, Ying-Chun Liu (PaulLiu) wrote:
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
Add DA9052 mfd driver from Dialog.
Modify Kconfig/Makefile for DA9052 mfd driver.
This needs to be the first patch in the series, all the other patches
need it to work.
On Fri, Jun 10, 2011 at 07:38:43PM +0200, Arnd Bergmann wrote:
I've reviewed part of it now. Once you have addressed the issues I pointed
out, please do another round of reviews, then I can look at more files.
In case you hadn't seen it I previously pointed out that there's a
separate series
On Fri, Jun 10, 2011 at 08:31:12PM +0200, Arnd Bergmann wrote:
What's the subject and mailing list of the other submission? I might
have a look at that then.
There's been some insanely large number of submissions (I think we must
be over 20 by now) and one of the issues is that they're not
On Wed, Dec 01, 2010 at 03:15:55PM +0800, Yong Shen wrote:
move some common functions and micros of mc13783 regulaor driver to
a seperate file, which makes it possible for mc13892 to share code.
You've done way more than this in the patch - you've also renamed a lot
of things and done other
101 - 156 of 156 matches
Mail list logo
