* [PATCH] RFC: leds-pwm: don't disable pwm when setting brightness to 0
From: Uwe Kleine-König @ 2012-10-24 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024095603.GH639@pengutronix.de>
This fixes disabling the LED on i.MX28. The PWM hardware delays using
the newly set pwm-config until the beginning of a new period. It's very
likely that pwm_disable is called before the current period ends. In
case the LED was on brightness=max before the LED stays on because in
the disabled PWM block the period never ends.
It's unclear if the mxs-pwm driver doesn't implement the API as expected
(i.e. it should block until the newly set config is effective) or if the
leds-pwm driver makes wrong assumptions. This patch assumes the latter.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Hello,
I'm not sure this is correct, but this is the workaround I'm using until
I get some feed back.
Best regards
Uwe
drivers/leds/leds-pwm.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index f2e44c7..a909f4f 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -38,13 +38,8 @@ static void led_pwm_set(struct led_classdev *led_cdev,
unsigned int max = led_dat->cdev.max_brightness;
unsigned int period = led_dat->period;
- if (brightness == 0) {
- pwm_config(led_dat->pwm, 0, period);
- pwm_disable(led_dat->pwm);
- } else {
- pwm_config(led_dat->pwm, brightness * period / max, period);
- pwm_enable(led_dat->pwm);
- }
+ pwm_config(led_dat->pwm, brightness * period / max, period);
+ pwm_enable(led_dat->pwm);
}
static int led_pwm_probe(struct platform_device *pdev)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Gregory CLEMENT @ 2012-10-24 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210241224.06791.arnd@arndb.de>
On 10/24/2012 02:24 PM, Arnd Bergmann wrote:
> On Wednesday 24 October 2012, Gregory CLEMENT wrote:
>> On 10/24/2012 01:48 PM, Gregory CLEMENT wrote:
>>> On 10/24/2012 01:36 PM, Arnd Bergmann wrote:
>>>>
>>>> I think it would be cleaner to statically define the operations in a constant
>>>> structure and point directly to the functions you need. If necessary, use
>>>> multiple structures.
>>>
>>> My problem was that these functions are not exposed, only arm_dma_op and
>>> arm_coherent_dma_ops are exported.
>>> Or do you think about something like this:
>>
>> struct dma_map_ops *dma_ops = {
>> .alloc = arm_coherent_dma_ops.arm_coherent_dma_alloc,
>> .free = arm_coherent_dma_ops.arm_coherent_dma_free,
>> .mmap = arm_coherent_dma_ops.arm_dma_mmap,
>> .get_sgtable = arm_coherent_dma_ops.arm_dma_get_sgtable,
>> .map_sg = arm_coherent_dma_ops.arm_dma_map_sg,
>> .set_dma_mask = arm_coherent_dma_ops.arm_dma_set_mask,
>> .map_page = armada_xp_dma_map_page,
>> .unmap_page = armada_xp_dma_unmap_page,
>> .unmap_sg = arm_dma_ops.unmap_sg,
>> .sync_single_for_cpu = armada_xp_dma_sync,
>> .sync_single_for_device = armada_xp_dma_sync,
>> .sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu,
>> .sync_sg_for_device = arm_dma_ops.sync_sg_for_device,
>> };
>
> No, I was thinking of making the underlying functions globally visible
> and have extern declarations in a header file so you can access them
> directly.
>
> Generally speaking, when you run into a problem with common code, your
> first approach should be to fix the common code before you try to work
> around it.
OK I thought it was done on purpose. But if you consider it needs to be
fixed I will add patch for it in next version.
>
> Arnd
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 10/10] ARM: imx6q: implement WAIT mode with coupled cpuidle
From: Shawn Guo @ 2012-10-24 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023173543.GA15113@e102568-lin.cambridge.arm.com>
On Tue, Oct 23, 2012 at 06:35:43PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Oct 23, 2012 at 04:22:59PM +0100, Shawn Guo wrote:
>
> [...]
>
> > +/*
> > + * For each cpu, setup the broadcast timer because local timer
> > + * stops for the states other than WFI.
> > + */
> > +static void imx6q_setup_broadcast_timer(void *arg)
> > +{
> > + int cpu = smp_processor_id();
> > +
> > + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
> > +}
>
> Can anyone explain to me please why this is needed ?
>
It basically does nothing if either NO_HZ or HIGH_RES_TIMERS is
enabled, in which case tick_broadcast_setup_oneshot is already called
on init_timers path to set up bc->event_handler. This is the general
case since nowadays we have both options enabled by default for most
systems.
However if neither option is enabled, CLOCK_EVT_NOTIFY_BROADCAST_ON
notifying will help route to call tick_broadcast_setup_oneshot to have
bc->event_handler set up.
So in short, it's needed to have broadcast timer work as expected when
neither NO_HZ or HIGH_RES_TIMERS is enabled.
Shawn
^ permalink raw reply
* Possible regression in arm/io.h
From: Will Deacon @ 2012-10-24 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABYn4sz4v7Uf07am=MtPAKAvvAjwt+-bTRaLrBjoiRuyR9cfZw@mail.gmail.com>
On Wed, Oct 24, 2012 at 02:35:11PM +0100, Bastian Hecht wrote:
> 2012/10/24 Will Deacon <will.deacon@arm.com>:
> > On Wed, Oct 24, 2012 at 01:34:18PM +0100, Bastian Hecht wrote:
> >> 2012/10/24 Will Deacon <will.deacon@arm.com>:
> >> > It sounds like we need to:
> >> >
> >> > (a) Understand what has changed in GCC to cause this error to start
> >> > cropping up.
> >> >
> >> > (b) Have a look at the impact of using only "Q" on the generated
> >> > code (especially register usage for the address).
> >> >
> >>
> >> Uff... I've just started to write ARM assembly and have no practical
> >> experience with the inner workings of real world compilers. So this
> >> time I'm afraid I was just good enough to report this. It sounds
> >> interesting to hunt it, but would take ages for me at this point.
> >
> > Ok, I'll have a look at the impact of moving exclusively to "Q" when I get a
> > chance. Which toolchain are you using?
>
> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> For a more verbose info take a look at the bug report link.
Ok, thanks. One other thing you could try while I try to find a copy of that
toolchain is changing the "+" modifier to an "=", like I proposed in this
version of the patch:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/114971.html
Cheers,
Will
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update
From: Thomas Petazzoni @ 2012-10-24 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351086561-13569-3-git-send-email-gregory.clement@free-electrons.com>
Hello,
Shouldn't you split into one commit adding the SATA definition in
the .dtsi + doing the defconfig change (the "SoC" level modifications),
and then another commit for the .dts change? I don't really care
personally, it's really up to Jason/Andrew on this.
Another comment below, though.
On Wed, 24 Oct 2012 15:49:21 +0200, Gregory CLEMENT wrote:
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
> index 94b4b9e..3f08233 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -69,6 +69,16 @@
> compatible = "marvell,armada-addr-decoding-controller";
> reg = <0xd0020000 0x258>;
> };
> +
> + sata at d00a0000 {
> + compatible = "marvell,orion-sata";
> + reg = <0xd00a0000 0x2400>;
> + interrupts = <55>;
> + nr-ports = <2>;
> + clocks = <&coreclk 0>;//, <&coreclk 0>;
Alignment problem + remainings of tests or something like that.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 10/10] ARM: imx6q: implement WAIT mode with coupled cpuidle
From: Shawn Guo @ 2012-10-24 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D9DA41B75289BC488A38AE7992B7866301261C4A@039-SN2MPN1-022.039d.mgd.msft.net>
On Tue, Oct 23, 2012 at 04:09:08PM +0000, Lee Robert-B18647 wrote:
> Hey Shawn,
>
> For your SRPG implementation, a couple of weeks ago an issue was found that affects all i.MX6 SRPG functionality that requires a work around for 100% reliable operation. It's my understanding that the workaround is almost but not yet finalized. Ranjani is most familiar with this issue so you and her can discuss further.
>
Thanks for the info, Rob.
I worked with Anson today trying to reproduce the issue with my kernel
on imx6q. But so far, we can not reproduce it. So I would have the
series go as it is, and we can add workaround later when we see the
real failure on imx6q to keep the history clear.
Shawn
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update
From: Gregory CLEMENT @ 2012-10-24 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024160139.6dbf5e16@skate>
On 10/24/2012 04:01 PM, Thomas Petazzoni wrote:
> Hello,
>
> Shouldn't you split into one commit adding the SATA definition in
> the .dtsi + doing the defconfig change (the "SoC" level modifications),
> and then another commit for the .dts change? I don't really care
> personally, it's really up to Jason/Andrew on this.
>
> Another comment below, though.
>
> On Wed, 24 Oct 2012 15:49:21 +0200, Gregory CLEMENT wrote:
>
>> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
>> index 94b4b9e..3f08233 100644
>> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
>> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
>> @@ -69,6 +69,16 @@
>> compatible = "marvell,armada-addr-decoding-controller";
>> reg = <0xd0020000 0x258>;
>> };
>> +
>> + sata at d00a0000 {
>> + compatible = "marvell,orion-sata";
>> + reg = <0xd00a0000 0x2400>;
>> + interrupts = <55>;
>> + nr-ports = <2>;
>> + clocks = <&coreclk 0>;//, <&coreclk 0>;
>
> Alignment problem + remainings of tests or something like that.
True I missed this one.
Jason, Andrew, do you want I split this patch as suggested by Thomas or
are you fine with having one single patch?
I will wait your answer before sending the V2.
Thanks,
Gregory
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update
From: Andrew Lunn @ 2012-10-24 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351086561-13569-3-git-send-email-gregory.clement@free-electrons.com>
On Wed, Oct 24, 2012 at 03:49:21PM +0200, Gregory CLEMENT wrote:
> From: Lior Amsalem <alior@marvell.com>
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Lior Amsalem <alior@marvell.com>
> ---
> arch/arm/boot/dts/armada-370-db.dts | 3 +++
> arch/arm/boot/dts/armada-370-xp.dtsi | 10 ++++++++++
> arch/arm/boot/dts/armada-xp-db.dts | 3 +++
> arch/arm/configs/mvebu_defconfig | 7 +++++++
> 4 files changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
> index 4a31b03..2a2aa75 100644
> --- a/arch/arm/boot/dts/armada-370-db.dts
> +++ b/arch/arm/boot/dts/armada-370-db.dts
> @@ -34,5 +34,8 @@
> clock-frequency = <200000000>;
> status = "okay";
> };
> + sata at d00a0000 {
> + status = "okay";
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
> index 94b4b9e..3f08233 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -69,6 +69,16 @@
> compatible = "marvell,armada-addr-decoding-controller";
> reg = <0xd0020000 0x258>;
> };
> +
> + sata at d00a0000 {
> + compatible = "marvell,orion-sata";
> + reg = <0xd00a0000 0x2400>;
> + interrupts = <55>;
> + nr-ports = <2>;
> + clocks = <&coreclk 0>;//, <&coreclk 0>;
> + status = "disabled";
> + };
> +
> };
> };
>
> diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
> index b1fc728..b0db9a3 100644
> --- a/arch/arm/boot/dts/armada-xp-db.dts
> +++ b/arch/arm/boot/dts/armada-xp-db.dts
> @@ -46,5 +46,8 @@
> clock-frequency = <250000000>;
> status = "okay";
> };
> + sata at d00a0000 {
> + status = "okay";
> + };
> };
> };
Hi Gregory
Should there be some pinctrl setup somewhere, to ensure the pins used
for SATA are really setup up for SATA?
Also, for kirkwood, the number of SATA ports varies. So we don't
define it in the base kirkwood.dtsi and leave each board to set it.
Do we want to be consistent between kirkwood and 370/xp?
Thanks
Andrew
^ permalink raw reply
* [PATCH] arm: mvebu: support for the PlatHome OpenBlocks AX3 board
From: Thomas Petazzoni @ 2012-10-24 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087AD9A.8020801@free-electrons.com>
Dear Gregory CLEMENT,
On Wed, 24 Oct 2012 10:58:02 +0200, Gregory CLEMENT wrote:
> On 10/23/2012 10:19 AM, Thomas Petazzoni wrote:
> > This platform, available in Japan from PlatHome, has a dual-core
> > Armada XP, the MV78260. For now, only the two serial ports and the
> > three front LEDs are supported. Support for network, SATA, USB and
> > other peripherals will be added as drivers for them become available
> > for Armada XP in mainline.
> And don't forget the SMP support too, MV78260 is supposed to have 2 cores.
Sure. My plan is to progressively add support for other devices and
features (SMP included) as we get them merged in mainline.
> Besides this, this patch looks good. I have applied it on a v3.7-rc2
> without any problem, and managed to build it also.
> So you can add my
> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] arm: mvebu: update defconfig with 3.7 changes
From: Thomas Petazzoni @ 2012-10-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087A94E.4000706@free-electrons.com>
Dear Gregory CLEMENT,
On Wed, 24 Oct 2012 10:39:42 +0200, Gregory CLEMENT wrote:
> On 10/23/2012 10:17 AM, Thomas Petazzoni wrote:
> > The split of 370 and XP into two Kconfig options and the multiplatform
> > kernel support has changed a few Kconfig symbols, so let's update the
> > mvebu_defconfig file with the latest changes.
>
> Indeed this patch fixes the mvebu_defconfig which was broken.
> But as now mvebu is part of multi_v7_defconfig, shouldn't we just
> removed mvebu_defconfig ?
I think for now, SoC family specific defconfig files are still
accepted, so I'd prefer to keep mvebu_defconfig around. Multiplatform
is nice for users, but I prefer to build a mvebu-only kernel when I'm
doing kernel development.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: PMU: fix runtime PM enable
From: Jon Hunter @ 2012-10-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024093150.GA23775@mudshark.cambridge.arm.com>
Hi Will,
On 10/24/2012 04:31 AM, Will Deacon wrote:
> Hi Jon,
>
> On Tue, Oct 23, 2012 at 09:31:08PM +0100, Jon Hunter wrote:
>> Commit 7be2958 (ARM: PMU: Add runtime PM Support) updated the ARM PMU code to
>> use runtime PM which was prototyped and validated on the OMAP devices. In this
>> commit, there is no call pm_runtime_enable() and for OMAP devices
>> pm_runtime_enable() is currently being called from the OMAP PMU code when the
>> PMU device is created. However, there are two problems with this:
>>
>> 1. For any other ARM device wishing to use runtime PM for PMU they will need
>> to call pm_runtime_enable() for runtime PM to work.
>> 2. When booting with device-tree and using device-tree to create the PMU
>> device, pm_runtime_enable() needs to be called from within the ARM PERF
>> driver as we are no longer calling any device specific code to create the
>> device. Hence, PMU does not work on OMAP devices that use the runtime PM
>> callbacks when using device-tree to create the PMU device.
>>
>> Therefore, add a new platform data variable to indicate whether runtime PM is
>> used and if so call pm_runtime_enable() when the PMU device is registered. Note
>> that devices using runtime PM may not use the runtime_resume/suspend callbacks
>> and so we cannot use the presence of these handlers in the platform data to
>> determine whether we should call pm_runtime_enable().
>
> [...]
>
>> diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
>> index a26170d..50a6c3b 100644
>> --- a/arch/arm/include/asm/pmu.h
>> +++ b/arch/arm/include/asm/pmu.h
>> @@ -36,6 +36,7 @@
>> struct arm_pmu_platdata {
>> irqreturn_t (*handle_irq)(int irq, void *dev,
>> irq_handler_t pmu_handler);
>> + bool use_runtime_pm;
>> int (*runtime_resume)(struct device *dev);
>> int (*runtime_suspend)(struct device *dev);
>
> Can we not just use the presence of the resume/suspend function pointers to
> indicate whether we should enable runtime pm or not? i.e. if they're not
> NULL, then enable the thing?
I wondered if you would ask that :-)
Unfortunately, we can't. For example, OMAP3430 and OMAP4460 both require
runtime_pm to be enabled to turn on the debug sub-system in OMAP for PMU
to work. However, neither of these devices are using the suspend/resume
callbacks because the HWMOD framework is doing this for us behind the
scenes.
So then you ask, why do we need the resume/suspend callbacks, well we
will need them for OMAP4430 where in addition to turning on the debug
sub-system we need to configure the CTI module. Therefore, I had to add
another plat data variable.
By the way, I did add a comment in the above changelog about this. See
the last paragraph, not sure if this is 100% clear.
One alternative I had thought about was always calling
pm_runtime_enable() on registering the PMU device and avoid having a
use_runtime_pm variable. For ARM platforms that don't use runtime PM the
pm_runtime_enable() function does nothing. However, I was more concerned
about adding unnecessary overhead for ARM platforms that are using
runtime PM but don't need runtime PM for PMU. I don't see any side
affects on our OMAP2 platform that does not need runtime PM for PMU.
However, was not sure what is best here.
Cheers
Jon
^ permalink raw reply
* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Kevin Hilman @ 2012-10-24 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANOLnOOUHJg5W9VbHhnK8ta+Bys_oMpSz9M5jQ0xCeOB1gxtdg@mail.gmail.com>
Grazvydas Ignotas <notasas@gmail.com> writes:
> On Tue, Oct 23, 2012 at 9:09 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> From: Kevin Hilman <khilman@ti.com>
>>
>> When debounce clocks are disabled, ensure that the banks
>> dbck_enable_mask is cleared also. Otherwise, context restore on
>> subsequent off-mode transition will restore previous value from the
>> shadow copies (bank->context.debounce*) leading to mismatch state
>> between driver state and hardware state.
>
> This doesn't look right to me, aren't you effectively disabling
> debounce forever here? _gpio_dbck_disable is called from
> omap_gpio_runtime_suspend() and nothing will ever restore
> dbck_enable_mask back to what it was set by _set_gpio_debounce and
> debounce functionality is lost.
Yes, you're right. Good catch.
I need a fix that's more targetted to the free/reset path.
Linus, please revert if it's not too late, and I'll come up with a more
targetted fix.
Kevin
^ permalink raw reply
* [PATCH 0/5] Enable mvebu pinctrl/gpio for Dove and Kirkwood
From: Andrew Lunn @ 2012-10-24 14:25 UTC (permalink / raw)
To: linux-arm-kernel
This is the first step in converting Dove and Kirkwood boards to use
pinctrl. Allow the MVEBU pinctrl driver and GPIO driver to be used by
these two SoC families.
Andrew Lunn (2):
ARM: Kirkwood: Allow use of pinctrl
ARM: Kirkwood: Allow use of MVEBU GPIO driver.
Sebastian Hesselbarth (3):
pinctrl: dove: fix iomem and pdma clock
ARM: Dove: Make use of pinctrl driver
ARM: Dove: Make use of MVEBU GPIO driver
arch/arm/Kconfig | 6 ++++++
arch/arm/boot/dts/dove.dtsi | 19 ++++++++++++++++---
arch/arm/boot/dts/kirkwood.dtsi | 11 +++++++++--
arch/arm/plat-orion/irq.c | 5 +----
drivers/gpio/Kconfig | 2 +-
drivers/pinctrl/Kconfig | 2 +-
drivers/pinctrl/pinctrl-dove.c | 20 +++++++++++++-------
7 files changed, 47 insertions(+), 18 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH 1/5] ARM: Kirkwood: Allow use of pinctrl
From: Andrew Lunn @ 2012-10-24 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351088724-11142-1-git-send-email-andrew@lunn.ch>
We now have a pinctrl driver for arch-mvebu. It supports kirkwood out
of the box. Allow ARCH_KIRKWOOD to select it, and make ARCH_KIRKWOOD
select it. This then allows the convertion of board-*.c files away
from MPP to pinctrl in DT, before they get moved over into mach-mvebu.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/Kconfig | 2 ++
drivers/pinctrl/Kconfig | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 73067ef..160cd40 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -548,6 +548,8 @@ config ARCH_KIRKWOOD
select GENERIC_CLOCKEVENTS
select PCI
select PLAT_ORION_LEGACY
+ select PINCTRL
+ select PINCTRL_KIRKWOOD
help
Support for the following Marvell Kirkwood series SoCs:
88F6180, 88F6192 and 88F6281.
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 7bf914d..5682c96 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -188,7 +188,7 @@ config PINCTRL_EXYNOS4
config PINCTRL_MVEBU
bool
- depends on ARCH_MVEBU
+ depends on ARCH_MVEBU || ARCH_KIRKWOOD
select PINMUX
select PINCONF
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/5] ARM: Kirkwood: Allow use of MVEBU GPIO driver.
From: Andrew Lunn @ 2012-10-24 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351088724-11142-1-git-send-email-andrew@lunn.ch>
This GPIO driver is generic to all Marvel Orion/XP/370 SoCs. Allow
Kirkwood to enable and use it. Fix the kirkwood DT to pass the
expected properties and remove the old gpio probing code.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/kirkwood.dtsi | 11 +++++++++--
arch/arm/plat-orion/irq.c | 5 +----
drivers/gpio/Kconfig | 2 +-
4 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 160cd40..0203af8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -544,6 +544,7 @@ config ARCH_DOVE
config ARCH_KIRKWOOD
bool "Marvell Kirkwood"
select ARCH_REQUIRE_GPIOLIB
+ select ARCH_WANT_OPTIONAL_GPIOLIB
select CPU_FEROCEON
select GENERIC_CLOCKEVENTS
select PCI
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 4e5b815..5bc7a8b 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -4,6 +4,11 @@
compatible = "marvell,kirkwood";
interrupt-parent = <&intc>;
+ aliases {
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ };
+
intc: interrupt-controller {
compatible = "marvell,orion-intc", "marvell,intc";
interrupt-controller;
@@ -24,7 +29,8 @@
#gpio-cells = <2>;
gpio-controller;
reg = <0x10100 0x40>;
- ngpio = <32>;
+ ngpios = <32>;
+ interrupt-controller;
interrupts = <35>, <36>, <37>, <38>;
};
@@ -33,7 +39,8 @@
#gpio-cells = <2>;
gpio-controller;
reg = <0x10140 0x40>;
- ngpio = <18>;
+ ngpios = <18>;
+ interrupt-controller;
interrupts = <39>, <40>, <41>;
};
diff --git a/arch/arm/plat-orion/irq.c b/arch/arm/plat-orion/irq.c
index 1867944..eec296a 100644
--- a/arch/arm/plat-orion/irq.c
+++ b/arch/arm/plat-orion/irq.c
@@ -41,7 +41,7 @@ void __init orion_irq_init(unsigned int irq_start, void __iomem *maskaddr)
static int __init orion_add_irq_domain(struct device_node *np,
struct device_node *interrupt_parent)
{
- int i = 0, irq_gpio;
+ int i = 0;
void __iomem *base;
do {
@@ -55,9 +55,6 @@ static int __init orion_add_irq_domain(struct device_node *np,
irq_domain_add_legacy(np, i * 32, 0, 0,
&irq_domain_simple_ops, NULL);
- irq_gpio = i * 32;
- orion_gpio_of_init(irq_gpio);
-
return 0;
}
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d055cee..2155aef 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -152,7 +152,7 @@ config GPIO_MSM_V2
config GPIO_MVEBU
def_bool y
- depends on ARCH_MVEBU
+ depends on ARCH_MVEBU || ARCH_KIRKWOOD
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/5] pinctrl: dove: fix iomem and pdma clock
From: Andrew Lunn @ 2012-10-24 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351088724-11142-1-git-send-email-andrew@lunn.ch>
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Since 3.7 readl/writel require register addresses to be const void*
instead of unsigned int. The register addresses are converted using
IOMEM() and offsets are added instead of OR'ed.
Also a workaround for the pdma clock is added, that is required as
there is still no DT clock provider available on Dove.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
drivers/pinctrl/pinctrl-dove.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-dove.c b/drivers/pinctrl/pinctrl-dove.c
index ffe74b2..70befaa 100644
--- a/drivers/pinctrl/pinctrl-dove.c
+++ b/drivers/pinctrl/pinctrl-dove.c
@@ -22,22 +22,22 @@
#include "pinctrl-mvebu.h"
-#define DOVE_SB_REGS_VIRT_BASE 0xfde00000
-#define DOVE_MPP_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE | 0xd0200)
+#define DOVE_SB_REGS_VIRT_BASE IOMEM(0xfde00000)
+#define DOVE_MPP_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE + 0xd0200)
#define DOVE_PMU_MPP_GENERAL_CTRL (DOVE_MPP_VIRT_BASE + 0x10)
#define DOVE_AU0_AC97_SEL BIT(16)
-#define DOVE_GLOBAL_CONFIG_1 (DOVE_SB_REGS_VIRT_BASE | 0xe802C)
+#define DOVE_GLOBAL_CONFIG_1 (DOVE_SB_REGS_VIRT_BASE + 0xe802C)
#define DOVE_TWSI_ENABLE_OPTION1 BIT(7)
-#define DOVE_GLOBAL_CONFIG_2 (DOVE_SB_REGS_VIRT_BASE | 0xe8030)
+#define DOVE_GLOBAL_CONFIG_2 (DOVE_SB_REGS_VIRT_BASE + 0xe8030)
#define DOVE_TWSI_ENABLE_OPTION2 BIT(20)
#define DOVE_TWSI_ENABLE_OPTION3 BIT(21)
#define DOVE_TWSI_OPTION3_GPIO BIT(22)
-#define DOVE_SSP_CTRL_STATUS_1 (DOVE_SB_REGS_VIRT_BASE | 0xe8034)
+#define DOVE_SSP_CTRL_STATUS_1 (DOVE_SB_REGS_VIRT_BASE + 0xe8034)
#define DOVE_SSP_ON_AU1 BIT(0)
-#define DOVE_MPP_GENERAL_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE | 0xe803c)
+#define DOVE_MPP_GENERAL_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE + 0xe803c)
#define DOVE_AU1_SPDIFO_GPIO_EN BIT(1)
#define DOVE_NAND_GPIO_EN BIT(0)
-#define DOVE_GPIO_LO_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE | 0xd0400)
+#define DOVE_GPIO_LO_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE + 0xd0400)
#define DOVE_MPP_CTRL4_VIRT_BASE (DOVE_GPIO_LO_VIRT_BASE + 0x40)
#define DOVE_SPI_GPIO_SEL BIT(5)
#define DOVE_UART1_GPIO_SEL BIT(4)
@@ -587,6 +587,12 @@ static int __devinit dove_pinctrl_probe(struct platform_device *pdev)
* grab clk to make sure it is ticking.
*/
clk = devm_clk_get(&pdev->dev, NULL);
+
+ /* Currently there is no DT clock provider for pdma clock,
+ this fallback ensures pdma clock is ticking */
+ if (IS_ERR(clk))
+ clk = clk_get_sys("dove-pdma", NULL);
+
if (!IS_ERR(clk))
clk_prepare_enable(clk);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/5] ARM: Dove: Make use of pinctrl driver
From: Andrew Lunn @ 2012-10-24 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351088724-11142-1-git-send-email-andrew@lunn.ch>
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Allow ARCH_DOVE to select pinctrl-mvebu with support for Dove SoC.
With the now enabled pinctrl driver also add the corresponding DT node
to Dove DT.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
arch/arm/Kconfig | 2 ++
arch/arm/boot/dts/dove.dtsi | 5 +++++
drivers/pinctrl/Kconfig | 2 +-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0203af8..b12d1dd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -537,6 +537,8 @@ config ARCH_DOVE
select GENERIC_CLOCKEVENTS
select MIGHT_HAVE_PCI
select PLAT_ORION_LEGACY
+ select PINCTRL
+ select PINCTRL_DOVE
select USB_ARCH_HAS_EHCI
help
Support for the Marvell Dove SoC 88AP510
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 5a00022..1617c0c 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -67,6 +67,11 @@
status = "disabled";
};
+ pinctrl: pinctrl at d0200 {
+ compatible = "marvell,dove-pinctrl";
+ reg = <0xd0200 0x20>;
+ };
+
gpio0: gpio at d0400 {
compatible = "marvell,orion-gpio";
#gpio-cells = <2>;
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 5682c96..463100c 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -188,7 +188,7 @@ config PINCTRL_EXYNOS4
config PINCTRL_MVEBU
bool
- depends on ARCH_MVEBU || ARCH_KIRKWOOD
+ depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_DOVE
select PINMUX
select PINCONF
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/5] ARM: Dove: Make use of MVEBU GPIO driver
From: Andrew Lunn @ 2012-10-24 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351088724-11142-1-git-send-email-andrew@lunn.ch>
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
The MVEBU driver is generic to all Marvell Orion/XP/370 SoCs. Allow
Dove DT to enable and use it. Also fix dove DT to pass the expected
properties and add gpio aliases.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/dove.dtsi | 14 +++++++++++---
drivers/gpio/Kconfig | 2 +-
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b12d1dd..bde1015 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -533,6 +533,7 @@ config ARCH_IXP4XX
config ARCH_DOVE
bool "Marvell Dove"
select ARCH_REQUIRE_GPIOLIB
+ select ARCH_WANT_OPTIONAL_GPIOLIB
select CPU_V7
select GENERIC_CLOCKEVENTS
select MIGHT_HAVE_PCI
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 1617c0c..f101323 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -4,6 +4,12 @@
compatible = "marvell,dove";
model = "Marvell Armada 88AP510 SoC";
+ aliases {
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ gpio2 = &gpio2;
+ };
+
soc at f1000000 {
compatible = "simple-bus";
#address-cells = <1>;
@@ -77,7 +83,8 @@
#gpio-cells = <2>;
gpio-controller;
reg = <0xd0400 0x20>;
- ngpio = <32>;
+ ngpios = <32>;
+ interrupt-controller;
interrupts = <12>, <13>, <14>, <60>;
};
@@ -86,7 +93,8 @@
#gpio-cells = <2>;
gpio-controller;
reg = <0xd0420 0x20>;
- ngpio = <32>;
+ ngpios = <32>;
+ interrupt-controller;
interrupts = <61>;
};
@@ -95,7 +103,7 @@
#gpio-cells = <2>;
gpio-controller;
reg = <0xe8400 0x0c>;
- ngpio = <8>;
+ ngpios = <8>;
};
spi0: spi at 10600 {
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 2155aef..2a0c1e1 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -152,7 +152,7 @@ config GPIO_MSM_V2
config GPIO_MVEBU
def_bool y
- depends on ARCH_MVEBU || ARCH_KIRKWOOD
+ depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_DOVE
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ARM: PMU: fix runtime PM enable
From: Will Deacon @ 2012-10-24 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087F84B.9070705@ti.com>
On Wed, Oct 24, 2012 at 03:16:43PM +0100, Jon Hunter wrote:
> Hi Will,
>
> On 10/24/2012 04:31 AM, Will Deacon wrote:
> > Can we not just use the presence of the resume/suspend function pointers to
> > indicate whether we should enable runtime pm or not? i.e. if they're not
> > NULL, then enable the thing?
>
> I wondered if you would ask that :-)
>
> Unfortunately, we can't. For example, OMAP3430 and OMAP4460 both require
> runtime_pm to be enabled to turn on the debug sub-system in OMAP for PMU
> to work. However, neither of these devices are using the suspend/resume
> callbacks because the HWMOD framework is doing this for us behind the
> scenes.
>
> So then you ask, why do we need the resume/suspend callbacks, well we
> will need them for OMAP4430 where in addition to turning on the debug
> sub-system we need to configure the CTI module. Therefore, I had to add
> another plat data variable.
Hmmm, now I start to wonder whether your original idea of having separate
callbacks for enable/disable irq and resume/suspend doesn't make more sense.
Then the CTI magic can go in the irq management code and be totally separate
to the PM stuff.
What do you reckon?
> By the way, I did add a comment in the above changelog about this. See
> the last paragraph, not sure if this is 100% clear.
Sorry, I missed that this morning.
> One alternative I had thought about was always calling
> pm_runtime_enable() on registering the PMU device and avoid having a
> use_runtime_pm variable. For ARM platforms that don't use runtime PM the
> pm_runtime_enable() function does nothing. However, I was more concerned
> about adding unnecessary overhead for ARM platforms that are using
> runtime PM but don't need runtime PM for PMU. I don't see any side
> affects on our OMAP2 platform that does not need runtime PM for PMU.
> However, was not sure what is best here.
Nah, we should be able to fix this in the platdata, I'd just rather have
function pointers instead of state variables in there.
Will
^ permalink raw reply
* [PATCH] i2c: at91: add a sanity check on i2c message length
From: ludovic.desroches @ 2012-10-24 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349879158-27268-1-git-send-email-ludovic.desroches@atmel.com>
Hi Wolfram,
Le 10/10/2012 04:25 PM, ludovic.desroches at atmel.com a ?crit :
> From: Ludovic Desroches <ludovic.desroches@atmel.com>
>
> If the i2c message length is zero, i2c-at91 will directly return an error
> instead of trying to send a zero-length message.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> ---
>
> fix for 3.7
>
> drivers/i2c/busses/i2c-at91.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index aa59a25..eaddc77 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -263,6 +263,9 @@ static int at91_twi_xfer(struct i2c_adapter *adap, struct i2c_msg *msg, int num)
> unsigned int_addr_flag = 0;
> struct i2c_msg *m_start = msg;
>
> + if (!msg->len)
> + return -EINVAL;
> +
> dev_dbg(&adap->dev, "at91_xfer: processing %d messages:\n", num);
>
> /*
>
Could you take this fix for 3.7?
Thanks
Regards
Ludovic
^ permalink raw reply
* [PATCH] ARM: dts: exynos4: Add support for Exynos4x12 SoCs
From: Tomasz Figa @ 2012-10-24 14:35 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds device tree sources for Exynos4x12 SoC series (currently
Exynos4212 and Exynos4412) and enables mach-exynos4-dt to support these
SoCs.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/arm/boot/dts/exynos4212.dtsi | 28 ++++++++++++++++++++++++++++
arch/arm/boot/dts/exynos4412.dtsi | 28 ++++++++++++++++++++++++++++
arch/arm/boot/dts/exynos4x12.dtsi | 31 +++++++++++++++++++++++++++++++
arch/arm/mach-exynos/mach-exynos4-dt.c | 2 ++
4 files changed, 89 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos4212.dtsi
create mode 100644 arch/arm/boot/dts/exynos4412.dtsi
create mode 100644 arch/arm/boot/dts/exynos4x12.dtsi
diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
new file mode 100644
index 0000000..c6ae200
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Samsung's Exynos4212 SoC device tree source
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos4212 SoC device nodes are listed in this file. Exynos4212
+ * based board files can include this file and provide values for board specfic
+ * bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * Exynos4212 SoC. As device tree coverage for Exynos4212 increases, additional
+ * nodes can be added to this file.
+ *
+ * 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/ "exynos4x12.dtsi"
+
+/ {
+ compatible = "samsung,exynos4212";
+
+ gic:interrupt-controller at 10490000 {
+ cpu-offset = <0x8000>;
+ };
+};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
new file mode 100644
index 0000000..d7dfe31
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Samsung's Exynos4412 SoC device tree source
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos4412 SoC device nodes are listed in this file. Exynos4412
+ * based board files can include this file and provide values for board specfic
+ * bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * Exynos4412 SoC. As device tree coverage for Exynos4412 increases, additional
+ * nodes can be added to this file.
+ *
+ * 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/ "exynos4x12.dtsi"
+
+/ {
+ compatible = "samsung,exynos4412";
+
+ gic:interrupt-controller at 10490000 {
+ cpu-offset = <0x4000>;
+ };
+};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
new file mode 100644
index 0000000..b6a66f4
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -0,0 +1,31 @@
+/*
+ * Samsung's Exynos4x12 SoCs device tree source
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos4x12 SoCs device nodes are listed in this file. Exynos4x12
+ * based board files can include this file and provide values for board specfic
+ * bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * Exynos4x12 SoC. As device tree coverage for Exynos4x12 increases, additional
+ * nodes can be added to this file.
+ *
+ * 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/ "exynos4.dtsi"
+/include/ "exynos4x12-pinctrl.dtsi"
+
+/ {
+ combiner:interrupt-controller at 10440000 {
+ interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+ <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
+ <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+ <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
+ <0 16 0>, <0 17 0>, <0 18 0>, <0 19 0>;
+ };
+};
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c
index 977bd39..b2b9cc1 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -94,6 +94,8 @@ static void __init exynos4_dt_machine_init(void)
static char const *exynos4_dt_compat[] __initdata = {
"samsung,exynos4210",
+ "samsung,exynos4212",
+ "samsung,exynos4412",
NULL
};
--
1.7.12
^ permalink raw reply related
* [PATCH 0/4] pinctrl: samsung: Add support for Exynos4x12 SoCs
From: Tomasz Figa @ 2012-10-24 14:37 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds pinctrl support for SoCs from Exynos4x12 family.
First two patches make necessary preperations to skip legacy GPIO and
GPIO interrupt registration in case of Exynos4x12 SoCs which are not
supported by legacy (non-DT) code.
Third patch adds Exynos4x12-specific definitions to pinctrl-samsung driver.
Fourth patch adds device nodes for pin controllers available on Exynos4x12
SoCs to Exynos4x12 device tree sources.
This series depends on:
- [PATCH] ARM: dts: exynos4: Add support for Exynos4x12 SoCs
Tomasz Figa (4):
ARM: EXYNOS: Skip wakeup-int setup if pinctrl driver is used on
Exynos4x12
gpio: samsung: Skip registration if pinctrl driver is present on
Exynos4x12
pinctrl: samsung: Add support for Exynos4x12
ARM: dts: exynos4x12: Add nodes for pin controllers
.../bindings/pinctrl/samsung-pinctrl.txt | 1 +
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 965 +++++++++++++++++++++
arch/arm/boot/dts/exynos4x12.dtsi | 38 +
arch/arm/mach-exynos/common.c | 7 +-
drivers/gpio/gpio-samsung.c | 43 +-
drivers/pinctrl/pinctrl-exynos.c | 110 +++
drivers/pinctrl/pinctrl-samsung.c | 2 +
drivers/pinctrl/pinctrl-samsung.h | 1 +
8 files changed, 1144 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
--
1.7.12
^ permalink raw reply
* [PATCH 1/4] ARM: EXYNOS: Skip wakeup-int setup if pinctrl driver is used on Exynos4x12
From: Tomasz Figa @ 2012-10-24 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351089457-8205-1-git-send-email-t.figa@samsung.com>
This patch modifies the old wakeup interrupt initialization code to
detect pinctrl driver by using for_each_matching_node instead of
for_each_compatible_node and adds match table for both Exynos4210 and
Exynos4x12.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/arm/mach-exynos/common.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index cb891a7..109f878 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -1032,11 +1032,14 @@ static int __init exynos_init_irq_eint(void)
* platforms switch over to using the pinctrl driver, the wakeup
* interrupt support code here can be completely removed.
*/
+ static const struct of_device_id exynos_pinctrl_ids[] = {
+ { .compatible = "samsung,pinctrl-exynos4210", },
+ { .compatible = "samsung,pinctrl-exynos4x12", },
+ };
struct device_node *pctrl_np, *wkup_np;
- const char *pctrl_compat = "samsung,pinctrl-exynos4210";
const char *wkup_compat = "samsung,exynos4210-wakeup-eint";
- for_each_compatible_node(pctrl_np, NULL, pctrl_compat) {
+ for_each_matching_node(pctrl_np, exynos_pinctrl_ids) {
if (of_device_is_available(pctrl_np)) {
wkup_np = of_find_compatible_node(pctrl_np, NULL,
wkup_compat);
--
1.7.12
^ permalink raw reply related
* [PATCH 2/4] gpio: samsung: Skip registration if pinctrl driver is present on Exynos4x12
From: Tomasz Figa @ 2012-10-24 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351089457-8205-1-git-send-email-t.figa@samsung.com>
This patch modifies the Samsung GPIO driver to check for pinctrl driver
presence earlier and use generic matching instead of a single compatible
value.
This allows us to fix warning about unrecognized SoC in case of
Exynos4x12, which is not supported by this driver.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/gpio/gpio-samsung.c | 43 ++++++++++++++++++++++---------------------
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 43c4595..01f7fe9 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -2796,27 +2796,6 @@ static __init void exynos4_gpiolib_init(void)
int group = 0;
void __iomem *gpx_base;
-#ifdef CONFIG_PINCTRL_SAMSUNG
- /*
- * This gpio driver includes support for device tree support and
- * there are platforms using it. In order to maintain
- * compatibility with those platforms, and to allow non-dt
- * Exynos4210 platforms to use this gpiolib support, a check
- * is added to find out if there is a active pin-controller
- * driver support available. If it is available, this gpiolib
- * support is ignored and the gpiolib support available in
- * pin-controller driver is used. This is a temporary check and
- * will go away when all of the Exynos4210 platforms have
- * switched to using device tree and the pin-ctrl driver.
- */
- struct device_node *pctrl_np;
- const char *pctrl_compat = "samsung,pinctrl-exynos4210";
- pctrl_np = of_find_compatible_node(NULL, NULL, pctrl_compat);
- if (pctrl_np)
- if (of_device_is_available(pctrl_np))
- return;
-#endif
-
/* gpio part1 */
gpio_base1 = ioremap(EXYNOS4_PA_GPIO1, SZ_4K);
if (gpio_base1 == NULL) {
@@ -3031,6 +3010,28 @@ static __init int samsung_gpiolib_init(void)
int i, nr_chips;
int group = 0;
+#ifdef CONFIG_PINCTRL_SAMSUNG
+ /*
+ * This gpio driver includes support for device tree support and there
+ * are platforms using it. In order to maintain compatibility with those
+ * platforms, and to allow non-dt Exynos4210 platforms to use this
+ * gpiolib support, a check is added to find out if there is a active
+ * pin-controller driver support available. If it is available, this
+ * gpiolib support is ignored and the gpiolib support available in
+ * pin-controller driver is used. This is a temporary check and will go
+ * away when all of the Exynos4210 platforms have switched to using
+ * device tree and the pin-ctrl driver.
+ */
+ struct device_node *pctrl_np;
+ static const struct of_device_id exynos_pinctrl_ids[] = {
+ { .compatible = "samsung,pinctrl-exynos4210", },
+ { .compatible = "samsung,pinctrl-exynos4x12", },
+ };
+ for_each_matching_node(pctrl_np, exynos_pinctrl_ids)
+ if (pctrl_np && of_device_is_available(pctrl_np))
+ return -ENODEV;
+#endif
+
samsung_gpiolib_set_cfg(samsung_gpio_cfgs, ARRAY_SIZE(samsung_gpio_cfgs));
if (soc_is_s3c24xx()) {
--
1.7.12
^ permalink raw reply related
* [PATCH 3/4] pinctrl: samsung: Add support for Exynos4x12
From: Tomasz Figa @ 2012-10-24 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351089457-8205-1-git-send-email-t.figa@samsung.com>
This patch extends the driver with any necessary SoC-specific
definitions to support Exynos4x12 SoCs.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
.../bindings/pinctrl/samsung-pinctrl.txt | 1 +
drivers/pinctrl/pinctrl-exynos.c | 110 +++++++++++++++++++++
drivers/pinctrl/pinctrl-samsung.c | 2 +
drivers/pinctrl/pinctrl-samsung.h | 1 +
4 files changed, 114 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 63806e2..e97a278 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -8,6 +8,7 @@ on-chip controllers onto these pads.
Required Properties:
- compatible: should be one of the following.
- "samsung,pinctrl-exynos4210": for Exynos4210 compatible pin-controller.
+ - "samsung,pinctrl-exynos4x12": for Exynos4x12 compatible pin-controller.
- "samsung,pinctrl-exynos5250": for Exynos5250 compatible pin-controller.
- reg: Base address of the pin controller hardware module and length of
diff --git a/drivers/pinctrl/pinctrl-exynos.c b/drivers/pinctrl/pinctrl-exynos.c
index 73a0aa2..19fab68 100644
--- a/drivers/pinctrl/pinctrl-exynos.c
+++ b/drivers/pinctrl/pinctrl-exynos.c
@@ -566,3 +566,113 @@ struct samsung_pin_ctrl exynos4210_pin_ctrl[] = {
.label = "exynos4210-gpio-ctrl2",
},
};
+
+/* pin banks of exynos4x12 pin-controller 0 */
+static struct samsung_pin_bank exynos4x12_pin_banks0[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
+ EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpb", 0x08),
+ EXYNOS_PIN_BANK_EINTG(5, 0x060, "gpc0", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpc1", 0x10),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0A0, "gpd0", 0x14),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0C0, "gpd1", 0x18),
+ EXYNOS_PIN_BANK_EINTG(8, 0x180, "gpf0", 0x30),
+ EXYNOS_PIN_BANK_EINTG(8, 0x1A0, "gpf1", 0x34),
+ EXYNOS_PIN_BANK_EINTG(8, 0x1C0, "gpf2", 0x38),
+ EXYNOS_PIN_BANK_EINTG(6, 0x1E0, "gpf3", 0x3c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x240, "gpj0", 0x40),
+ EXYNOS_PIN_BANK_EINTG(5, 0x260, "gpj1", 0x44),
+};
+
+/* pin banks of exynos4x12 pin-controller 1 */
+static struct samsung_pin_bank exynos4x12_pin_banks1[] = {
+ EXYNOS_PIN_BANK_EINTG(7, 0x040, "gpk0", 0x08),
+ EXYNOS_PIN_BANK_EINTG(7, 0x060, "gpk1", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(7, 0x080, "gpk2", 0x10),
+ EXYNOS_PIN_BANK_EINTG(7, 0x0A0, "gpk3", 0x14),
+ EXYNOS_PIN_BANK_EINTG(7, 0x0C0, "gpl0", 0x18),
+ EXYNOS_PIN_BANK_EINTG(2, 0x0E0, "gpl1", 0x1c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x100, "gpl2", 0x20),
+ EXYNOS_PIN_BANK_EINTG(8, 0x260, "gpm0", 0x24),
+ EXYNOS_PIN_BANK_EINTG(7, 0x280, "gpm1", 0x28),
+ EXYNOS_PIN_BANK_EINTG(5, 0x2A0, "gpm2", 0x2c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x2C0, "gpm3", 0x30),
+ EXYNOS_PIN_BANK_EINTG(8, 0x2E0, "gpm4", 0x34),
+ EXYNOS_PIN_BANK_EINTN(6, 0x120, "gpy0"),
+ EXYNOS_PIN_BANK_EINTN(4, 0x140, "gpy1"),
+ EXYNOS_PIN_BANK_EINTN(6, 0x160, "gpy2"),
+ EXYNOS_PIN_BANK_EINTN(8, 0x180, "gpy3"),
+ EXYNOS_PIN_BANK_EINTN(8, 0x1A0, "gpy4"),
+ EXYNOS_PIN_BANK_EINTN(8, 0x1C0, "gpy5"),
+ EXYNOS_PIN_BANK_EINTN(8, 0x1E0, "gpy6"),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC00, "gpx0", 0x00),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC20, "gpx1", 0x04),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC40, "gpx2", 0x08),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC60, "gpx3", 0x0c),
+};
+
+/* pin banks of exynos4x12 pin-controller 2 */
+static struct samsung_pin_bank exynos4x12_pin_banks2[] = {
+ EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),
+};
+
+/* pin banks of exynos4x12 pin-controller 3 */
+static struct samsung_pin_bank exynos4x12_pin_banks3[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpv0", 0x00),
+ EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpv1", 0x04),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpv2", 0x08),
+ EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpv3", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(2, 0x080, "gpv4", 0x10),
+};
+
+/*
+ * Samsung pinctrl driver data for Exynos4x12 SoC. Exynos4x12 SoC includes
+ * four gpio/pin-mux/pinconfig controllers.
+ */
+struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
+ {
+ /* pin-controller instance 0 data */
+ .pin_banks = exynos4x12_pin_banks0,
+ .nr_banks = ARRAY_SIZE(exynos4x12_pin_banks0),
+ .geint_con = EXYNOS_GPIO_ECON_OFFSET,
+ .geint_mask = EXYNOS_GPIO_EMASK_OFFSET,
+ .geint_pend = EXYNOS_GPIO_EPEND_OFFSET,
+ .svc = EXYNOS_SVC_OFFSET,
+ .eint_gpio_init = exynos_eint_gpio_init,
+ .label = "exynos4x12-gpio-ctrl0",
+ }, {
+ /* pin-controller instance 1 data */
+ .pin_banks = exynos4x12_pin_banks1,
+ .nr_banks = ARRAY_SIZE(exynos4x12_pin_banks1),
+ .geint_con = EXYNOS_GPIO_ECON_OFFSET,
+ .geint_mask = EXYNOS_GPIO_EMASK_OFFSET,
+ .geint_pend = EXYNOS_GPIO_EPEND_OFFSET,
+ .weint_con = EXYNOS_WKUP_ECON_OFFSET,
+ .weint_mask = EXYNOS_WKUP_EMASK_OFFSET,
+ .weint_pend = EXYNOS_WKUP_EPEND_OFFSET,
+ .svc = EXYNOS_SVC_OFFSET,
+ .eint_gpio_init = exynos_eint_gpio_init,
+ .eint_wkup_init = exynos_eint_wkup_init,
+ .label = "exynos4x12-gpio-ctrl1",
+ }, {
+ /* pin-controller instance 2 data */
+ .pin_banks = exynos4x12_pin_banks2,
+ .nr_banks = ARRAY_SIZE(exynos4x12_pin_banks2),
+ .geint_con = EXYNOS_GPIO_ECON_OFFSET,
+ .geint_mask = EXYNOS_GPIO_EMASK_OFFSET,
+ .geint_pend = EXYNOS_GPIO_EPEND_OFFSET,
+ .svc = EXYNOS_SVC_OFFSET,
+ .eint_gpio_init = exynos_eint_gpio_init,
+ .label = "exynos4x12-gpio-ctrl2",
+ }, {
+ /* pin-controller instance 3 data */
+ .pin_banks = exynos4x12_pin_banks3,
+ .nr_banks = ARRAY_SIZE(exynos4x12_pin_banks3),
+ .geint_con = EXYNOS_GPIO_ECON_OFFSET,
+ .geint_mask = EXYNOS_GPIO_EMASK_OFFSET,
+ .geint_pend = EXYNOS_GPIO_EPEND_OFFSET,
+ .svc = EXYNOS_SVC_OFFSET,
+ .eint_gpio_init = exynos_eint_gpio_init,
+ .label = "exynos4x12-gpio-ctrl3",
+ },
+};
diff --git a/drivers/pinctrl/pinctrl-samsung.c b/drivers/pinctrl/pinctrl-samsung.c
index fc34cac..81c9896 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -947,6 +947,8 @@ static int __devinit samsung_pinctrl_probe(struct platform_device *pdev)
static const struct of_device_id samsung_pinctrl_dt_match[] = {
{ .compatible = "samsung,pinctrl-exynos4210",
.data = (void *)exynos4210_pin_ctrl },
+ { .compatible = "samsung,pinctrl-exynos4x12",
+ .data = (void *)exynos4x12_pin_ctrl },
{},
};
MODULE_DEVICE_TABLE(of, samsung_pinctrl_dt_match);
diff --git a/drivers/pinctrl/pinctrl-samsung.h b/drivers/pinctrl/pinctrl-samsung.h
index 0670d9e..5addfd1 100644
--- a/drivers/pinctrl/pinctrl-samsung.h
+++ b/drivers/pinctrl/pinctrl-samsung.h
@@ -236,5 +236,6 @@ struct samsung_pmx_func {
/* list of all exported SoC specific data */
extern struct samsung_pin_ctrl exynos4210_pin_ctrl[];
+extern struct samsung_pin_ctrl exynos4x12_pin_ctrl[];
#endif /* __PINCTRL_SAMSUNG_H */
--
1.7.12
^ 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