Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Sudeep Holla @ 2014-02-10 10:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAJuA9agcpbKYocaQUBr2-VCXcXAo3r3urFF=+G_+ib2jCZqvwg@mail.gmail.com>

On 08/02/14 06:47, Thomas Abraham wrote:
> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 17:37, Nishanth Menon wrote:
>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> [...]
>>
>>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>>> frequencies and the boost parameters are exposed through sysfs)
>>>
>>> That will be a different problem -> as currently every single
>>> frequency in the cpufreq list has ability to be marked as boost
>>> frequency - if userspace does not maintain that, then, IMHO, fix the
>>> userspace :D
>>>
>>
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
>> the list of frequencies based on the state of the boost feature at anytime.
> 
> The list of frequencies in
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
> does not change based in the state of the boost feature (enabled or
> disabled). But the scaling_max_frequency and scaling_min_frequency are
> updated based on the set of available + boost frequencies available.
> 

Ah ok, sorry just glanced the code and misunderstood it. It make sense to update
only max_frequency.

Regards,
Sudeep

^ permalink raw reply

* [PATCH] staging: drm/imx: remove an unnecessary local variable
From: Russell King - ARM Linux @ 2014-02-10 10:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52F8AD31.4000109@freescale.com>

On Mon, Feb 10, 2014 at 06:42:57PM +0800, Liu Ying wrote:
> On 02/10/2014 06:29 PM, Russell King - ARM Linux wrote:
> > On Mon, Feb 10, 2014 at 06:29:45PM +0800, Liu Ying wrote:
> >> This patch removes an unnecessary local variable defined
> >> in the function imx_drm_driver_unload() so as to fix the
> >> following build warning.
> >>
> >> drivers/staging/imx-drm/imx-drm-core.c: \
> >> In function ?imx_drm_driver_unload?:
> >> drivers/staging/imx-drm/imx-drm-core.c:87:25: \
> >> warning: unused variable ?imxdrm? [-Wunused-variable]
> > 
> > Already-Naked-by: me.  This is required by later patches in the series
> > posted earlier.
> > 
> 
> Sorry. Did you mean that you have already got a fix for this?

No, I mean patches which come after the three which Greg has recently
merged - one of which removes users of the above variable - reintroduce
users of this variable, so deleting the variable will break those patches.
It was also pointless to remove it and then bring it back in the series.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

^ permalink raw reply

* [PATCH] arm: add DSB after icache flush in __flush_icache_all()
From: Catalin Marinas @ 2014-02-10 10:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52F71BAD.80607@gmail.com>

On Sun, Feb 09, 2014 at 06:09:49AM +0000, Dirk Behme wrote:
> Am 05.02.2014 10:33, schrieb Vinayak Kale:
> > Add DSB after icache flush to complete the cache maintenance operation.
> >
> > Signed-off-by: Vinayak Kale <vkale@apm.com>
> 
> Should this go to -stable, too?
> 
> I haven't looked into the details, but at least it seems to apply 
> cleanly on a 3.8 kernel.

It should. For the similar arm64 fix I added 'cc: stable' myself (commit
5044bad43ee57).

Thanks.

-- 
Catalin

^ permalink raw reply

* [PATCH] staging: drm/imx: remove an unnecessary local variable
From: Liu Ying @ 2014-02-10 10:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140210102906.GP26684@n2100.arm.linux.org.uk>

On 02/10/2014 06:29 PM, Russell King - ARM Linux wrote:
> On Mon, Feb 10, 2014 at 06:29:45PM +0800, Liu Ying wrote:
>> This patch removes an unnecessary local variable defined
>> in the function imx_drm_driver_unload() so as to fix the
>> following build warning.
>>
>> drivers/staging/imx-drm/imx-drm-core.c: \
>> In function ?imx_drm_driver_unload?:
>> drivers/staging/imx-drm/imx-drm-core.c:87:25: \
>> warning: unused variable ?imxdrm? [-Wunused-variable]
> 
> Already-Naked-by: me.  This is required by later patches in the series
> posted earlier.
> 

Sorry. Did you mean that you have already got a fix for this?

^ permalink raw reply

* [PATCH 09/17] spi: pl022: Simplify clock handling
From: Ulf Hansson @ 2014-02-10 10:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140204191947.GV22609@sirena.org.uk>

On 4 February 2014 20:19, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Feb 04, 2014 at 04:58:50PM +0100, Ulf Hansson wrote:
>> Make use of clk_prepare_enable and clk_disable_unprepare to simplify
>> code. No functional change.
>
> I went ahead and applied this since it looks good and seems like an
> unrelated cleanup to the runtime PM stuff which seems to be where the
> interdependencies are - thanks!  It's on a separate branch with the
> already applied change so if it does need to be cross merged we can do
> that easily or even drop the branch.

Thanks Mark, it seems like a good approach.

Kind regards
Ulf Hansson

^ permalink raw reply

* [PATCH] ARM: mm: report both sections from PMD
From: Catalin Marinas @ 2014-02-10 10:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140210102935.GC25305@arm.com>

On Mon, Feb 10, 2014 at 10:29:35AM +0000, Catalin Marinas wrote:
> On Sun, Feb 09, 2014 at 10:18:26PM +0000, Kees Cook wrote:
> > diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
> > index 1f7b1e13d945..ff1559f9200c 100644
> > --- a/arch/arm/mm/dump.c
> > +++ b/arch/arm/mm/dump.c
> > @@ -264,6 +264,9 @@ static void walk_pmd(struct pg_state *st, pud_t *pud, unsigned long start)
> >  			note_page(st, addr, 3, pmd_val(*pmd));
> >  		else
> >  			walk_pte(st, pmd, addr);
> > +
> > +		if (SECTION_SIZE < PMD_SIZE && pmd_sect(*pmd))
> > +			note_page(st, addr + SECTION_SIZE, 3, pmd_val(pmd[1]));
> 
> You can  use pmd_large() here as well.
> 
> But I think this function is broken (the "for" statement not shown
> here). The pmd_t is 32-bit with classic MMU and it uses pmd++ while the
> address grows by PMD_SIZE (two pmd_t entries).

Actually it's ok since PTRS_PER_PMD is 1, so it only goes through this
loop once.

But in your patch shouldn't you check for pmd_large(*(pmd+1))? The first
pmd is already caught by the 'if' statement.

-- 
Catalin

^ permalink raw reply

* [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree
From: Sudeep Holla @ 2014-02-10 10:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAJuA9agT4PC6YOmhCwKQ=58qaGEr1qSuhTpX57ro1pEuk++Miw@mail.gmail.com>

On 08/02/14 05:10, Thomas Abraham wrote:
> On Fri, Feb 7, 2014 at 9:31 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 15:19, Thomas Abraham wrote:
>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>
>>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>>> support for CPU boost mode. This patch adds support for finding available
>>> boost frequencies from device tree and marking them as usable in boost mode.
>>>
>>> Cc: Nishanth Menon <nm@ti.com>
>>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>> ---
>>>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
>>>  1 file changed, 33 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>>> index fa41874..b636826 100644
>>> --- a/drivers/base/power/opp.c
>>> +++ b/drivers/base/power/opp.c
>>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>>       struct device_opp *dev_opp;
>>>       struct dev_pm_opp *opp;
>>>       struct cpufreq_frequency_table *freq_table;
>>> -     int i = 0;
>>> +     int i = 0, j, len, ret;
>>> +     u32 *boost_freqs = NULL;
>>>
>>>       /* Pretend as if I am an updater */
>>>       mutex_lock(&dev_opp_list_lock);
>>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>>               return -ENOMEM;
>>>       }
>>>
>>> +     if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>>> +             if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>>> +                     dev_err(dev, "%s: invalid boost frequency\n", __func__);
>>> +                     ret = -EINVAL;
>>> +                     goto err_boost;
>>> +             }
>>> +
>>> +             boost_freqs = kzalloc(len, GFP_KERNEL);
>>> +             if (!boost_freqs) {
>>> +                     dev_warn(dev, "%s: no memory for boost freq table\n",
>>> +                                     __func__);
>>> +                     ret = -ENOMEM;
>>> +                     goto err_boost;
>>> +             }
>>> +             of_property_read_u32_array(dev->of_node, "boost-frequency",
>>> +                     boost_freqs, len / sizeof(u32));
>>> +     }
>>> +
>>>       list_for_each_entry(opp, &dev_opp->opp_list, node) {
>>>               if (opp->available) {
>>>                       freq_table[i].driver_data = i;
>>>                       freq_table[i].frequency = opp->rate / 1000;
>>> +                     for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>>> +                             if (boost_freqs[j] == freq_table[i].frequency) {
>>> +                                     freq_table[i].driver_data =
>>> +                                                     CPUFREQ_BOOST_FREQ;
>>> +                                     break;
>>> +                             }
>>> +                     }
>>>                       i++;
>>>               }
>>>       }
>> IIRC you had mentioned that the boost-opp was not limited to be a cpufreq, but
>> this change seems to be cpufreq only.
> 
> Yes, but as you have initiated the discussion on extending the OPP
> binding, this has been limited to cpufreq only. If the new OPP library
> has support for listing boost frequency, this can be migrated to the
> new OPP libaray.
> 

Fair enough, just wanted to check as I couldn't get the info following the
thread. I might have missed it.

Regards,
Sudeep

^ permalink raw reply

* [PATCH] backlight: add PWM dependencies
From: Thierry Reding @ 2014-02-10 10:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1391518634-6472-1-git-send-email-linus.walleij@linaro.org>

On Tue, Feb 04, 2014 at 01:57:14PM +0100, Linus Walleij wrote:
> In some compilations the LM3630A and LP855X backlight drivers
> fail like this:
> 
> drivers/built-in.o: In function `lm3630a_pwm_ctrl':
> drivers/video/backlight/lm3630a_bl.c:168: undefined reference to `pwm_config'
> drivers/video/backlight/lm3630a_bl.c:172: undefined reference to `pwm_disable'
> drivers/video/backlight/lm3630a_bl.c:170: undefined reference to `pwm_enable'
> drivers/built-in.o: In function `lp855x_pwm_ctrl':
> drivers/video/backlight/lp855x_bl.c:249: undefined reference to `pwm_config'
> drivers/video/backlight/lp855x_bl.c:253: undefined reference to `pwm_disable'
> drivers/video/backlight/lp855x_bl.c:251: undefined reference to `pwm_enable'
> 
> This is because both drivers depend on the PWM framework, so
> add this dependency to their Kconfig entries.
> 
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  drivers/video/backlight/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)

Hi Linus,

it seems like at least BACKLIGHT_LP8788 is missing a corresponding
dependency as well.

I have applied Sascha's patch to remove the obsolete HAVE_PWM symbol,
and this will fix at least the build issues. However it will also cause
the driver to fail at runtime because the pwm_*() functions won't work.

So I wonder if we should still apply this patch to make it clear that
PWM support is necessary to make the driver work. I guess the point is
somewhat moot because even if we had PWM enabled it could still happen
that no PWM driver is enabled to provide a PWM device... I guess it's
equally justifiable to leave that up to the defconfig.

Should we just drop this patch? Cc'ing Arnd who's commented on Jingoo's
alternate proposal.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/1b95b04c/attachment.sig>

^ permalink raw reply

* [PATCH 5/8] tty/serial: at91: add dtr control via gpio
From: Nicolas Ferre @ 2014-02-10 10:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACQ1gAjQi+g0=HcR9K0rBQxBUZ_cN783sCWx40P5Hec-BdRtVg@mail.gmail.com>

On 10/02/2014 11:24, Richard Genoud :
> 2014-02-07 16:21 GMT+01:00 Alexander Shiyan <shc_work@mail.ru>:
>> Hello.
>>
>> ???????,  7 ??????? 2014, 15:59 +01:00 ?? Richard Genoud <richard.genoud@gmail.com>:
>>> On sam9x5, the USART controller doesn't handle DTR/DSR/DCD/RI signals,
>>> so we have to control them via GPIO.
>>>
>>> This patch permits to use a GPIO to control the DTR signal.
>>>
>>> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
>>> ---
>> ...
>>> +     if (gpio_is_valid(atmel_port->gpio.dtr)) {
>>> +             if (mctrl & TIOCM_DTR)
>>> +                     gpio_set_value(atmel_port->gpio.dtr, 0);
>>> +             else
>>> +                     gpio_set_value(atmel_port->gpio.dtr, 1);
>>> +     }
>>
>> So, if you use GPIO for such purpose (here and in the other patches),
>> you should take and use GPIO active level from bindings.
>> It will make use of GPIO more flexible and deliver us from further special
>> possible bindings to declare the active level.
> Yes, I could do that. I'll have to change the alreday merged RTS
> binding so that it gets it's active level from DTS, but I don't think
> it's a problem, since it's not already in mainline.
> Linus, Nicolas, what do you think ?

Yes I agree. It is not used yet, so the sooner we move to this
specification, the better.

>> Actually, it would be good to have a separate unit for mctrl GPIOs,
>> which could be used for other drivers.
> good idea, I can add them in serial_core.c

That would be great. Thanks Richard!

Bye,
-- 
Nicolas Ferre

^ permalink raw reply

* [PATCH] ARM: zynq: Add waituart implementation
From: Michal Simek @ 2014-02-10 10:37 UTC (permalink / raw)
  To: linux-arm-kernel

Add missing waituart implementation.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---

 arch/arm/include/debug/zynq.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/include/debug/zynq.S b/arch/arm/include/debug/zynq.S
index f9aa974..0b762fa 100644
--- a/arch/arm/include/debug/zynq.S
+++ b/arch/arm/include/debug/zynq.S
@@ -42,6 +42,9 @@
 		.endm

 		.macro	waituart,rd,rx
+1001:		ldr	\rd, [\rx, #UART_SR_OFFSET]
+		tst	\rd, #UART_SR_TXEMPTY
+		beq	1001b
 		.endm

 		.macro	busyuart,rd,rx
--
1.8.2.3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/cc6785ff/attachment.sig>

^ permalink raw reply related

* [PATCH 08/17] spi: pl022: Fully gate clocks at request inactivity
From: Ulf Hansson @ 2014-02-10 10:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140204170746.GD22609@sirena.org.uk>

On 4 February 2014 18:07, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Feb 04, 2014 at 04:58:49PM +0100, Ulf Hansson wrote:
>> Use clk_disable_unprepare and clk_prepare_enable from the runtime PM
>> callbacks, to fully gate|ungate clocks. Potentially this will save more
>> power, depending on the clock tree for the current SOC.
>
> The same patch has already been applied (I noticed and fixed it while
> doing unrelated code review).

Sorry, didn't notice that.

Thanks!

Kind regards
Ulf Hansson

>
>>       pinctrl_pm_select_default_state(dev);
>> -     clk_enable(pl022->clk);
>> +     clk_prepare_enable(pl022->clk);
>
> Someone should really make this check errors though!

^ permalink raw reply

* [PATCH v4 8/8] ARM: dts: sun7i: Add ethernet alias for GMAC
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392028554-32545-1-git-send-email-wens@csie.org>

All Allwinner A20 boards we support can only use either EMAC or GMAC,
as they share the same pins. As we have switched all supported to
GMAC, we should alias GMAC (the active controller) as ethernet0,
so u-boot will insert the MAC address for the correct controller.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 68c889c..1b5fb88 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -17,7 +17,7 @@
 	interrupt-parent = <&gic>;
 
 	aliases {
-		ethernet0 = &emac;
+		ethernet0 = &gmac;
 		serial0 = &uart0;
 		serial1 = &uart1;
 		serial2 = &uart2;
-- 
1.9.rc1

^ permalink raw reply related

* [PATCH v4 7/8] ARM: dts: sun7i: a20-olinuxino-micro: Enable GMAC instead of EMAC
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392028554-32545-1-git-send-email-wens@csie.org>

GMAC has better performance and fewer hardware issues.
Use the GMAC in MII mode for ethernet instead of the EMAC.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 27 +++++++++++--------------
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index ead3013..b02a796 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -19,21 +19,6 @@
 	compatible = "olimex,a20-olinuxino-micro", "allwinner,sun7i-a20";
 
 	soc at 01c00000 {
-		emac: ethernet at 01c0b000 {
-			pinctrl-names = "default";
-			pinctrl-0 = <&emac_pins_a>;
-			phy = <&phy1>;
-			status = "okay";
-		};
-
-		mdio at 01c0b080 {
-			status = "okay";
-
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
-			};
-		};
-
 		pinctrl at 01c20800 {
 			led_pins_olinuxino: led_pins at 0 {
 				allwinner,pins = "PH2";
@@ -78,6 +63,18 @@
 			pinctrl-0 = <&i2c2_pins_a>;
 			status = "okay";
 		};
+
+		gmac: ethernet at 01c50000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&gmac_pins_mii_a>;
+			phy = <&phy1>;
+			phy-mode = "mii";
+			status = "okay";
+
+			phy1: ethernet-phy at 1 {
+				reg = <1>;
+			};
+		};
 	};
 
 	leds {
-- 
1.9.rc1

^ permalink raw reply related

* [PATCH v4 6/8] ARM: dts: sun7i: cubieboard2: Enable GMAC instead of EMAC
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392028554-32545-1-git-send-email-wens@csie.org>

GMAC has better performance and fewer hardware issues.
Use the GMAC in MII mode for ethernet instead of the EMAC.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 27 ++++++++++++---------------
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index 5c51cb8..7bf4935 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -19,21 +19,6 @@
 	compatible = "cubietech,cubieboard2", "allwinner,sun7i-a20";
 
 	soc at 01c00000 {
-		emac: ethernet at 01c0b000 {
-			pinctrl-names = "default";
-			pinctrl-0 = <&emac_pins_a>;
-			phy = <&phy1>;
-			status = "okay";
-		};
-
-		mdio at 01c0b080 {
-			status = "okay";
-
-			phy1: ethernet-phy at 1 {
-				reg = <1>;
-			};
-		};
-
 		pinctrl at 01c20800 {
 			led_pins_cubieboard2: led_pins at 0 {
 				allwinner,pins = "PH20", "PH21";
@@ -60,6 +45,18 @@
 			pinctrl-0 = <&i2c1_pins_a>;
 			status = "okay";
 		};
+
+		gmac: ethernet at 01c50000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&gmac_pins_mii_a>;
+			phy = <&phy1>;
+			phy-mode = "mii";
+			status = "okay";
+
+			phy1: ethernet-phy at 1 {
+				reg = <1>;
+			};
+		};
 	};
 
 	leds {
-- 
1.9.rc1

^ permalink raw reply related

* [PATCH v4 5/8] ARM: dts: sun7i: cubietruck: Enable the GMAC
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392028554-32545-1-git-send-email-wens@csie.org>

The CubieTruck uses the GMAC with an RGMII phy.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index f9dcb61..025ce52 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -51,6 +51,18 @@
 			pinctrl-0 = <&i2c2_pins_a>;
 			status = "okay";
 		};
+
+		gmac: ethernet at 01c50000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&gmac_pins_rgmii_a>;
+			phy = <&phy1>;
+			phy-mode = "rgmii";
+			status = "okay";
+
+			phy1: ethernet-phy at 1 {
+				reg = <1>;
+			};
+		};
 	};
 
 	leds {
-- 
1.9.rc1

^ permalink raw reply related

* [PATCH v4 4/8] ARM: dts: sun7i: Add pin muxing options for the GMAC
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392028554-32545-1-git-send-email-wens@csie.org>

The A20 has EMAC and GMAC muxed on the same pins.
Add pin sets with gmac function for MII and RGMII mode to the DTSI.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 8eb4d54..68c889c 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -484,6 +484,32 @@
 				allwinner,drive = <0>;
 				allwinner,pull = <0>;
 			};
+
+			gmac_pins_mii_a: gmac_mii at 0 {
+				allwinner,pins = "PA0", "PA1", "PA2",
+						"PA3", "PA4", "PA5", "PA6",
+						"PA7", "PA8", "PA9", "PA10",
+						"PA11", "PA12", "PA13", "PA14",
+						"PA15", "PA16";
+				allwinner,function = "gmac";
+				allwinner,drive = <0>;
+				allwinner,pull = <0>;
+			};
+
+			gmac_pins_rgmii_a: gmac_rgmii at 0 {
+				allwinner,pins = "PA0", "PA1", "PA2",
+						"PA3", "PA4", "PA5", "PA6",
+						"PA7", "PA8", "PA10",
+						"PA11", "PA12", "PA13",
+						"PA15", "PA16";
+				allwinner,function = "gmac";
+				/*
+				 * data lines in RGMII mode use DDR mode
+				 * and need a higher signal drive strength
+				 */
+				allwinner,drive = <3>;
+				allwinner,pull = <0>;
+			};
 		};
 
 		timer at 01c20c00 {
-- 
1.9.rc1

^ permalink raw reply related

* [PATCH v4 3/8] ARM: dts: sun7i: Add GMAC controller node to sun7i DTSI
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392028554-32545-1-git-send-email-wens@csie.org>

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index dd567ea..8eb4d54 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -645,6 +645,21 @@
 			status = "disabled";
 		};
 
+		gmac: ethernet at 01c50000 {
+			compatible = "allwinner,sun7i-a20-gmac";
+			reg = <0x01c50000 0x10000>;
+			interrupts = <0 85 4>;
+			interrupt-names = "macirq";
+			clocks = <&ahb_gates 49>, <&gmac_tx_clk>;
+			clock-names = "stmmaceth", "allwinner_gmac_tx";
+			snps,pbl = <2>;
+			snps,fixed-burst;
+			snps,force_sf_dma_mode;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
 		hstimer at 01c60000 {
 			compatible = "allwinner,sun7i-a20-hstimer";
 			reg = <0x01c60000 0x1000>;
-- 
1.9.rc1

^ permalink raw reply related

* [PATCH v4 2/8] ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392028554-32545-1-git-send-email-wens@csie.org>

The GMAC uses 1 of 2 sources for its transmit clock, depending on the
PHY interface mode. Add both sources as dummy clocks, and as parents
to the GMAC clock node.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 4fbe530..dd567ea 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -322,6 +322,34 @@
 		};
 
 		/*
+		 * The following two are dummy clocks, placeholders used in the gmac_tx
+		 * clock. The gmac driver will choose one parent depending on the PHY
+		 * interface mode, using clk_set_rate auto-reparenting.
+		 * The actual TX clock rate is not controlled by the gmac_tx clock.
+		 */
+		mii_phy_tx_clk: clk at 2 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <25000000>;
+			clock-output-names = "mii_phy_tx";
+		};
+
+		gmac_int_tx_clk: clk at 3 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <125000000>;
+			clock-output-names = "gmac_int_tx";
+		};
+
+		gmac_tx_clk: clk at 01c20164 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun7i-a20-gmac-clk";
+			reg = <0x01c20164 0x4>;
+			clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
+			clock-output-names = "gmac_tx";
+		};
+
+		/*
 		 * Dummy clock used by output clocks
 		 */
 		osc24M_32k: clk at 1 {
-- 
1.9.rc1

^ permalink raw reply related

* [PATCH v4 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392028554-32545-1-git-send-email-wens@csie.org>

The Allwinner A20/A31 clock module controls the transmit clock source
and interface type of the GMAC ethernet controller. Model this as
a single clock for GMAC drivers to use.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 Documentation/devicetree/bindings/clock/sunxi.txt | 30 +++++++
 drivers/clk/sunxi/clk-sunxi.c                     | 97 +++++++++++++++++++++++
 2 files changed, 127 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 0cf679b..28421d2 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -37,6 +37,7 @@ Required properties:
 	"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
 	"allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
 	"allwinner,sun7i-a20-out-clk" - for the external output clocks
+	"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
@@ -50,6 +51,9 @@ Required properties for all clocks:
 	If the clock module only has one output, the name shall be the
 	module name.
 
+For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
+dummy clocks at 25 MHz and 125 MHz, respectively. See example.
+
 Clock consumers should specify the desired clocks they use with a
 "clocks" phandle cell. Consumers that are using a gated clock should
 provide an additional ID in their clock property. This ID is the
@@ -96,3 +100,29 @@ mmc0_clk: clk at 01c20088 {
 	clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
 	clock-output-names = "mmc0";
 };
+
+mii_phy_tx_clk: clk at 2 {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <25000000>;
+	clock-output-names = "mii_phy_tx";
+};
+
+gmac_int_tx_clk: clk at 3 {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <125000000>;
+	clock-output-names = "gmac_int_tx";
+};
+
+gmac_clk: clk at 01c20164 {
+	#clock-cells = <0>;
+	compatible = "allwinner,sun7i-a20-gmac-clk";
+	reg = <0x01c20164 0x4>;
+	/*
+	 * The first clock must be fixed at 25MHz;
+	 * the second clock must be fixed at 125MHz
+	 */
+	clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
+	clock-output-names = "gmac";
+};
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 736fb60..da1d5cc 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -379,6 +379,103 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32 parent_rate,
 
 
 /**
+ * sun7i_a20_gmac_clk_setup - Setup function for A20/A31 GMAC clock module
+ *
+ * This clock looks something like this
+ *                               ________________________
+ *  MII TX clock from PHY >-----|___________    _________|----> to GMAC core
+ *  GMAC Int. RGMII TX clk >----|___________\__/__gate---|----> to PHY
+ *  Ext. 125MHz RGMII TX clk >--|__divider__/            |
+ *                              |________________________|
+ *
+ * The external 125 MHz reference is optional, i.e. GMAC can use its
+ * internal TX clock just fine. The A31 GMAC clock module does not have
+ * the divider controls for the external reference.
+ *
+ * To keep it simple, let the GMAC use either the MII TX clock for MII mode,
+ * and its internal TX clock for GMII and RGMII modes. The GMAC driver should
+ * select the appropriate source and gate/ungate the output to the PHY.
+ *
+ * Only the GMAC should use this clock. Altering the clock so that it doesn't
+ * match the GMAC's operation parameters will result in the GMAC not being
+ * able to send traffic out. The GMAC driver should set the clock rate and
+ * enable/disable this clock to configure the required state. The clock
+ * driver then responds by auto-reparenting the clock.
+ */
+
+#define SUN7I_A20_GMAC_GPIT	2
+#define SUN7I_A20_GMAC_MASK	0x3
+#define SUN7I_A20_GMAC_PARENTS	2
+
+static void __init sun7i_a20_gmac_clk_setup(struct device_node *node)
+{
+	struct clk *clk;
+	struct clk_mux *mux;
+	struct clk_gate *gate;
+	const char *clk_name = node->name;
+	const char *parents[SUN7I_A20_GMAC_PARENTS];
+	void *reg;
+	int i = 0;
+
+	if (of_property_read_string(node, "clock-output-names", &clk_name))
+		return;
+
+	/* allocate mux and gate clock structs */
+	mux = kzalloc(sizeof(struct clk_mux), GFP_KERNEL);
+	if (!mux)
+		return;
+
+	gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
+	if (!gate)
+		goto free_mux;
+
+	/* gmac clock requires exactly 2 parents */
+	parents[0] = of_clk_get_parent_name(node, 0);
+	parents[1] = of_clk_get_parent_name(node, 1);
+	if (!parents[0] || !parents[1])
+		goto free_gate;
+
+	reg = of_iomap(node, 0);
+	if (!reg)
+		goto free_gate;
+
+	/* set up gate and fixed rate properties */
+	gate->reg = reg;
+	gate->bit_idx = SUN7I_A20_GMAC_GPIT;
+	gate->lock = &clk_lock;
+	mux->reg = reg;
+	mux->mask = SUN7I_A20_GMAC_MASK;
+	mux->flags = CLK_MUX_INDEX_BIT;
+	mux->lock = &clk_lock;
+
+	clk = clk_register_composite(NULL, clk_name,
+			parents, SUN7I_A20_GMAC_PARENTS,
+			&mux->hw, &clk_mux_ops,
+			NULL, NULL,
+			&gate->hw, &clk_gate_ops,
+			0);
+
+	if (IS_ERR(clk))
+		goto iounmap_reg;
+
+	of_clk_add_provider(node, of_clk_src_simple_get, clk);
+	clk_register_clkdev(clk, clk_name, NULL);
+
+	return;
+
+iounmap_reg:
+	iounmap(reg);
+free_gate:
+	kfree(gate);
+free_mux:
+	kfree(mux);
+}
+CLK_OF_DECLARE(sun7i_a20_gmac, "allwinner,sun7i-a20-gmac-clk",
+		sun7i_a20_gmac_clk_setup);
+
+
+
+/**
  * sunxi_factors_clk_setup() - Setup function for factor clocks
  */
 
-- 
1.9.rc1

^ permalink raw reply related

* [PATCH v4 0/8] Add Allwinner A20 GMAC ethernet support
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

This is the v4 of the remaining Allwinner A20 GMAC glue layer patches.
The stmmac driver changes have been merged through net-next. The
remaining bits are clock and DT patches. The patches should be applied
over my clock renaming patches.

The Allwinner A20 SoC integrates an early version of dwmac
IP from Synopsys. On top of that is a hardware glue layer.
This layer needs to be configured before the dwmac can be
used.

Part of the glue layer is a clock mux, which controls the
source and direction of the TX clock used by GMAC.

Changes since v3:

  * Rework error checking in GMAC clock driver
  * Clarify required parent clock order for GMAC clock in DT bindings
  * Rewrite commit log for "ARM: dts: sun7i: Add ethernet alias for GMAC"
  * Corrected "a20-olinuxino-micro" in commit message
  * Rewrite comments in sun7i dtsi to clarify purpose of dummy clocks
  * Rebase onto Maxime's sunxi-next branch

Changes since v2:

  * Added more comments on GMAC clock driver
  * Drop CLK_SET_PARENT_GATE in GMAC clock driver
  * Use macro for max clock parents
  * Line wrapping

Changes since v1:

  * Added optional reset control to stmmac driver core
  * Added non CONFIG_RESET_CONROLLER routines for the above change
  * Extended callback API, as discussed with Srinivas
  * Used new stmmac_of_data to pass features and callbacks,
    instead of platform data, as discussed
  * Seperated clock module glue layer into clock driver

Cheers,
ChenYu


Chen-Yu Tsai (8):
  clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
  ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
  ARM: dts: sun7i: Add GMAC controller node to sun7i DTSI
  ARM: dts: sun7i: Add pin muxing options for the GMAC
  ARM: dts: sun7i: cubietruck: Enable the GMAC
  ARM: dts: sun7i: cubieboard2: Enable GMAC instead of EMAC
  ARM: dts: sun7i: a20-olinuxino-micro: Enable GMAC instead of EMAC
  ARM: dts: sun7i: Add ethernet alias for GMAC

 Documentation/devicetree/bindings/clock/sunxi.txt | 30 +++++++
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts       | 27 +++----
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts        | 12 +++
 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts   | 27 +++----
 arch/arm/boot/dts/sun7i-a20.dtsi                  | 71 ++++++++++++++++-
 drivers/clk/sunxi/clk-sunxi.c                     | 97 +++++++++++++++++++++++
 6 files changed, 233 insertions(+), 31 deletions(-)

-- 
1.9.rc1

^ permalink raw reply

* [RFC PATCHv2 0/4] Add DT support for fixed PHYs
From: Christian Gmeiner @ 2014-02-10 10:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAH9NwWfBGHmZ+HfUndeh18NW+HyZ=c82W=O_4hJSOH-oZuM9jA@mail.gmail.com>

2013-09-25 9:12 GMT+02:00 Christian Gmeiner <christian.gmeiner@gmail.com>:
> Hi
>
>>> Hello,
>>>
>>> Here is a second version of the patch set that adds a Device Tree
>>> binding and the related code to support fixed PHYs. Marked as RFC,
>>> this patch set is obviously not intended for merging in 3.12.
>>>
>>> Since the first version, the changes have been:
>>>
>>>  * Instead of using a 'fixed-link' property inside the Ethernet device
>>>    DT node, with a fairly cryptic succession of integer values, we now
>>>    use a PHY subnode under the Ethernet device DT node, with explicit
>>>    properties to configure the duplex, speed, pause and other PHY
>>>    properties.
>>>
>>>  * The PHY address is automatically allocated by the kernel and no
>>>    longer visible in the Device Tree binding.
>>>
>>>  * The PHY device is created directly when the network driver calls
>>>    of_phy_connect_fixed_link(), and associated to the PHY DT node,
>>>    which allows the existing of_phy_connect() function to work,
>>>    without the need to use the deprecated of_phy_connect_fixed_link().
>>>
>>> The things I am not entirely happy with yet are:
>>>
>>>  * The PHY ID is hardcoded to 0xdeadbeef. Ideally, it should be a
>>>    properly reserved vendor/device identifier, but it isn't clear how
>>>    to get one allocated for this purpose.
>>>
>>>  * The fixed_phy_register() function in drivers/net/phy/fixed.c has
>>>    some OF references. So ideally, I would have preferred to put this
>>>    code in drivers/of/of_mdio.c, but to call get_phy_device(), we need
>>>    a reference to the mii_bus structure that represents the fixed MDIO
>>>    bus.
>>>
>>>  * There is some error management missing in fixed_phy_register(), but
>>>    it can certainly be added easily. This RFC is meant to sort out the
>>>    general idea.
>>
>> +1 for the general idea. This really looks good now. I've not much more
>> to say. Maybe someone from the devicetree corner has a few words for the
>> binding?
>>
>
> I tested the whole series with an I.MX6D board with the FEC driver:
> fec 2188000.ethernet eth0: Freescale FEC PHY driver [Generic PHY]
> (mii_bus:phy_addr=fixed-0:00, irq=-1)
>
> For me binding looks nice and I hope to see this patch series in 3.13.
>
> Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com>

Is there any update on this patch series?

--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

^ permalink raw reply

* [PATCH] ARM: zynq: Add support for SOC_BUS
From: Michal Simek @ 2014-02-10 10:30 UTC (permalink / raw)
  To: linux-arm-kernel

Provide information through SOC_BUS to user space.
Silicon revision is provided through devcfg device.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---

Based on zynq/cleanup branch

---
 arch/arm/boot/dts/zynq-7000.dtsi |  5 +++
 arch/arm/mach-zynq/Kconfig       |  1 +
 arch/arm/mach-zynq/common.c      | 72 +++++++++++++++++++++++++++++++++++++++-
 arch/arm/mach-zynq/common.h      |  1 +
 arch/arm/mach-zynq/slcr.c        | 19 +++++++++++
 5 files changed, 97 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 116f83b5..7284499 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -155,6 +155,11 @@
 			};
 		};

+		devcfg: devcfg at f8007000 {
+			compatible = "xlnx,zynq-devcfg-1.00.a";
+			reg = <0xf8007000 0x100>;
+		} ;
+
 		global_timer: timer at f8f00200 {
 			compatible = "arm,cortex-a9-global-timer";
 			reg = <0xf8f00200 0x20>;
diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
index f3e6ce4..16ba63f 100644
--- a/arch/arm/mach-zynq/Kconfig
+++ b/arch/arm/mach-zynq/Kconfig
@@ -16,5 +16,6 @@ config ARCH_ZYNQ
 	select ARM_GLOBAL_TIMER
 	select MFD_SYSCON
 	select GENERIC_ALLOCATOR
+	select SOC_BUS
 	help
 	  Support for Xilinx Zynq ARM Cortex A9 Platform
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 5755129..9d3c88e 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -28,6 +28,8 @@
 #include <linux/of.h>
 #include <linux/irqchip.h>
 #include <linux/irqchip/arm-gic.h>
+#include <linux/slab.h>
+#include <linux/sys_soc.h>

 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -36,10 +38,15 @@
 #include <asm/page.h>
 #include <asm/pgtable.h>
 #include <asm/smp_scu.h>
+#include <asm/system_info.h>
 #include <asm/hardware/cache-l2x0.h>

 #include "common.h"

+#define ZYNQ_DEVCFG_MCTRL		0x80
+#define ZYNQ_DEVCFG_PS_VERSION_SHIFT	28
+#define ZYNQ_DEVCFG_PS_VERSION_MASK	0xF
+
 void __iomem *zynq_scu_base;

 static struct platform_device zynq_cpuidle_device = {
@@ -47,17 +54,80 @@ static struct platform_device zynq_cpuidle_device = {
 };

 /**
+ * zynq_get_revision - Get Zynq silicon revision
+ *
+ * Return: Silicon version or -1 otherwise
+ */
+static int __init zynq_get_revision(void)
+{
+	struct device_node *np;
+	void __iomem *zynq_devcfg_base;
+	u32 revision;
+
+	np = of_find_compatible_node(NULL, NULL, "xlnx,zynq-devcfg-1.00.a");
+	if (!np) {
+		pr_err("%s: no devcfg node found\n", __func__);
+		return -1;
+	}
+
+	zynq_devcfg_base = of_iomap(np, 0);
+	if (!zynq_devcfg_base) {
+		pr_err("%s: Unable to map I/O memory\n", __func__);
+		return -1;
+	}
+
+	revision = readl(zynq_devcfg_base + ZYNQ_DEVCFG_MCTRL);
+	revision >>= ZYNQ_DEVCFG_PS_VERSION_SHIFT;
+	revision &= ZYNQ_DEVCFG_PS_VERSION_MASK;
+
+	iounmap(zynq_devcfg_base);
+
+	return revision;
+}
+
+/**
  * zynq_init_machine - System specific initialization, intended to be
  *		       called from board specific initialization.
  */
 static void __init zynq_init_machine(void)
 {
+	struct soc_device_attribute *soc_dev_attr;
+	struct soc_device *soc_dev;
+	struct device *parent = NULL;
+
 	/*
 	 * 64KB way size, 8-way associativity, parity disabled
 	 */
 	l2x0_of_init(0x02060000, 0xF0F0FFFF);

-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+	if (!soc_dev_attr)
+		goto out;
+
+	system_rev = zynq_get_revision();
+
+	soc_dev_attr->family = kasprintf(GFP_KERNEL, "Xilinx Zynq");
+	soc_dev_attr->revision = kasprintf(GFP_KERNEL, "0x%x", system_rev);
+	soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "0x%x",
+					 zynq_slcr_get_device_id());
+
+	soc_dev = soc_device_register(soc_dev_attr);
+	if (IS_ERR(soc_dev)) {
+		kfree(soc_dev_attr->family);
+		kfree(soc_dev_attr->revision);
+		kfree(soc_dev_attr->soc_id);
+		kfree(soc_dev_attr);
+		goto out;
+	}
+
+	parent = soc_device_to_device(soc_dev);
+
+out:
+	/*
+	 * Finished with the static registrations now; fill in the missing
+	 * devices
+	 */
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, parent);

 	platform_device_register(&zynq_cpuidle_device);

diff --git a/arch/arm/mach-zynq/common.h b/arch/arm/mach-zynq/common.h
index 953f6a1..26a23fe 100644
--- a/arch/arm/mach-zynq/common.h
+++ b/arch/arm/mach-zynq/common.h
@@ -25,6 +25,7 @@ extern void zynq_slcr_system_reset(void);
 extern void zynq_slcr_cpu_stop(int cpu);
 extern void zynq_slcr_cpu_start(int cpu);
 extern u32 zynq_slcr_get_ocm_config(void);
+extern u32 zynq_slcr_get_device_id(void);

 #ifdef CONFIG_SMP
 extern void secondary_startup(void);
diff --git a/arch/arm/mach-zynq/slcr.c b/arch/arm/mach-zynq/slcr.c
index f310081..594b280 100644
--- a/arch/arm/mach-zynq/slcr.c
+++ b/arch/arm/mach-zynq/slcr.c
@@ -26,11 +26,14 @@
 #define SLCR_PS_RST_CTRL_OFFSET		0x200 /* PS Software Reset Control */
 #define SLCR_A9_CPU_RST_CTRL_OFFSET	0x244 /* CPU Software Reset Control */
 #define SLCR_REBOOT_STATUS_OFFSET	0x258 /* PS Reboot Status */
+#define SLCR_PSS_IDCODE			0x530 /* PS IDCODE */
 #define SLCR_OCM_CFG_OFFSET		0x910 /* OCM Address Mapping */

 #define SLCR_UNLOCK_MAGIC		0xDF0D
 #define SLCR_A9_CPU_CLKSTOP		0x10
 #define SLCR_A9_CPU_RST			0x1
+#define SLCR_PSS_IDCODE_DEVICE_SHIFT	12
+#define SLCR_PSS_IDCODE_DEVICE_MASK	0x1F

 static void __iomem *zynq_slcr_base;
 static struct regmap *zynq_slcr_regmap;
@@ -84,6 +87,22 @@ static inline int zynq_slcr_unlock(void)
 }

 /**
+ * zynq_slcr_get_device_id - Read device code id
+ *
+ * Return:	Device code id
+ */
+u32 zynq_slcr_get_device_id(void)
+{
+	u32 val;
+
+	zynq_slcr_read(&val, SLCR_PSS_IDCODE);
+	val >>= SLCR_PSS_IDCODE_DEVICE_SHIFT;
+	val &= SLCR_PSS_IDCODE_DEVICE_MASK;
+
+	return val;
+}
+
+/**
  * zynq_slcr_system_reset - Reset the entire system.
  */
 void zynq_slcr_system_reset(void)
--
1.8.2.3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/43981403/attachment.sig>

^ permalink raw reply related

* [PATCH] staging: drm/imx: remove an unnecessary local variable
From: Liu Ying @ 2014-02-10 10:29 UTC (permalink / raw)
  To: linux-arm-kernel

This patch removes an unnecessary local variable defined
in the function imx_drm_driver_unload() so as to fix the
following build warning.

drivers/staging/imx-drm/imx-drm-core.c: \
In function ?imx_drm_driver_unload?:
drivers/staging/imx-drm/imx-drm-core.c:87:25: \
warning: unused variable ?imxdrm? [-Wunused-variable]

Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
 drivers/staging/imx-drm/imx-drm-core.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c b/drivers/staging/imx-drm/imx-drm-core.c
index 236ed66..573fe88 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -84,8 +84,6 @@ static void imx_drm_driver_lastclose(struct drm_device *drm)
 
 static int imx_drm_driver_unload(struct drm_device *drm)
 {
-	struct imx_drm_device *imxdrm = drm->dev_private;
-
 	imx_drm_device_put();
 
 	drm_vblank_cleanup(drm);
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH] ARM: mm: report both sections from PMD
From: Catalin Marinas @ 2014-02-10 10:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140209221826.GA30556@www.outflux.net>

On Sun, Feb 09, 2014 at 10:18:26PM +0000, Kees Cook wrote:
> diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
> index 1f7b1e13d945..ff1559f9200c 100644
> --- a/arch/arm/mm/dump.c
> +++ b/arch/arm/mm/dump.c
> @@ -264,6 +264,9 @@ static void walk_pmd(struct pg_state *st, pud_t *pud, unsigned long start)
>  			note_page(st, addr, 3, pmd_val(*pmd));
>  		else
>  			walk_pte(st, pmd, addr);
> +
> +		if (SECTION_SIZE < PMD_SIZE && pmd_sect(*pmd))
> +			note_page(st, addr + SECTION_SIZE, 3, pmd_val(pmd[1]));

You can  use pmd_large() here as well.

But I think this function is broken (the "for" statement not shown
here). The pmd_t is 32-bit with classic MMU and it uses pmd++ while the
address grows by PMD_SIZE (two pmd_t entries).

-- 
Catalin

^ permalink raw reply

* [PATCH] staging: drm/imx: remove an unnecessary local variable
From: Russell King - ARM Linux @ 2014-02-10 10:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1392028185-4528-1-git-send-email-Ying.Liu@freescale.com>

On Mon, Feb 10, 2014 at 06:29:45PM +0800, Liu Ying wrote:
> This patch removes an unnecessary local variable defined
> in the function imx_drm_driver_unload() so as to fix the
> following build warning.
> 
> drivers/staging/imx-drm/imx-drm-core.c: \
> In function ?imx_drm_driver_unload?:
> drivers/staging/imx-drm/imx-drm-core.c:87:25: \
> warning: unused variable ?imxdrm? [-Wunused-variable]

Already-Naked-by: me.  This is required by later patches in the series
posted earlier.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

^ permalink raw reply


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