* [PATCH] ARM: mxs: gpio-mxs: Add IRQ_TYPE_EDGE_BOTH support
From: Linus Walleij @ 2013-01-28 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359306248-28690-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
On Sun, Jan 27, 2013 at 6:04 PM, Gwenhael Goavec-Merou
<gwenhael.goavec-merou@armadeus.com> wrote:
> This patch adds support for IRQ_TYPE_EDGE_BOTH needed for some driver
> (gpio-keys).
> Inspired from gpio-mxc.c
>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
Looks correct to me, Shawn do you ACK this?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 2/3] gpio: pca953x: add support for pca9505
From: Linus Walleij @ 2013-01-28 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51045261.5020709@free-electrons.com>
On Sat, Jan 26, 2013 at 11:02 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> I was about to fix the issues you have pointed but I didn't find anything like
>
> #ifdef CONFIG_ARCH_PXA
> if (cpu_is_pxa25x()) {
> #ifdef CONFIG_CPU_PXA26x
> count = 89;
> gpio_type = PXA26X_GPIO;
> #elif defined(CONFIG_PXA25x)
>
> in the pca953x driver! I think you messed up with another patch set!
Yes I did.
Forget about this, thanks for the other nice patches!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 01/10] gpio: pxa: set initcall level to module init
From: Linus Walleij @ 2013-01-28 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6h2NSZoTaG1vN4gCRV5WdR07ZKepYP5z3JujuRs8Pn2pwdVQ@mail.gmail.com>
On Mon, Jan 28, 2013 at 5:26 AM, Haojian Zhuang
<haojian.zhuang@linaro.org> wrote:
> On 26 January 2013 05:01, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> Haojian Zhuang <haojian.zhuang@linaro.org> writes:
>>
>>> gpio & pinctrl driver are used together. The pinctrl driver is already
>>> launched before gpio driver in Makefile. So set gpio driver to module
>>> init level. Otherwise, the sequence will be inverted.
>> Hi Haojian,
>>
>> If you switch gpio to module level, and as some modules use gpios in their init
>> path, isn't it possible that some modules will fail their init, as GPIO API
>> won't provide the gpio_*_value() functions ?
>
> gpio_request() should return EPROBE_DEFER, then the driver is using gpio API
> fails and it should be retried after a while. At that time, gpio
> driver should be launched
> properly.
Correct. However it is not uncommon for modules to have untested
errorpaths, such as:
ret = gpio_request(12);
if (ret)
return -ENODEV;
So you will not know before you test.
Then it is often common to have memory leaks in the errorpath...
So Tested-by: tags are appreciated.
Yours,
Linus Walleij
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: Mohammed, Afzal @ 2013-01-28 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126084604.GB8754@arwen.pp.htv.fi>
Hi,
On Sat, Jan 26, 2013 at 14:16:04, Balbi, Felipe wrote:
> On Sat, Jan 26, 2013 at 08:40:07AM +0000, Paul Walmsley wrote:
> > * am335xbone: hangs after "Starting kernel"
> > - Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
> > - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html
> > - http://marc.info/?l=linux-omap&m=135903184512238&w=2
>
> FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and
> without it, also removed CONFIG_DEBUG_LL completely and nothing seemed
> to help my bone, no matter if I had appended DTB or not.
Following patch with low level debug may help to find where the issue is,
(my observation is that it boots with mainline u-boot)
Regards
Afzal
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41b581f..178a411 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -117,6 +117,10 @@ config SOC_AM33XX
select CPU_V7
select MULTI_IRQ_HANDLER
select COMMON_CLK
+ select MACH_AM335XEVM
+
+config MACH_AM335XEVM
+ bool
config OMAP_PACKAGE_ZAF
bool
^ permalink raw reply related
* [Suggestion] ARM:kernel: memcpy, checking the length before copy.
From: Chen Gang @ 2013-01-28 10:36 UTC (permalink / raw)
To: linux-arm-kernel
Hello Russell King:
in arch/arm/kernel/fiq.c:
since the function set_fiq_handler is an EXPORT_SYMBOL function.
do we need checking memory length, before copy ?
(have to understand the madly using by outside users)
if really it is, maybe also need provide the return value for failure.
Regards
gchen.
80 void set_fiq_handler(void *start, unsigned int length)
81 {
82 #if defined(CONFIG_CPU_USE_DOMAINS)
83 memcpy((void *)0xffff001c, start, length);
84 #else
85 memcpy(vectors_page + 0x1c, start, length);
86 #endif
87 flush_icache_range(0xffff001c, 0xffff001c + length);
88 if (!vectors_high())
89 flush_icache_range(0x1c, 0x1c + length);
90 }
91
...
137 EXPORT_SYMBOL(set_fiq_handler);
^ permalink raw reply
* [RFC V2 PATCH 0/8] ARM: kirkwood: cleanup DT conversion
From: Ezequiel Garcia @ 2013-01-28 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125183407.GC7393@obsidianresearch.com>
Hi Jason,
On Fri, Jan 25, 2013 at 11:34:07AM -0700, Jason Gunthorpe wrote:
> On Fri, Jan 25, 2013 at 04:03:29PM +0100, Sebastian Hesselbarth wrote:
> > On Fri, Jan 25, 2013 at 1:52 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > > Once I have the mv643xx_eth binding working reliably, preferably with
> > > mvmdio, I'll take a look at removing the last board-*.c files. If the
> > > stars align, we'll get it all done for v3.9.
> > >
> > > The only big thing left will be pcie.
>
> > there is also addr_map that we haven't thought about yet. Is it supposed
> > to be configurable through DT or do we leave it as "linux wants it that way"?
>
> FWIW, this was a pain + surprise for us when we started out. The
> address map Linux wants is not the same as the device power on
> default, and the Linux mapping is hardwired into the kernel :(
>
> I would be happy to see the address map setup be more flexible and
> done via DT. It would be a bit of a pain to change, but via DT each
> decoded window could be described as a bus with a ranges and an OF
> address map driver could directly setup the windows to match those DT
> nodes. Something like this, repeated for each window:
>
> // MBUS Decoder window for NAND
> nand at f4000000 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "simple-bus", "marvell,orion-mbus";
> mbus-target = 0xXXXXX;
> ranges = <0 0xf4000000 0x10000>;
>
> nand at 0 {
> cle = <0>;
> ale = <1>;
> bank-width = <1>;
> chip-delay = <50>;
> compatible = "marvell,orion-nand";
> reg = <0x0 0x400>;
> };
> };
>
This is a nice idea.
I have a few questions, though.
1. Are you sure we should use "ranges" property?
In this case it's not an address translation but rather
and address window configuration.
If I got this right, in this case child device address
space is the same as its parent. So, it's not an actual translation.
I would think we could add a new "windows" property to reflect
address window configuration.
2. Also, If we use "ranges" property. How would that work?
By reading the property in the addr-map driver or
by somehow improving on of_bus to include this new kind of busses?
Thanks,
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCHv1 for soc 4/5] arm: Add v7_invalidate_l1 to cache-v7.S
From: Pavel Machek @ 2013-01-28 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51020D20.60505@wwwdotorg.org>
On Thu 2013-01-24 20:42:08, Stephen Warren wrote:
> On 01/24/2013 05:00 PM, dinguyen at altera.com wrote:
> > From: Dinh Nguyen <dinguyen@altera.com>
> >
> > mach-socfpga is another platform that needs to use
> > v7_invalidate_l1 to bringup additional cores. There was a comment that
> > the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
>
> > diff --git a/arch/arm/mach-tegra/headsmp.S b/arch/arm/mach-tegra/headsmp.S
>
> > -ENTRY(v7_invalidate_l1)
> > - mov r0, #0
>
> Unfortunately, there's a patch in the Tegra tree for 3.9 that moves that
> function from headsmp.S to reset-handler.S, so this patch will conflict.
> How do you want to handle that?
Drop the patch from Tegra tree and merge this one there? Having three
copies of code is not nice to start with, no matter where it is...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: Felipe Balbi @ 2013-01-28 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA9456A@DBDE01.ent.ti.com>
Hi,
On Mon, Jan 28, 2013 at 11:34:15AM +0100, Mohammed, Afzal wrote:
> Hi,
>
> On Sat, Jan 26, 2013 at 14:16:04, Balbi, Felipe wrote:
> > On Sat, Jan 26, 2013 at 08:40:07AM +0000, Paul Walmsley wrote:
>
> > > * am335xbone: hangs after "Starting kernel"
> > > - Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
> > > - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html
> > > - http://marc.info/?l=linux-omap&m=135903184512238&w=2
> >
> > FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and
> > without it, also removed CONFIG_DEBUG_LL completely and nothing seemed
> > to help my bone, no matter if I had appended DTB or not.
>
> Following patch with low level debug may help to find where the issue is,
> (my observation is that it boots with mainline u-boot)
will try your patch, but are you using Beagle Bone white or black ? I
should've made it clear I'm using beagle bone black.
--
balbi
-------------- 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/20130128/1cb14c78/attachment.sig>
^ permalink raw reply
* [PATCH 09/26] mfd: ab8500-debugfs: Provide a means for a user subscribe to IRQs
From: Samuel Ortiz @ 2013-01-28 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128102223.GA18212@gmail.com>
Hi Lee,
On Mon, Jan 28, 2013 at 10:22:23AM +0000, Lee Jones wrote:
> On Mon, 28 Jan 2013, Samuel Ortiz wrote:
>
> > Hi Lee,
> >
> > On Tue, Jan 15, 2013 at 12:55:49PM +0000, Lee Jones wrote:
> > > Allow users to subscribe to and view IRQ events live from debugfs.
> > I seem to remember that I got a similar patch some time ago for the same
> > purpose and my answer was: Please use a UIO driver for this. There already is
> > such driver, it's uio_pdrv_genirq. What your debugfs registration entry could
> > do is adding a platform device for the specific interrupt number. This would
> > avoid the irq handler registration and the sysfs entry creation, both things I
> > believe are not very elegant and open coded. It also gives you an IRQ count
> > implementation.
> > Ideally, the UIO framework could be improved to support IRQ ranges (through
> > IRQ domains) instead of the current single interrupt number.
> >
> > Have you considered going through that path ?
>
> I'm going to have to put this patch-set in the bin. Pulling this
> patch, causes lots of conflicts to the remaining patches in the
> set.
I bet removing this one causes a lot of conflicts. I'm not saying it should
absolutely be removed, but I'm afraid once it's upstream no one is going to
look at improving it. And to be honest, having an IRQ handler from debugfs
code looks weird to me. I know you can put all sort of crazyness into a
debugfs entry, but still.
> I'll start again from scratch and find another way to sync the ab* MFD
> drivers. I might even have to do it manually i.e. throw out all
> commit history and upstream it as my own patches pulled in from diffs.
I don't have any problems with that.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: Mohammed, Afzal @ 2013-01-28 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128104752.GB28698@arwen.pp.htv.fi>
Hi Felipe,
On Mon, Jan 28, 2013 at 16:17:52, Balbi, Felipe wrote:
> will try your patch, but are you using Beagle Bone white or black ? I
> should've made it clear I'm using beagle bone black.
Hmm.., I am using white, have never tried on black.
Regards
Afzal
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: Felipe Balbi @ 2013-01-28 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA945AB@DBDE01.ent.ti.com>
Hi,
On Mon, Jan 28, 2013 at 11:55:20AM +0100, Mohammed, Afzal wrote:
> Hi Felipe,
>
> On Mon, Jan 28, 2013 at 16:17:52, Balbi, Felipe wrote:
>
> > will try your patch, but are you using Beagle Bone white or black ? I
> > should've made it clear I'm using beagle bone black.
>
> Hmm.., I am using white, have never tried on black.
ok, maybe there's something missing to get Black booting up :-s
--
balbi
-------------- 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/20130128/2d396ebc/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 1/3] pwm: Add pwm_cansleep() as exported API to users
From: Florian Vaussard @ 2013-01-28 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128095754.GA23134@avionic-0098.adnet.avionic-design.de>
Le 28/01/2013 10:57, Thierry Reding a ?crit :
> On Mon, Jan 28, 2013 at 10:36:07AM +0100, Florian Vaussard wrote:
>> Hello,
>>
>> Le 28/01/2013 09:45, Peter Ujfalusi a ?crit :
>>> hi Thierry,
>>>
>>> On 01/26/2013 06:40 AM, Thierry Reding wrote:
> [...]
>>>>> +{
>>>>> + return pwm->chip->can_sleep;
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(pwm_cansleep);
>>>>
>>>> Would it make sense to check for NULL pointers here? I guess that
>>>> passing NULL into the function could be considered a programming error
>>>> and an oops would be okay, but in that case there's no point in making
>>>> the function return an int. Also see my next comment.
>>>
>>> While it is unlikely to happen it is better to be safe, something like this
>>> will do:
>>>
>>> return pwm ? pwm->chip->can_sleep : 0;
>>>
>>
>> Ok. And what about:
>>
>> BUG_ON(pwm == NULL);
>> return pwm->chip->can_sleep;
>
> I don't think we need that. In case pwm == NULL, dereferencing it will
> oops anyway. So either we make it safe and return an error code, or we
> let it oops without explicit BUG_ON().
>
Calling this function with a NULL pointer is a programming error, so there
is no error codes for such errors. I propose to return bool, and let it
oops if such case happens.
Regards,
Florian
^ permalink raw reply
* [PATCH 12/15] ARM: mach-shmobile: sh73a0: Allow initialisation of GIC by DT
From: Mark Rutland @ 2013-01-28 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128004819.GE3423@verge.net.au>
On Mon, Jan 28, 2013 at 12:48:19AM +0000, Simon Horman wrote:
> On Fri, Jan 25, 2013 at 10:22:10AM +0000, Mark Rutland wrote:
> > On Fri, Jan 25, 2013 at 03:55:30AM +0000, Simon Horman wrote:
> > > This allows the GIC interrupt controller of the sh73a0 SoC to be
> > > initialised using a flattened device tree blob.
> > >
> > > It does not allow the INTC interrupt controller which is also present on
> > > the sh73a0 SoC to be enabled via device tree. Nor does it handle sharing
> > > of interrupts between the GIC and INTC interrupt controllers.
> > >
> > > This limits the usefulness of this code to applications which only wish to
> > > access devices which use interrupts that can be handled by the GIC
> > > interrupt controller. Other applications should, for now, continue using
> > > non-device tree initialisation of the sh72a0 interrupt controllers.
> > >
> > > Includes update to use irqchip_init() by Thierry Reding
> > >
> > > Cc: Thierry Reding <thierry.reding@avionic-design.de>
> > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > > ---
> > > arch/arm/boot/dts/sh73a0.dtsi | 33 ++++++++++++++++++++++++++
> > > arch/arm/mach-shmobile/include/mach/common.h | 1 +
> > > arch/arm/mach-shmobile/intc-sh73a0.c | 9 +++++++
> > > 3 files changed, 43 insertions(+)
> > > create mode 100644 arch/arm/boot/dts/sh73a0.dtsi
> > >
> > > diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
> > > new file mode 100644
> > > index 0000000..7dae1f4
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/sh73a0.dtsi
> > > @@ -0,0 +1,33 @@
> > > +/*
> > > + * Device Tree Source for the SH73A0 SoC
> > > + *
> > > + * Copyright (C) 2012 Renesas Solutions Corp.
> > > + *
> > > + * This file is licensed under the terms of the GNU General Public License
> > > + * version 2. This program is licensed "as is" without any warranty of any
> > > + * kind, whether express or implied.
> > > + */
> > > +
> > > +/include/ "skeleton.dtsi"
> > > +
> > > +/ {
> > > + compatible = "renesas,sh73a0";
> > > +
> > > + cpus {
> > > + cpu at 0 {
> > > + compatible = "arm,cortex-a9";
> > > + };
> > > + cpu at 1 {
> > > + compatible = "arm,cortex-a9";
> > > + };
> >
> > I replied to v1, not realising you'd posted a v2:
> >
> > It would be good to have the reg and device_type properties set here for the
> > logical map.
>
> Thanks.
>
> I'd prefer to handle this as an incremental patch to be applied after the
> pull-request in which the patch above appears. The patch below is what
> I have in mind.
Sure. The patch looks right to me :)
>
> I also believe that the following files seem to be targets for a similar
> change. The latter two are for UP boards, could you comment on if reg
> and device_type are appropriate for them too.
>
> arch/arm/boot/dts/emev2.dtsi
Yup, this one should have reg and device_type added.
> arch/arm/boot/dts/r8a7740.dtsi
> arch/arm/boot/dts/sh7372.dtsi
I'm not sure what the deal is with v7 UP hardware. For v6 and below, the lack
of an MPIDR means there's nothing to describe. On v7 we should have an MPIDR
with Aff fields at least, so there is something to describe (even if we don't
use this currently). I don't believe this would cause any problems, and it
would make the dts look consistent.
I've Cc'd Lorenzo in case he has any thoughts on the matter.
>
>
> From: Simon Horman <horms+renesas@verge.net.au>
>
> ARM: mach-shmobile: sh73a0: Add reg and device_type properties to cpus
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
> index 721f486..f202298 100644
> --- a/arch/arm/boot/dts/sh73a0.dtsi
> +++ b/arch/arm/boot/dts/sh73a0.dtsi
> @@ -15,10 +15,14 @@
>
> cpus {
> cpu at 0 {
> + device_type = "cpu";
> compatible = "arm,cortex-a9";
> + reg = <0>;
> };
> cpu at 1 {
> + device_type = "cpu";
> compatible = "arm,cortex-a9";
> + reg = <1>;
> };
> };
>
>
Thanks,
Mark.
^ permalink raw reply
* [PATCH 03/10] gpio: pxa: avoid to use global irq base
From: Igor Grinberg @ 2013-01-28 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358929554-32265-4-git-send-email-haojian.zhuang@linaro.org>
On 01/23/13 10:25, Haojian Zhuang wrote:
> Avoid to use global irq_base in gpio-pxa driver. Define irq_base in each
> pxa_gpio_chip instead. Then we can avoid to use macro PXA_GPIO_TO_IRQ() &
> MMP_GPIO_TO_IRQ().
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
> ---
> arch/arm/mach-pxa/pxa25x.c | 2 +-
> arch/arm/mach-pxa/pxa27x.c | 2 +-
> drivers/gpio/gpio-pxa.c | 142 ++++++++++++++++++++++----------------------
> include/linux/gpio-pxa.h | 4 +-
> 4 files changed, 77 insertions(+), 73 deletions(-)
[...]
> diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
> index 8e66c6b..da6e7fd 100644
> --- a/drivers/gpio/gpio-pxa.c
> +++ b/drivers/gpio/gpio-pxa.c
[...]
> @@ -485,7 +452,7 @@ static int pxa_irq_domain_map(struct irq_domain *d, unsigned int irq,
> return 0;
> }
>
> -const struct irq_domain_ops pxa_irq_domain_ops = {
> +static const struct irq_domain_ops pxa_irq_domain_ops = {
> .map = pxa_irq_domain_map,
> .xlate = irq_domain_xlate_twocell,
> };
You should also move this out of CONFIG_OF as I don't think it is a dependency,
and also otherwise you get the below...
> @@ -529,14 +496,6 @@ static int pxa_gpio_probe_dt(struct platform_device *pdev)
> nr_gpios = nr_banks << 5;
> pxa_last_gpio = nr_gpios - 1;
>
> - irq_base = irq_alloc_descs(-1, 0, nr_gpios, 0);
> - if (irq_base < 0) {
> - dev_err(&pdev->dev, "Failed to allocate IRQ numbers\n");
> - goto err;
> - }
> - domain = irq_domain_add_legacy(np, nr_gpios, irq_base, 0,
> - &pxa_irq_domain_ops, NULL);
> - pxa_gpio_of_node = np;
> return 0;
> err:
> iounmap(gpio_reg_base);
> @@ -546,6 +505,56 @@ err:
> #define pxa_gpio_probe_dt(pdev) (-1)
> #endif
>
> +static int pxa_init_gpio_chip(struct platform_device *pdev, int gpio_end,
> + int (*set_wake)(unsigned int, unsigned int))
> +{
> + int i, gpio, nbanks = gpio_to_bank(gpio_end) + 1;
> + struct pxa_gpio_chip *chips;
> +
> + chips = devm_kzalloc(&pdev->dev, nbanks * sizeof(*chips), GFP_KERNEL);
> + if (chips == NULL) {
> + pr_err("%s: failed to allocate GPIO chips\n", __func__);
> + return -ENOMEM;
> + }
> +
> + for (i = 0, gpio = 0; i < nbanks; i++, gpio += 32) {
> + struct gpio_chip *c = &chips[i].chip;
> +
> + sprintf(chips[i].label, "gpio-%d", i);
> + chips[i].regbase = gpio_reg_base + BANK_OFF(i);
> + chips[i].set_wake = set_wake;
> +
> + c->base = gpio;
> + c->label = chips[i].label;
> +
> + c->direction_input = pxa_gpio_direction_input;
> + c->direction_output = pxa_gpio_direction_output;
> + c->get = pxa_gpio_get;
> + c->set = pxa_gpio_set;
> + c->to_irq = pxa_gpio_to_irq;
> +#ifdef CONFIG_OF_GPIO
> + c->of_node = pxa_gpio_of_node;
> + c->of_xlate = pxa_gpio_of_xlate;
> + c->of_gpio_n_cells = 2;
> +#endif
> +
> + /* number of GPIOs on last bank may be less than 32 */
> + c->ngpio = (gpio + 31 > gpio_end) ? (gpio_end - gpio + 1) : 32;
> +
> + chips[i].irq_base = irq_alloc_descs(-1, 0, c->ngpio, 0);
> + if (chips[i].irq_base < 0)
> + return -EINVAL;
> + if (!irq_domain_add_legacy(pdev->dev.of_node, c->ngpio,
> + chips[i].irq_base, 0,
> + &pxa_irq_domain_ops, &chips[i]))
if !CONFIG_OF, you get:
drivers/gpio/gpio-pxa.c:479: error: 'pxa_irq_domain_ops' undeclared (first use in this function)
Also, for !CONFIG_IRQ_DOMAIN, you get:
drivers/gpio/gpio-pxa.c: In function 'pxa_init_gpio_chip':
drivers/gpio/gpio-pxa.c:477: error: implicit declaration of function 'irq_domain_add_legacy'
Should we select IRQ_DOMAIN for PXA?
Will it work for other drivers?
> + return -ENODEV;
> +
> + gpiochip_add(c);
> + }
> + pxa_gpio_chips = chips;
> + return 0;
> +}
> +
> static int pxa_gpio_probe(struct platform_device *pdev)
> {
> struct pxa_gpio_chip *c;
[...]
--
Regards,
Igor.
^ permalink raw reply
* [PATCH v2] ARM: versatile: fix the PCI IRQ regression
From: Tetsuo Handa @ 2013-01-28 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359328750-28046-1-git-send-email-linus.walleij@linaro.org>
Linus Walleij wrote:
> ---
> ChangeLog v1->v2:
> - Got the PIC/SIC valid mask wrong again, take a deep breath
> and use the foolproof method of defining each bit so that
> nobody will get caught by this again. Didn't see this first
> because the SCSI layer takes for ever to time out.
> ---
> arch/arm/mach-versatile/core.c | 15 ++++++++++++++-
> arch/arm/mach-versatile/pci.c | 11 ++++++-----
> 2 files changed, 20 insertions(+), 6 deletions(-)
>
This patch fixes my problem. Please send to 3.8. Thank you!
^ permalink raw reply
* [PATCH] arm: dts: omap5-evm: Add I2c pinctrl data
From: Sourav Poddar @ 2013-01-28 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Booting 3.8-rc4 om omap 5430evm results in the following error
omap_i2c 48070000.i2c: did not get pins for i2c error: -19
[ 1.024261] omap_i2c 48070000.i2c: bus 0 rev0.12 at 100 kHz
[ 1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[ 1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[ 1.043762] omap_i2c 48060000.i2c: did not get pins for i2c error: -19
[ 1.050964] omap_i2c 48060000.i2c: bus 2 rev0.12 at 100 kHz
[ 1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
[ 1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
This happens because omap5 dts file is not adapted to use i2c through pinctrl
framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap5430 evm with 3.8-rc4 kernel.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/boot/dts/omap5-evm.dts | 62 +++++++++++++++++++++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 8722c15..a96acc0 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -80,6 +80,41 @@
0x15a 0x100 /* abemcbsp2_clkx.abemcbsp2_clkx INPUT | MODE0 */
>;
};
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ 0x1b2 0x118 /* i2c2_scl PULLUP | INPUTENABLE | MODE0 */
+ 0x1b4 0x118 /* i2c2_sda PULLUP | INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0x178 0x100 /* i2c2_scl INPUTENABLE | MODE0 */
+ 0x17a 0x100 /* i2c2_sda INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ 0x13a 0x100 /* i2c3_scl INPUTENABLE | MODE0 */
+ 0x13c 0x100 /* i2c3_sda INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins = <
+ 0xb8 0x100 /* i2c4_scl INPUTENABLE | MODE0 */
+ 0xba 0x100 /* i2c4_sda INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c5_pins: pinmux_i2c5_pins {
+ pinctrl-single,pins = <
+ 0x184 0x100 /* i2c4_scl INPUTENABLE | MODE0 */
+ 0x186 0x100 /* i2c4_sda INPUTENABLE | MODE0 */
+ >;
+ };
};
&mmc1 {
@@ -106,7 +141,17 @@
status = "disabled";
};
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+
+ clock-frequency = <400000>;
+};
+
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
clock-frequency = <400000>;
/* Pressure Sensor */
@@ -116,7 +161,17 @@
};
};
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+
+ clock-frequency = <400000>;
+};
+
&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4_pins>;
+
clock-frequency = <400000>;
/* Temperature Sensor */
@@ -126,6 +181,13 @@
};
};
+&i2c5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c5_pins>;
+
+ clock-frequency = <400000>;
+};
+
&keypad {
keypad,num-rows = <8>;
keypad,num-columns = <8>;
--
1.7.1
^ permalink raw reply related
* [PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
From: Sourav Poddar @ 2013-01-28 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Booting 3.8-rc4 om omap 4430sdp results in the following error
omap_i2c 48070000.i2c: did not get pins for i2c error: -19
[ 1.024261] omap_i2c 48070000.i2c: bus 0 rev0.12 at 100 kHz
[ 1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[ 1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[ 1.043762] omap_i2c 48060000.i2c: did not get pins for i2c error: -19
[ 1.050964] omap_i2c 48060000.i2c: bus 2 rev0.12 at 100 kHz
[ 1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
[ 1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
This happens because omap4 dts file is not adapted to use i2c through pinctrl
framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap4430 sdp with 3.8-rc4 kernel.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 40 +++++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..40a04c9 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -212,9 +212,40 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN | MODE3 */
>;
};
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ 0xe2 0x118 /* i2c1_scl PULLUP | INPUTENABLE | MODE0 */
+ 0xe4 0x118 /* i2c1_sda PULLUP | INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0xe6 0x118 /* i2c2_scl PULLUP | INPUTENABLE | MODE0 */
+ 0xe8 0x118 /* i2c2_sda PULLUP | INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ 0xea 0x118 /* i2c3_scl PULLUP | INPUTENABLE | MODE0 */
+ 0xec 0x118 /* i2c3_sda PULLUP | INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins = <
+ 0xee 0x118 /* i2c4_scl PULLUP | INPUTENABLE | MODE0 */
+ 0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0 */
+ >;
+ };
};
&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+
clock-frequency = <400000>;
twl: twl at 48 {
@@ -253,10 +284,16 @@
/include/ "twl6030.dtsi"
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
clock-frequency = <400000>;
};
&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+
clock-frequency = <400000>;
/*
@@ -279,6 +316,9 @@
};
&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4_pins>;
+
clock-frequency = <400000>;
/*
--
1.7.1
^ permalink raw reply related
* [PATCHv1 for soc 2/5] arm: socfpga: Add clock entries to socfpga.dtsi
From: Pavel Machek @ 2013-01-28 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128071312.GI25723@quad.lixom.net>
Hi!
> On Thu, Jan 24, 2013 at 07:00:30PM -0600, dinguyen at altera.com wrote:
> > From: Dinh Nguyen <dinguyen@altera.com>
> >
> > Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Olof Johansson <olof@lixom.net>
> > Cc: Pavel Machek <pavel@denx.de>
> > ---
> > arch/arm/boot/dts/socfpga.dtsi | 37 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> > index 936d230..688729f 100644
> > --- a/arch/arm/boot/dts/socfpga.dtsi
> > +++ b/arch/arm/boot/dts/socfpga.dtsi
> > @@ -78,6 +78,43 @@
> > };
> > };
> >
> > + clkmgr at ffd04000 {
> > + compatible = "altr, clk-mgr";
>
>
> No space after "altr,". Also, this should have documented bindings under
> Documentation/device-tree/bindings (and those should be cc:d to the appropriate
> maintainers).
Are the clk-mgr entries used in this series? I see only definition in
device tree, but no usage... Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH 00/13] ARM: spear multiplatform support
From: vipul kumar samar @ 2013-01-28 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359156956-32404-1-git-send-email-arnd@arndb.de>
Hello Arnd,
On 1/26/2013 5:05 AM, Arnd Bergmann wrote:
> This is a series I did some time ago but forgot to
> send out earlier. I'd like to get this into v3.9,
> so please give this a test if you can.
Me and bhavna tried to test this patch set on spear1340 and
spear320-hmi. We applied your patch set on the latest kernel v3.8-rc5
and in both case (1340 and 320-hmi) we observe that the kernel load
address is changed form 0x8000 to 0xfffffff2.
---------------------------------------------------------------
Legacy Image at E6080000:
Image Name: Linux-3.8.0-rc5-00013-g35c416f
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2144560 Bytes = 2 MiB
Load Address: fffffff2
Entry Point: fffffff2
Verifying Checksum ... OK
---------------------------------------------------------------
Previously it was like:
---------------------------------------------------------------
Legacy Image at E6080000:
Image Name: Linux-3.5.0-lsp-3.3.1-spear13xx
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3060704 Bytes = 2.9 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... O
---------------------------------------------------------------
And thats why it is giving following crash:
---------------------------------------------------------------
u-boot> bootm 0xe6080000 - 0xe6070000
## Booting kernel from Legacy Image at e6080000 ...
Image Name: Linux-3.8.0-rc5-00013-g35c416f
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2144560 Bytes = 2 MiB
Load Address: fffffff2
Entry Point: fffffff2
Verifying Checksum ... OK
## Flattened Device Tree blob at e6070000
Booting using the fdt blob at 0xe6070000
Loading Kernel Image ... data abort
pc : [<3ff94608>] lr : [<3ff69ef4>]
sp : 3fe65aa8 ip : 00000000 fp : 00000000
r10: e6080040 r9 : e628b970 r8 : 3fe65f58
r7 : e6080000 r6 : 00000000 r5 : 3fe65b10 r4 : 00000000
r3 : fffffff2 r2 : 0000000d r1 : e6080040 r0 : fffffff2
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ..
---------------------------------------------------------------
Regards
Vipul Samar
^ permalink raw reply
* [PATCH 09/10] gpio: pxa: move gpio properties into child node
From: Igor Grinberg @ 2013-01-28 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358929554-32265-10-git-send-email-haojian.zhuang@linaro.org>
On 01/23/13 10:25, Haojian Zhuang wrote:
> Move gpio properties into child node. So pinctrl driver could binds to
> each gpio chip with gpio range.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
> ---
> drivers/gpio/gpio-pxa.c | 33 ++++++++-------------------------
> 1 file changed, 8 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
> index 21cf8fd..528f742 100644
> --- a/drivers/gpio/gpio-pxa.c
> +++ b/drivers/gpio/gpio-pxa.c
> @@ -63,10 +63,6 @@
>
> int pxa_last_gpio;
>
> -#ifdef CONFIG_OF
> -static struct device_node *pxa_gpio_of_node;
> -#endif
> -
> struct pxa_gpio_chip {
> struct gpio_chip chip;
> void __iomem *regbase;
> @@ -404,9 +400,9 @@ static const struct irq_domain_ops pxa_irq_domain_ops = {
>
> static int pxa_gpio_probe_dt(struct platform_device *pdev)
> {
> - int ret, nr_banks;
> + int ret;
> struct pxa_gpio_platform_data *pdata;
> - struct device_node *prev, *next, *np = pdev->dev.of_node;
> + struct device_node *np = pdev->dev.of_node;
> const struct of_device_id *of_id =
> of_match_device(pxa_gpio_dt_ids, &pdev->dev);
>
> @@ -432,25 +428,7 @@ static int pxa_gpio_probe_dt(struct platform_device *pdev)
> /* set the platform data */
> pdev->dev.platform_data = pdata;
>
> - next = of_get_next_child(np, NULL);
> - prev = next;
> - if (!next) {
> - dev_err(&pdev->dev, "Failed to find child gpio node\n");
> - ret = -EINVAL;
> - goto err;
> - }
> - for (nr_banks = 1; ; nr_banks++) {
> - next = of_get_next_child(np, prev);
> - if (!next)
> - break;
> - prev = next;
> - }
> - of_node_put(prev);
> -
> return 0;
> -err:
> - iounmap(gpio_reg_base);
> - return ret;
> }
> #else
> #define pxa_gpio_probe_dt(pdev) (-1)
> @@ -460,6 +438,7 @@ static int pxa_init_gpio_chip(struct platform_device *pdev, int gpio_end,
> int (*set_wake)(unsigned int, unsigned int))
> {
> int i, gpio, nbanks = gpio_to_bank(gpio_end) + 1;
> + struct device_node *next, *np = pdev->dev.of_node;
The above introduces:
drivers/gpio/gpio-pxa.c:453: warning: unused variable 'np'
drivers/gpio/gpio-pxa.c:453: warning: unused variable 'next'
for the !CONFIG_OF case (after the below is fixed).
> struct pxa_gpio_chip *chips;
>
> chips = devm_kzalloc(&pdev->dev, nbanks * sizeof(*chips), GFP_KERNEL);
> @@ -468,6 +447,7 @@ static int pxa_init_gpio_chip(struct platform_device *pdev, int gpio_end,
> return -ENOMEM;
> }
>
> + next = of_get_next_child(np, NULL);
This does not compile for the !CONFIG_OF case, so at least,
you should #ifdef the above line or probably the better solution would be
to stub out the of_get_next_child() in the OF code (probably include/linux/of.h).
> for (i = 0, gpio = 0; i < nbanks; i++, gpio += 32) {
> struct gpio_chip *gc = &chips[i].chip;
>
> @@ -495,7 +475,10 @@ static int pxa_init_gpio_chip(struct platform_device *pdev, int gpio_end,
> gc->set = pxa_gpio_set;
> gc->to_irq = pxa_gpio_to_irq;
> #ifdef CONFIG_OF_GPIO
> - gc->of_node = pxa_gpio_of_node;
> + gc->of_node = next;
> + next = of_get_next_child(np, next);
> + of_node_put(gc->of_node);
> +
> gc->of_xlate = pxa_gpio_of_xlate;
> gc->of_gpio_n_cells = 2;
> #endif
>
--
Regards,
Igor.
^ permalink raw reply
* [PATCH 6/6 v14] gpio: Add block gpio to several gpio drivers
From: Stijn Devriendt @ 2013-01-28 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5105303E.5050007@antcom.de>
On Sun, Jan 27, 2013 at 2:48 PM, Roland Stigge <stigge@antcom.de> wrote:
> On 27/01/13 13:18, Stijn Devriendt wrote:
>>>> In my patch, I go out of the way of this kind of thing for a simple reason:
>>>> You may generate incorrect timing by doing this.
>>>
>>> You are right, certain things like synchronous on+off is not really
>>> possible.
>>>
>>> However, the above at least supports switching on simulaneously, and
>>> switching off simultaneously, which is an improvement in certain cases
>>> (and this certain hardware part doesn't support more). Maybe this
>>> certain driver behaviour can be documented even better than just in the
>>> driver source.
>>>
>>
>> The question here is: do you expect a user of the block-GPIO API to
>> go look into the base-driver code to see what will be supported?
>>
>> In my version of the patch this means:
>> - do not provide a single GPIO-block that crosses multiple base-drivers
>> - only provide gpio_block_get/set for GPIO drivers that support the complete
>> operation in a single go. (for example, in the above example there would be
>> no gpio_block_set() function)
>>
>> Perhaps the best approach is to make this explicit: Allow drivers to expose
>> their capabilities wrt timing and allow users to request strict-timing or
>> loose-timing. Loose-timing allows multiple gpio-drivers to be combined and
>> allows drivers with separate set/clear, hi/lo registers to be used.
>
> Interesting idea. However, it will be difficult to agree on good metrics
> here. As Mark Brown pointed out, even when hardware seems to support
> "simultaneousness" by registers, this doesn't actually mean that voltage
> levels are switched simultaneously wrt. sub-nanosecond timing.
>
> Also, it depends on further wiring between the actually supported GPIO
> hardware chip and the integrated device's I/O connections.
>
> Resulting in scenarios where GPIO chips (in terms of Linux drivers)
> without explicit I/O set registers (e.g., set/clear regs) could be "more
> simultaneous" than those having explicit I/O regs but hardware wiring
> leading to bad "simultaneousness" behaviour.
>
> Questionable if the kernel could address those details.
>
True, but does the kernel _need_ to address that? If this is fixed at the
kernel level, at least the kernel is not the cause of the effect.
Strict-timing could mean as much as "the kernel will do everything it can
(int this case impose limits) to make sure timings are strict - actual
results may
depend on your H/W".
It allows graceful degradation at the driver level (e.g. fallback to requesting
separate pins and toggling them in the right order - or calling the request
function again with loose-timing + dev_warn(... "things may break!") )
OTOH, is it worth it? There may be extra work involved when doing the latter.
Usage of block GPIO for things like emulating busses will need testing anyway.
>> Of course, for a first version you may as well leave it out. Perhaps the
>> use-cases for cross-GPIO-driver blocks are not worth the extra complexity
>> as of today?
>
> I actually started the current block gpio patches to support this kind
> of use case. :-)
Right, our use-cases were less advanced... ;)
Regards,
Stijn
>
> Roland
^ permalink raw reply
* [PATCH] sunxi: a10-cubieboard: Add user LEDs to the device tree
From: Emilio López @ 2013-01-28 11:27 UTC (permalink / raw)
To: linux-arm-kernel
Cubieboard has two LEDs available for use, a blue one (labeled LED1)
and a green one (labeled LED2).
Signed-off-by: Emilio L?pez <emilio@elopez.com.ar>
---
This patch requires all of the sunxi pinctrl/gpio/led patches by
Maxime Ripard to function.
arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index 5cab825..88e2dc1 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -27,6 +27,15 @@
};
soc {
+ pinctrl at 01c20800 {
+ led_pins_cubieboard: led_pins at 0 {
+ allwinner,pins = "PH20", "PH21";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <1>;
+ allwinner,pull = <0>;
+ };
+ };
+
uart0: uart at 01c28000 {
status = "okay";
};
@@ -35,4 +44,21 @@
status = "okay";
};
};
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins_cubieboard>;
+
+ blue {
+ label = "cubieboard::blue";
+ gpios = <&pio 7 21 0>; /* LED1 */
+ };
+
+ green {
+ label = "cubieboard::green";
+ gpios = <&pio 7 20 0>; /* LED2 */
+ linux,default-trigger = "heartbeat";
+ };
+ };
};
--
1.8.1.1
^ permalink raw reply related
* [PATCH 05/10] gpio: pxa: remove gpio_type
From: Igor Grinberg @ 2013-01-28 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYj3Bm0GKhdvcmvwu4mz3YLTnyaOWjGT7qt2atbZ_x2EA@mail.gmail.com>
On 01/25/13 12:01, Linus Walleij wrote:
> On Wed, Jan 23, 2013 at 9:25 AM, Haojian Zhuang
> <haojian.zhuang@linaro.org> wrote:
>
>> Since gpio_type is used to check whether gafr register is valid. So
>> move it into platform data.
>>
>> Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
>
> (...)
>
>> +++ b/drivers/gpio/gpio-pxa.c
>> @@ -72,6 +72,7 @@ struct pxa_gpio_chip {
>> void __iomem *regbase;
>> unsigned int irq_base;
>> unsigned int inverted;
>> + unsigned int gafr;
>> char label[10];
>
> Also looks like some kind of a bool.
Actually, no... GAFR is the PXA Alternate Function register name,
so unsigned int (or u32) is good.
--
Regards,
Igor.
^ permalink raw reply
* [PATCH v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
From: Roger Quadros @ 2013-01-28 11:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The OMAP's High Speed Host controller can interface to ULPI/UTMI
PHYs transparently i.e. whithout requiring the device drivers to
access the PHY. However, the OS must ensure that the PHY has the necessary
resources (power/clock/reset) enabled before it is used.
Till now, the omap-ehci driver was managing the power and reset of the PHY
whereas, clock enabling was left to the bootloader or board files.
In this patchset we make the NOP PHY driver (nop-usb-xceiv.c) handle
all the PHY resources that are available so that it can be used by
platforms like OMAP.
The board files add the PHY as a platform device and use usb_bind_phy()
(API introduced in [2]) to bind the PHY device to the controller's port.
The ehci-omap driver then uses usb_get_phy_dev() to get the PHY device
associated to the controller's port.
All this results in a much cleaner code and makes USB PHY resource management
work properly on OMAP.
NOTE: Tested on 4460ES-B1 Panda and BeagleBoard C4 only. Other boards are only
build tested.
Patches are based on Linux-3.8-rc5 and depend on
[1] [PATCH v9 00/20] OMAP USB Host cleanup
https://lkml.org/lkml/2013/1/23/155
[2] [PATCH v2 0/6] USB: Add support for multiple PHYs of same type
https://lkml.org/lkml/2013/1/24/876
v2:
- Added Alan's patch to split ehci-omap into separate driver
- Addressed Russell King's comments on usage of clk/regulator framework.
- Adapted all board using ehci-omap to using the PHY mechanism.
The following changes since commit e18d48b7f7e563664a41d4658b8cc15679ee4745:
usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type (2013-01-28 12:20:54 +0200)
git://github.com/rogerq/linux.git linux-usbhost15
---
Alan Stern (1):
USB: EHCI: split ehci-omap out to a separate driver
Roger Quadros (29):
usb: phy: nop: use devm_kzalloc()
usb: phy: nop: Manage PHY clock
usb: phy: nop: Handle power supply regulator for the PHY
usb: phy: nop: Handle RESET for the PHY
usb: phy: nop: use new PHY API to register PHY
mfd: omap-usb-host: update nports in platform_data
mfd: omap-usb-host: Remove PHY reset handling code
USB: ehci-omap: Use devm_request_and_ioremap()
USB: ehci-omap: Use PHY APIs to get the PHY device and put it out of
suspend
usb: ehci-omap: Remove PHY reset handling code
usb: ehci-omap: Remove PHY regulator handling code
ARM: OMAP2+: omap4panda: Provide USB Host's PHY platform data
ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes
ARM: OMAP3: Beagle: Adapt to ehci-omap changes
ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes
ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes
ARM: OMAP: AM3517crane: Adapt to ehci-omap changes
ARM: OMAP: AM3517evm: Adapt to ehci-omap changes
ARM: OMAP3: cm-t35: Adapt to ehci-omap changes
ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes
ARM: OMAP: devkit8000: Adapt to ehci-omap changes
ARM: OMAP3: igep0020: Adapt to ehci-omap changes
ARM: OMAP3: omap3evm: Adapt to ehci-omap changes
ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes
ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes
ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes
ARM: OMAP3: overo: Adapt to ehci-omap changes
ARM: OMAP: zoom: Adapt to ehci-omap changes
ARM: OMAP: USB: Remove unused fields from struct
usbhs_omap_platform_data
arch/arm/mach-omap2/board-3430sdp.c | 99 +++++++++++-
arch/arm/mach-omap2/board-3630sdp.c | 100 +++++++++++-
arch/arm/mach-omap2/board-am3517crane.c | 95 ++++++++++--
arch/arm/mach-omap2/board-am3517evm.c | 66 +++++++-
arch/arm/mach-omap2/board-cm-t35.c | 95 ++++++++++-
arch/arm/mach-omap2/board-cm-t3517.c | 97 +++++++++++-
arch/arm/mach-omap2/board-devkit8000.c | 20 ++-
arch/arm/mach-omap2/board-igep0020.c | 112 +++++++++++--
arch/arm/mach-omap2/board-omap3beagle.c | 93 ++++++++++-
arch/arm/mach-omap2/board-omap3evm.c | 63 ++++++--
arch/arm/mach-omap2/board-omap3pandora.c | 54 +++++-
arch/arm/mach-omap2/board-omap3stalker.c | 52 +++++-
arch/arm/mach-omap2/board-omap3touchbook.c | 62 ++++++-
arch/arm/mach-omap2/board-omap4panda.c | 123 ++++++++++----
arch/arm/mach-omap2/board-overo.c | 55 ++++++-
arch/arm/mach-omap2/board-zoom.c | 56 ++++++-
drivers/mfd/omap-usb-host.c | 48 +------
drivers/usb/host/Kconfig | 2 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +-
drivers/usb/host/ehci-omap.c | 245 +++++++++++-----------------
drivers/usb/otg/nop-usb-xceiv.c | 106 +++++++++++--
include/linux/platform_data/usb-omap.h | 3 -
include/linux/usb/nop-usb-xceiv.h | 1 +
24 files changed, 1288 insertions(+), 366 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH 01/30] USB: EHCI: split ehci-omap out to a separate driver
From: Roger Quadros @ 2013-01-28 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359372631-8180-1-git-send-email-rogerq@ti.com>
From: Alan Stern <stern@rowland.harvard.edu>
This patch (as1645) converts ehci-omap over to the new "ehci-hcd is a
library" approach, so that it can coexist peacefully with other EHCI
platform drivers and can make use of the private area allocated at
the end of struct ehci_hcd.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
---
drivers/usb/host/Kconfig | 2 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +---
drivers/usb/host/ehci-omap.c | 76 +++++++++++++++++++-----------------------
4 files changed, 37 insertions(+), 48 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3a21c5d..11e102e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -155,7 +155,7 @@ config USB_EHCI_MXC
Variation of ARC USB block used in some Freescale chips.
config USB_EHCI_HCD_OMAP
- bool "EHCI support for OMAP3 and later chips"
+ tristate "EHCI support for OMAP3 and later chips"
depends on USB_EHCI_HCD && ARCH_OMAP
default y
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 001fbff..56de410 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
obj-$(CONFIG_USB_EHCI_HCD_PLATFORM) += ehci-platform.o
obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
+obj-$(CONFIG_USB_EHCI_HCD_OMAP) += ehci-omap.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 09537b2..5a35246 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1251,11 +1251,6 @@ MODULE_LICENSE ("GPL");
#define PLATFORM_DRIVER ehci_hcd_sh_driver
#endif
-#ifdef CONFIG_USB_EHCI_HCD_OMAP
-#include "ehci-omap.c"
-#define PLATFORM_DRIVER ehci_hcd_omap_driver
-#endif
-
#ifdef CONFIG_PPC_PS3
#include "ehci-ps3.c"
#define PS3_SYSTEM_BUS_DRIVER ps3_ehci_driver
@@ -1345,6 +1340,7 @@ MODULE_LICENSE ("GPL");
!IS_ENABLED(CONFIG_USB_EHCI_HCD_PLATFORM) && \
!IS_ENABLED(CONFIG_USB_CHIPIDEA_HOST) && \
!IS_ENABLED(CONFIG_USB_EHCI_MXC) && \
+ !IS_ENABLED(CONFIG_USB_EHCI_HCD_OMAP) && \
!defined(PLATFORM_DRIVER) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
!defined(OF_PLATFORM_DRIVER) && \
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index b96a4bf..30fc482 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -36,6 +36,9 @@
* - convert to use hwmod and runtime PM
*/
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/io.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/usb/ulpi.h>
@@ -43,6 +46,10 @@
#include <linux/pm_runtime.h>
#include <linux/gpio.h>
#include <linux/clk.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ehci.h"
#include <linux/platform_data/usb-omap.h>
@@ -57,9 +64,11 @@
#define EHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#define EHCI_INSNREG05_ULPI_WRDATA_SHIFT 0
-/*-------------------------------------------------------------------------*/
+#define DRIVER_DESC "OMAP-EHCI Host Controller driver"
-static const struct hc_driver ehci_omap_hc_driver;
+static const char hcd_name[] = "ehci-omap";
+
+/*-------------------------------------------------------------------------*/
static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
@@ -166,6 +175,12 @@ static void disable_put_regulator(
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
+static struct hc_driver __read_mostly ehci_omap_hc_driver;
+
+static const struct ehci_driver_overrides ehci_omap_overrides __initdata = {
+ .reset = omap_ehci_init,
+};
+
/**
* ehci_hcd_omap_probe - initialize TI-based HCDs
*
@@ -315,56 +330,33 @@ static struct platform_driver ehci_hcd_omap_driver = {
/*.suspend = ehci_hcd_omap_suspend, */
/*.resume = ehci_hcd_omap_resume, */
.driver = {
- .name = "ehci-omap",
+ .name = hcd_name,
}
};
/*-------------------------------------------------------------------------*/
-static const struct hc_driver ehci_omap_hc_driver = {
- .description = hcd_name,
- .product_desc = "OMAP-EHCI Host Controller",
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /*
- * generic hardware linkage
- */
- .irq = ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /*
- * basic lifecycle operations
- */
- .reset = omap_ehci_init,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /*
- * managing i/o requests and associated device resources
- */
- .urb_enqueue = ehci_urb_enqueue,
- .urb_dequeue = ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
- .endpoint_reset = ehci_endpoint_reset,
+static int __init ehci_omap_init(void)
+{
+ if (usb_disabled())
+ return -ENODEV;
- /*
- * scheduling support
- */
- .get_frame_number = ehci_get_frame,
+ pr_info("%s: " DRIVER_DESC "\n", hcd_name);
- /*
- * root hub support
- */
- .hub_status_data = ehci_hub_status_data,
- .hub_control = ehci_hub_control,
- .bus_suspend = ehci_bus_suspend,
- .bus_resume = ehci_bus_resume,
+ ehci_init_driver(&ehci_omap_hc_driver, &ehci_omap_overrides);
+ return platform_driver_register(&ehci_hcd_omap_driver);
+}
+module_init(ehci_omap_init);
- .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
-};
+static void __exit ehci_omap_cleanup(void)
+{
+ platform_driver_unregister(&ehci_hcd_omap_driver);
+}
+module_exit(ehci_omap_cleanup);
MODULE_ALIAS("platform:omap-ehci");
MODULE_AUTHOR("Texas Instruments, Inc.");
MODULE_AUTHOR("Felipe Balbi <felipe.balbi@nokia.com>");
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
--
1.7.4.1
^ permalink raw reply related
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