* [GIT PULL] Xilinx Zynq fix for v3.14
From: Kevin Hilman @ 2014-02-10 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F8C356.8060209@monstr.eu>
Michal Simek <monstr@monstr.eu> writes:
> Hi,
>
> please consider to queue this bug fix for v3.14.
>
> Bug was reported here:
> https://lkml.org/lkml/2014/1/27/212
>
> I have also discussed this with Rob regarding memreserve DT feature.
> Here is thread with Rob:
> https://lkml.org/lkml/2014/1/31/105
>
> Moving kernel start is currently enabled by:
> "ARM: ignore memory below PHYS_OFFSET"
> (sha1: 571b14375019c3a66ef70d4d4a7083f4238aca30)
>
> Thanks,
> Michal
>
>
> The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
>
> Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
>
> are available in the git repository at:
>
> git://git.xilinx.com/linux-xlnx.git tags/zynq-fixes-for-3.14
>
> for you to fetch changes up to a73cbb758171c34cc3d58f3dfb80feef501a2079:
>
> ARM: zynq: Reserve not DMAable space in front of the kernel (2014-02-10 13:04:35 +0100)
>
> ----------------------------------------------------------------
> arm: Xilinx Zynq fixes for v3.14
>
> - Protect DMA buffer allocation below
> kernel start address
>
> ----------------------------------------------------------------
Applied to fixes,
Thanks,
Kevin
^ permalink raw reply
* [PATCH 06/11] ARM: mvebu: add Armada 380/385 support to the system-controller driver
From: Jason Cooper @ 2014-02-10 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210184726.2a787050@skate>
On Mon, Feb 10, 2014 at 06:47:26PM +0100, Thomas Petazzoni wrote:
> Dear Jason Cooper,
>
> On Mon, 10 Feb 2014 12:39:57 -0500, Jason Cooper wrote:
>
> > > Note that we intentionally do not use the same compatible string as
> > > Armada 370/XP, as the current system-controller driver is far from
> > > exploiting all the possibilities of the hardware, and we may in the
> > > future discover differences between Armada 370/XP and Armada 380/385.
> >
> > I'd much prefer to add a new compatible string iff it accompanies
> > incompatible changes.
> >
> > For now, I think it's best to use 'marvell,armada-370-xp-system-controller'
> > in the dtsi file and change it when you introduce the incompatible
> > features.
>
> This doesn't work really well: if an user keeps an old DTB around,
> which uses the old compatible string, then you're screwed because
> there's no way a new kernel version can make the distinction between
> Armada 370/XP and Armada 380/385.
devicetree is designed to handle this. The dtb is _supposed_ to be
separate from the kernel.
> If we discover than Armada 380/385 need a special quirk to really work
> reliably for example, but that this quirk doesn't apply to Armada
> 370/XP, then you have a serious problem.
No, you don't. It's the responsibility of the driver author to _not_
make incompatible changes and to sanely fall back to default behavior.
Right now there are no differences, and both SoCs work with the same
compatible string. If later there is support added for a feature for
one of them, we add a compatible string to differentiate the two. When
the driver encounters a potentially old dtb, it defaults to behaving as
it does today. iow, no new feature.
In this situation, the driver or SoC code could see the root compatible
node is marvell,armada385 with a sys-con node using
marvell,armada-370-xp-sys-con. It could then print a warning about
potentially old dtb. Depending on the severity of the bug (which
couldn't be too severe, otherwise you'd have code here today ;) ), you
could even override the compatible string in the SoC code.
> Therefore, I would like to really insist to have separate compatible
> strings for different SOCs. As an example, we used to have the same
> compatible string for the timer between Armada 370 and Armada XP, and
> later discovered that it was not possible due to a bug affecting only
> one of the two SOCs. Our experience clearly shows that sharing
> compatible strings is a bad idea, and having separate compatible
> strings from the beginning doesn't cost anything, and offers higher
> flexibility for the future.
Your argument is tempting, but I see a lot of over-quantization with
little to no measurable gain other than "just in case."
If I follow your logic and refer to the i2c transaction generator
problem, should we go back and add compatible strings for all on-die IP
blocks for every SoC and SoC revision? Even though we only wish we had
something once? Can we anticipate every possible way an IP block will
be broken?
Ultimately, what I'm saying is that the devicetree process should be
able to handle this kind of situation. And if it can't, the process is
broken. No amount of bubblewrap and safety helmets will save us then.
Now, wrt marvell,armada-38x-system-controller, if you can point out
specific features you know about *today* that are different from the
370/xp sys-con, please spell them out at least in the commit log. I'm
fine with just mentioning the features at this point, since we're
dealing with initial SoC support. But "...we may in the future discover
differences between..." doesn't inspire confidence.
thx,
Jason.
^ permalink raw reply
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Arnaud Ebalard @ 2014-02-10 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122235620.GC20359@xanatos>
Hi Sarah,
Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> On Wed, Jan 22, 2014 at 11:43:16PM +0100, Arnaud Ebalard wrote:
>> Hi Jason,
>>
>> Jason Cooper <jason@lakedaemon.net> writes:
>>
>> > On Wed, Jan 22, 2014 at 11:23:23PM +0100, Arnaud Ebalard wrote:
>> >> With the patch applied on top of 3.13.0 kernel recompiled w/
>> >> CONFIG_PCI_MSI enabled, I cannot reproduce the bug. I guess
>> >> you can add my:
>> >>
>> >> Reported-and-tested-By: Arnaud Ebalard <arno@natisbad.org>
>> >>
>> >> Since you'll have to push the patch to -stable team at least for 3.13,
>> >> I wonder if it would not make sense to extend that at least to 3.12.
>> >> and possibly 3.10 (3.2 is still widely used but I wonder if it makes
>> >> sense to go that far).
>> >
>> > Can you pinpoint the commit that introduced the regression?
>>
>> f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco Logic hosts."
>>
>> Technically, this is not per se the commit which introduced the
>> regression but the one that *partially* fixed it by introducing the XHCI
>> quirk to skip MSI enabling for Fresco Logic chips. The thing is it
>> should have included the FL1009 in the targets. Sarah, can you confirm
>> this?
>
> I don't know if it should have included FL1009, it was just a guess,
> based on the fact that the 0x1000 and 0x1400 devices did need MSI
> disabled. I can attempt to ask the Fresco Logic folks I know, but I'm
> not sure if/when I'll get a response back.
>
> That still doesn't necessarily rule out MSI issues in the Marvell PCI
> host controller code. Can you attach another PCI device with MSI
> support under the host and see if it works?
Unless you have some objections or some positive feedback from Fresco
Logic people, can you queue your quirks for FL1009 for 3.14-rc* and
-stable? Note that I am just asking, i.e. if you want to wait a bit
more, I am not that in a hurry.
Cheers,
a+
^ permalink raw reply
* [PATCH 06/11] ARM: mvebu: add Armada 380/385 support to the system-controller driver
From: Thomas Petazzoni @ 2014-02-10 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210184857.GT8533@titan.lakedaemon.net>
Dear Jason Cooper,
On Mon, 10 Feb 2014 13:48:57 -0500, Jason Cooper wrote:
> > This doesn't work really well: if an user keeps an old DTB around,
> > which uses the old compatible string, then you're screwed because
> > there's no way a new kernel version can make the distinction between
> > Armada 370/XP and Armada 380/385.
>
> devicetree is designed to handle this. The dtb is _supposed_ to be
> separate from the kernel.
Exactly. Which is the whole point why your strategy doesn't work. Since
the DTB is supposed to be separate from the kernel, we have no
guarantee that the user will update the DTB when updating the kernel.
Therefore, we have to keep compatibility for old DTBs, which forces us
to be extra cautious when choosing compatible strings.
> > If we discover than Armada 380/385 need a special quirk to really work
> > reliably for example, but that this quirk doesn't apply to Armada
> > 370/XP, then you have a serious problem.
>
> No, you don't. It's the responsibility of the driver author to _not_
> make incompatible changes and to sanely fall back to default behavior.
This is not always possible. If we discover that the 38x system
controller has a bug that needs to be worked around in a way that isn't
suitable for Armada 370/XP, then there is *no* way for the driver
author to keep backward compatibility.
> Right now there are no differences, and both SoCs work with the same
> compatible string. If later there is support added for a feature for
> one of them, we add a compatible string to differentiate the two. When
> the driver encounters a potentially old dtb, it defaults to behaving as
> it does today. iow, no new feature.
This only works if you *add* new features. Not if you have to get back
to existing features and make changes that have to be different between
the SOCs to fix bugs for existing features.
> In this situation, the driver or SoC code could see the root compatible
> node is marvell,armada385 with a sys-con node using
> marvell,armada-370-xp-sys-con. It could then print a warning about
> potentially old dtb. Depending on the severity of the bug (which
> couldn't be too severe, otherwise you'd have code here today ;) ), you
> could even override the compatible string in the SoC code.
This seems overly complicated compared to the simple usage of different
compatible strings per-SoC.
At least, I'd like your policy to be baked by statements from the DT
maintainers because I am not sure this policy is universally accepted.
> > Therefore, I would like to really insist to have separate compatible
> > strings for different SOCs. As an example, we used to have the same
> > compatible string for the timer between Armada 370 and Armada XP, and
> > later discovered that it was not possible due to a bug affecting only
> > one of the two SOCs. Our experience clearly shows that sharing
> > compatible strings is a bad idea, and having separate compatible
> > strings from the beginning doesn't cost anything, and offers higher
> > flexibility for the future.
>
> Your argument is tempting, but I see a lot of over-quantization with
> little to no measurable gain other than "just in case."
Did you see the very real example of "just in case" I described in the
paragraph just above, with the Armada 370/XP timer? This "just in case"
lead us to break compatibility with old DTs, and have a broken kernel
until -rc4 or -rc5, due to issues in merging the necessary DT changes
and driver changes.
To me, your policy is simply ignoring the experience.
> If I follow your logic and refer to the i2c transaction generator
> problem, should we go back and add compatible strings for all on-die IP
> blocks for every SoC and SoC revision? Even though we only wish we had
> something once? Can we anticipate every possible way an IP block will
> be broken?
Hard to anticipate all the cases, but when we can, we should do it.
Armada 370/XP and Armada 38x are *very* different SOCs. They don't use
the same CPU core, the same cache controller, the same interrupt
controller, a large number of peripherals have changed. The likely-hood
of discovering differences is fairly high.
> Ultimately, what I'm saying is that the devicetree process should be
> able to handle this kind of situation. And if it can't, the process is
> broken. No amount of bubblewrap and safety helmets will save us then.
>
> Now, wrt marvell,armada-38x-system-controller, if you can point out
> specific features you know about *today* that are different from the
> 370/xp sys-con, please spell them out at least in the commit log. I'm
> fine with just mentioning the features at this point, since we're
> dealing with initial SoC support. But "...we may in the future discover
> differences between..." doesn't inspire confidence.
Have you ever had a look at a very early datasheet? It seems like not.
The datasheet details at this stage of the SoC development are very
limited as the datasheet is still being written. Remember that we are
talking about a SoC that has not even been announced publicly on the
SoC vendor web site.
We had to get back to Marvell many, many times to have enough details
to understand various aspects of the SoC. So yes, we may very well
discover differences in the future, simply because we have no way,
today, to have a clear view of all aspects of the SoC.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/2] Marvell Armada 375 and 38x timer support
From: Ezequiel Garcia @ 2014-02-10 19:07 UTC (permalink / raw)
To: linux-arm-kernel
Hello Daniel,
This small series adds support for the two new Marvell ARM SoCs:
the Armada 375 and Armada 38x.
These new SoCs are based on Cortex-A9 CPU cores, and share a
number of peripherals with their predecessors in the mach-mvebu
family. The core support (arch/arm/mach-mvebu) for these SOCs have just
been posted, and we're aiming at having this merged for 3.15.
The A375 SoC timer is modeled matching the A370 timer, while the
A38x SoC timer is modeled matching the AXP timer. However, we'd like
to keep the compatible strings as SoC-specific.
In the past, we've had trouble chosing a common compatible string, resulting
in the introduction of per-SoC compatibles. Such compatible-string change
of course implies breaking backards compatibility, and was only possible
after agreeing that the old compatible wasn't used in production.
So, in order to avoid such problems, we think it's better to keep them
separate.
Gregory CLEMENT (2):
clocksource: armada-370-xp: Add support for Armada 375
clocksource: armada-370-xp: Add support for Armada 38x
.../bindings/timer/marvell,armada-370-xp-timer.txt | 13 ++++++++----
drivers/clocksource/time-armada-370-xp.c | 23 +++++++++++++++++++++-
2 files changed, 31 insertions(+), 5 deletions(-)
--
1.8.1.5
^ permalink raw reply
* [PATCH 1/2] clocksource: armada-370-xp: Add support for Armada 375
From: Ezequiel Garcia @ 2014-02-10 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392059274-26965-1-git-send-email-ezequiel.garcia@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
The Armada 375 has a 25 Mhz fixed clock, but it is non-functional.
Therefore, let's use the A370 initialization for now, using the provided
parent clock.
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
.../bindings/timer/marvell,armada-370-xp-timer.txt | 13 +++++++++----
drivers/clocksource/time-armada-370-xp.c | 13 ++++++++++++-
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
index f455182..59894fb 100644
--- a/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
+++ b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
@@ -1,9 +1,11 @@
-Marvell Armada 370 and Armada XP Timers
----------------------------------------
+Marvell Armada 370, 375 and XP Timers
+-------------------------------------
Required properties:
-- compatible: Should be either "marvell,armada-370-timer" or
- "marvell,armada-xp-timer" as appropriate.
+- compatible: Should be either:
+ - "marvell,armada-370-timer"
+ - "marvell,armada-375-timer"
+ - "marvell,armada-xp-timer"
- interrupts: Should contain the list of Global Timer interrupts and
then local timer interrupts
- reg: Should contain location and length for timers register. First
@@ -13,6 +15,9 @@ Required properties:
Clocks required for compatible = "marvell,armada-370-timer":
- clocks : Must contain a single entry describing the clock input
+Clocks required for compatible = "marvell,armada-375-timer":
+- clocks : Must contain a single entry describing the clock input
+
Clocks required for compatible = "marvell,armada-xp-timer":
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index ee8691b..87eda6d 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -15,12 +15,15 @@
* used as clock_event_device.
*
* ---
- * Clocksource driver for Armada 370 and Armada XP SoC.
+ * Clocksource driver for Armada 370, Armada 375 and Armada XP SoC.
* This driver implements one compatible string for each SoC, given
* each has its own characteristics:
*
* * Armada 370 has no 25 MHz fixed timer.
*
+ * * Armada 375 has a non-usable 25 Mhz fixed timer, due to hardware
+ * issues.
+ *
* * Armada XP cannot work properly without such 25 MHz fixed timer as
* doing otherwise leads to using a clocksource whose frequency varies
* when doing cpufreq frequency changes.
@@ -316,3 +319,11 @@ static void __init armada_370_timer_init(struct device_node *np)
}
CLOCKSOURCE_OF_DECLARE(armada_370, "marvell,armada-370-timer",
armada_370_timer_init);
+
+/*
+ * Currently support the Armada 375 timer as identical to the Armada 370.
+ * However, let's keep a SoC-specific compatible string to allow to change
+ * this in the future.
+ */
+CLOCKSOURCE_OF_DECLARE(armada_375, "marvell,armada-375-timer",
+ armada_370_timer_init);
--
1.8.1.5
^ permalink raw reply related
* [PATCH 2/2] clocksource: armada-370-xp: Add support for Armada 38x
From: Ezequiel Garcia @ 2014-02-10 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392059274-26965-1-git-send-email-ezequiel.garcia@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
The Armada 38x has a 25 Mhz fixed clock. Therefore, we can model it
as compatible to the Armada XP timer for now. Nevertheless, we introduce
a new compatible string to allow future changes.
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
drivers/clocksource/time-armada-370-xp.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index 87eda6d..9fd20b2 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -24,6 +24,8 @@
* * Armada 375 has a non-usable 25 Mhz fixed timer, due to hardware
* issues.
*
+ * * Armada 380 has a 25 Mhz fixed timer.
+ *
* * Armada XP cannot work properly without such 25 MHz fixed timer as
* doing otherwise leads to using a clocksource whose frequency varies
* when doing cpufreq frequency changes.
@@ -327,3 +329,11 @@ CLOCKSOURCE_OF_DECLARE(armada_370, "marvell,armada-370-timer",
*/
CLOCKSOURCE_OF_DECLARE(armada_375, "marvell,armada-375-timer",
armada_370_timer_init);
+
+/*
+ * Support the Armada 38x timer as identical to the Armada XP, using the
+ * available 25 MHz clock. We maintain a SoC-specific compatible string to
+ * allow to change this in the future.
+ */
+CLOCKSOURCE_OF_DECLARE(armada_380, "marvell,armada-380-timer",
+ armada_xp_timer_init);
--
1.8.1.5
^ permalink raw reply related
* [PATCHv4 4/7] hwspinlock/core: add common OF helpers
From: Suman Anna @ 2014-02-10 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJAp7Oi7wD+VsMAd37gT04yZ4TH4ygXFmheDhvmWuanUjpBmVQ@mail.gmail.com>
Bjorn,
On 02/07/2014 04:49 PM, Bjorn Andersson wrote:
> On Mon, Jan 13, 2014 at 4:19 PM, Suman Anna <s-anna@ti.com> wrote:
>> This patch adds three new OF helper functions to use/request
>> locks from a hwspinlock device instantiated through a
>> device-tree blob.
>
> Nice, I ran in to the problem of needing a probe deferral on a
> hwspinlock earlier this week so I implemented this yesterday...then I
> got a pointer to your series.
>
> [snip]
>> /**
>> + * of_hwspin_lock_request_specific() - request a OF phandle-based specific lock
>> + * @np: device node from which to request the specific hwlock
>> + * @propname: property name containing hwlock specifier(s)
>> + * @index: index of the hwlock
>> + *
>> + * This function is the OF equivalent of hwspin_lock_request_specific(). This
>> + * function provides a means for users of the hwspinlock module to request a
>> + * specific hwspinlock using the phandle of the hwspinlock device. The requested
>> + * lock number is indexed relative to the hwspinlock device, unlike the
>> + * hwspin_lock_request_specific() which is an absolute lock number.
>> + *
>> + * Returns the address of the assigned hwspinlock, or NULL on error
>> + */
>> +struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
>> + const char *propname, int index)
>> +{
>> + struct hwspinlock_device *bank;
>> + struct of_phandle_args args;
>> + int id;
>> + int ret;
>> +
>> + ret = of_parse_phandle_with_args(np, propname, "#hwlock-cells", index,
>> + &args);
>> + if (ret) {
>> + pr_warn("%s: can't parse hwlocks property of node '%s[%d]' ret = %d\n",
>> + __func__, np->full_name, index, ret);
>> + return NULL;
>> + }
>
> of_parse_phandle_with_args() already does pr_err if it can't find the
> phandle and on some of the issues related to arguments. So please
> remove this pr_warn().
Yes, I will clean this up.
>
> It seems to be standard practice to pass the error value back to the
> consumer, so you should
> return ERR_PTR(ret); here instead of the NULL...
I have modelled the return values in this function based on the return
values in the existing hwspin_lock_request interfaces. I would need to
change those functions as well.
Ohad,
Do you have any objections to the return code convention change? I agree
with Bjorn on the changes. If you are ok, then I will add a separate
patch for the existing functions and revise this patch as well.
>
>> +
>> + mutex_lock(&hwspinlock_tree_lock);
>> + list_for_each_entry(bank, &hwspinlock_devices, list)
>> + if (bank->dev->of_node == args.np)
>> + break;
>> + mutex_unlock(&hwspinlock_tree_lock);
>> + if (&bank->list == &hwspinlock_devices) {
>> + pr_warn("%s: requested hwspinlock device %s is not registered\n",
>> + __func__, args.np->full_name);
>> + return NULL;
>
> ...especially since you want the consumer to have the ability to
> identify this error. Here you should
> return ERR_PTR(-EPROBE_DEFER); so that the consumer knows that this
> lock is not _yet_ registered, but will be in the future.
>
> You should remove this pr_warn as well. The standard use of this
> function would be in a probe() and just returning this error value
> from that probe will give you a line in the log indicating that this
> was in fact the issue.
OK.
>
>> + }
>> +
>> + id = bank->ops->of_xlate(bank, &args);
>> + if (id < 0 || id >= bank->num_locks) {
>> + pr_warn("%s: requested lock %d is either out of range [0, %d] or failed translation\n",
>> + __func__, id, bank->num_locks - 1);
>> + return NULL;
>
> Please return ERR_PTR(-EINVAL); here.
OK, will change this based on Ohad's ack/nack.
>
> Looking forward to your next spin, as I will actually use this interface :)
Thanks for your comments. I will wait to see if there are any additional
comments before I refresh the series later this week.
regards
Suman
^ permalink raw reply
* [PATCH 0/2] Armada 375/38x MBus support
From: Ezequiel Garcia @ 2014-02-10 19:24 UTC (permalink / raw)
To: linux-arm-kernel
As part of the submission of the Armada 375/38x initial support, these
two small patches add MBus support.
You will find that despite the MBus support being identical for the whole
SoC family: Armada 370/XP/375 and 38x, we have per-SoC compatible for each
of them.
Such decision is being currently discussed; see:
http://www.spinics.net/lists/arm-kernel/msg306480.html
Gregory CLEMENT (1):
bus: mvebu-mbus: Add support for the Armada 375 SoCs
Thomas Petazzoni (1):
bus: mvebu: Add support for the Armada 38x SoCs
Documentation/devicetree/bindings/bus/mvebu-mbus.txt | 2 ++
drivers/bus/mvebu-mbus.c | 4 ++++
2 files changed, 6 insertions(+)
--
1.8.1.5
^ permalink raw reply
* [PATCH 1/2] bus: mvebu-mbus: Add support for the Armada 375 SoCs
From: Ezequiel Garcia @ 2014-02-10 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392060298-27094-1-git-send-email-ezequiel.garcia@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
The mvebu-mbus driver handles the special MBus mechanism of Marvell
EBU SoCs. The new members of the EBU family, the Armada 375, is
identical in terms of MBus handling, and share the same number of
windows and register organization as Armada 370/XP.
Therefore, this commit adds a new "marvell,armada375-mbus" compatible
string, which for now uses the same data structure as the one for
Armada 370 and Armada XP.
The SoC-specific compatible string is added in order to allow
the support of SoC-specific quirks in the future.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
Documentation/devicetree/bindings/bus/mvebu-mbus.txt | 1 +
drivers/bus/mvebu-mbus.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
index 7586fb6..ac21b16 100644
--- a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -7,6 +7,7 @@ Required properties:
marvell,armada370-mbus
marvell,armadaxp-mbus
marvell,armada370-mbus
+ marvell,armada375-mbus
marvell,armadaxp-mbus
marvell,kirkwood-mbus
marvell,dove-mbus
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 725c461..23af1b8 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -591,6 +591,8 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
static const struct of_device_id of_mvebu_mbus_ids[] = {
{ .compatible = "marvell,armada370-mbus",
.data = &armada_370_xp_mbus_data, },
+ { .compatible = "marvell,armada375-mbus",
+ .data = &armada_370_xp_mbus_data, },
{ .compatible = "marvell,armadaxp-mbus",
.data = &armada_370_xp_mbus_data, },
{ .compatible = "marvell,kirkwood-mbus",
--
1.8.1.5
^ permalink raw reply related
* [PATCH 2/2] bus: mvebu: Add support for the Armada 38x SoCs
From: Ezequiel Garcia @ 2014-02-10 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392060298-27094-1-git-send-email-ezequiel.garcia@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The mvebu-mbus driver handles the special MBus mechanism of Marvell
EBU SoCs. The two new members of the EBU family, the Armada 380 and
Armada 385, are identical in terms of MBus handling, and share the
same number of windows and register organization as Armada 370/XP.
Therefore, this commit adds a new "marvell,armada380-mbus" compatible
string, which for now uses the same data structure as the one for
Armada 370 and Armada XP.
The SoC-specific compatible string is added in order to allow
the support of SoC-specific quirks in the future.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
Documentation/devicetree/bindings/bus/mvebu-mbus.txt | 1 +
drivers/bus/mvebu-mbus.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
index ac21b16..d779921 100644
--- a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -8,6 +8,7 @@ Required properties:
marvell,armadaxp-mbus
marvell,armada370-mbus
marvell,armada375-mbus
+ marvell,armada380-mbus
marvell,armadaxp-mbus
marvell,kirkwood-mbus
marvell,dove-mbus
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 23af1b8..74607c4 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -593,6 +593,8 @@ static const struct of_device_id of_mvebu_mbus_ids[] = {
.data = &armada_370_xp_mbus_data, },
{ .compatible = "marvell,armada375-mbus",
.data = &armada_370_xp_mbus_data, },
+ { .compatible = "marvell,armada380-mbus",
+ .data = &armada_370_xp_mbus_data, },
{ .compatible = "marvell,armadaxp-mbus",
.data = &armada_370_xp_mbus_data, },
{ .compatible = "marvell,kirkwood-mbus",
--
1.8.1.5
^ permalink raw reply related
* [PATCHv4 0/7] omap hwspinlock dt support
From: Suman Anna @ 2014-02-10 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389658764-39199-1-git-send-email-s-anna@ti.com>
Mark,
On 01/13/2014 06:19 PM, Suman Anna wrote:
> Hi,
>
> This is an updated series mainly addressing Mark Rutland's comments
> about hwlock specifier being always one-cell. The series adds the
> support for #hwlock-cells property and adds a simple default OF
> translate function.
>
> The DTS patches from previous series have already been merged, and
> needs this property to be added. This is handled in a separate series
> that only deals with OMAP hwspinlock DTS patches.
>
> The series, along with the DTS patches, is tested on top of v3.13-rc8
> plus Tero's v13 clock DT series and Tony's 3.14 staged branches. The
> validation on OMAP5, DRA7, AM437 requires Tero's series with couple of
> additional base patches for AM43xx. AM43xx functionality needs a hwmod
> fix [1] for creating the associated omap_device as well.
>
Can you please take a look at this series and give your ack on the
bindings if you do not have any further comments? The only comments so
far are from Bjorn on the OF helpers.
regards
Suman
^ permalink raw reply
* [PATCH v4 0/8] Add Allwinner A20 GMAC ethernet support
From: Maxime Ripard @ 2014-02-10 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392028554-32545-1-git-send-email-wens@csie.org>
Hi Chen-Yu,
On Mon, Feb 10, 2014 at 06:35:46PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> This is the v4 of the remaining Allwinner A20 GMAC glue layer patches.
> The stmmac driver changes have been merged through net-next. The
> remaining bits are clock and DT patches. The patches should be applied
> over my clock renaming patches.
>
> The Allwinner A20 SoC integrates an early version of dwmac
> IP from Synopsys. On top of that is a hardware glue layer.
> This layer needs to be configured before the dwmac can be
> used.
>
> Part of the glue layer is a clock mux, which controls the
> source and direction of the TX clock used by GMAC.
Just merged patches 2-8.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/907e36b8/attachment.sig>
^ permalink raw reply
* [PATCH v4 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
From: Maxime Ripard @ 2014-02-10 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392028554-32545-2-git-send-email-wens@csie.org>
On Mon, Feb 10, 2014 at 06:35:47PM +0800, Chen-Yu Tsai wrote:
> The Allwinner A20/A31 clock module controls the transmit clock source
> and interface type of the GMAC ethernet controller. Model this as
> a single clock for GMAC drivers to use.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/de47ace9/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: OMAP2+: Fix boot with multi_v7_defconfig
From: Nishanth Menon @ 2014-02-10 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392055835-6494-1-git-send-email-rogerq@ti.com>
$subject probably needs clarity.
On 02/10/2014 12:10 PM, Roger Quadros wrote:
> The OMAP EHCI controller is not compatible with the EHCI
> platform HCD driver so don't claim that we are.
might want to refer to the change in drivers/usb/host/ehci-platform.c
that created this regression as well.
we also probably want to make better explanation about this issue and
why we think this is the correct fix for it - for example, question
Kevin asked in [1]
>
> This fixes boot on OMAP platforms with CONFIG_USB_EHCI_HCD_PLATFORM=y
> e.g. multi_v7_defconfig
>
> Reported-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
[1] http://marc.info/?t=139204803900004&r=1&w=2
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 2/3] mfd: axp20x: Add dtsi for axp20x
From: Maxime Ripard @ 2014-02-10 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391875428-6281-3-git-send-email-carlo@caione.org>
Hi Carlo,
On Sat, Feb 08, 2014 at 05:03:47PM +0100, Carlo Caione wrote:
> This patch adds a new dtsi for supporting axp20x.
>
> Signed-off-by: Carlo Caione <carlo@caione.org>
> ---
> arch/arm/boot/dts/axp20x.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
> create mode 100644 arch/arm/boot/dts/axp20x.dtsi
>
> diff --git a/arch/arm/boot/dts/axp20x.dtsi b/arch/arm/boot/dts/axp20x.dtsi
> new file mode 100644
> index 0000000..98d4c7c
> --- /dev/null
> +++ b/arch/arm/boot/dts/axp20x.dtsi
> @@ -0,0 +1,9 @@
> +/*
> +* Integrated Power Management Chip AXP209
> +*/
> +
> +&axp {
> + compatible = "x-powers,axp20x";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +};
Hmmm, this refers to an undefined node, I can't see this DTSI used
anywhere, and why do you need a DTSI of its own in the first place?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/b62a7ee4/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] irqchip: Armada 370/XP MPIC as a slave controller
From: Ezequiel Garcia @ 2014-02-10 20:00 UTC (permalink / raw)
To: linux-arm-kernel
The newly introduced Armada 375 and Armada 38x Marvell SoCs are based on
Cortex-A9 CPU cores and use the ARM GIC as their main interrupt controller.
However, for various purposes (wake-up from suspend, MSI interrupts),
the SoCs have a separate MPIC interrupt controller, acting as a slave
to the GIC. This MPIC was already used as the primary controller on
previous Marvell SoCs, so this commit extends the existing driver to
allow the MPIC to be used as a GIC slave.
This series consists in two patches: the first one adds a helper function
to handle MSI interrupts. The second patch implements a chained handler, which
uses the previously introduced helper.
These patches apply cleanly on v3.14-rc1 plus:
36802fd irqchip: armada-370-xp: fix MSI race condition
e1603bb irqchip: armada-370-xp: fix IPI race condition
Or simply on v3.14-rc2.
Ezequiel Garcia (2):
irqchip: armada-370-xp: Add helper for the MSI IRQ handling
irqchip: armada-370-xp: Setup a chained handler for the MPIC
.../devicetree/bindings/arm/armada-370-xp-mpic.txt | 8 +-
drivers/irqchip/irq-armada-370-xp.c | 96 ++++++++++++++++------
2 files changed, 76 insertions(+), 28 deletions(-)
--
1.8.1.5
^ permalink raw reply
* [PATCH 1/2] irqchip: armada-370-xp: Add helper for the MSI IRQ handling
From: Ezequiel Garcia @ 2014-02-10 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392062402-27357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Introduce a helper function to handle the MSI interrupts. This makes
the code more readable. In addition, this will allow to introduce a
chained IRQ handler mechanism, which is needed in situations where the
MPIC is used as a slave to another interrupt controller.
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
drivers/irqchip/irq-armada-370-xp.c | 54 ++++++++++++++++++++-----------------
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index 5409564..2ba5761 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -352,6 +352,34 @@ static struct irq_domain_ops armada_370_xp_mpic_irq_ops = {
.xlate = irq_domain_xlate_onecell,
};
+#ifdef CONFIG_PCI_MSI
+static void armada_370_xp_handle_msi_irq(struct pt_regs *regs)
+{
+ u32 msimask, msinr;
+
+ msimask = readl_relaxed(per_cpu_int_base +
+ ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
+ & PCI_MSI_DOORBELL_MASK;
+
+ writel(~msimask, per_cpu_int_base +
+ ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
+
+ for (msinr = PCI_MSI_DOORBELL_START;
+ msinr < PCI_MSI_DOORBELL_END; msinr++) {
+ int irq;
+
+ if (!(msimask & BIT(msinr)))
+ continue;
+
+ irq = irq_find_mapping(armada_370_xp_msi_domain,
+ msinr - 16);
+ handle_IRQ(irq, regs);
+ }
+}
+#else
+static void armada_370_xp_handle_msi_irq(struct pt_regs *r) {}
+#endif
+
static asmlinkage void __exception_irq_entry
armada_370_xp_handle_irq(struct pt_regs *regs)
{
@@ -372,31 +400,9 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
continue;
}
-#ifdef CONFIG_PCI_MSI
/* MSI handling */
- if (irqnr == 1) {
- u32 msimask, msinr;
-
- msimask = readl_relaxed(per_cpu_int_base +
- ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
- & PCI_MSI_DOORBELL_MASK;
-
- writel(~msimask, per_cpu_int_base +
- ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
-
- for (msinr = PCI_MSI_DOORBELL_START;
- msinr < PCI_MSI_DOORBELL_END; msinr++) {
- int irq;
-
- if (!(msimask & BIT(msinr)))
- continue;
-
- irq = irq_find_mapping(armada_370_xp_msi_domain,
- msinr - 16);
- handle_IRQ(irq, regs);
- }
- }
-#endif
+ if (irqnr == 1)
+ armada_370_xp_handle_msi_irq(regs);
#ifdef CONFIG_SMP
/* IPI Handling */
--
1.8.1.5
^ permalink raw reply related
* [PATCH 2/2] irqchip: armada-370-xp: Setup a chained handler for the MPIC
From: Ezequiel Garcia @ 2014-02-10 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392062402-27357-1-git-send-email-ezequiel.garcia@free-electrons.com>
The new Armada 375 and Armada 38x Marvell SoCs are based on Cortex-A9
CPU cores and use the ARM GIC as their main interrupt controller.
However, for various purposes (wake-up from suspend, MSI interrupts),
they have kept a separate MPIC interrupt controller, acting as a slave
to the GIC. This MPIC was already used as the primary controller on
previous Marvell SoCs, so this commit extends the existing driver to
allow the MPIC to be used as a GIC slave.
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
.../devicetree/bindings/arm/armada-370-xp-mpic.txt | 8 +++-
drivers/irqchip/irq-armada-370-xp.c | 50 +++++++++++++++++++---
2 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
index d74091a..5fc0313 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
@@ -1,4 +1,4 @@
-Marvell Armada 370 and Armada XP Interrupt Controller
+Marvell Armada 370, 375, 38x, XP Interrupt Controller
-----------------------------------------------------
Required properties:
@@ -16,7 +16,13 @@ Required properties:
automatically map to the interrupt controller registers of the
current CPU)
+Optional properties:
+- interrupts: If defined, then it indicates that this MPIC is
+ connected as a slave to another interrupt controller. This is
+ typically the case on Armada 375 and Armada 38x, where the MPIC is
+ connected as a slave to the Cortex-A9 GIC. The provided interrupt
+ indicate to which GIC interrupt the MPIC output is connected.
Example:
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index 2ba5761..cd79503 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -18,6 +18,7 @@
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/interrupt.h>
+#include <linux/irqchip/chained_irq.h>
#include <linux/io.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
@@ -42,6 +43,7 @@
#define ARMADA_370_XP_INT_SOURCE_CTL(irq) (0x100 + irq*4)
#define ARMADA_370_XP_CPU_INTACK_OFFS (0x44)
+#define ARMADA_375_PPI_CAUSE (0x10)
#define ARMADA_370_XP_SW_TRIG_INT_OFFS (0x4)
#define ARMADA_370_XP_IN_DRBEL_MSK_OFFS (0xc)
@@ -353,7 +355,7 @@ static struct irq_domain_ops armada_370_xp_mpic_irq_ops = {
};
#ifdef CONFIG_PCI_MSI
-static void armada_370_xp_handle_msi_irq(struct pt_regs *regs)
+static void armada_370_xp_handle_msi_irq(struct pt_regs *regs, bool is_chained)
{
u32 msimask, msinr;
@@ -373,13 +375,41 @@ static void armada_370_xp_handle_msi_irq(struct pt_regs *regs)
irq = irq_find_mapping(armada_370_xp_msi_domain,
msinr - 16);
- handle_IRQ(irq, regs);
+
+ if (is_chained)
+ generic_handle_irq(irq);
+ else
+ handle_IRQ(irq, regs);
}
}
#else
-static void armada_370_xp_handle_msi_irq(struct pt_regs *r) {}
+static void armada_370_xp_handle_msi_irq(struct pt_regs *r, bool b) {}
#endif
+static void armada_370_xp_mpic_handle_cascade_irq(unsigned int irq,
+ struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_get_chip(irq);
+ unsigned long irqmap, irqn;
+ unsigned int cascade_irq;
+
+ chained_irq_enter(chip, desc);
+
+ irqmap = readl_relaxed(per_cpu_int_base + ARMADA_375_PPI_CAUSE);
+
+ if (irqmap & BIT(0)) {
+ armada_370_xp_handle_msi_irq(NULL, true);
+ irqmap &= ~BIT(0);
+ }
+
+ for_each_set_bit(irqn, &irqmap, BITS_PER_LONG) {
+ cascade_irq = irq_find_mapping(armada_370_xp_mpic_domain, irqn);
+ generic_handle_irq(cascade_irq);
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
static asmlinkage void __exception_irq_entry
armada_370_xp_handle_irq(struct pt_regs *regs)
{
@@ -402,7 +432,7 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
/* MSI handling */
if (irqnr == 1)
- armada_370_xp_handle_msi_irq(regs);
+ armada_370_xp_handle_msi_irq(regs, false);
#ifdef CONFIG_SMP
/* IPI Handling */
@@ -433,6 +463,7 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
struct device_node *parent)
{
struct resource main_int_res, per_cpu_int_res;
+ int parent_irq;
u32 control;
BUG_ON(of_address_to_resource(node, 0, &main_int_res));
@@ -461,8 +492,6 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
BUG_ON(!armada_370_xp_mpic_domain);
- irq_set_default_host(armada_370_xp_mpic_domain);
-
#ifdef CONFIG_SMP
armada_xp_mpic_smp_cpu_init();
@@ -478,7 +507,14 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
armada_370_xp_msi_init(node, main_int_res.start);
- set_handle_irq(armada_370_xp_handle_irq);
+ parent_irq = irq_of_parse_and_map(node, 0);
+ if (parent_irq <= 0) {
+ irq_set_default_host(armada_370_xp_mpic_domain);
+ set_handle_irq(armada_370_xp_handle_irq);
+ } else {
+ irq_set_chained_handler(parent_irq,
+ armada_370_xp_mpic_handle_cascade_irq);
+ }
return 0;
}
--
1.8.1.5
^ permalink raw reply related
* [PATCH 1/3] mfd: axp20x: Add mfd driver for axp20x PMIC
From: Maxime Ripard @ 2014-02-10 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391875428-6281-2-git-send-email-carlo@caione.org>
On Sat, Feb 08, 2014 at 05:03:46PM +0100, Carlo Caione wrote:
> This patch introduces the preliminary support for PMICs X-Powers AXP202
> and AXP209. The core contains support only for two sub-modules (PEK
> and regulators) that will be added with two different patch-sets.
>
> Signed-off-by: Carlo Caione <carlo@caione.org>
> ---
> drivers/mfd/Kconfig | 12 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/axp20x.c | 251 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/axp20x.h | 178 ++++++++++++++++++++++++++++++++
> 4 files changed, 442 insertions(+)
> create mode 100644 drivers/mfd/axp20x.c
> create mode 100644 include/linux/mfd/axp20x.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index dd67158..33d38c4 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -59,6 +59,18 @@ config MFD_AAT2870_CORE
> additional drivers must be enabled in order to use the
> functionality of the device.
>
> +config MFD_AXP20X
> + bool "X-Powers AXP20X"
> + select MFD_CORE
> + select REGMAP_I2C
> + select REGMAP_IRQ
> + depends on I2C=y
> + help
> + If you say Y here you get support for the AXP20X.
> + This driver provides common support for accessing the device,
> + additional drivers must be enabled in order to use the
> + functionality of the device.
> +
> config MFD_CROS_EC
> tristate "ChromeOS Embedded Controller"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 8a28dc9..371020e 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -101,6 +101,7 @@ obj-$(CONFIG_PMIC_DA9052) += da9052-irq.o
> obj-$(CONFIG_PMIC_DA9052) += da9052-core.o
> obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
> obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
> +obj-$(CONFIG_MFD_AXP20X) += axp20x.o
>
> obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> new file mode 100644
> index 0000000..efd0cb3
> --- /dev/null
> +++ b/drivers/mfd/axp20x.c
> @@ -0,0 +1,251 @@
> +/*
> + * Author: Carlo Caione <carlo@caione.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/mfd/axp20x.h>
> +#include <linux/mfd/core.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> +
> +static const struct regmap_range axp20x_writeable_ranges[] = {
> + {
> + .range_min = AXP20X_DATA(0),
> + .range_max = AXP20X_IRQ5_STATE,
> + }, {
> + .range_min = AXP20X_DCDC_MODE,
> + .range_max = AXP20X_FG_RES,
> + },
> +};
> +
> +static const struct regmap_range axp20x_volatile_ranges[] = {
> + {
> + .range_min = AXP20X_IRQ1_EN,
> + .range_max = AXP20X_IRQ5_STATE,
> + },
> +};
> +
> +static const struct regmap_access_table axp20x_writeable_table = {
> + .yes_ranges = axp20x_writeable_ranges,
> + .n_yes_ranges = ARRAY_SIZE(axp20x_writeable_ranges),
> +};
> +
> +static const struct regmap_access_table axp20x_volatile_table = {
> + .yes_ranges = axp20x_volatile_ranges,
> + .n_yes_ranges = ARRAY_SIZE(axp20x_volatile_ranges),
> +};
> +
> +static struct resource axp20x_pek_resources[] = {
> + {
> + .name = "PEK_DBR",
> + .start = AXP20X_IRQ_PEK_RIS_EDGE,
> + .end = AXP20X_IRQ_PEK_RIS_EDGE,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .name = "PEK_DBF",
> + .start = AXP20X_IRQ_PEK_FAL_EDGE,
> + .end = AXP20X_IRQ_PEK_FAL_EDGE,
> + .flags = IORESOURCE_IRQ,
> + },
> +
> +};
>From your documentation, it seems like you want to declare them in the
DT too. Why do you need to declare the resources in both locations?
> +
> +static const struct regmap_config axp20x_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .wr_table = &axp20x_writeable_table,
> + .volatile_table = &axp20x_volatile_table,
> + .max_register = AXP20X_FG_RES,
> + .cache_type = REGCACHE_RBTREE,
> +};
> +
> +#define AXP20X_IRQ(_irq, _off, _mask) \
> + [AXP20X_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
> +
> +static const struct regmap_irq axp20x_regmap_irqs[] = {
> + AXP20X_IRQ(ACIN_OVER_V, 0, 7),
> + AXP20X_IRQ(ACIN_PLUGIN, 0, 6),
> + AXP20X_IRQ(ACIN_REMOVAL, 0, 5),
> + AXP20X_IRQ(VBUS_OVER_V, 0, 4),
> + AXP20X_IRQ(VBUS_PLUGIN, 0, 3),
> + AXP20X_IRQ(VBUS_REMOVAL, 0, 2),
> + AXP20X_IRQ(VBUS_V_LOW, 0, 1),
> + AXP20X_IRQ(BATT_PLUGIN, 1, 7),
> + AXP20X_IRQ(BATT_REMOVAL, 1, 6),
> + AXP20X_IRQ(BATT_ENT_ACT_MODE, 1, 5),
> + AXP20X_IRQ(BATT_EXIT_ACT_MODE, 1, 4),
> + AXP20X_IRQ(CHARG, 1, 3),
> + AXP20X_IRQ(CHARG_DONE, 1, 2),
> + AXP20X_IRQ(BATT_TEMP_HIGH, 1, 1),
> + AXP20X_IRQ(BATT_TEMP_LOW, 1, 0),
> + AXP20X_IRQ(DIE_TEMP_HIGH, 2, 7),
> + AXP20X_IRQ(CHARG_I_LOW, 2, 6),
> + AXP20X_IRQ(DCDC1_V_LONG, 2, 5),
> + AXP20X_IRQ(DCDC2_V_LONG, 2, 4),
> + AXP20X_IRQ(DCDC3_V_LONG, 2, 3),
> + AXP20X_IRQ(PEK_SHORT, 2, 1),
> + AXP20X_IRQ(PEK_LONG, 2, 0),
> + AXP20X_IRQ(N_OE_PWR_ON, 3, 7),
> + AXP20X_IRQ(N_OE_PWR_OFF, 3, 6),
> + AXP20X_IRQ(VBUS_VALID, 3, 5),
> + AXP20X_IRQ(VBUS_NOT_VALID, 3, 4),
> + AXP20X_IRQ(VBUS_SESS_VALID, 3, 3),
> + AXP20X_IRQ(VBUS_SESS_END, 3, 2),
> + AXP20X_IRQ(LOW_PWR_LVL1, 3, 1),
> + AXP20X_IRQ(LOW_PWR_LVL2, 3, 0),
> + AXP20X_IRQ(TIMER, 4, 7),
> + AXP20X_IRQ(PEK_RIS_EDGE, 4, 6),
> + AXP20X_IRQ(PEK_FAL_EDGE, 4, 5),
> + AXP20X_IRQ(GPIO3_INPUT, 4, 3),
> + AXP20X_IRQ(GPIO2_INPUT, 4, 2),
> + AXP20X_IRQ(GPIO1_INPUT, 4, 1),
> + AXP20X_IRQ(GPIO0_INPUT, 4, 0),
> +};
> +
> +static const struct regmap_irq_chip axp20x_regmap_irq_chip = {
> + .name = "axp20x_irq_chip",
> + .status_base = AXP20X_IRQ1_STATE,
> + .ack_base = AXP20X_IRQ1_STATE,
> + .mask_base = AXP20X_IRQ1_EN,
> + .num_regs = 5,
> + .irqs = axp20x_regmap_irqs,
> + .num_irqs = ARRAY_SIZE(axp20x_regmap_irqs),
> + .mask_invert = 1,
> + .init_ack_masked = 1,
> +};
> +
> +static struct mfd_cell axp20x_cells[] = {
> + {
> + .name = "axp20x-pek",
> + .of_compatible = "x-powers,axp20x-pek",
> + .num_resources = ARRAY_SIZE(axp20x_pek_resources),
> + .resources = axp20x_pek_resources,
> + }, {
> + .name = "axp20x-regulator",
> + },
> +};
> +
> +const struct of_device_id axp20x_of_match[] = {
> + { .compatible = "x-powers,axp20x", .data = (void *)AXP20X },
> + { },
> +};
> +
> +static struct axp20x_dev *axp20x_pm_power_off;
> +static void axp20x_power_off(void)
> +{
> + regmap_write(axp20x_pm_power_off->regmap, AXP20X_OFF_CTRL, 0x80);
> +}
> +
> +static int axp20x_i2c_probe(struct i2c_client *i2c,
> + const struct i2c_device_id *id)
> +{
> + struct axp20x_dev *axp20x;
> + const struct of_device_id *of_id;
> + int ret;
> +
> + axp20x = devm_kzalloc(&i2c->dev, sizeof(*axp20x), GFP_KERNEL);
> + if (!axp20x)
> + return -ENOMEM;
> +
> + of_id = of_match_device(axp20x_of_match, &i2c->dev);
> + if (!of_id) {
> + dev_err(&i2c->dev, "Unable to setup AXP20X data\n");
> + return -ENODEV;
> + }
> + axp20x->variant = (int) of_id->data;
> +
> + axp20x->i2c_client = i2c;
> + i2c_set_clientdata(i2c, axp20x);
> +
> + axp20x->dev = &i2c->dev;
> + dev_set_drvdata(axp20x->dev, axp20x);
> +
> + axp20x->regmap = devm_regmap_init_i2c(i2c, &axp20x_regmap_config);
> + if (IS_ERR(axp20x->regmap)) {
> + ret = PTR_ERR(axp20x->regmap);
> + dev_err(&i2c->dev, "regmap init failed: %d\n", ret);
> + return ret;
> + }
> +
> + axp20x->irq = i2c->irq;
> + ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
> + IRQF_ONESHOT | IRQF_SHARED, -1,
> + &axp20x_regmap_irq_chip,
> + &axp20x->regmap_irqc);
> + if (ret != 0) {
> + dev_err(&i2c->dev, "failed to add irq chip: %d\n", ret);
> + return ret;
> + }
> +
> + ret = mfd_add_devices(axp20x->dev, -1, axp20x_cells,
> + ARRAY_SIZE(axp20x_cells), NULL, 0, NULL);
> + if (ret != 0) {
> + dev_err(&i2c->dev, "failed to add MFD devices: %d\n", ret);
> + goto mfd_err;
> + }
> +
> + if (!pm_power_off) {
> + axp20x_pm_power_off = axp20x;
> + pm_power_off = axp20x_power_off;
> + }
> +
> + dev_info(&i2c->dev, "AXP20X driver loaded\n");
> +
> + return 0;
> +
> +mfd_err:
> + regmap_del_irq_chip(axp20x->irq, axp20x->regmap_irqc);
> +
> + return ret;
> +}
> +
> +static int axp20x_i2c_remove(struct i2c_client *i2c)
> +{
> + struct axp20x_dev *axp20x = i2c_get_clientdata(i2c);
> +
> + if (axp20x == axp20x_pm_power_off) {
> + axp20x_pm_power_off = NULL;
> + pm_power_off = NULL;
> + }
> +
> + mfd_remove_devices(axp20x->dev);
> + regmap_del_irq_chip(axp20x->i2c_client->irq, axp20x->regmap_irqc);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id axp20x_i2c_id[] = {
> + { "axp20x", AXP20X },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
> +
> +static struct i2c_driver axp20x_i2c_driver = {
> + .driver = {
> + .name = "axp20x",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(axp20x_of_match),
> + },
> + .probe = axp20x_i2c_probe,
> + .remove = axp20x_i2c_remove,
> + .id_table = axp20x_i2c_id,
> +};
> +
> +module_i2c_driver(axp20x_i2c_driver);
> +
> +MODULE_DESCRIPTION("PMIC MFD core driver for AXP20X");
> +MODULE_AUTHOR("Carlo Caione <carlo@caione.org>");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> new file mode 100644
> index 0000000..94d99fd
> --- /dev/null
> +++ b/include/linux/mfd/axp20x.h
> @@ -0,0 +1,178 @@
> +/*
> + * Functions to access AXP20X power management chip.
> + *
> + * Copyright (C) 2013, Carlo Caione <carlo@caione.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __LINUX_MFD_AXP20X_H
> +#define __LINUX_MFD_AXP20X_H
> +
> +#define AXP20X 0
> +
> +#define AXP20X_DATA(m) (0x04 + (m))
> +
> +/* Power supply */
> +#define AXP20X_PWR_INPUT_STATUS 0x00
> +#define AXP20X_PWR_OP_MODE 0x01
> +#define AXP20X_USB_OTG_STATUS 0x02
> +#define AXP20X_PWR_OUT_CTRL 0x12
> +#define AXP20X_DCDC2_V_OUT 0x23
> +#define AXP20X_DCDC2_LDO3_V_SCAL 0x25
> +#define AXP20X_DCDC3_V_OUT 0x27
> +#define AXP20X_LDO24_V_OUT 0x28
> +#define AXP20X_LDO3_V_OUT 0x29
> +#define AXP20X_VBUS_IPSOUT_MGMT 0x30
> +#define AXP20X_V_OFF 0x31
> +#define AXP20X_OFF_CTRL 0x32
> +#define AXP20X_CHRG_CTRL1 0x33
> +#define AXP20X_CHRG_CTRL2 0x34
> +#define AXP20X_CHRG_BAK_CTRL 0x35
> +#define AXP20X_PEK_KEY 0x36
> +#define AXP20X_DCDC_FREQ 0x37
> +#define AXP20X_V_LTF_CHRG 0x38
> +#define AXP20X_V_HTF_CHRG 0x39
> +#define AXP20X_APS_WARN_L1 0x3a
> +#define AXP20X_APS_WARN_L2 0x3b
> +#define AXP20X_V_LTF_DISCHRG 0x3c
> +#define AXP20X_V_HTF_DISCHRG 0x3d
> +
> +/* Interrupt */
> +#define AXP20X_IRQ1_EN 0x40
> +#define AXP20X_IRQ2_EN 0x41
> +#define AXP20X_IRQ3_EN 0x42
> +#define AXP20X_IRQ4_EN 0x43
> +#define AXP20X_IRQ5_EN 0x44
> +#define AXP20X_IRQ1_STATE 0x48
> +#define AXP20X_IRQ2_STATE 0x49
> +#define AXP20X_IRQ3_STATE 0x4a
> +#define AXP20X_IRQ4_STATE 0x4b
> +#define AXP20X_IRQ5_STATE 0x4c
> +
> +/* ADC */
> +#define AXP20X_ACIN_V_ADC_H 0x56
> +#define AXP20X_ACIN_V_ADC_L 0x57
> +#define AXP20X_ACIN_I_ADC_H 0x58
> +#define AXP20X_ACIN_I_ADC_L 0x59
> +#define AXP20X_VBUS_V_ADC_H 0x5a
> +#define AXP20X_VBUS_V_ADC_L 0x5b
> +#define AXP20X_VBUS_I_ADC_H 0x5c
> +#define AXP20X_VBUS_I_ADC_L 0x5d
> +#define AXP20X_TEMP_ADC_H 0x5e
> +#define AXP20X_TEMP_ADC_L 0x5f
> +#define AXP20X_TS_IN_H 0x62
> +#define AXP20X_TS_IN_L 0x63
> +#define AXP20X_GPIO0_V_ADC_H 0x64
> +#define AXP20X_GPIO0_V_ADC_L 0x65
> +#define AXP20X_GPIO1_V_ADC_H 0x66
> +#define AXP20X_GPIO1_V_ADC_L 0x67
> +#define AXP20X_PWR_BATT_H 0x70
> +#define AXP20X_PWR_BATT_M 0x71
> +#define AXP20X_PWR_BATT_L 0x72
> +#define AXP20X_BATT_V_H 0x78
> +#define AXP20X_BATT_V_L 0x79
> +#define AXP20X_BATT_CHRG_I_H 0x7a
> +#define AXP20X_BATT_CHRG_I_L 0x7b
> +#define AXP20X_BATT_DISCHRG_I_H 0x7c
> +#define AXP20X_BATT_DISCHRG_I_L 0x7d
> +#define AXP20X_IPSOUT_V_HIGH_H 0x7e
> +#define AXP20X_IPSOUT_V_HIGH_L 0x7f
> +
> +/* Power supply */
> +#define AXP20X_DCDC_MODE 0x80
> +#define AXP20X_ADC_EN1 0x82
> +#define AXP20X_ADC_EN2 0x83
> +#define AXP20X_ADC_RATE 0x84
> +#define AXP20X_GPIO10_IN_RANGE 0x85
> +#define AXP20X_GPIO1_ADC_IRQ_RIS 0x86
> +#define AXP20X_GPIO1_ADC_IRQ_FAL 0x87
> +#define AXP20X_TIMER_CTRL 0x8a
> +#define AXP20X_VBUS_MON 0x8b
> +#define AXP20X_OVER_TMP 0x8f
> +
> +/* GPIO */
> +#define AXP20X_GPIO0_CTRL 0x90
> +#define AXP20X_LDO5_V_OUT 0x91
> +#define AXP20X_GPIO1_CTRL 0x92
> +#define AXP20X_GPIO2_CTRL 0x93
> +#define AXP20X_GPIO20_SS 0x94
> +#define AXP20X_GPIO3_CTRL 0x95
> +
> +/* Battery */
> +#define AXP20X_CHRG_CC_31_24 0xb0
> +#define AXP20X_CHRG_CC_23_16 0xb1
> +#define AXP20X_CHRG_CC_15_8 0xb2
> +#define AXP20X_CHRG_CC_7_0 0xb3
> +#define AXP20X_DISCHRG_CC_31_24 0xb4
> +#define AXP20X_DISCHRG_CC_23_16 0xb5
> +#define AXP20X_DISCHRG_CC_15_8 0xb6
> +#define AXP20X_DISCHRG_CC_7_0 0xb7
> +#define AXP20X_CC_CTRL 0xb8
> +#define AXP20X_FG_RES 0xb9
> +
> +/* Regulators IDs */
> +enum {
> + AXP20X_LDO1 = 0,
> + AXP20X_LDO2,
> + AXP20X_LDO3,
> + AXP20X_LDO4,
> + AXP20X_LDO5,
> + AXP20X_DCDC2,
> + AXP20X_DCDC3,
> + AXP20X_REG_ID_MAX,
> +};
> +
> +/* IRQs */
> +enum {
> + AXP20X_IRQ_ACIN_OVER_V = 1,
> + AXP20X_IRQ_ACIN_PLUGIN,
> + AXP20X_IRQ_ACIN_REMOVAL,
> + AXP20X_IRQ_VBUS_OVER_V,
> + AXP20X_IRQ_VBUS_PLUGIN,
> + AXP20X_IRQ_VBUS_REMOVAL,
> + AXP20X_IRQ_VBUS_V_LOW,
> + AXP20X_IRQ_BATT_PLUGIN,
> + AXP20X_IRQ_BATT_REMOVAL,
> + AXP20X_IRQ_BATT_ENT_ACT_MODE,
> + AXP20X_IRQ_BATT_EXIT_ACT_MODE,
> + AXP20X_IRQ_CHARG,
> + AXP20X_IRQ_CHARG_DONE,
> + AXP20X_IRQ_BATT_TEMP_HIGH,
> + AXP20X_IRQ_BATT_TEMP_LOW,
> + AXP20X_IRQ_DIE_TEMP_HIGH,
> + AXP20X_IRQ_CHARG_I_LOW,
> + AXP20X_IRQ_DCDC1_V_LONG,
> + AXP20X_IRQ_DCDC2_V_LONG,
> + AXP20X_IRQ_DCDC3_V_LONG,
> + AXP20X_IRQ_PEK_SHORT = 22,
> + AXP20X_IRQ_PEK_LONG,
> + AXP20X_IRQ_N_OE_PWR_ON,
> + AXP20X_IRQ_N_OE_PWR_OFF,
> + AXP20X_IRQ_VBUS_VALID,
> + AXP20X_IRQ_VBUS_NOT_VALID,
> + AXP20X_IRQ_VBUS_SESS_VALID,
> + AXP20X_IRQ_VBUS_SESS_END,
> + AXP20X_IRQ_LOW_PWR_LVL1,
> + AXP20X_IRQ_LOW_PWR_LVL2,
> + AXP20X_IRQ_TIMER,
> + AXP20X_IRQ_PEK_RIS_EDGE,
> + AXP20X_IRQ_PEK_FAL_EDGE,
> + AXP20X_IRQ_GPIO3_INPUT,
> + AXP20X_IRQ_GPIO2_INPUT,
> + AXP20X_IRQ_GPIO1_INPUT,
> + AXP20X_IRQ_GPIO0_INPUT,
> +};
> +
> +struct axp20x_dev {
> + struct device *dev;
> + struct i2c_client *i2c_client;
> + struct regmap *regmap;
> + struct regmap_irq_chip_data *regmap_irqc;
> + int variant;
> + int irq;
> +};
> +
> +#endif /* __LINUX_MFD_AXP20X_H */
> --
> 1.8.5.3
>
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/29cdfb48/attachment-0001.sig>
^ permalink raw reply
* [PATCH 3/3] mfd: axp20x: Add bindings documentation
From: Lee Jones @ 2014-02-10 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391875428-6281-4-git-send-email-carlo@caione.org>
> Bindings documentation for the axp20x driver. In this file also two
> sub-nodes (PEK and regulators) are documented.
>
> Signed-off-by: Carlo Caione <carlo@caione.org>
> ---
> Documentation/devicetree/bindings/mfd/axp20x.txt | 87 ++++++++++++++++++++++++
You need to CC the Device Tree guys.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/3] mfd: axp20x: Add dtsi for axp20x
From: Lee Jones @ 2014-02-10 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391875428-6281-3-git-send-email-carlo@caione.org>
On Sat, 08 Feb 2014, Carlo Caione wrote:
> This patch adds a new dtsi for supporting axp20x.
>
> Signed-off-by: Carlo Caione <carlo@caione.org>
> ---
> arch/arm/boot/dts/axp20x.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
> create mode 100644 arch/arm/boot/dts/axp20x.dtsi
>
> diff --git a/arch/arm/boot/dts/axp20x.dtsi b/arch/arm/boot/dts/axp20x.dtsi
> new file mode 100644
> index 0000000..98d4c7c
> --- /dev/null
> +++ b/arch/arm/boot/dts/axp20x.dtsi
> @@ -0,0 +1,9 @@
> +/*
> +* Integrated Power Management Chip AXP209
> +*/
> +
> +&axp {
> + compatible = "x-powers,axp20x";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +};
I's suggest not doing it this way. Having a .dtsi file for every
device is not the way Device Tree has been designed. This snippet
should be copied directly into device's .dts(i) files.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 2/3] mfd: axp20x: Add dtsi for axp20x
From: Carlo Caione @ 2014-02-10 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210195942.GA3192@lukather>
On Mon, Feb 10, 2014 at 8:59 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Carlo,
>
> On Sat, Feb 08, 2014 at 05:03:47PM +0100, Carlo Caione wrote:
>> This patch adds a new dtsi for supporting axp20x.
>>
>> Signed-off-by: Carlo Caione <carlo@caione.org>
>> ---
>> arch/arm/boot/dts/axp20x.dtsi | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>> create mode 100644 arch/arm/boot/dts/axp20x.dtsi
>>
>> diff --git a/arch/arm/boot/dts/axp20x.dtsi b/arch/arm/boot/dts/axp20x.dtsi
>> new file mode 100644
>> index 0000000..98d4c7c
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/axp20x.dtsi
>> @@ -0,0 +1,9 @@
>> +/*
>> +* Integrated Power Management Chip AXP209
>> +*/
>> +
>> +&axp {
>> + compatible = "x-powers,axp20x";
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> +};
>
> Hmmm, this refers to an undefined node, I can't see this DTSI used
> anywhere, and why do you need a DTSI of its own in the first place?
Since axp is an independent MFD this could be integrated in the DTS of
the SoC using it (multiple SoC could be using the same axp), that's
why I left it in a DTSI.
i.e. it will be integrated in sun7i-a20-cubieboard2.dts once the
problem with the NMI controller has been solved (and we have a NMI
controller to link the axp to).
Thanks,
--
Carlo Caione
^ permalink raw reply
* [PATCH 2/3] mfd: axp20x: Add dtsi for axp20x
From: Carlo Caione @ 2014-02-10 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210200850.GB32042@lee--X1>
On Mon, Feb 10, 2014 at 9:08 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Sat, 08 Feb 2014, Carlo Caione wrote:
>
>> This patch adds a new dtsi for supporting axp20x.
>>
>> Signed-off-by: Carlo Caione <carlo@caione.org>
>> ---
>> arch/arm/boot/dts/axp20x.dtsi | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>> create mode 100644 arch/arm/boot/dts/axp20x.dtsi
>>
>> diff --git a/arch/arm/boot/dts/axp20x.dtsi b/arch/arm/boot/dts/axp20x.dtsi
>> new file mode 100644
>> index 0000000..98d4c7c
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/axp20x.dtsi
>> @@ -0,0 +1,9 @@
>> +/*
>> +* Integrated Power Management Chip AXP209
>> +*/
>> +
>> +&axp {
>> + compatible = "x-powers,axp20x";
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> +};
>
> I's suggest not doing it this way. Having a .dtsi file for every
> device is not the way Device Tree has been designed. This snippet
> should be copied directly into device's .dts(i) files.
Well, ok then :) I'll fix it in v2.
Thanks,
--
Carlo Caione
^ permalink raw reply
* [PATCH 3/3] mfd: axp20x: Add bindings documentation
From: Maxime Ripard @ 2014-02-10 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391875428-6281-4-git-send-email-carlo@caione.org>
Hi Carlo,
On Sat, Feb 08, 2014 at 05:03:48PM +0100, Carlo Caione wrote:
> Bindings documentation for the axp20x driver. In this file also two
> sub-nodes (PEK and regulators) are documented.
>
> Signed-off-by: Carlo Caione <carlo@caione.org>
> ---
> Documentation/devicetree/bindings/mfd/axp20x.txt | 87 ++++++++++++++++++++++++
> 1 file changed, 87 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> new file mode 100644
> index 0000000..ccea6b8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -0,0 +1,87 @@
> +* axp20x device tree bindings
> +
> +The axp20x family current members :-
> +axp202 (x-powers)
> +axp209 (x-powers)
> +
> +Required properties:
> +- compatible : Should be "x-powers,axp20x" (for axp202 and axp209)
"Generic" compatibles are usually a bad thing, for several reasons,
mostly because there's no way to actually differentiate the two
without keeping adding DT properties (and hence, being unable to
actually fix something or add a quirk for one single of these devices
without having to modify the DT too.)
Please use the "real" compatibles.
> +- interrupt-controller : axp20x has its own internal IRQs
> +- #interrupt-cells : should be set to 1
> +- interrupt-parent : The parent interrupt controller
Is this really required? It was not in your DTSI.
> +- interrupts : Specifies the list of interrupt lines which are handled by
> + the device in the parent controller's notation
Hmmm, I'm not sure what you mean here.
> +- reg : Specifies base physical address and size of the registers
Base physical address? Isn't it a I2C device?
> +
> +Sub-nodes
> +* regulators : Contain the regulator nodes. The regulators are bound using
> + their name as listed here: dcdc2, dcdc3, ldo1, ldo2, ldo3,
> + ldo4, ldo5.
> + The bindings details of individual regulator device can be found in:
> + Documentation/devicetree/bindings/regulator/regulator.txt with the
> + exception of:
I'm guessing this is where you differentiate between AXP202 and
AXP209?
> +
> + - dcdc-freq : defines the work frequency of DC-DC where
> + F=(1+dcdc-freq*5%)*1.5MHz
I'd very much prefer this DCDC frequency to be in Hz, or a similar
unit, and let the driver do the conversion.
> +
> +* axp20x-pek : Power Enable Key
> + - compatible : should be "x-powers,axp20x-pek"
> + - interrupts : two interrupt numbers with order defined by interrupt-names
> + (one irq number for rising transition of the power key, the
> + other one for falling transition)
> + - interrupt-names : should be "PEK_DBR" and "PEK_DBF"
Is this actually needed since you declare the resources in your driver?
> +
> +Example:
> +
> +axp {
> + compatible = "x-powers,axp20x";
> + interrupt-controller;
> + #interrupt-cells = <1>;
No reg property ?
> +
> + axp20x-pek {
> + compatible = "x-powers,axp20x-pek";
> + interrupts = <33>, <34>;
> + interrupt-names = "PEK_DBR", "PEK_DBF";
> + };
> +
> + regulators {
> + dcdc-freq = "8";
> +
> + axp_dcdc2: dcdc2 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <2275000>;
> + dcdc-workmode = <0>;
And what is this dcdc-workmode property about?
> + };
> +
> + axp_dcdc3: dcdc3 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3500000>;
> + dcdc-workmode = <0>;
> + };
> +
> + axp_ldo1: ldo1 {
> + regulator-min-microvolt = <1300000>;
> + regulator-max-microvolt = <1300000>;
> + };
> +
> + axp_ldo2: ldo2 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + axp_ldo3: ldo3 {
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <3500000>;
> + };
> +
> + axp_ldo4: ldo4 {
> + regulator-min-microvolt = <1250000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + axp_ldo5: ldo5 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + };
> + };
> +};
> --
> 1.8.5.3
>
Thanks for working on this!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/03fc1689/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox