On Thu, Dec 15, 2011 at 06:59:53PM +0530, Ashish Jangam wrote:
> Reported-by: Mark Brown
> Signed-off-by: David Dajun Chen
> Signed-off-by: Ashish Jangam
Applied, but this really should have been sent as two separate patches
as it's two unrelated changes which don't over
On Tue, Dec 13, 2011 at 03:49:33PM +0530, Rajendra Nayak wrote:
I'm OK with this but would prefer that OMAP or TWL people were OK with
it too. If you do need to respin:
> +For twl4030 regulators/LDO's
' should *not* be used for plurals except when omitting a duplicated s
introduced by one (gram
On Fri, Dec 16, 2011 at 06:30:59PM +0800, Richard Zhao wrote:
> +
> + if (higher && cpu_reg)
> + regulator_set_voltage(cpu_reg,
> + cpu_volts[index], cpu_volts[index]);
This is really bad, you're only supporting the configuration of a
specific voltage w
On Mon, Dec 19, 2011 at 11:21:40AM +0800, Richard Zhao wrote:
> It support single core and multi-core ARM SoCs. But currently it assume
> all cores share the same frequency and voltage.
My comments on the previous version of the patch still apply:
- The voltage ranges being set need to be specif
On Wed, Dec 21, 2011 at 07:27:03AM +0800, Richard Zhao wrote:
> On Tue, Dec 20, 2011 at 02:59:04PM +0000, Mark Brown wrote:
> > My comments on the previous version of the patch still apply:
> > - The voltage ranges being set need to be specified as ranges.
> cpu normally ne
On Wed, Dec 21, 2011 at 09:20:46AM +0800, Richard Zhao wrote:
> On Tue, Dec 20, 2011 at 11:48:45PM +0000, Mark Brown wrote:
> > Note also that not all hardware specifies things in terms of a fixed set
> > of operating points, sometimes only the minimum voltage specification is
On Wed, Dec 21, 2011 at 10:24:53AM +0800, Richard Zhao wrote:
> On Wed, Dec 21, 2011 at 01:32:21AM +0000, Mark Brown wrote:
> > That's not the point - the point is that you may do something like
> > specify a defined set of frequencies and just drop the minimum supported
On Wed, Dec 21, 2011 at 09:43:34AM +, Arnd Bergmann wrote:
> On Wednesday 21 December 2011, Richard Zhao wrote:
> > Mark, cpu node is not a struct device, sys_device instead. I can not find
> > regulator via device/dt node. Can I still use the string to get regulator
> > after converting to DT
On Wed, Dec 21, 2011 at 12:44:57PM +0100, Kay Sievers wrote:
> We will convert all classes to buses over time time, and have a single
> type of device and a single type of subsystem.
Are there any conversions that have been done already that I can look at
for reference?
_
On Wed, Dec 21, 2011 at 10:19:11PM +0800, Richard Zhao wrote:
> Even cpu node is device, I still need to find a way to get it. I think it's
> better have another patch to fix the regulator dt binding in cpu node. I'll
> not include it in this patch series.
I'd expect this to be easy if we can fi
On Wed, Dec 21, 2011 at 05:03:31PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> Anatop regulator driver is used by i.MX6 SoC. The regulator provides
> controlling the voltage of PU, CORE, SOC, and some devices. This patch
> adds the Anatop regulator driver.
It's st
On Thu, Dec 22, 2011 at 03:09:10PM +0800, Richard Zhao wrote:
> The driver get cpu operation point table from device tree cpu0 node,
> and adjusts operating points using clk and regulator APIs.
Reviewed-by: Mark Brown
but one nit:
> +Required properties in /cpus/cpu@0:
> +- cpu
On Wed, Dec 21, 2011 at 11:04:53AM +0400, Dmitry Antipov wrote:
> From 00753f3d48c4b6c45c1778c3e37bc9949ed79e77 Mon Sep 17 00:00:00 2001
> From: Dmitry Antipov
> Date: Wed, 21 Dec 2011 11:01:42 +0400
> Subject: [PATCH] regulator: use usleep_range() instead of mdelay()/udelay()
Follow the instruct
On Sat, Dec 24, 2011 at 04:55:42PM +0800, Richard Zhao wrote:
> On Fri, Dec 23, 2011 at 01:18:51PM +0000, Mark Brown wrote:
> > > +- trans-latency : transition_latency, in unit of ns.
> > trans-latency should really say what latency is being measured (the CPU
> >
On Thu, Dec 22, 2011 at 11:33:38AM +, Mark Brown wrote:
> On Wed, Dec 21, 2011 at 05:03:31PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> > + if (anatop_reg->rdata->control_reg) {
> > + val = anatop_reg->rdata->min_bit_val +
> > +
On Sat, Dec 24, 2011 at 09:28:33PM +0800, Richard Zhao wrote:
> On Sat, Dec 24, 2011 at 12:24:11PM +0000, Mark Brown wrote:
> - trans-latency : transition latency of cpu freq and related regulator,
>in unit of ns.
> Does it look better?
I think it shouldn't include the
On Sat, Dec 24, 2011 at 11:52:29PM +0800, Richard Zhao wrote:
> On Sat, Dec 24, 2011 at 01:42:29PM +0000, Mark Brown wrote:
> > On Sat, Dec 24, 2011 at 09:28:33PM +0800, Richard Zhao wrote:
> > > If you think regulator thansition latency is board specific, then the
> &g
On Mon, Dec 26, 2011 at 09:44:52PM +0800, Richard Zhao wrote:
> On Mon, Dec 26, 2011 at 11:10:30AM +0000, Mark Brown wrote:
Fix your mailer to word wrap properly please.
> > The *call* is there in the regulator subsystem, it's just that none of
> > the drivers back
On Tue, Dec 27, 2011 at 09:51:10AM +0800, Richard Zhao wrote:
> On Mon, Dec 26, 2011 at 02:22:34PM +0000, Mark Brown wrote:
> > Fix your mailer to word wrap properly please.
> If you mean last mail I sent, I didn't see anything wrong. I use
> mutt.
It's wrapping at a b
On Tue, Dec 27, 2011 at 06:06:27PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> (2011年12月22日 19:33), Mark Brown wrote:
> >> +#include
> >> +#include
> > Why does your regulator driver need this? That suggests a layering
> > violation.
> Sorry, I'm not sur
On Tue, Dec 27, 2011 at 06:16:34PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> + initdata = pdev->dev.platform_data;
> + sreg = initdata->driver_data;
> +
> + spin_lock_init(&sreg->lock);
You don't actually appear to use this, though it looks like you need to
do something to protect again
On Wed, Dec 28, 2011 at 11:31:29AM +0800, Richard Zhao wrote:
> On Wed, Dec 28, 2011 at 11:14:10AM +0800, Richard Zhao wrote:
> > > + if (cpu_reg) {
> > > + ret = regulator_is_supported_voltage(cpu_reg,
> > > + cpu_volts[i * 2], cpu_volts[i *
On Wed, Dec 28, 2011 at 08:05:20PM +0800, Richard Zhao wrote:
Looks like the problem with your mail client is that it's wrapping at
exactly 80 characters which is too little - you need to leave space for
being quoted.
> On Wed, Dec 28, 2011 at 11:42:37AM +0000, Mark Brown wrote:
>
On Wed, Dec 28, 2011 at 08:40:56PM +0800, Richard Zhao wrote:
> On Wed, Dec 28, 2011 at 12:14:04PM +0000, Mark Brown wrote:
> > On Wed, Dec 28, 2011 at 08:05:20PM +0800, Richard Zhao wrote:
> >
> > Looks like the problem with your mail client is that it's wrapping at
On Wed, Dec 28, 2011 at 09:06:20PM +0800, Shawn Guo wrote:
> On Wed, Dec 28, 2011 at 12:47:40PM +0000, Mark Brown wrote:
> > > One word. You mean I have to always depends on REGULATOR config, right?
> > Yes.
> I do not care too much. But it puts the driver on an interestin
On Tue, Jan 03, 2012 at 01:47:09PM +, Russell King - ARM Linux wrote:
> On Tue, Jan 03, 2012 at 09:25:30PM +0800, Richard Zhao wrote:
> > In latest v6 version, I get clk transition latency from dt property, and get
> > regulator transition latency from regulator API.
> > Could you please help
On Tue, Jan 17, 2012 at 01:10:53AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> +#define DA9052_LDO1_VOLT_UPPER 1800
> +#define DA9052_LDO1_VOLT_LOWER 600
> +#define DA9052_LDO1_VOLT_STEP50
This is almost certainly wrong - you should
On Fri, Dec 16, 2011 at 06:30:59PM +0800, Richard Zhao wrote:
> + if (higher && cpu_reg)
> + regulator_set_voltage(cpu_reg,
> + cpu_volts[index], cpu_volts[index]);
> +
> + ret = clk_set_rate(cpu_clk, freq);
> + if (ret != 0) {
> + pr
On Wed, Jan 18, 2012 at 11:39:50AM +, Mark Brown wrote:
> This appears to reintroduce the setting of an exact voltage which I'm
> sure was fixed in previous versions of the patch.
Erk, sorry - it looks like the device tree list has quite a bit of lag
in moderation and sent o
On Mon, Jan 09, 2012 at 10:55:45PM -0600, Kurt Taylor wrote:
> 1) Port and enhance functional drop of tinyhardware -
> https://blueprints.launchpad.net/linaro-multimedia-ucm/+spec/linaro-mmwg-ucm4android
I should be forward porting this to ICS in the next few weeks, for
values of "forward port" w
On Thu, Jan 26, 2012 at 02:26:06PM -0600, Kurt Taylor wrote:
> Is this complete? Absolutely not. This is meant to be a place to capture
> and refine ideas before creating cards and/or blueprints for them. In other
> words, this should compliment the existing work and backlog already in LP.
Looks
On Thu, Feb 09, 2012 at 04:51:26AM +0800, Ying-Chun Liu (PaulLiu) wrote:
Overall this is looking pretty good, a few issues but relatively minor.
> + if (uv < anatop_reg->rdata->min_voltage
> + || uv > anatop_reg->rdata->max_voltage) {
> + if (max_uV > anatop_reg->rdata->mi
On Fri, Feb 10, 2012 at 10:36:38PM -0800, Shawn Guo wrote:
> On Thu, Feb 09, 2012 at 04:51:26AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> > + rval = of_get_property(np, "min-voltage", NULL);
> > + if (rval)
> > + sreg->rdata->min_voltage = be32_to_cpu(*rval);
> > + rval = of_get_prop
On Thu, Feb 23, 2012 at 05:05:53PM +0530, Rajendra Nayak wrote:
> Modify the twl regulator driver to extract the regulator_init_data from
> device tree when passed, instead of getting it through platform_data
> structures (on non-DT builds)
This doesn't apply to current -next, I expect because of
On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:
> Depending on what order Mark happens to pull them in, I am fine
> re-sending adding support for the 2 twl6030 fixed regulators.
Please can you guys come up with a single unified series for this stuff
- I'll hold off on applying any
On Mon, Feb 27, 2012 at 02:52:05PM +0100, Cousson, Benoit wrote:
> On 2/27/2012 2:41 PM, Mark Brown wrote:
> >On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:
> >Please can you guys come up with a single unified series for this stuff
> >- I'll hold off on
On Mon, Feb 27, 2012 at 03:21:26PM +0100, Cousson, Benoit wrote:
> Mmm, it is written in Rajendra's changelog:
> "-2- All common regulator nodes for twl4030 and twl6030 are
> now defined in the twl4030.dtsi and twl6030.dtsi instead of
Oh, it's buried at the end of a rather verbose inter-patch ch
On Tue, Feb 28, 2012 at 11:11:48AM +0530, Rajendra Nayak wrote:
> changes have no dependencies with any other DT series. I will repost
> all of Tero/Peter and my changes (to add DT support to the driver) as
> one single series and drop the dts file updates, which I guess can go
> via Tony/OMAP tre
On Tue, Feb 28, 2012 at 03:09:09PM +0530, Rajendra Nayak wrote:
> Hi Mark,
>
> Here is a consolidated series which adds DT support for twl regulator
> driver and adds support for VDD1/2/3 regulator and support for
> fixed LDO V1V8 and V2V1. The patches are based on -next and tested
> on omap3 beag
On Thu, Mar 01, 2012 at 05:10:52PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> + if (IS_ERR(rdev)) {
> + dev_err(&pdev->dev, "failed to register %s\n",
> + rdesc->name);
> + kfree(rdesc->name);
> + return PTR_ERR(rdev);
> + }
> +
> +
On Thu, Mar 01, 2012 at 05:10:51PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> + spin_lock(&adata->reglock);
> + val = readl(adata->ioreg + addr);
> + spin_unlock(&adata->reglock);
Do you really need to take a lock for a single read operation from a
memory mapped register? I'd expect thi
On Fri, Mar 02, 2012 at 02:53:35PM +0100, Samuel Ortiz wrote:
> Mark, Liam, are you guys taking this one ?
Yes.
signature.asc
Description: Digital signature
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listin
On Sat, Mar 03, 2012 at 04:36:05PM +0530, Amit Daniel Kachhap wrote:
> This movement is needed because the hwmon entries and corresponding
> sysfs interface is a duplicate of utilities already provided by
> driver/thermal/thermal_sys.c. The goal is to place it in mfd folder
> and add necessary call
On Sun, Mar 04, 2012 at 01:39:12AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> Anatop is a mfd chip embedded in Freescale i.MX6Q SoC.
> Anatop provides regulators and thermal.
> This driver handles the address space and the operation of the mfd device.
Please stop
On Sun, Mar 04, 2012 at 02:51:48PM +0800, Shawn Guo wrote:
> > + sreg = devm_kzalloc(dev, sizeof(struct anatop_regulator), GFP_KERNEL);
> > + if (!sreg)
> > + return -EINVAL;
> > + rdesc = devm_kzalloc(dev, sizeof(struct regulator_desc), GFP_KERNEL);
> > + if (!rdesc)
> > +
On Wed, Mar 07, 2012 at 02:22:25PM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > +- compatible: Must be "fsl,anatop-regulator"
> > +- vol-bit-shift: Bit shift for the register
> > +- vol-bit-width: Number of bits used in the register
> > +- min-bit-val: Minimum value of this register
> > +-
On Wed, Mar 07, 2012 at 04:36:22PM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > This really doesn't seem at all sane for a device which is already
> > vendor specific, it's just noise in the bindings.
> No it's
...?
> Here is a good example as we have regulator generic binding & vendor
>
On Fri, Mar 09, 2012 at 10:58:34AM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > I've modify the patch based on your review. However, the last one cannot
> > be made because regulator_unregister is void return.
> so we have a issue here regulator_unregister MUST return an error conde
The e
On Fri, Mar 09, 2012 at 03:57:09PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> Anatop is an integrated regulator inside i.MX6 SoC.
> There are 3 digital regulators which controls PU, CORE (ARM), and SOC.
> And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB).
On Sat, Mar 10, 2012 at 11:13:08AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> Anatop is an integrated regulator inside i.MX6 SoC.
> There are 3 digital regulators which controls PU, CORE (ARM), and SOC.
> And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB).
On Wed, Mar 14, 2012 at 10:29:12AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> Anatop is an integrated regulator inside i.MX6 SoC.
> There are 3 digital regulators which controls PU, CORE (ARM), and SOC.
> And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB).
On Thu, Mar 15, 2012 at 09:07:29AM +, Arnd Bergmann wrote:
> Very broadly speaking, I wonder whether we could use the regmap
> infrastructure for these things in the future, but I would first
> need to understand whether that is actually in the scope of regmap.
> It seems that you just need a
e mfd device.
Reviwed-by: Mark Brown
signature.asc
Description: Digital signature
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote:
> >So it would be interesting to know more about why you (or anyone else)
> >perceive that the Kconfig changes would be harmful.
> But the enthusiasm of the clock driver developers doesn't
> necessarily translate to users of the clo
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
> On 03/21/2012 12:33 PM, Tony Lindgren wrote:
> >* Mark Brown [120321 12:11]:
> >>These aren't new APIs, the clock API has been around since forever.
> I disagree. When I say clock API, I mean the ac
On Wed, Mar 21, 2012 at 01:04:22PM -0700, Saravana Kannan wrote:
> Sure, prepare/unprepare are already there in the .h file. But they
> are stubs and have no impact till we move to the common clock
> framework or platforms move to them with their own implementation
> (certainly not happening in up
On Tue, Mar 27, 2012 at 03:54:01PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> Change "reg" to "anatop-reg-offset" due to there is a warning of handling no
> size field in reg.
>
> This patch also adds the missing device-tree binding documentation.
Applied, thank
On Thu, Apr 12, 2012 at 11:39:41PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> +- compatible : Should be "dialog,da9052", "dialog,da9053-aa",
> + "dialog,da9053-ab", or "dialog,da9053-bb"
This is generally the stock ticker symbol so DLG for Dialog.
> +Sub-nodes:
> +- regulators
On Thu, Apr 12, 2012 at 11:39:42PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> +#ifdef CONFIG_OF
> + struct device_node *nproot = da9052->dev->of_node;
> + struct device_node *np;
> + int c;
> +
> + if (!nproot) {
> + ret = -ENODEV;
>
On Wed, Apr 11, 2012 at 06:02:38PM -0700, Mike Turquette wrote:
> This series collects many of the fixes posted for the recently merged
> common clock framework as well as some general clean-up. Most of the
> code classifies as a clean-up moreso than a bug fix; hopefully this is
> not a problem si
On Fri, Apr 13, 2012 at 09:37:40PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> + regulators {
> + buck0 {
> + regulator-name = "DA9052_BUCK_CORE";
> + regulator-min-microvolt = <50>;
> +
On Fri, Apr 13, 2012 at 09:37:41PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> This patch adds device tree support for dialog regulators
Applied, thanks. It'd be good to correct the documentation in patch 1
but there should be no code dependency on the core chang
On Fri, Apr 20, 2012 at 12:38:40AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> +Sub-nodes:
> +- regulators : Contain the regulator nodes. The MC34708 regulators are
> + bound using their names as listed below for enabling.
> +
> +mc34708__sw1a: regulator SW1A
> +mc34708__sw1b: regula
On Fri, Apr 20, 2012 at 12:38:41AM +0800, Ying-Chun Liu (PaulLiu) wrote:
> +static const int mc34708_sw1A[] = {
> + 65, 662500, 675000, 687500, 70, 712500,
Replace these by direct calculations, using tables is both less
efficient and less clear.
> + mc34708_lock(priv->mc34708);
>
On Mon, May 14, 2012 at 10:52:46AM +0200, Heiko St??bner wrote:
> Am Montag, 14. Mai 2012, 01:51:00 schrieb Daniel Lezcano:
> > On 05/09/2012 04:08 PM, Daniel Lezcano wrote:
> > Are these patches ok for inclusion ?
> you might want to include the maintainer
> Kukjin Kim
> and the samsung
On Mon, May 14, 2012 at 04:06:17PM +0200, Daniel Lezcano wrote:
> The timekeeping is computed from the cpuidle core if we set
> the .en_core_tk_irqen flag. Let's use it and remove the duplicated
> code.
Tested-by: Mark Brown
signature.asc
Description: Dig
On Mon, May 14, 2012 at 04:06:16PM +0200, Daniel Lezcano wrote:
> The states are now part of the cpuidle_driver structure, so we can
> declare the states in this structure directly. That saves us an extra
> variable declaration and a memcpy.
Tested-by: Mark Brown
signature.asc
De
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
> #include
>
> -/* Buck step size Macros */
> +/* Buck step size */
> #define DA9052_BUCK_PERI_3uV_STEP
is moved before calls to regulator_register.
Acked-by: Mark Brown
___
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 appro
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 = rdev
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-o
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_
On Wed, Jul 06, 2011 at 04:02:13PM +0530, ashishj3 wrote:
> DA9052 PMIC has 16 bit GPIO bus for peripheral control.
>
> This patch add support for the GPIO pins on the DA9052.
Acked-by: Mark Brown
___
linaro-dev mailing list
l
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
___
linaro-de
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 enable
On Wed, Jul 06, 2011 at 04:19:27PM +0530, Ashish Jangam wrote:
> > > The DA9052 PMIC has below featured regulators:-
> > Having patch version info as [Patch V2 5/11] would be better.
> This is a good idea but in my recent post I did not incorporate it
> bcoz this would change the subject line an
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 y
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 res
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 co
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 warn_u
On Thu, Jul 21, 2011 at 10:40:23PM +0200, Arnd Bergmann wrote:
> On Thursday 21 July 2011 16:47:48 Mark Brown wrote:
> > Although the bigger problem is why are these interruptible? That's
> > very unusual.
> Well, the default should really be to use _interruptible or at
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 underly
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,
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_SP
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
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
> > sel
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 Wed, Sep 07, 2011 at 12:07:21PM +0100, Mans Rullgard wrote:
> This adds MODULE_ALIAS directives to the omap-mcbsp-dai and
> omap-pcm-audio drivers so they can be auto-loaded when platform
> devices are scanned.
Acked-by: Mark Brown
___
l
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
On Thu, Sep 08, 2011 at 04:41:30PM +0100, Mans Rullgard wrote:
> On 8 September 2011 16:15, Lars-Peter Clausen 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 code - it look
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 a
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 Fri, Sep 09, 2011 at 12:01:02AM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 08, 2011 at 03:47:31PM -0700, Mark Brown wrote:
> > What will happen for device tree is that there will be a device in the
> > device tree for the ASoC board.
> Sounds like you just solved
On Fri, Sep 09, 2011 at 10:41:56AM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote:
> > The problem is that someone has to manually go and add the device to
> > every board that needs one and people find that tedious and slightl
e corresponding driver in soc-core.
>
> Signed-off-by: Mans Rullgard
Acked-by: Mark Brown
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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
> p
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 platfor
e corresponding driver in soc-core.
>
> Signed-off-by: Mans Rullgard
Acked-by: Mark Brown
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
1 - 100 of 186 matches
Mail list logo
