On Fri, May 06, 2016 at 02:03:42PM -0400, Jon Masters wrote:
> On 05/06/2016 01:10 PM, Mark Brown wrote:
> > On Fri, May 06, 2016 at 12:20:40PM -0400, Jon Masters wrote:
> > > But is it really worth trying after so long of the right thing not
> > > happening? If anyon
On Fri, May 06, 2016 at 12:20:40PM -0400, Jon Masters wrote:
> But is it really worth trying after so long of the right thing not
> happening? If anyone really cared about making general purpose distros boot
> on embedded boards, efforts to compel standards would have happened years
> ago. To do i
On Thu, May 05, 2016 at 12:44:57PM -0700, Brendan Conoboy wrote:
> All of the best practices people here are talking about appear to be geared
> toward a frictionless connection to the ARM Linux ecosystem. That's
> something many software focused Linaro participants care about, but is that
> some
On Thu, May 05, 2016 at 07:47:41PM +0100, Martin Stadtler wrote:
> Specifically for the 96boards, the spec is a recommended view, but its not
> meant to be constraining, however it does allow one to then show a best
> practice, that others can adopt. That's where the RPB comes in to play,
> again
On Thu, May 05, 2016 at 06:03:40PM +0100, Grant Likely wrote:
> On Thu, May 5, 2016 at 5:53 PM, Mark Brown wrote:
> > I think there's one other slightly different angle on this which we
> > should address at the same time, creating fresh boot media for a device
> > (&qu
On Thu, May 05, 2016 at 04:21:59PM +0100, Grant Likely wrote:
> I think we have everything we need to work around the location of the
> FW boot image without breaking the UEFI spec. The biggest problem is
> making sure partitioning tools don't go stomping over required
> firmware data and renderin
On Thu, May 05, 2016 at 09:01:05PM +0530, Amit Kucheria wrote:
> On Thu, May 5, 2016 at 5:15 PM, Marcin Juszkiewicz
> > Solution for existing SoCs is usually adding 1MB of SPI flash during design
> > phase of device and store boot loader(s) there. But it is so expensive
> > someone would say when
On 17 June 2014 13:16, Jon Medhurst (Tixy) wrote:
> On Tue, 2014-06-17 at 12:53 +0100, Mark Brown wrote:
> > I've added him.
>
> You didn't seem to have, unless this more of the Linaro's lists's
> default behaviour of dropping people from CC who are su
On 17 June 2014 12:18, Vishal Bhoj wrote:
> On 17 June 2014 16:41, Fathi Boudra wrote:
>
>> Vishal,
>>
>> 1. against which tree should it be applied?
>>
> I have tested it against TC2 with the LSK tree. I was not sure if the
> patches directly go to LSK. I thought it should first go into config
On 16 September 2013 11:48, Riku Voipio wrote:
> Do we have a plan for adding gator to LSK now? I have a request to
> support gator on LSK based image, and I'd prefer not to add the module
> from outside the kernel.
>
No, there's a card in process but it's not been approved yet.
___
On Thu, Aug 08, 2013 at 05:50:57PM +0400, Andrey Konovalov wrote:
> On 08/08/2013 05:30 PM, Mark Brown wrote:
> >Any great reason why not? It doesn't seem particularly controversial or
> >anything and definitely seems useful.
> Just the patch author is not with Linaro any
On Thu, Aug 08, 2013 at 05:20:46PM +0400, Andrey Konovalov wrote:
> On 08/05/2013 11:34 PM, Mark Brown wrote:
> >These appear to be upstream anyway in one form or another.
> >>"KBuild: Allow scripts/* to be cross compiled"
> >What's the upstreaming
On Tue, Aug 06, 2013 at 09:12:44PM +0800, Andy Green wrote:
> On 6 August 2013 20:47, Mark Brown wrote:
> > Please submit things normally - attachments are non-standard and
> > difficult to work with (both from the point of view of applying and from
> > the point of view of
On Tue, Aug 06, 2013 at 08:24:52AM +0800, Andy Green wrote:
> I went through and split out the fixes after examining each one.
Please submit things normally - attachments are non-standard and
difficult to work with (both from the point of view of applying and from
the point of view of workflow) a
On Mon, Aug 05, 2013 at 11:23:19PM +0400, Andrey Konovalov wrote:
> # Misc fixes which don't belong to any particular topic:
> ynk/llct-v3.10-misc-fixes
> "Add cross-build support to tools/lib/lk library"
> "perf tools: make perf to build in 3.9 kernel tree again"
> "ARM: crypto:
On Mon, Aug 05, 2013 at 07:37:10PM +0800, Andy Green wrote:
> On 5 August 2013 18:59, Mark Brown wrote:
> > - The regmap change isn't something that I've seen upstream...
> If you mean where did the original come from
I mean I haven't seen that warning t
On Mon, Aug 05, 2013 at 06:42:33PM +0800, Andy Green wrote:
> On 5 August 2013 18:16, Mark Brown wrote:
> > There may be other stuff lurking in linux-linaro that I'm not aware of,
> > everything is supposed to be individually selected for backport.
> Literally linux
On 5 August 2013 11:00, Jon Medhurst (Tixy) wrote:
> As was mentioned on linaro-kernel the plan is that you should be
> > sending me incremental updates as needed.
>
> But who decides what's needed? If what is in 3.10 works, why backport a
> different version? And I hadn't planned on spending a
On 5 August 2013 03:45, Andy Green wrote:
> 1) There seems to be two choices, linux-linaro-lsk and
> linux-linaro-lsk-android.
>
> I chose the android one, I assume it has the same "androidization"
> series on top that linux-linaro-core-tracking used at 3.10? Are there
> any other differences?
On 5 August 2013 10:44, Jon Medhurst (Tixy) wrote:
> On Mon, 2013-08-05 at 17:13 +0800, Andy Green wrote:
>
> > The whole list is good things to have I just wonder how ongoing
> > updates will be handled for backport. For example at some point
> > "Tweaks to the MCPM code which aren't upstream
On 5 August 2013 10:11, Jon Medhurst (Tixy) wrote:
> On Mon, 2013-08-05 at 16:43 +0800, Andy Green wrote:
>
> > 5) Gator bits don't seem to be in there, presumably that's something
> > ARM would like to see in there (it appears in llct)
>
> Yes, and I believe someone was raising a card to get i
On Wed, Jun 05, 2013 at 12:05:30AM +0400, Andrey Konovalov wrote:
> Another point to mention, is the proposal to merge the board
> enablement topics first, and the generic features next (the LSK
> case). This would assume the generic topics to enable their features
> for "all the linaro supported"
On Fri, May 03, 2013 at 09:47:53AM +0100, Jon Medhurst (Tixy) wrote:
> On Thu, 2013-05-02 at 22:40 +0400, Andrey Konovalov wrote:
> > v3.9 release based linux-linaro-core-tracking (llct) rebuild has been
> > published, the tag is llct-20130502.0 . The 13.05 linux-linaro release
> > will be v3.10
On Mon, Apr 29, 2013 at 09:28:16AM -0400, Christopher Covington wrote:
> I'm familiar with a submit- or merge-time option for this. It's not clear to
> me from your reply whether you're referring to this or an upload- or push-time
> option.
Oh, on initial push? I've not seen that but it does str
On Wed, Apr 17, 2013 at 09:14:54AM -0400, Christopher Covington wrote:
> On 04/17/2013 06:29 AM, Jon Medhurst (Tixy) wrote:
> > And with gerrit the patch author needs to get an account enabled with the
> > project, produce a git commit against the current tip,
> I can't recall ever seeing an uplo
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, 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 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 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 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 13, 2012 at 09:37:40PM +0800, Ying-Chun Liu (PaulLiu) wrote:
> + regulators {
> + buck0 {
> + regulator-name = "DA9052_BUCK_CORE";
> + regulator-min-microvolt = <50>;
> +
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 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 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 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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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 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 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 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: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 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 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 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 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 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 Fri, Dec 09, 2011 at 07:48:20PM +0530, Ashish Jangam wrote:
> The Dialog PMIC has below featured regulators:-
> DA9052-BC - 4 DVS Buck converters 0.5V - 3.6V upto 1Amp.
> DA9053-AA/BX - 4 DVS Buck converters 0.5V - 2.5V upto 3Amp.
> DA9052/53 - 10 Programmable LDO's High PSSR, 1% accuracy.
Appl
On Wed, Dec 14, 2011 at 05:42:09PM +0400, Anton Vorontsov wrote:
> I presume this depends on other patches, so I'm fine if this goes via
> non-battery tree,
There should be no direct dependencies for new MFDs - the Kconfig
required to depend on the MFD core means that the drivers can't be
selecte
On Mon, Dec 12, 2011 at 08:06:56PM +0530, Ashish Jangam wrote:
> The DA9052/53 is a highly integrated PMIC subsystem with supply domain
> flexibility to support wide range of high performance application.
Applied, thanks.
___
linaro-dev mailing list
lin
On Mon, Dec 12, 2011 at 08:37:41PM +0530, Ashish Jangam wrote:
> This patch add SPI support for DA9052/53 MFD core module.
Applied, thanks.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wed, Dec 14, 2011 at 09:24:33AM +0100, Linus Walleij wrote:
> The above remaps and reads from some random ROM page to get
> the ASIC ID is actually not screwing things up. Right now.
The ASIC ID reads are also done by Samsung platforms which boot fine -
it's not strictly good but it happens to
control and other functionality.
> This patch is functionally tested on Samsung SMDKV6410.
Reviewed-by: Mark Brown
Looking good now! Samuel, this uses regmap-irq so either I can carry
this or you can merge:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git topic/irq
into y
On Fri, Dec 09, 2011 at 07:46:33PM +0530, Ashish Jangam wrote:
> The DA9052/53 is a highly integrated PMIC subsystem with supply domain
> flexibility to support wide range of high performance application.
Reviwed-by: Mark Brown
Looks good, though again you should've CCed Samuel.
On Fri, Dec 09, 2011 at 07:46:06PM +0530, Ashish Jangam wrote:
> + req = kzalloc(sizeof(*req), GFP_KERNEL);
> + if (!req)
> + return -ENOMEM;
> + init_completion(&req->done);
> + req->input = channel;
> +
> + if (channel > DA9052_ADC_VBBAT)
> + return -
1 - 100 of 186 matches
Mail list logo
