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
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
>
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,
>
On Thu, May 05, 2016 at 06:03:40PM +0100, Grant Likely wrote:
> On Thu, May 5, 2016 at 5:53 PM, Mark Brown <broo...@kernel.org> 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
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
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 12:18, Vishal Bhoj vishal.b...@linaro.org wrote:
On 17 June 2014 16:41, Fathi Boudra fathi.bou...@linaro.org 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
On 17 June 2014 13:16, Jon Medhurst (Tixy) t...@linaro.org 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 subscribed?
Looks like it. It's
On 16 September 2013 11:48, Riku Voipio riku.voi...@linaro.org 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
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 status on this?
Good question. There are no plans
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 more. So I am not very
On Tue, Aug 06, 2013 at 09:12:44PM +0800, Andy Green wrote:
On 6 August 2013 20:47, Mark Brown broo...@kernel.org 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 workflow
On 5 August 2013 10:11, Jon Medhurst (Tixy) t...@linaro.org 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
On 5 August 2013 10:44, Jon Medhurst (Tixy) t...@linaro.org 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
On 5 August 2013 03:45, Andy Green andy.gr...@linaro.org 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
On 5 August 2013 11:00, Jon Medhurst (Tixy) t...@linaro.org 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
On Mon, Aug 05, 2013 at 06:42:33PM +0800, Andy Green wrote:
On 5 August 2013 18:16, Mark Brown broo...@linaro.org 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-linaro I'm
On Mon, Aug 05, 2013 at 07:37:10PM +0800, Andy Green wrote:
On 5 August 2013 18:59, Mark Brown broo...@kernel.org 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 that I'm aware
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 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-rc3
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
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 upload
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 broo...@opensource.wolfsonmicro.com
signature.asc
Description: Digital
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 broo...@opensource.wolfsonmicro.com
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 kgene@samsung.com
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: regulator
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 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 since
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) paul@linaro.org
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
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 : Contain
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 Tue, Mar 27, 2012 at 03:54:01PM +0800, Ying-Chun Liu (PaulLiu) wrote:
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
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.
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 clock
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
.
Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com
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) paul@linaro.org
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,
On Sat, Mar 10, 2012 at 11:13:08AM +0800, Ying-Chun Liu (PaulLiu) wrote:
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
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,
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 error
On Fri, Mar 09, 2012 at 03:57:09PM +0800, Ying-Chun Liu (PaulLiu) wrote:
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
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,
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 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)
+ return
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 calls
On Sun, Mar 04, 2012 at 01:39:12AM +0800, Ying-Chun Liu (PaulLiu) wrote:
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
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.
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);
+ }
+
+ return 0;
+}
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 this to be
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 beagle
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 tree.
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
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 applying anything to allow you
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
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_property(np,
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-min_voltage)
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 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) {
+
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 out some old patches
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 review
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 * 2 + 1]);
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 +, Mark Brown wrote:
You can't
On Wed, Dec 28, 2011 at 08:40:56PM +0800, Richard Zhao wrote:
On Wed, Dec 28, 2011 at 12:14:04PM +, 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
exactly 80 characters which is too
On Wed, Dec 28, 2011 at 09:06:20PM +0800, Shawn Guo wrote:
On Wed, Dec 28, 2011 at 12:47:40PM +, 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 interesting
position, that is it can
On Tue, Dec 27, 2011 at 09:51:10AM +0800, Richard Zhao wrote:
On Mon, Dec 26, 2011 at 02:22:34PM +, 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 bit more than 80 columns a lot
On Tue, Dec 27, 2011 at 06:06:27PM +0800, Ying-Chun Liu (PaulLiu) wrote:
(2011年12月22日 19:33), Mark Brown wrote:
+#include linux/platform_device.h
+#include linux/regulator/machine.h
Why does your regulator driver need this? That suggests a layering
violation.
Sorry, I'm not sure what
On Sat, Dec 24, 2011 at 11:52:29PM +0800, Richard Zhao wrote:
On Sat, Dec 24, 2011 at 01:42:29PM +, 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
board
dts can overrite
On Mon, Dec 26, 2011 at 09:44:52PM +0800, Richard Zhao wrote:
On Mon, Dec 26, 2011 at 11:10:30AM +, 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 it up with an actual implementation
On Sat, Dec 24, 2011 at 04:55:42PM +0800, Richard Zhao wrote:
On Fri, Dec 23, 2011 at 01:18:51PM +, Mark Brown wrote:
+- trans-latency : transition_latency, in unit of ns.
trans-latency should really say what latency is being measured (the CPU
core only or the whole operation
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 +
+ (uv - reg-constraints-min_uV) / 25000;
You're
On Sat, Dec 24, 2011 at 09:28:33PM +0800, Richard Zhao wrote:
On Sat, Dec 24, 2011 at 12:24:11PM +, 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 regulator part
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 broo...@opensource.wolfsonmicro.com
but one nit:
+Required properties in /cpus
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 dmitry.anti...@linaro.org
Date: Wed, 21 Dec 2011 11:01:42 +0400
Subject: [PATCH] regulator: use usleep_range() instead of
On Wed, Dec 21, 2011 at 05:03:31PM +0800, Ying-Chun Liu (PaulLiu) wrote:
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
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
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?
I
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 find
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 which
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
On Wed, Dec 21, 2011 at 07:27:03AM +0800, Richard Zhao wrote:
On Tue, Dec 20, 2011 at 02:59:04PM +, 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 need strict voltages
On Wed, Dec 21, 2011 at 09:20:46AM +0800, Richard Zhao wrote:
On Tue, Dec 20, 2011 at 11:48:45PM +, 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
varied with frequency
On Wed, Dec 21, 2011 at 10:24:53AM +0800, Richard Zhao wrote:
On Wed, Dec 21, 2011 at 01:32:21AM +, 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
voltage without altering
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
On Thu, Dec 15, 2011 at 06:59:53PM +0530, Ashish Jangam wrote:
Reported-by: Mark Brown broo...@opensource.wolfsonmicro.com
Signed-off-by: David Dajun Chen dc...@diasemi.com
Signed-off-by: Ashish Jangam ashish.jan...@kpitcummins.com
Applied, but this really should have been sent as two separate
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
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
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 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.
Applied
and other functionality.
This patch is functionally tested on Samsung SMDKV6410.
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
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
looks good.
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
+int da9052_add_regulator_devices(struct da9052 *da9052)
+{
+ struct platform_device *pdev;
+ int i, ret;
+
+ for (i = 0; i DA9052_MAX_REGULATORS; i++) {
+ pdev = platform_device_alloc(da9052
On Fri, Dec 09, 2011 at 07:45:44PM +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.
Oh, actually I see you didn't Samuel, you must always CC maintainers on
patches otherwise
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 -EINVAL;
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 broo...@opensource.wolfsonmicro.com
Looks good, though again you
On Wed, Dec 07, 2011 at 09:53:18PM +0800, Ying-Chun Liu (PaulLiu) wrote:
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
Anatop regulator driver is used by i.MX6 SoC. This patch adds the
Anatop regulator driver.
This changelog isn't terribly verbose but looking at the code what
you've
On Mon, Dec 05, 2011 at 02:40:50PM +0530, Thomas Abraham wrote:
On 4 December 2011 21:24, Mark Brown
If the regulator isn't software managed then always_on covers this - the
regulator core will enable any always_on regulators that haven't been
enabled already.
Thanks for the hint. I
On Mon, Dec 05, 2011 at 04:14:40PM +0530, Thomas Abraham wrote:
On 5 December 2011 16:04, Mark Brown
With the regulator device tree bindings if the regulator is configured
to run a single voltage the bindings will set apply_uV unconditionally
so there's no need for a separate constraint
On Mon, Dec 05, 2011 at 12:16:24PM +0530, ashishj3 wrote:
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -164,7 +164,6 @@ static irqreturn_t regmap_irq_thread(int irq, void *d)
* irq: The IRQ the device uses to signal interrupts
* irq_flags: The
1 - 100 of 156 matches
Mail list logo
