Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 08/18] watchdog: orion: Make RSTOUT register a separate resource
From: Thomas Petazzoni @ 2014-01-26  8:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390431915-5115-9-git-send-email-ezequiel.garcia@free-electrons.com>

Dear Ezequiel Garcia,

On Wed, 22 Jan 2014 20:05:05 -0300, Ezequiel Garcia wrote:

> +/* RSTOUT mask register physical address for Orion5x, Kirkwood and Dove */
> +#define ORION_RSTOUT_MASK_OFFSET	0x20108
> +
> +/* Internal registers can be configured at any 1 MiB aligned address */
> +#define INTERNAL_REGS_MASK		~(SZ_1M - 1)

I'm not a big fan of hardcoding the internal register window size in a
driver. I would have preferred to have used the offset between the
watchdog registers and the rstout register, but since this one is
*before* the watchdog registers, it would have to be a negative offset.
Not sure how to handle this.

> +/*
> + * The original devicetree binding for this driver specified only
> + * one memory resource, so in order to keep DT backwards compatibility
> + * we try to fallback to a hardcoded register address, if the resource
> + * is missing from the devicetree.
> + */
> +static void __iomem *try_rstout_ioremap(struct platform_device *pdev,
> +					phys_addr_t internal_regs)

Why is it called "try" ? It actually does the mapping. So I would
prefer the function to be named:

	orion_wdt_ioremap_rstout()

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH v4 07/18] watchdog: orion: Handle IRQ
From: Thomas Petazzoni @ 2014-01-26  8:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390431915-5115-8-git-send-email-ezequiel.garcia@free-electrons.com>

Dear Ezequiel Garcia,

On Wed, 22 Jan 2014 20:05:04 -0300, Ezequiel Garcia wrote:
> DT-enabled where an irqchip driver for the brigde interrupt controller is
> available can handle the watchdog IRQ properly. Therefore, we request
> the interruption and add a dummy handler that merely calls panic().

I don't quiite understand the first sentence of this commit log, and
the commit title looks wrong. Maybe a bad copy/paste or something?

> 
> This is done in order to have an initial 'ack' of the interruption,

interruption -> interrupt

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH v2 2/3] ata: sata_mv: fix disk hotplug for Armada 370/XP SoCs
From: Thomas Petazzoni @ 2014-01-26  7:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1389711007-7239-3-git-send-email-simon.guinot@sequanux.org>

Dear Simon Guinot,

On Tue, 14 Jan 2014 15:50:06 +0100, Simon Guinot wrote:

> +			if (hpriv->hp_flags & MV_HP_FIX_LP_PHY_CTL) {
> +				void __iomem *lp_phy_addr =
> +					mv_ap_base(link->ap) + LP_PHY_CTL;
> +				/*
> +				 * Set PHY speed according to SControl speed.
> +				 */
> +				if ((val & 0xf0) == 0x10)
> +					writelfl(0x7, lp_phy_addr);
> +				else
> +					writelfl(0x227, lp_phy_addr);
> +			}

I think we could do a little bit better than these magical values.

The datasheet says:

 * bits 12:9, PIN_PHY_GEN_RX. Value 0x0 => 1.5 Gbps, value 0x1 => 3 Gbps
 * bits 8:5, PIN_PHY_GEN_TX. Value 0x0 => 1.5 Gbps, value 0x1 => 3 Gbps
 * bit 2, PIN_PU_TX. Value 0x0 => Power down, value 0x1 => Power up.
 * bit 1, PIN_PU_RX. Value 0x0 => Power down, value 0x1 => Power up.
 * bit 0, PIN_PU_PLL. Value 0x0 => Power down, value 0x1 => Power up.

So maybe something like:

#define PIN_PHY_GEN_1_5		0
#define PIN_PHY_GEN_3		1

#define PIN_PHY_GEN_RX(gen)	((gen) << 9)
#define PIN_PHY_GEN_TX(gen)	((gen) << 5)
#define PIN_PU_TX		BIT(2)
#define PIN_PU_RX		BIT(1)
#define PIN_PU_PLL		BIT(0)


		u32 sata_gen;

		if ((val & 0xf0) == 0x10)
			sata_gen = PIN_PHY_GEN_1_5;
		else
			sata_gen = PIN_PHY_GEN_3;

		writelfl(PIN_PHY_GEN_RX(sata_gen) |
			 PIN_PHY_GEN_TX(sata_gen) |
			 PIN_PU_TX | PIN_PU_RX | PIN_PU_PLL,
			 lp_phy_addr);


> +	/*
> +	 * To allow disk hotplug on Armada 370/XP SoCs, the PHY speed must be
> +	 * updated in the LP_PHY_CTL register.
> +	 */
> +	if (pdev->dev.of_node &&
> +		of_device_is_compatible(pdev->dev.of_node,
> +					"marvell,armada-370-xp-sata"))

Testing whether pdev->dev.of_node is not NULL does not seems to be
useful. A quick read of of_device_is_compatible() and the function it's
calling seem to indicate that of_device_is_compatible will return false
if the passed struct device_node * is NULL.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* [Q] L1_CACHE_BYTES on flush_pfn_alias function.
From: Jungseung Lee @ 2014-01-26  5:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140124154321.GI19052@arm.com>

Not to flush some more bytes. In the scenario, they can *omit* to flush last 32 bytes.

L1_CACHE_BYTES = 64 (ARM v7, CA9)

asm(    "mcrr   p15, 0, %1, %0, c14\n"
    "   mcr p15, 0, %2, c7, c10, 4"
        :
        : "r" (to), "r" (to + PAGE_SIZE - L1_CACHE_BYTES), "r" (zero)
        : "cc");
-----Original Message-----
From: Catalin Marinas [mailto:catalin.marinas at arm.com] 
Sent: Saturday, January 25, 2014 12:43 AM
Cc: linux-arm-kernel at lists.infradead.org; linux at arm.linux.org.uk; linux-kernel at vger.kernel.org
Subject: Re: [Q] L1_CACHE_BYTES on flush_pfn_alias function.

On Fri, Jan 17, 2014 at 09:54:42AM +0000,        wrote:
> Follow the mailing-list
> http://comments.gmane.org/gmane.linux.ports.arm.omap/31686
> 
> >>Setting the L1 cache line size larger than it actually is should be safe.
> 
> the written code expected as L1_CACHE_BYTES should be real cache line 
> size has bug.
> It looks like that flush_pfn_alias function should be fixed.

Did you actually notice any problem with flushing some more bytes? It's a clean+invalidate rather than invalidate, I don't see any problem.

--
Catalin

^ permalink raw reply

* GPIO triggers kernel reboot
From: Florian Fainelli @ 2014-01-26  2:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52E3E031.6040709@denx.de>

Le 25/01/2014 08:02, Heiko Schocher a ?crit :
> Hello all,
>
> is it possible to reboot current mainline kernel triggered from a
> GPIO in kernel space?
>
> If not, how can be done this, so that it has a chance to go into
> mainline?

Your GPIO could (should) be bound to a gpio-keys driver which will 
deliver key presses event; which you can ultimately bind to the action 
of triggering a system reboot.

Granted, this makes you cross a lot of layers, and requires user-space 
to implemnt the reboot policy, but what you are asking for is both a 
mechanism and policy mix, which is usually not accepted.

You are probably working with HW which won't change, but wiring a reset 
button to a system reset output is usually much simpler ;)

>
> Thanks for any suggestions
>
> bye,
> Heiko

^ permalink raw reply

* [PATCH 0/4] clk: mvebu: fix clk init order
From: Ezequiel Garcia @ 2014-01-26  0:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52E4367B.3090608@elopez.com.ar>

Hi Emilio,

Thanks for your help with this.

On Sat, Jan 25, 2014 at 07:11:07PM -0300, Emilio L?pez wrote:
[..]
> >
> > Ok, I'll look if using of_clk_get_parent_name will help here. But again,
> > I can see that clk-gating driver gets registered before core-clk driver.
> > There may be no code to give you the parent name at that time.
> 
> After looking at some of the armada*.dtsi, I see you don't list the 
> clock names on the coreclk node, so of_clk_get_parent_name may not be of 
> much value after all.
> 

IIRC, we faced a similar issue with the Core Divider clock and solved it by
specifying the clock names in the DT.

I meant to complete the core and gating clocks in a similar way
(providing names on the DT), but apparently (as discussed with Gregory Clement)
Mike Turquette and others are planning to remove the clock names from
the DT entirely.

Can you guys explain about this plan a bit further? Or do you think we
should specify the names on the DT for all the clocks instead?

Notice that the latter would remove lots of strings from the kernel
itself (right?)
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

^ permalink raw reply

* [PATCH 0/4] clk: mvebu: fix clk init order
From: Emilio López @ 2014-01-25 22:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52E43046.1030105@gmail.com>

Sebastian,

El 25/01/14 18:44, Sebastian Hesselbarth escribi?:
> On 01/25/2014 10:32 PM, Emilio L?pez wrote:
>> El 25/01/14 15:19, Sebastian Hesselbarth escribi?:
>>> This patch set fixes clk init order that went upside-down with
>>> v3.14. I haven't really investigated what caused this, but I assume
>>> it is related with DT node reordering by addresses.
>>
>> The framework should be able to deal with unordered registration. I am
>> not very familiar with the mvebu driver though, do you have a valid
>> reason to require a specific order?
>
> Emilio,
>
> I rather think that everthing registered with CLK_OF_DECLARE cannot
> deal with unordered registration. The callback passed to CLK_OF_DECLARE
> has to have void as return value, so there is no way to pass errors,
> e.g. -EPROBE_DEFER, back to of_clk_init.

Indeed. What I meant is that the framework works fine if you first 
register a child clock that refers to a not yet registered parent, and 
then register the parent. The registration need not be strictly ordered.

> The reason for this ordering is that the clock gates depend on core
> clocks. It is always that way, so merging both init functions isn't
> that odd.

If your only dependency is the parent name, and you can use DT or 
something else to get it, then you don't need to enforce an order.

>>> Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
>>> registered before core clocks driver. Unfortunately, we cannot
>>> return -EPROBE_DEFER in drivers initialized by clk_of_init.
>>
>> Why would you need to do so? After a quick inspection on the code, I see
>> you may have problems on mvebu_clk_gating_setup() when getting the
>> default parent clock name, but I believe you could solve it in an easier
>> way by using of_clk_get_parent_name().
>
> Ok, I'll look if using of_clk_get_parent_name will help here. But again,
> I can see that clk-gating driver gets registered before core-clk driver.
> There may be no code to give you the parent name at that time.

After looking at some of the armada*.dtsi, I see you don't list the 
clock names on the coreclk node, so of_clk_get_parent_name may not be of 
much value after all.

Cheers,

Emilio

^ permalink raw reply

* [PATCH 0/4] clk: mvebu: fix clk init order
From: Sebastian Hesselbarth @ 2014-01-25 21:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52E42D6A.5050508@elopez.com.ar>

On 01/25/2014 10:32 PM, Emilio L?pez wrote:
> El 25/01/14 15:19, Sebastian Hesselbarth escribi?:
>> This patch set fixes clk init order that went upside-down with
>> v3.14. I haven't really investigated what caused this, but I assume
>> it is related with DT node reordering by addresses.
>
> The framework should be able to deal with unordered registration. I am
> not very familiar with the mvebu driver though, do you have a valid
> reason to require a specific order?

Emilio,

I rather think that everthing registered with CLK_OF_DECLARE cannot
deal with unordered registration. The callback passed to CLK_OF_DECLARE
has to have void as return value, so there is no way to pass errors,
e.g. -EPROBE_DEFER, back to of_clk_init.

The reason for this ordering is that the clock gates depend on core
clocks. It is always that way, so merging both init functions isn't
that odd.

>> Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
>> registered before core clocks driver. Unfortunately, we cannot
>> return -EPROBE_DEFER in drivers initialized by clk_of_init.
>
> Why would you need to do so? After a quick inspection on the code, I see
> you may have problems on mvebu_clk_gating_setup() when getting the
> default parent clock name, but I believe you could solve it in an easier
> way by using of_clk_get_parent_name().

Ok, I'll look if using of_clk_get_parent_name will help here. But again,
I can see that clk-gating driver gets registered before core-clk driver.
There may be no code to give you the parent name at that time.

Sebastian

^ permalink raw reply

* [PATCH 0/4] clk: mvebu: fix clk init order
From: Emilio López @ 2014-01-25 21:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390673950-4521-1-git-send-email-sebastian.hesselbarth@gmail.com>

Hello Sebastian,

El 25/01/14 15:19, Sebastian Hesselbarth escribi?:
> This patch set fixes clk init order that went upside-down with
> v3.14. I haven't really investigated what caused this, but I assume
> it is related with DT node reordering by addresses.

The framework should be able to deal with unordered registration. I am 
not very familiar with the mvebu driver though, do you have a valid 
reason to require a specific order?

> Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
> registered before core clocks driver. Unfortunately, we cannot
> return -EPROBE_DEFER in drivers initialized by clk_of_init.

Why would you need to do so? After a quick inspection on the code, I see 
you may have problems on mvebu_clk_gating_setup() when getting the 
default parent clock name, but I believe you could solve it in an easier 
way by using of_clk_get_parent_name().

Cheers,

Emilio

^ permalink raw reply

* [PATCH 9/9] ARM: dts: omap3-gta04: Add ti, omap36xx to compatible property to avoid problems with booting.
From: Marek Belisko @ 2014-01-25 21:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390685343-11663-1-git-send-email-marek@goldelico.com>

Without that change booting leads to crash with more warnings like below:
[    0.284454] omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
[    0.284484] omap_hwmod: uart4: cannot _init_clocks
[    0.284484] ------------[ cut here ]------------
[    0.284545] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2543 _init+0x300/0x3e4()
[    0.284545] omap_hwmod: uart4: couldn't init clocks
[    0.284576] Modules linked in:
[    0.284606] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-next-20140124-00020-gd2aefec-dirty #26
[    0.284637] [<c00151c0>] (unwind_backtrace) from [<c0011e20>] (show_stack+0x10/0x14)
[    0.284667] [<c0011e20>] (show_stack) from [<c0568544>] (dump_stack+0x7c/0x94)
[    0.284729] [<c0568544>] (dump_stack) from [<c003ff94>] (warn_slowpath_common+0x6c/0x90)
[    0.284729] [<c003ff94>] (warn_slowpath_common) from [<c003ffe8>] (warn_slowpath_fmt+0x30/0x40)
[    0.284759] [<c003ffe8>] (warn_slowpath_fmt) from [<c07d1be8>] (_init+0x300/0x3e4)
[    0.284790] [<c07d1be8>] (_init) from [<c07d217c>] (__omap_hwmod_setup_all+0x40/0x8c)
[    0.284820] [<c07d217c>] (__omap_hwmod_setup_all) from [<c0008918>] (do_one_initcall+0xe8/0x14c)
[    0.284851] [<c0008918>] (do_one_initcall) from [<c07c5c18>] (kernel_init_freeable+0x104/0x1c8)
[    0.284881] [<c07c5c18>] (kernel_init_freeable) from [<c0563524>] (kernel_init+0x8/0x118)
[    0.284912] [<c0563524>] (kernel_init) from [<c000e368>] (ret_from_fork+0x14/0x2c)
[    0.285064] ---[ end trace 63de210ad43b627d ]---

Reference:
https://lkml.org/lkml/2013/10/8/553

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 arch/arm/boot/dts/omap3-gta04.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index ea1b94d..998fe1e 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -13,7 +13,7 @@
 
 / {
 	model = "OMAP3 GTA04";
-	compatible = "ti,omap3-gta04", "ti,omap3";
+	compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";
 
 	cpus {
 		cpu at 0 {
-- 
1.8.3.2

^ permalink raw reply related

* [PATCH 8/9] ARM: dts: omap3-gta04: Add support for magnetometer.
From: Marek Belisko @ 2014-01-25 21:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390685343-11663-1-git-send-email-marek@goldelico.com>

Signed-off-by: NeilBrown <neilb@suse.de>
---
 arch/arm/boot/dts/omap3-gta04.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 151ed3b..ea1b94d 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -100,6 +100,12 @@
 			regulator-max-microvolt = <3150000>;
 		};
 	};
+
+	/* compass aka magnetometer */
+	hmc5843 at 1e {
+		compatible = "honeywell,hmc5843";
+		reg = <0x1e>;
+	};
 };
 
 #include "twl4030.dtsi"
-- 
1.8.3.2

^ permalink raw reply related

* [PATCH 7/9] ARM: dts: omap3-gta04: Add touchscreen properties.
From: Marek Belisko @ 2014-01-25 21:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390685343-11663-1-git-send-email-marek@goldelico.com>

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 arch/arm/boot/dts/omap3-gta04.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index f72e408..151ed3b 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -150,6 +150,16 @@
 			reg = <0x4>;
 		};
 	};
+
+	/* touchscreen */
+	tsc2007 at 48 {
+		compatible = "ti,tsc2007";
+		reg = <0x48>;
+		interrupt-parent = <&gpio6>;
+		interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+		gpios = <&gpio6 0 GPIO_ACTIVE_LOW>;
+		ti,x-plate-ohms = <600>;
+	};
 };
 
 &i2c3 {
-- 
1.8.3.2

^ permalink raw reply related

* [PATCH 6/9] ARM: dts: omap3-gta04: Add twl4030 charger.
From: Marek Belisko @ 2014-01-25 21:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390685343-11663-1-git-send-email-marek@goldelico.com>

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 arch/arm/boot/dts/omap3-gta04.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index a924a843..f72e408 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -198,3 +198,7 @@
 	pinctrl-0 = <&uart3_pins>;
 };
 
+&charger {
+	bb_uvolt = <3200000>;
+	bb_uamp = <150>;
+};
-- 
1.8.3.2

^ permalink raw reply related

* [PATCH 5/9] ARM: dts: omap3-gta04: Add basic sound support.
From: Marek Belisko @ 2014-01-25 21:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390685343-11663-1-git-send-email-marek@goldelico.com>

Signed-off-by: NeilBrown <neilb@suse.de>
---
 arch/arm/boot/dts/omap3-gta04.dts | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 7e09410..a924a843 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -36,6 +36,14 @@
 			gpio-key,wakeup;
 		};
 	};
+
+	sound {
+		compatible = "ti,omap-twl4030";
+		ti,model = "gta04";
+
+		ti,mcbsp = <&mcbsp2>;
+		ti,codec = <&twl_audio>;
+	};
 };
 
 &omap3_pmx_core {
@@ -79,6 +87,13 @@
 		reg = <0x48>;
 		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
 		interrupt-parent = <&intc>;
+
+		twl_audio: audio {
+			compatible = "ti,twl4030-audio";
+			codec {
+			};
+		};
+
 		vaux4: regulator-vaux4 {
 			compatible = "ti,twl4030-vaux4";
 			regulator-min-microvolt = <2800000>;
-- 
1.8.3.2

^ permalink raw reply related

* [PATCH 4/9] ARM: dts: omap3-gta04: Enable mmc2 for wifi.
From: Marek Belisko @ 2014-01-25 21:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390685343-11663-1-git-send-email-marek@goldelico.com>

From: NeilBrown <neilb@suse.de>

This requires vaux4.

Reset line isn't used yet, so wifi isn't reliable.
But it does work once per boot.

Signed-off-by: NeilBrown <neilb@suse.de>
---
 arch/arm/boot/dts/omap3-gta04.dts | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 6011151..7e09410 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -79,6 +79,11 @@
 		reg = <0x48>;
 		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
 		interrupt-parent = <&intc>;
+		vaux4: regulator-vaux4 {
+			compatible = "ti,twl4030-vaux4";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <3150000>;
+		};
 	};
 };
 
@@ -154,7 +159,9 @@
 };
 
 &mmc2 {
-	status = "disabled";
+	vmmc-supply = <&vaux4>;
+	bus-width = <4>;
+	ti,non-removable;
 };
 
 &mmc3 {
-- 
1.8.3.2

^ permalink raw reply related

* [PATCH 3/9] ARM: dts: omap3-gta04: Fix mmc1 properties.
From: Marek Belisko @ 2014-01-25 21:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390685343-11663-1-git-send-email-marek@goldelico.com>

Does not have an aux supply, and must be non-removable.

Otherwise it is removed during suspend and filesystem gets confused.

Signed-off-by: NeilBrown <neilb@suse.de>
---
 arch/arm/boot/dts/omap3-gta04.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index e315675..6011151 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -149,8 +149,8 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc1_pins>;
 	vmmc-supply = <&vmmc1>;
-	vmmc_aux-supply = <&vsim>;
 	bus-width = <4>;
+	ti,non-removable;
 };
 
 &mmc2 {
-- 
1.8.3.2

^ permalink raw reply related

* [PATCH 2/9] ARM: dts: omap3-gta04: Add bma180 accelerometer.
From: Marek Belisko @ 2014-01-25 21:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390685343-11663-1-git-send-email-marek@goldelico.com>

From: NeilBrown <neilb@suse.de>

Signed-off-by: NeilBrown <neilb@suse.de>
---
 arch/arm/boot/dts/omap3-gta04.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 9d37184..e315675 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -94,6 +94,14 @@
 		reg = <0x77>;
 	};
 
+	/* accelerometer */
+	bma180 at 41 {
+		compatible = "bosch,bma180";
+		reg = <0x41>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
 	/* leds */
 	tca6507 at 45 {
 		compatible = "ti,tca6507";
-- 
1.8.3.2

^ permalink raw reply related

* [PATCH 1/9] ARM: dts: omap3-gta04: Fix 'aux' gpio key flags.
From: Marek Belisko @ 2014-01-25 21:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390685343-11663-1-git-send-email-marek@goldelico.com>

From: NeilBrown <neilb@suse.de>

It should be ACTIVE_HIGH.

Signed-off-by: NeilBrown <neilb@suse.de>
---
 arch/arm/boot/dts/omap3-gta04.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index b9b55c9..9d37184 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -32,7 +32,7 @@
 		aux-button {
 			label = "aux";
 			linux,code = <169>;
-			gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+			gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
 			gpio-key,wakeup;
 		};
 	};
-- 
1.8.3.2

^ permalink raw reply related

* [PATCH 0/9] ARM: dts: omap3-gta04: Various devicetree updates.
From: Marek Belisko @ 2014-01-25 21:28 UTC (permalink / raw)
  To: linux-arm-kernel

This pathes fix some wrong property issues and add some new devices to
devicetree. This was tested on linux-next (next-20140124).

Marek Belisko (6):
  ARM: dts: omap3-gta04: Fix mmc1 properties.
  ARM: dts: omap3-gta04: Add basic sound support.
  ARM: dts: omap3-gta04: Add twl4030 charger.
  ARM: dts: omap3-gta04: Add touchscreen properties.
  ARM: dts: omap3-gta04: Add support for magnetometer.
  ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid
    problems with booting.

NeilBrown (3):
  ARM: dts: omap3-gta04: Fix 'aux' gpio key flags.
  ARM: dts: omap3-gta04: Add bma180 accelerometer.
  ARM: dts: omap3-gta04: Enable mmc2 for wifi.

 arch/arm/boot/dts/omap3-gta04.dts | 58 ++++++++++++++++++++++++++++++++++++---
 1 file changed, 54 insertions(+), 4 deletions(-)

-- 
1.8.3.2

^ permalink raw reply

* [PATCH RESEND TAKE 3] clk: si5351: remove variant from platform_data
From: Sebastian Hesselbarth @ 2014-01-25 20:48 UTC (permalink / raw)
  To: linux-arm-kernel

Commit 9807362bfe1748d9bb48eecb9261f1b1aaafea1c
  "clk: si5351: declare all device IDs for module loading"
removed the common i2c_device_id and introduced new ones for each variant
of the clock generator. Instead of exploiting that information in the driver,
it still depends on platform_data passing the chips .variant.

This removes the now redundant .variant from the platform_data and puts it in
i2c_device_id's .driver_data instead.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Mike,

this is the patch I mentioned during ARM summit ;). Still applies to
pre-v3.14-rc1 cleanly. Maybe it is time to take it now?

Cc: Mike Turquette <mturquette@linaro.org>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/clk/clk-si5351.c             |   28 ++++++++++++----------------
 drivers/clk/clk-si5351.h             |   14 ++++++++++++++
 include/linux/platform_data/si5351.h |   16 ----------------
 3 files changed, 26 insertions(+), 32 deletions(-)

diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index c50e837..b95aa09 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -1111,11 +1111,11 @@ static const struct of_device_id si5351_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, si5351_dt_ids);
 
-static int si5351_dt_parse(struct i2c_client *client)
+static int si5351_dt_parse(struct i2c_client *client,
+			   enum si5351_variant variant)
 {
 	struct device_node *child, *np = client->dev.of_node;
 	struct si5351_platform_data *pdata;
-	const struct of_device_id *match;
 	struct property *prop;
 	const __be32 *p;
 	int num = 0;
@@ -1124,15 +1124,10 @@ static int si5351_dt_parse(struct i2c_client *client)
 	if (np == NULL)
 		return 0;
 
-	match = of_match_node(si5351_dt_ids, np);
-	if (match == NULL)
-		return -EINVAL;
-
 	pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
 	if (!pdata)
 		return -ENOMEM;
 
-	pdata->variant = (enum si5351_variant)match->data;
 	pdata->clk_xtal = of_clk_get(np, 0);
 	if (!IS_ERR(pdata->clk_xtal))
 		clk_put(pdata->clk_xtal);
@@ -1163,7 +1158,7 @@ static int si5351_dt_parse(struct i2c_client *client)
 			pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
 			break;
 		case 1:
-			if (pdata->variant != SI5351_VARIANT_C) {
+			if (variant != SI5351_VARIANT_C) {
 				dev_err(&client->dev,
 					"invalid parent %d for pll %d\n",
 					val, num);
@@ -1187,7 +1182,7 @@ static int si5351_dt_parse(struct i2c_client *client)
 		}
 
 		if (num >= 8 ||
-		    (pdata->variant == SI5351_VARIANT_A3 && num >= 3)) {
+		    (variant == SI5351_VARIANT_A3 && num >= 3)) {
 			dev_err(&client->dev, "invalid clkout %d\n", num);
 			return -EINVAL;
 		}
@@ -1226,7 +1221,7 @@ static int si5351_dt_parse(struct i2c_client *client)
 					SI5351_CLKOUT_SRC_XTAL;
 				break;
 			case 3:
-				if (pdata->variant != SI5351_VARIANT_C) {
+				if (variant != SI5351_VARIANT_C) {
 					dev_err(&client->dev,
 						"invalid parent %d for clkout %d\n",
 						val, num);
@@ -1307,6 +1302,7 @@ static int si5351_dt_parse(struct i2c_client *client)
 static int si5351_i2c_probe(struct i2c_client *client,
 			    const struct i2c_device_id *id)
 {
+	enum si5351_variant variant = (enum si5351_variant)id->driver_data;
 	struct si5351_platform_data *pdata;
 	struct si5351_driver_data *drvdata;
 	struct clk_init_data init;
@@ -1315,7 +1311,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
 	u8 num_parents, num_clocks;
 	int ret, n;
 
-	ret = si5351_dt_parse(client);
+	ret = si5351_dt_parse(client, variant);
 	if (ret)
 		return ret;
 
@@ -1331,7 +1327,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
 
 	i2c_set_clientdata(client, drvdata);
 	drvdata->client = client;
-	drvdata->variant = pdata->variant;
+	drvdata->variant = variant;
 	drvdata->pxtal = pdata->clk_xtal;
 	drvdata->pclkin = pdata->clk_clkin;
 
@@ -1568,10 +1564,10 @@ static int si5351_i2c_probe(struct i2c_client *client,
 }
 
 static const struct i2c_device_id si5351_i2c_ids[] = {
-	{ "si5351a", 0 },
-	{ "si5351a-msop", 0 },
-	{ "si5351b", 0 },
-	{ "si5351c", 0 },
+	{ "si5351a", SI5351_VARIANT_A },
+	{ "si5351a-msop", SI5351_VARIANT_A3 },
+	{ "si5351b", SI5351_VARIANT_B },
+	{ "si5351c", SI5351_VARIANT_C },
 	{ }
 };
 MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
index c0dbf26..4d0746b 100644
--- a/drivers/clk/clk-si5351.h
+++ b/drivers/clk/clk-si5351.h
@@ -153,4 +153,18 @@
 #define  SI5351_XTAL_ENABLE			(1<<6)
 #define  SI5351_MULTISYNTH_ENABLE		(1<<4)
 
+/**
+ * enum si5351_variant - SiLabs Si5351 chip variant
+ * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
+ * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
+ * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
+ * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
+ */
+enum si5351_variant {
+	SI5351_VARIANT_A = 1,
+	SI5351_VARIANT_A3 = 2,
+	SI5351_VARIANT_B = 3,
+	SI5351_VARIANT_C = 4,
+};
+
 #endif
diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h
index 5433439..a947ab8 100644
--- a/include/linux/platform_data/si5351.h
+++ b/include/linux/platform_data/si5351.h
@@ -8,20 +8,6 @@
 struct clk;
 
 /**
- * enum si5351_variant - SiLabs Si5351 chip variant
- * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
- * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
- * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
- * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
- */
-enum si5351_variant {
-	SI5351_VARIANT_A = 1,
-	SI5351_VARIANT_A3 = 2,
-	SI5351_VARIANT_B = 3,
-	SI5351_VARIANT_C = 4,
-};
-
-/**
  * enum si5351_pll_src - Si5351 pll clock source
  * @SI5351_PLL_SRC_DEFAULT: default, do not change eeprom config
  * @SI5351_PLL_SRC_XTAL: pll source clock is XTAL input
@@ -115,14 +101,12 @@ struct si5351_clkout_config {
 
 /**
  * struct si5351_platform_data - Platform data for the Si5351 clock driver
- * @variant: Si5351 chip variant
  * @clk_xtal: xtal input clock
  * @clk_clkin: clkin input clock
  * @pll_src: array of pll source clock setting
  * @clkout: array of clkout configuration
  */
 struct si5351_platform_data {
-	enum si5351_variant variant;
 	struct clk *clk_xtal;
 	struct clk *clk_clkin;
 	enum si5351_pll_src pll_src[2];
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH v4 01/18] ARM: Introduce atomic MMIO modify
From: Jason Cooper @ 2014-01-25 20:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390431915-5115-2-git-send-email-ezequiel.garcia@free-electrons.com>

Russell,

On Wed, Jan 22, 2014 at 08:04:58PM -0300, Ezequiel Garcia wrote:
> Some SoC have MMIO regions that are shared across orthogonal
> subsystems. This commit implements a possible solution for the
> thread-safe access of such regions through a spinlock-protected API.
> 
> Concurrent access is protected with a single spinlock for the
> entire MMIO address space. While this protects shared-registers,
> it also serializes access to unrelated/unshared registers.
> 
> We add relaxed and non-relaxed variants, by using writel_relaxed and writel,
> respectively. The rationale for this is that some users may not require
> register write completion but only thread-safe access to a register.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
>  arch/arm/include/asm/io.h |  6 ++++++
>  arch/arm/kernel/io.c      | 35 +++++++++++++++++++++++++++++++++++
>  2 files changed, 41 insertions(+)

This has been in your patch tracker for a while:

  http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7930/1

When you requested Acks, we sent them:

  http://www.spinics.net/lists/arm-kernel/msg300250.html

Is there anything more you need from us?  The rest of this series
depends on this patch.  Could you place it in a topic branch so we can
base the rest of the series off of it?  Or, if you prefer, Ack it and
drop it from your patch tracker?  I'm fine either way.

thx,

Jason.

> 
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index fbeb39c..8aa4cca 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -38,6 +38,12 @@
>  #define isa_bus_to_virt phys_to_virt
>  
>  /*
> + * Atomic MMIO-wide IO modify
> + */
> +extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
> +extern void atomic_io_modify_relaxed(void __iomem *reg, u32 mask, u32 set);
> +
> +/*
>   * Generic IO read/write.  These perform native-endian accesses.  Note
>   * that some architectures will want to re-define __raw_{read,write}w.
>   */
> diff --git a/arch/arm/kernel/io.c b/arch/arm/kernel/io.c
> index dcd5b4d..9203cf8 100644
> --- a/arch/arm/kernel/io.c
> +++ b/arch/arm/kernel/io.c
> @@ -1,6 +1,41 @@
>  #include <linux/export.h>
>  #include <linux/types.h>
>  #include <linux/io.h>
> +#include <linux/spinlock.h>
> +
> +static DEFINE_RAW_SPINLOCK(__io_lock);
> +
> +/*
> + * Generic atomic MMIO modify.
> + *
> + * Allows thread-safe access to registers shared by unrelated subsystems.
> + * The access is protected by a single MMIO-wide lock.
> + */
> +void atomic_io_modify_relaxed(void __iomem *reg, u32 mask, u32 set)
> +{
> +	unsigned long flags;
> +	u32 value;
> +
> +	raw_spin_lock_irqsave(&__io_lock, flags);
> +	value = readl_relaxed(reg) & ~mask;
> +	value |= (set & mask);
> +	writel_relaxed(value, reg);
> +	raw_spin_unlock_irqrestore(&__io_lock, flags);
> +}
> +EXPORT_SYMBOL(atomic_io_modify_relaxed);
> +
> +void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
> +{
> +	unsigned long flags;
> +	u32 value;
> +
> +	raw_spin_lock_irqsave(&__io_lock, flags);
> +	value = readl_relaxed(reg) & ~mask;
> +	value |= (set & mask);
> +	writel(value, reg);
> +	raw_spin_unlock_irqrestore(&__io_lock, flags);
> +}
> +EXPORT_SYMBOL(atomic_io_modify);
>  
>  /*
>   * Copy data from IO memory space to "real" memory space.
> -- 
> 1.8.1.5
> 

^ permalink raw reply

* GPIO triggers kernel reboot
From: Mehaffey, John @ 2014-01-25 20:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <371E240E6FC1D44DA5E51EE9DCDCB7845E5EA0A1@NA-MBX-01.mgc.mentorg.com>

> -----Original Message-----
> From: linux-embedded-owner at vger.kernel.org 
> [mailto:linux-embedded-owner at vger.kernel.org] On Behalf Of Heiko 
> Schocher
> Sent: Saturday, January 25, 2014 8:03 AM
> To: linux-embedded at vger.kernel.org
> Cc: Wolfgang Denk; linux-arm-kernel at lists.infradead.org
> Subject: GPIO triggers kernel reboot
> 
> Hello all,
> 
> is it possible to reboot current mainline kernel triggered from a GPIO in kernel space?
> 
> If not, how can be done this, so that it has a chance to go into mainline?
> 
> Thanks for any suggestions
> 
> bye,
> Heiko

Hi Heiko,
Call kexec() from the GPIO driver.
It will take some effort to get it right :)

Or if a simple reboot is all that you want, examine the several reboot APIs in kernel/reboot.c

Sincerely,
John Mehaffey
Principal Engineer, Automotive
Mentor Graphics
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-embedded" in the body of a message to majordomo at vger.kernel.org 
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo at vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [RFC PATCH V2 1/4] pci: APM X-Gene PCIe controller driver
From: Arnd Bergmann @ 2014-01-25 20:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACoXjc=-JtpiM3m4DSA_DeOxYr3sihGGf4FSaJ2yC08rpm6ANQ@mail.gmail.com>

On Friday 24 January 2014 13:28:22 Tanmay Inamdar wrote:
> On Thu, Jan 16, 2014 at 5:10 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
> > On Wed, Jan 15, 2014 at 4:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Wednesday 15 January 2014, Tanmay Inamdar wrote:

> >>
> >>> +static void xgene_pcie_poll_linkup(struct xgene_pcie_port *port, u32 *lanes)
> >>> +{
> >>> +     void *csr_base = port->csr_base;
> >>> +     u32 val32;
> >>> +     u64 start_time, time;
> >>> +
> >>> +     /*
> >>> +      * A component enters the LTSSM Detect state within
> >>> +      * 20ms of the end of fundamental core reset.
> >>> +      */
> >>> +     msleep(XGENE_LTSSM_DETECT_WAIT);
> >>> +     port->link_up = 0;
> >>> +     start_time = jiffies;
> >>> +     do {
> >>> +             val32 = readl(csr_base + PCIECORE_CTLANDSTATUS);
> >>> +             if (val32 & LINK_UP_MASK) {
> >>> +                     port->link_up = 1;
> >>> +                     port->link_speed = PIPE_PHY_RATE_RD(val32);
> >>> +                     val32 = readl(csr_base + BRIDGE_STATUS_0);
> >>> +                     *lanes = val32 >> 26;
> >>> +             }
> >>> +             time = jiffies_to_msecs(jiffies - start_time);
> >>> +     } while ((!port->link_up) || (time <= XGENE_LTSSM_L0_WAIT));
> >>> +}
> >>
> >> Maybe another msleep() in the loop? It seems weird to first do an
> >> unconditional sleep but then busy-wait for the result.
> >
> > ok.
> 
> This loop can execute for maximum 4 msec. So putting msleep(1) won't
> get us much.
 
4 msec is still quite a long time for a busy loop that can be spent doing
useful work in another thread.

> >>
> >> Another general note: Your "compatible" strings are rather unspecific.
> >> Do you have a version number for this IP block? I suppose that it's related
> >> to one that has been used in other chips before, or will be used in future
> >> chips, if it's not actually licensed from some other company.
> >
> > I will have to check this.
> >
> 
> We have decided to stick with current compatible string for now.

Can you elaborate on your reasoning? Does this mean X-Gene is a one-off
product and you won't be doing any new chips based on the same hardware
components?

	Arnd

^ permalink raw reply

* GPIO triggers kernel reboot
From: Mehaffey, John @ 2014-01-25 19:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52E3E031.6040709@denx.de>

> -----Original Message-----
> From: linux-embedded-owner at vger.kernel.org [mailto:linux-embedded-owner at vger.kernel.org] On Behalf Of Heiko Schocher
> Sent: Saturday, January 25, 2014 8:03 AM
> To: linux-embedded at vger.kernel.org
> Cc: Wolfgang Denk; linux-arm-kernel at lists.infradead.org
> Subject: GPIO triggers kernel reboot
> 
> Hello all,
> 
> is it possible to reboot current mainline kernel triggered from a GPIO in kernel space?
> 
> If not, how can be done this, so that it has a chance to go into mainline?
> 
> Thanks for any suggestions
> 
> bye,
> Heiko

Hi Heiko,
Call kexec() from the GPIO driver.
It will take some effort to get it right :)

Sincerely,
John Mehaffey
Principal Engineer, Automotive
Mentor Graphics
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo at vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH 11/11] pinctrl: mvebu: dove: use global register regmap
From: Sebastian Hesselbarth @ 2014-01-25 18:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390674856-4993-1-git-send-email-sebastian.hesselbarth@gmail.com>

Now that we have a regmap for global registers, get rid of the last
remaining hardcoded physical addresses. While at it, also remove
DOVE_ prefix from those macros.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-dove.c | 128 ++++++++++++++++-------------------
 1 file changed, 60 insertions(+), 68 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c b/drivers/pinctrl/mvebu/pinctrl-dove.c
index 32cb3bbf2e18..90b6e7279ff9 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -30,21 +30,6 @@
 #define PMU_REGS_OFFS			0xd802c
 #define GC_REGS_OFFS			0xe802c
 
-#define DOVE_SB_REGS_VIRT_BASE		IOMEM(0xfde00000)
-#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_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_ON_AU1		BIT(0)
-#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)
-
 /* MPP Base registers */
 #define PMU_MPP_GENERAL_CTRL	0x10
 #define  AU0_AC97_SEL		BIT(16)
@@ -62,6 +47,19 @@
 #define PMU_SIGNAL_SELECT_0	0x00
 #define PMU_SIGNAL_SELECT_1	0x04
 
+/* Global Config regmap registers */
+#define GLOBAL_CONFIG_1		0
+#define  TWSI_ENABLE_OPTION1	BIT(7)
+#define GLOBAL_CONFIG_2		1
+#define  TWSI_ENABLE_OPTION2	BIT(20)
+#define  TWSI_ENABLE_OPTION3	BIT(21)
+#define  TWSI_OPTION3_GPIO	BIT(22)
+#define SSP_CTRL_STATUS_1	2
+#define  SSP_ON_AU1		BIT(0)
+#define MPP_GENERAL_CONFIG	4
+#define  AU1_SPDIFO_GPIO_EN	BIT(1)
+#define  NAND_GPIO_EN		BIT(0)
+
 #define MPPS_PER_REG	8
 #define MPP_BITS	4
 #define MPP_MASK	0xf
@@ -187,9 +185,10 @@ static int dove_mpp4_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
 static int dove_nand_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 			      unsigned long *config)
 {
-	unsigned long gmpp = readl(DOVE_MPP_GENERAL_VIRT_BASE);
+	unsigned int gmpp;
 
-	*config = ((gmpp & DOVE_NAND_GPIO_EN) != 0);
+	regmap_read(gconfmap, MPP_GENERAL_CONFIG, &gmpp);
+	*config = ((gmpp & NAND_GPIO_EN) != 0);
 
 	return 0;
 }
@@ -197,14 +196,9 @@ static int dove_nand_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 static int dove_nand_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
 			      unsigned long config)
 {
-	unsigned long gmpp = readl(DOVE_MPP_GENERAL_VIRT_BASE);
-
-	gmpp &= ~DOVE_NAND_GPIO_EN;
-	if (config)
-		gmpp |= DOVE_NAND_GPIO_EN;
-
-	writel(gmpp, DOVE_MPP_GENERAL_VIRT_BASE);
-
+	regmap_update_bits(gconfmap, MPP_GENERAL_CONFIG,
+			   NAND_GPIO_EN,
+			   (config) ? NAND_GPIO_EN : 0);
 	return 0;
 }
 
@@ -234,19 +228,23 @@ static int dove_audio0_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
 static int dove_audio1_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 				unsigned long *config)
 {
-	unsigned long mpp4 = readl(mpp4_base + MPP_CTRL4);
-	unsigned long sspc1 = readl(DOVE_SSP_CTRL_STATUS_1);
-	unsigned long gmpp = readl(DOVE_MPP_GENERAL_VIRT_BASE);
-	unsigned long gcfg2 = readl(DOVE_GLOBAL_CONFIG_2);
+	unsigned int mpp4 = readl(mpp4_base + MPP_CTRL4);
+	unsigned int sspc1;
+	unsigned int gmpp;
+	unsigned int gcfg2;
+
+	regmap_read(gconfmap, SSP_CTRL_STATUS_1, &sspc1);
+	regmap_read(gconfmap, MPP_GENERAL_CONFIG, &gmpp);
+	regmap_read(gconfmap, GLOBAL_CONFIG_2, &gcfg2);
 
 	*config = 0;
 	if (mpp4 & AU1_GPIO_SEL)
 		*config |= BIT(3);
-	if (sspc1 & DOVE_SSP_ON_AU1)
+	if (sspc1 & SSP_ON_AU1)
 		*config |= BIT(2);
-	if (gmpp & DOVE_AU1_SPDIFO_GPIO_EN)
+	if (gmpp & AU1_SPDIFO_GPIO_EN)
 		*config |= BIT(1);
-	if (gcfg2 & DOVE_TWSI_OPTION3_GPIO)
+	if (gcfg2 & TWSI_OPTION3_GPIO)
 		*config |= BIT(0);
 
 	/* SSP/TWSI only if I2S1 not set*/
@@ -261,32 +259,22 @@ static int dove_audio1_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 static int dove_audio1_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
 				unsigned long config)
 {
-	unsigned long mpp4 = readl(mpp4_base + MPP_CTRL4);
-	unsigned long sspc1 = readl(DOVE_SSP_CTRL_STATUS_1);
-	unsigned long gmpp = readl(DOVE_MPP_GENERAL_VIRT_BASE);
-	unsigned long gcfg2 = readl(DOVE_GLOBAL_CONFIG_2);
+	unsigned int mpp4 = readl(mpp4_base + MPP_CTRL4);
 
-	/*
-	 * clear all audio1 related bits before configure
-	 */
-	gcfg2 &= ~DOVE_TWSI_OPTION3_GPIO;
-	gmpp &= ~DOVE_AU1_SPDIFO_GPIO_EN;
-	sspc1 &= ~DOVE_SSP_ON_AU1;
 	mpp4 &= ~AU1_GPIO_SEL;
-
-	if (config & BIT(0))
-		gcfg2 |= DOVE_TWSI_OPTION3_GPIO;
-	if (config & BIT(1))
-		gmpp |= DOVE_AU1_SPDIFO_GPIO_EN;
-	if (config & BIT(2))
-		sspc1 |= DOVE_SSP_ON_AU1;
 	if (config & BIT(3))
 		mpp4 |= AU1_GPIO_SEL;
-
 	writel(mpp4, mpp4_base + MPP_CTRL4);
-	writel(sspc1, DOVE_SSP_CTRL_STATUS_1);
-	writel(gmpp, DOVE_MPP_GENERAL_VIRT_BASE);
-	writel(gcfg2, DOVE_GLOBAL_CONFIG_2);
+
+	regmap_update_bits(gconfmap, SSP_CTRL_STATUS_1,
+			   SSP_ON_AU1,
+			   (config & BIT(2)) ? SSP_ON_AU1 : 0);
+	regmap_update_bits(gconfmap, MPP_GENERAL_CONFIG,
+			   AU1_SPDIFO_GPIO_EN,
+			   (config & BIT(1)) ? AU1_SPDIFO_GPIO_EN : 0);
+	regmap_update_bits(gconfmap, GLOBAL_CONFIG_2,
+			   TWSI_OPTION3_GPIO,
+			   (config & BIT(0)) ? TWSI_OPTION3_GPIO : 0);
 
 	return 0;
 }
@@ -334,15 +322,18 @@ static int dove_audio1_ctrl_gpio_dir(struct mvebu_mpp_ctrl *ctrl, u8 pid,
 static int dove_twsi_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 			      unsigned long *config)
 {
-	unsigned long gcfg1 = readl(DOVE_GLOBAL_CONFIG_1);
-	unsigned long gcfg2 = readl(DOVE_GLOBAL_CONFIG_2);
+	unsigned int gcfg1;
+	unsigned int gcfg2;
+
+	regmap_read(gconfmap, GLOBAL_CONFIG_1, &gcfg1);
+	regmap_read(gconfmap, GLOBAL_CONFIG_2, &gcfg2);
 
 	*config = 0;
-	if (gcfg1 & DOVE_TWSI_ENABLE_OPTION1)
+	if (gcfg1 & TWSI_ENABLE_OPTION1)
 		*config = 1;
-	else if (gcfg2 & DOVE_TWSI_ENABLE_OPTION2)
+	else if (gcfg2 & TWSI_ENABLE_OPTION2)
 		*config = 2;
-	else if (gcfg2 & DOVE_TWSI_ENABLE_OPTION3)
+	else if (gcfg2 & TWSI_ENABLE_OPTION3)
 		*config = 3;
 
 	return 0;
@@ -351,26 +342,27 @@ static int dove_twsi_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 static int dove_twsi_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
 				unsigned long config)
 {
-	unsigned long gcfg1 = readl(DOVE_GLOBAL_CONFIG_1);
-	unsigned long gcfg2 = readl(DOVE_GLOBAL_CONFIG_2);
-
-	gcfg1 &= ~DOVE_TWSI_ENABLE_OPTION1;
-	gcfg2 &= ~(DOVE_TWSI_ENABLE_OPTION2 | DOVE_TWSI_ENABLE_OPTION3);
+	unsigned int gcfg1 = 0;
+	unsigned int gcfg2 = 0;
 
 	switch (config) {
 	case 1:
-		gcfg1 |= DOVE_TWSI_ENABLE_OPTION1;
+		gcfg1 = TWSI_ENABLE_OPTION1;
 		break;
 	case 2:
-		gcfg2 |= DOVE_TWSI_ENABLE_OPTION2;
+		gcfg2 = TWSI_ENABLE_OPTION2;
 		break;
 	case 3:
-		gcfg2 |= DOVE_TWSI_ENABLE_OPTION3;
+		gcfg2 = TWSI_ENABLE_OPTION3;
 		break;
 	}
 
-	writel(gcfg1, DOVE_GLOBAL_CONFIG_1);
-	writel(gcfg2, DOVE_GLOBAL_CONFIG_2);
+	regmap_update_bits(gconfmap, GLOBAL_CONFIG_1,
+			   TWSI_ENABLE_OPTION1,
+			   gcfg1);
+	regmap_update_bits(gconfmap, GLOBAL_CONFIG_2,
+			   TWSI_ENABLE_OPTION2 | TWSI_ENABLE_OPTION3,
+			   gcfg2);
 
 	return 0;
 }
-- 
1.8.5.2

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox