Re: [PATCH] soc: dove: constify reset_control_ops structures

[Sebastian Hesselbarth]

On 24.03.2017 14:00, Russell King - ARM Linux wrote:

On Fri, Jan 13, 2017 at 05:55:26PM +0100, Gregory CLEMENT wrote:

Sorry when I saw SoC and Dove I though to Sebastian. And I ma sure he
would have redirect me to you :)


Should I change the MAINTAINERS entry, as it seems that I'm more involved
with Dove than Sebastian is now?  Sebastian?



Uhm, yeah, please change the MAINTAINERS entry.

I haven't been able to follow neither Dove nor mvebu discussion
lately.

If you want to take over, feel free to add my

Acked-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>

Sebastian

Re: [PATCH] soc: dove: constify reset_control_ops structures

[Sebastian Hesselbarth]

On 24.03.2017 14:00, Russell King - ARM Linux wrote:

On Fri, Jan 13, 2017 at 05:55:26PM +0100, Gregory CLEMENT wrote:

Sorry when I saw SoC and Dove I though to Sebastian. And I ma sure he
would have redirect me to you :)


Should I change the MAINTAINERS entry, as it seems that I'm more involved
with Dove than Sebastian is now?  Sebastian?



Uhm, yeah, please change the MAINTAINERS entry.

I haven't been able to follow neither Dove nor mvebu discussion
lately.

If you want to take over, feel free to add my

Acked-by: Sebastian Hesselbarth 

Sebastian

Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

[Sebastian Hesselbarth]

On 19.01.2017 22:12, Chris Packham wrote:
> On 14/01/17 20:50, Chris Packham wrote:
>> On 13/01/17 22:54, Sebastian Hesselbarth wrote:
>>> On 13.01.2017 10:12, Chris Packham wrote:
>>>> From: Kalyan Kinthada <kalyan.kinth...@alliedtelesis.co.nz>
>>>>
>>>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>>>> from Marvell.
>>>>
>>>> Signed-off-by: Kalyan Kinthada <kalyan.kinth...@alliedtelesis.co.nz>
>>>> Signed-off-by: Chris Packham <chris.pack...@alliedtelesis.co.nz>
>>>> Acked-by: Rob Herring <r...@kernel.org>
>>>> Acked-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
>>>> ---
>>>>
>>>> Notes:
>>>> Changes in v2:
>>>> - include sdio support for the 98DX4251
>>>> Changes in v3:
>>>> - None
>>>> Changes in v4:
>>>> - Correct some discrepencies between binding and driver.
>>>
>>> Well, unfortunately I still see differences between the "gpio" in
>>> the binding and "gpo" in the driver.
>>>
>>> Please go back to that list I sent you yesterday and fix them all.
>>>
>>
>> I think you may have missed my initial reply [1]. Or I have missed your
>> response to it. Long story short "gpo" is intentional because some of
>> those pins can't be used as inputs. But if you still want me to change
>> it I will.
>>
>> [1] - https://lkml.org/lkml/2017/1/12/117
>>
> 
> Did you get a chance to consider this. Do you still want me to change 
> gpo -> gpio given the information above?

Chris,

sorry if I wasn't clear enough. I don't want you to change every gpo
into gpio. All I was referring to is the _difference_ between driver
implementation and device tree binding - and soley resolve that.

So, for the gpo's I see that the binding doc still says "gpio" for the
available functions where the driver expects "gpo".

e.g. the binding has this:

mpp6  6gpio, sd0(clk), dev(a2)

if you change it to

mpp6  6gpo, sd0(clk), dev(a2)

both binding and driver are the same, right?

I do understand that the hardware is gp-output only and you correctly
reflected that in the pinctrl driver - but the binding doc does not
reflect that for those mpps in the list.

Did I make it clearer now or am I still missing the point?

Sebastian

Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

[Sebastian Hesselbarth]

On 19.01.2017 22:12, Chris Packham wrote:
> On 14/01/17 20:50, Chris Packham wrote:
>> On 13/01/17 22:54, Sebastian Hesselbarth wrote:
>>> On 13.01.2017 10:12, Chris Packham wrote:
>>>> From: Kalyan Kinthada 
>>>>
>>>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>>>> from Marvell.
>>>>
>>>> Signed-off-by: Kalyan Kinthada 
>>>> Signed-off-by: Chris Packham 
>>>> Acked-by: Rob Herring 
>>>> Acked-by: Sebastian Hesselbarth 
>>>> ---
>>>>
>>>> Notes:
>>>> Changes in v2:
>>>> - include sdio support for the 98DX4251
>>>> Changes in v3:
>>>> - None
>>>> Changes in v4:
>>>> - Correct some discrepencies between binding and driver.
>>>
>>> Well, unfortunately I still see differences between the "gpio" in
>>> the binding and "gpo" in the driver.
>>>
>>> Please go back to that list I sent you yesterday and fix them all.
>>>
>>
>> I think you may have missed my initial reply [1]. Or I have missed your
>> response to it. Long story short "gpo" is intentional because some of
>> those pins can't be used as inputs. But if you still want me to change
>> it I will.
>>
>> [1] - https://lkml.org/lkml/2017/1/12/117
>>
> 
> Did you get a chance to consider this. Do you still want me to change 
> gpo -> gpio given the information above?

Chris,

sorry if I wasn't clear enough. I don't want you to change every gpo
into gpio. All I was referring to is the _difference_ between driver
implementation and device tree binding - and soley resolve that.

So, for the gpo's I see that the binding doc still says "gpio" for the
available functions where the driver expects "gpo".

e.g. the binding has this:

mpp6  6gpio, sd0(clk), dev(a2)

if you change it to

mpp6  6gpo, sd0(clk), dev(a2)

both binding and driver are the same, right?

I do understand that the hardware is gp-output only and you correctly
reflected that in the pinctrl driver - but the binding doc does not
reflect that for those mpps in the list.

Did I make it clearer now or am I still missing the point?

Sebastian

Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

[Sebastian Hesselbarth]

On 13.01.2017 10:12, Chris Packham wrote:

From: Kalyan Kinthada <kalyan.kinth...@alliedtelesis.co.nz>

This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
from Marvell.

Signed-off-by: Kalyan Kinthada <kalyan.kinth...@alliedtelesis.co.nz>
Signed-off-by: Chris Packham <chris.pack...@alliedtelesis.co.nz>
Acked-by: Rob Herring <r...@kernel.org>
Acked-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
---

Notes:
Changes in v2:
- include sdio support for the 98DX4251
Changes in v3:
- None
Changes in v4:
- Correct some discrepencies between binding and driver.


Well, unfortunately I still see differences between the "gpio" in
the binding and "gpo" in the driver.

Please go back to that list I sent you yesterday and fix them all.

[...]

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
new file mode 100644
index ..b5bd23992fdf
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
@@ -0,0 +1,46 @@

[...]

+mpp6  6gpio, sd0(clk), dev(a2)


e.g. this is "gpio" ...

[...]

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index e4ea71a9d985..9601d662c7f5 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -49,6 +49,10 @@ enum armada_xp_variant {

[...]

+   MPP_MODE(6,
+MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),


... but here it is "gpo".

Sebastian

Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

[Sebastian Hesselbarth]

On 13.01.2017 10:12, Chris Packham wrote:

From: Kalyan Kinthada 

This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
from Marvell.

Signed-off-by: Kalyan Kinthada 
Signed-off-by: Chris Packham 
Acked-by: Rob Herring 
Acked-by: Sebastian Hesselbarth 
---

Notes:
Changes in v2:
- include sdio support for the 98DX4251
Changes in v3:
- None
Changes in v4:
- Correct some discrepencies between binding and driver.


Well, unfortunately I still see differences between the "gpio" in
the binding and "gpo" in the driver.

Please go back to that list I sent you yesterday and fix them all.

[...]

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
new file mode 100644
index ..b5bd23992fdf
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
@@ -0,0 +1,46 @@

[...]

+mpp6  6gpio, sd0(clk), dev(a2)


e.g. this is "gpio" ...

[...]

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index e4ea71a9d985..9601d662c7f5 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -49,6 +49,10 @@ enum armada_xp_variant {

[...]

+   MPP_MODE(6,
+MPP_VAR_FUNCTION(0x0, "gpo", NULL,  V_98DX3236_PLUS),


... but here it is "gpo".

Sebastian

Re: [PATCHv3 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

[Sebastian Hesselbarth]

On 01/11/2017 03:44 PM, Linus Walleij wrote:

On Fri, Jan 6, 2017 at 5:15 AM, Chris Packham
<chris.pack...@alliedtelesis.co.nz> wrote:


From: Kalyan Kinthada <kalyan.kinth...@alliedtelesis.co.nz>

This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
from Marvell.

Signed-off-by: Kalyan Kinthada <kalyan.kinth...@alliedtelesis.co.nz>
Signed-off-by: Chris Packham <chris.pack...@alliedtelesis.co.nz>


I am waiting for an ACK or comment from the maintainers on
this patch. Sebastian?


Sorry for the ignorance.

I don't have the patch to reply to inline, but:

- In the driver MPP_MODE2, spi0 there is a typo "csk" instead of "sck".
- MPP_MODE5 binding "dev","bootcs" and driver "dev","bootcs0" differ.
- MPP_MODE6 binding "gpio" and driver "gpo" differ.
- MPP_MODE17 binding "dev","clk" and driver "dev","clkout" differ.
- MPP_MODE19 binding mentiones "dev","rb" but driver does not.
- MPP_MODE20 binding "gpio" and driver "gpo" differ.
- MPP_MODE20 binding "dev","we" and driver "dev","we0" differ.
- MPP_MODE21 through MPP_MODE30 binding "gpio" and driver "gpo" differ.
- remove spaces before "0, 0" in mv98dx3236_mpp_gpio_ranges.

Most of it is cosmetic stuff, so if you fix it feel free to add my

Acked-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>

Sebastian

Re: [PATCHv3 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

[Sebastian Hesselbarth]

On 01/11/2017 03:44 PM, Linus Walleij wrote:

On Fri, Jan 6, 2017 at 5:15 AM, Chris Packham
 wrote:


From: Kalyan Kinthada 

This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
from Marvell.

Signed-off-by: Kalyan Kinthada 
Signed-off-by: Chris Packham 


I am waiting for an ACK or comment from the maintainers on
this patch. Sebastian?


Sorry for the ignorance.

I don't have the patch to reply to inline, but:

- In the driver MPP_MODE2, spi0 there is a typo "csk" instead of "sck".
- MPP_MODE5 binding "dev","bootcs" and driver "dev","bootcs0" differ.
- MPP_MODE6 binding "gpio" and driver "gpo" differ.
- MPP_MODE17 binding "dev","clk" and driver "dev","clkout" differ.
- MPP_MODE19 binding mentiones "dev","rb" but driver does not.
- MPP_MODE20 binding "gpio" and driver "gpo" differ.
- MPP_MODE20 binding "dev","we" and driver "dev","we0" differ.
- MPP_MODE21 through MPP_MODE30 binding "gpio" and driver "gpo" differ.
- remove spaces before "0, 0" in mv98dx3236_mpp_gpio_ranges.

Most of it is cosmetic stuff, so if you fix it feel free to add my

Acked-by: Sebastian Hesselbarth 

Sebastian

Re: [PATCH 23/39] ARM: dts: armada-xp-axpwifiap: Correct license text

[Sebastian Hesselbarth]

On 14.12.2016 23:37, Alexandre Belloni wrote:

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Arnaud Ebalard <a...@natisbad.org>
Cc: Boris Brezillon <boris.brezil...@free-electrons.com>
Cc: Ezequiel Garcia <ezequiel.gar...@free-electrons.com>
Cc: Paul Bolle <pebo...@tiscali.nl>
Cc: Rafał Miłecki <zaj...@gmail.com>
Cc: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>


Feel free to add my

Acked-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>

for Patches 23, 25, 27, 29, 30, 31, 32, 33, 35, 36, i.e. all I
have been in Cc.

Sebastian


Cc: Stefan Roese <s...@denx.de>
Cc: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
Signed-off-by: Alexandre Belloni <alexandre.bell...@free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-axpwifiap.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts 
b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
index ce152719bc28..6a25eb427822 100644
--- a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
+++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
@@ -20,17 +20,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -39,11 +39,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.

Re: [PATCH 23/39] ARM: dts: armada-xp-axpwifiap: Correct license text

[Sebastian Hesselbarth]

On 14.12.2016 23:37, Alexandre Belloni wrote:

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Arnaud Ebalard 
Cc: Boris Brezillon 
Cc: Ezequiel Garcia 
Cc: Paul Bolle 
Cc: Rafał Miłecki 
Cc: Sebastian Hesselbarth 


Feel free to add my

Acked-by: Sebastian Hesselbarth 

for Patches 23, 25, 27, 29, 30, 31, 32, 33, 35, 36, i.e. all I
have been in Cc.

Sebastian


Cc: Stefan Roese 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-xp-axpwifiap.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts 
b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
index ce152719bc28..6a25eb427822 100644
--- a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
+++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
@@ -20,17 +20,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -39,11 +39,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.

Re: [PATCH] MAINTAINERS: add myself as Marvell berlin SoC co-maintainers

[Sebastian Hesselbarth]

On 09/29/2016 08:55 AM, Jisheng Zhang wrote:

I would like to help maintaining Marvell berlin SoCs.


NAK. ;)

Let's face it, you'd be lucky if _I_ can co-maintain berlin. So,
let's be honest and describe it as it will be:

You'll be maintaining berlin and both the Commit msg and the order
of the E-mails below should represent that.

Thanks for taking over and if you reword the Patch, feel free to
add my

Acked-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>

Sebastian


Signed-off-by: Jisheng Zhang <jszh...@marvell.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b003d0c..b1e5243 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1411,6 +1411,7 @@ F:arch/arm/configs/mvebu_*_defconfig

 ARM/Marvell Berlin SoC support
 M:     Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
+M: Jisheng Zhang <jszh...@marvell.com>
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-berlin/

Re: [PATCH] MAINTAINERS: add myself as Marvell berlin SoC co-maintainers

[Sebastian Hesselbarth]

On 09/29/2016 08:55 AM, Jisheng Zhang wrote:

I would like to help maintaining Marvell berlin SoCs.


NAK. ;)

Let's face it, you'd be lucky if _I_ can co-maintain berlin. So,
let's be honest and describe it as it will be:

You'll be maintaining berlin and both the Commit msg and the order
of the E-mails below should represent that.

Thanks for taking over and if you reword the Patch, feel free to
add my

Acked-by: Sebastian Hesselbarth 

Sebastian


Signed-off-by: Jisheng Zhang 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b003d0c..b1e5243 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1411,6 +1411,7 @@ F:arch/arm/configs/mvebu_*_defconfig

 ARM/Marvell Berlin SoC support
 M: Sebastian Hesselbarth 
+M: Jisheng Zhang 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-berlin/

Re: [PATCH 00/10] ARM: dts: berlin: fix dtc warnings

[Sebastian Hesselbarth]

On 06.09.2016 10:40, Jisheng Zhang wrote:

This is a clean up series to fix berlin arm platforms dtc warnings.
Firstly we remove skeleton.dtsi inclusion. Then add missing unit name
of /soc node and /memory node. Lastly, we fix regulators' name

Jisheng Zhang (10):
   ARM: dts: berlin2q: Remove skeleton.dtsi inclusion
   ARM: dts: berlin2cd: Remove skeleton.dtsi inclusion
   ARM: dts: berlin2: Remove skeleton.dtsi inclusion
   ARM: dts: berlin2q: Add missing unit name to /soc node
   ARM: dts: berlin2cd: Add missing unit name to /soc node
   ARM: dts: berlin2: Add missing unit name to /soc node
   ARM: dts: berlin2q-marvell-dmp: add missing unit name to /memory node
   ARM: dts: chromecast: add missing unit name to /memory node


Jisheng,

Applied the 8 patches above.


   ARM: dts: sony-nsz-gs7: add missing unit name to /memory node


I didn't receive this one and could not find it online.
I recreated the patch by using the chromecast patch above, so
applied.


   ARM: dts: berlin2q-marvell-dmp: fix regulators' name


I have no clue what it should be fixed to.

Sebastian


  arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts|  2 +-
  arch/arm/boot/dts/berlin2.dtsi|  5 +++--
  arch/arm/boot/dts/berlin2cd-google-chromecast.dts |  2 +-
  arch/arm/boot/dts/berlin2cd.dtsi  |  5 +++--
  arch/arm/boot/dts/berlin2q-marvell-dmp.dts| 12 ++--
  arch/arm/boot/dts/berlin2q.dtsi   |  6 +++---
  6 files changed, 17 insertions(+), 15 deletions(-)

Re: [PATCH 00/10] ARM: dts: berlin: fix dtc warnings

[Sebastian Hesselbarth]

On 06.09.2016 10:40, Jisheng Zhang wrote:

This is a clean up series to fix berlin arm platforms dtc warnings.
Firstly we remove skeleton.dtsi inclusion. Then add missing unit name
of /soc node and /memory node. Lastly, we fix regulators' name

Jisheng Zhang (10):
   ARM: dts: berlin2q: Remove skeleton.dtsi inclusion
   ARM: dts: berlin2cd: Remove skeleton.dtsi inclusion
   ARM: dts: berlin2: Remove skeleton.dtsi inclusion
   ARM: dts: berlin2q: Add missing unit name to /soc node
   ARM: dts: berlin2cd: Add missing unit name to /soc node
   ARM: dts: berlin2: Add missing unit name to /soc node
   ARM: dts: berlin2q-marvell-dmp: add missing unit name to /memory node
   ARM: dts: chromecast: add missing unit name to /memory node


Jisheng,

Applied the 8 patches above.


   ARM: dts: sony-nsz-gs7: add missing unit name to /memory node


I didn't receive this one and could not find it online.
I recreated the patch by using the chromecast patch above, so
applied.


   ARM: dts: berlin2q-marvell-dmp: fix regulators' name


I have no clue what it should be fixed to.

Sebastian


  arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts|  2 +-
  arch/arm/boot/dts/berlin2.dtsi|  5 +++--
  arch/arm/boot/dts/berlin2cd-google-chromecast.dts |  2 +-
  arch/arm/boot/dts/berlin2cd.dtsi  |  5 +++--
  arch/arm/boot/dts/berlin2q-marvell-dmp.dts| 12 ++--
  arch/arm/boot/dts/berlin2q.dtsi   |  6 +++---
  6 files changed, 17 insertions(+), 15 deletions(-)

Re: [PATCH v2 02/10] reset: berlin: add driver Kconfig option

[Sebastian Hesselbarth]

On 30.08.2016 10:24, Philipp Zabel wrote:

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Antoine Tenart <antoine.ten...@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
Reviewed-by: Masahiro Yamada <yamada.masah...@socionext.com>
Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>


Sorry for the late reply, FWIW

Acked-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>



---
  drivers/reset/Kconfig  | 6 ++
  drivers/reset/Makefile | 2 +-
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 9da0507..1194cbe 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -21,6 +21,12 @@ config RESET_ATH79
  This enables the ATH79 reset controller driver that supports the
  AR71xx SoC reset controller.

+config RESET_BERLIN
+   bool "Berlin Reset Driver" if COMPILE_TEST
+   default ARCH_BERLIN
+   help
+ This enables the reset controller driver for Marvell Berlin SoCs.
+
  config RESET_OXNAS
bool

diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index e3fc337..34c0b23 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,7 +1,6 @@
  obj-y += core.o
  obj-$(CONFIG_ARCH_LPC18XX) += reset-lpc18xx.o
  obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
-obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
  obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
  obj-$(CONFIG_ARCH_MESON) += reset-meson.o
  obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
@@ -10,6 +9,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
  obj-$(CONFIG_ARCH_HISI) += hisilicon/
  obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
  obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
  obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
  obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
  obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o

Re: [PATCH v2 02/10] reset: berlin: add driver Kconfig option

[Sebastian Hesselbarth]

On 30.08.2016 10:24, Philipp Zabel wrote:

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Antoine Tenart 
Cc: Sebastian Hesselbarth 
Reviewed-by: Masahiro Yamada 
Signed-off-by: Philipp Zabel 


Sorry for the late reply, FWIW

Acked-by: Sebastian Hesselbarth 



---
  drivers/reset/Kconfig  | 6 ++
  drivers/reset/Makefile | 2 +-
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 9da0507..1194cbe 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -21,6 +21,12 @@ config RESET_ATH79
  This enables the ATH79 reset controller driver that supports the
  AR71xx SoC reset controller.

+config RESET_BERLIN
+   bool "Berlin Reset Driver" if COMPILE_TEST
+   default ARCH_BERLIN
+   help
+ This enables the reset controller driver for Marvell Berlin SoCs.
+
  config RESET_OXNAS
bool

diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index e3fc337..34c0b23 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,7 +1,6 @@
  obj-y += core.o
  obj-$(CONFIG_ARCH_LPC18XX) += reset-lpc18xx.o
  obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
-obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
  obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
  obj-$(CONFIG_ARCH_MESON) += reset-meson.o
  obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
@@ -10,6 +9,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
  obj-$(CONFIG_ARCH_HISI) += hisilicon/
  obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
  obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
  obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
  obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
  obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o

Re: [PATCH v2] clk: berlin: Migrate to clk_hw based registration and OF APIs

[Sebastian Hesselbarth]

On 17.08.2016 00:40, Stephen Boyd wrote:

Now that we have clk_hw based provider APIs to register clks, we
can get rid of struct clk pointers while registering clks in
these drivers, allowing us to move closer to a clear split of
consumer and provider clk APIs. We also remove some __init
markings in header files as they're useless and we're in the
area.

Cc: Jisheng Zhang <jszh...@marvell.com>
Cc: Alexandre Belloni <alexandre.bell...@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
Signed-off-by: Stephen Boyd <stephen.b...@linaro.org>
---

Changes from v1:
  * Fixed alignment
  * Added note about dropping __init in commit text

  drivers/clk/berlin/berlin2-avpll.c | 12 ++---
  drivers/clk/berlin/berlin2-avpll.h |  8 +---
  drivers/clk/berlin/berlin2-div.c   |  4 +-
  drivers/clk/berlin/berlin2-div.h   |  4 +-
  drivers/clk/berlin/berlin2-pll.c   |  6 +--
  drivers/clk/berlin/berlin2-pll.h   |  9 ++--
  drivers/clk/berlin/bg2.c   | 98 --
  drivers/clk/berlin/bg2q.c  | 39 ---
  8 files changed, 92 insertions(+), 88 deletions(-)

diff --git a/drivers/clk/berlin/berlin2-avpll.c 
b/drivers/clk/berlin/berlin2-avpll.c
index fd0f26c38465..5b0e4213b3ae 100644
--- a/drivers/clk/berlin/berlin2-avpll.c
+++ b/drivers/clk/berlin/berlin2-avpll.c
@@ -188,7 +188,7 @@ static const struct clk_ops berlin2_avpll_vco_ops = {
.recalc_rate= berlin2_avpll_vco_recalc_rate,
  };

-struct clk * __init berlin2_avpll_vco_register(void __iomem *base,
+int __init berlin2_avpll_vco_register(void __iomem *base,
   const char *name, const char *parent_name,
   u8 vco_flags, unsigned long flags)
  {
@@ -197,7 +197,7 @@ struct clk * __init berlin2_avpll_vco_register(void __iomem 
*base,

vco = kzalloc(sizeof(*vco), GFP_KERNEL);
if (!vco)
-   return ERR_PTR(-ENOMEM);
+   return -ENOMEM;

vco->base = base;
vco->flags = vco_flags;
@@ -208,7 +208,7 @@ struct clk * __init berlin2_avpll_vco_register(void __iomem 
*base,
init.num_parents = 1;
init.flags = flags;

-   return clk_register(NULL, >hw);
+   return clk_hw_register(NULL, >hw);
  }

  struct berlin2_avpll_channel {
@@ -364,7 +364,7 @@ static const struct clk_ops berlin2_avpll_channel_ops = {
   */
  static const u8 quirk_index[] __initconst = { 0, 6, 5, 4, 3, 2, 1, 7 };

-struct clk * __init berlin2_avpll_channel_register(void __iomem *base,
+int __init berlin2_avpll_channel_register(void __iomem *base,
   const char *name, u8 index, const char *parent_name,
   u8 ch_flags, unsigned long flags)
  {
@@ -373,7 +373,7 @@ struct clk * __init berlin2_avpll_channel_register(void 
__iomem *base,

ch = kzalloc(sizeof(*ch), GFP_KERNEL);
if (!ch)
-   return ERR_PTR(-ENOMEM);
+   return ENOMEM;

[...]

Stephen,

thanks for the conversion! There is a '-' missing in the line above.
With Jisheng's Tested-by and the minor fix above, feel free to add my

Acked-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>

Sebastian

Re: [PATCH v2] clk: berlin: Migrate to clk_hw based registration and OF APIs

[Sebastian Hesselbarth]

On 17.08.2016 00:40, Stephen Boyd wrote:

Now that we have clk_hw based provider APIs to register clks, we
can get rid of struct clk pointers while registering clks in
these drivers, allowing us to move closer to a clear split of
consumer and provider clk APIs. We also remove some __init
markings in header files as they're useless and we're in the
area.

Cc: Jisheng Zhang 
Cc: Alexandre Belloni 
Cc: Sebastian Hesselbarth 
Signed-off-by: Stephen Boyd 
---

Changes from v1:
  * Fixed alignment
  * Added note about dropping __init in commit text

  drivers/clk/berlin/berlin2-avpll.c | 12 ++---
  drivers/clk/berlin/berlin2-avpll.h |  8 +---
  drivers/clk/berlin/berlin2-div.c   |  4 +-
  drivers/clk/berlin/berlin2-div.h   |  4 +-
  drivers/clk/berlin/berlin2-pll.c   |  6 +--
  drivers/clk/berlin/berlin2-pll.h   |  9 ++--
  drivers/clk/berlin/bg2.c   | 98 --
  drivers/clk/berlin/bg2q.c  | 39 ---
  8 files changed, 92 insertions(+), 88 deletions(-)

diff --git a/drivers/clk/berlin/berlin2-avpll.c 
b/drivers/clk/berlin/berlin2-avpll.c
index fd0f26c38465..5b0e4213b3ae 100644
--- a/drivers/clk/berlin/berlin2-avpll.c
+++ b/drivers/clk/berlin/berlin2-avpll.c
@@ -188,7 +188,7 @@ static const struct clk_ops berlin2_avpll_vco_ops = {
.recalc_rate= berlin2_avpll_vco_recalc_rate,
  };

-struct clk * __init berlin2_avpll_vco_register(void __iomem *base,
+int __init berlin2_avpll_vco_register(void __iomem *base,
   const char *name, const char *parent_name,
   u8 vco_flags, unsigned long flags)
  {
@@ -197,7 +197,7 @@ struct clk * __init berlin2_avpll_vco_register(void __iomem 
*base,

vco = kzalloc(sizeof(*vco), GFP_KERNEL);
if (!vco)
-   return ERR_PTR(-ENOMEM);
+   return -ENOMEM;

vco->base = base;
vco->flags = vco_flags;
@@ -208,7 +208,7 @@ struct clk * __init berlin2_avpll_vco_register(void __iomem 
*base,
init.num_parents = 1;
init.flags = flags;

-   return clk_register(NULL, >hw);
+   return clk_hw_register(NULL, >hw);
  }

  struct berlin2_avpll_channel {
@@ -364,7 +364,7 @@ static const struct clk_ops berlin2_avpll_channel_ops = {
   */
  static const u8 quirk_index[] __initconst = { 0, 6, 5, 4, 3, 2, 1, 7 };

-struct clk * __init berlin2_avpll_channel_register(void __iomem *base,
+int __init berlin2_avpll_channel_register(void __iomem *base,
   const char *name, u8 index, const char *parent_name,
   u8 ch_flags, unsigned long flags)
  {
@@ -373,7 +373,7 @@ struct clk * __init berlin2_avpll_channel_register(void 
__iomem *base,

ch = kzalloc(sizeof(*ch), GFP_KERNEL);
if (!ch)
-   return ERR_PTR(-ENOMEM);
+   return ENOMEM;

[...]

Stephen,

thanks for the conversion! There is a '-' missing in the line above.
With Jisheng's Tested-by and the minor fix above, feel free to add my

Acked-by: Sebastian Hesselbarth 

Sebastian

Re: [PATCH] pinctrl: fix pincontrol definition for marvell

[Sebastian Hesselbarth]

On July 23, 2016 12:45:23 AM Andreas Klinger <a...@it-klinger.de> wrote:

Sebastian Hesselbarth <sebastian.hesselba...@gmail.com> schrieb am Fri, 22. 
Jul 18:59:

On 16.07.2016 17:07, Andreas Klinger wrote:
>On Marvell mv88f6180 with pin control driver one can not use multi
>purpose pins 35 through 44.
>I'm using this controller on an embedded board and i found that the
>pin multiplexing is not the same as in the hardware spezification.
>This patch alters the pin description so that mpp pins 0 to 19 as well
>as 35 to 44 are usable.
>
>Pin settings i used can be found here:
>http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf

Hi Andreas,

sorry for the delay. I double-checked the HW datasheet above and can
confirm that 6180 uses MPP[19:0] and MPP[44:35], i.e. there is a hole
in the middle.

So, looking at your patch, you basically move MPP[n] to MPP[n+15]
starting with MPP[20] to match the HW spec.

That's fine with me, if it works on 6180 Kirkwood.


Hi Sebastian,

i've testet pins 41, 42, 43 and 44 on a real hardware.


Ok. Thanks for the confirmation.

However, I thought about it an realized that
we probably copied the 6180 table from the
old platform driver pre-dating pinctrl-API.

That is why for 6180 there is no hole as gpios
had to be continuous back then.

I cannot check right now, but if we already have
a mainlined board dtb with 6180 we have to
update that as well. If not, the change is
painless.



>Signed-off-by: Andreas Klinger <a...@it-klinger.de>

Reviewed-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>

And we should probably have a Fixes: tag + stable.


I now think we don't need a fixed tag and it
should not go to stable. It is probably the
first time anyone uses DT pinctrl-API for 6180.

Sebastian




Sebastian

>---
>  drivers/pinctrl/mvebu/pinctrl-kirkwood.c | 85 


>  1 file changed, 43 insertions(+), 42 deletions(-)
>
>diff --git a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c 
b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c

>index a78e9a4..5f89c26 100644
>--- a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
>+++ b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
>@@ -168,87 +168,87 @@ static struct mvebu_mpp_mode mv88f6xxx_mpp_modes[] = {
>MPP_VAR_FUNCTION(0x0, "gpo", NULL,   V(1, 1, 1, 1, 1, 1)),
>MPP_VAR_FUNCTION(0x1, "nand", "io1", V(1, 1, 1, 1, 1, 1))),
>MPP_MODE(20,
>-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
>+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x1, "ts", "mp0",   V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x2, "tdm", "tx0ql",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x3, "ge1", "txd0", V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x5, "sata1", "act",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0xb, "lcd", "d0",   V(0, 0, 0, 0, 1, 0)),
>-   MPP_VAR_FUNCTION(0xc, "mii", "rxerr",V(1, 0, 0, 0, 0, 0))),
>+   MPP_VAR_FUNCTION(0xc, "mii", "rxerr",V(0, 0, 0, 0, 0, 0))),
>MPP_MODE(21,
>-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
>+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x1, "ts", "mp1",   V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x2, "tdm", "rx0ql",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x3, "ge1", "txd1", V(0, 1, 1, 1, 1, 0)),
>-   MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(1, 0, 0, 0, 0, 0)),
>+   MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(0, 0, 0, 0, 0, 0)),
>MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x5, "sata0", "act",V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0xb, "lcd", "d1",   V(0, 0, 0, 0, 1, 0))),
>MPP_MODE(22,
>-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
>+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x1, "ts", "mp2",   V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x2, "tdm", "tx2ql",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x3, "ge1", "txd2", V(0,

Re: [PATCH] pinctrl: fix pincontrol definition for marvell

[Sebastian Hesselbarth]

On July 23, 2016 12:45:23 AM Andreas Klinger  wrote:

Sebastian Hesselbarth  schrieb am Fri, 22. 
Jul 18:59:

On 16.07.2016 17:07, Andreas Klinger wrote:
>On Marvell mv88f6180 with pin control driver one can not use multi
>purpose pins 35 through 44.
>I'm using this controller on an embedded board and i found that the
>pin multiplexing is not the same as in the hardware spezification.
>This patch alters the pin description so that mpp pins 0 to 19 as well
>as 35 to 44 are usable.
>
>Pin settings i used can be found here:
>http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf

Hi Andreas,

sorry for the delay. I double-checked the HW datasheet above and can
confirm that 6180 uses MPP[19:0] and MPP[44:35], i.e. there is a hole
in the middle.

So, looking at your patch, you basically move MPP[n] to MPP[n+15]
starting with MPP[20] to match the HW spec.

That's fine with me, if it works on 6180 Kirkwood.


Hi Sebastian,

i've testet pins 41, 42, 43 and 44 on a real hardware.


Ok. Thanks for the confirmation.

However, I thought about it an realized that
we probably copied the 6180 table from the
old platform driver pre-dating pinctrl-API.

That is why for 6180 there is no hole as gpios
had to be continuous back then.

I cannot check right now, but if we already have
a mainlined board dtb with 6180 we have to
update that as well. If not, the change is
painless.



>Signed-off-by: Andreas Klinger 

Reviewed-by: Sebastian Hesselbarth 

And we should probably have a Fixes: tag + stable.


I now think we don't need a fixed tag and it
should not go to stable. It is probably the
first time anyone uses DT pinctrl-API for 6180.

Sebastian




Sebastian

>---
>  drivers/pinctrl/mvebu/pinctrl-kirkwood.c | 85 


>  1 file changed, 43 insertions(+), 42 deletions(-)
>
>diff --git a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c 
b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c

>index a78e9a4..5f89c26 100644
>--- a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
>+++ b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
>@@ -168,87 +168,87 @@ static struct mvebu_mpp_mode mv88f6xxx_mpp_modes[] = {
>MPP_VAR_FUNCTION(0x0, "gpo", NULL,   V(1, 1, 1, 1, 1, 1)),
>MPP_VAR_FUNCTION(0x1, "nand", "io1", V(1, 1, 1, 1, 1, 1))),
>MPP_MODE(20,
>-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
>+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x1, "ts", "mp0",   V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x2, "tdm", "tx0ql",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x3, "ge1", "txd0", V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x5, "sata1", "act",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0xb, "lcd", "d0",   V(0, 0, 0, 0, 1, 0)),
>-   MPP_VAR_FUNCTION(0xc, "mii", "rxerr",V(1, 0, 0, 0, 0, 0))),
>+   MPP_VAR_FUNCTION(0xc, "mii", "rxerr",V(0, 0, 0, 0, 0, 0))),
>MPP_MODE(21,
>-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
>+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x1, "ts", "mp1",   V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x2, "tdm", "rx0ql",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x3, "ge1", "txd1", V(0, 1, 1, 1, 1, 0)),
>-   MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(1, 0, 0, 0, 0, 0)),
>+   MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(0, 0, 0, 0, 0, 0)),
>MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x5, "sata0", "act",V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0xb, "lcd", "d1",   V(0, 0, 0, 0, 1, 0))),
>MPP_MODE(22,
>-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
>+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x1, "ts", "mp2",   V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x2, "tdm", "tx2ql",V(0, 0, 1, 1, 1, 0)),
>MPP_VAR_FUNCTION(0x3, "ge1", "txd2", V(0, 1, 1, 1, 1, 0)),
>-   MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(1, 0, 0, 0, 0, 0)),
>+   MPP_

Re: [PATCH] pinctrl: fix pincontrol definition for marvell

[Sebastian Hesselbarth]

On 16.07.2016 17:07, Andreas Klinger wrote:

On Marvell mv88f6180 with pin control driver one can not use multi
purpose pins 35 through 44.
I'm using this controller on an embedded board and i found that the
pin multiplexing is not the same as in the hardware spezification.
This patch alters the pin description so that mpp pins 0 to 19 as well
as 35 to 44 are usable.

Pin settings i used can be found here:
http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf


Hi Andreas,

sorry for the delay. I double-checked the HW datasheet above and can
confirm that 6180 uses MPP[19:0] and MPP[44:35], i.e. there is a hole
in the middle.

So, looking at your patch, you basically move MPP[n] to MPP[n+15]
starting with MPP[20] to match the HW spec.

That's fine with me, if it works on 6180 Kirkwood.


Signed-off-by: Andreas Klinger <a...@it-klinger.de>


Reviewed-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>

And we should probably have a Fixes: tag + stable.

Sebastian


---
  drivers/pinctrl/mvebu/pinctrl-kirkwood.c | 85 
  1 file changed, 43 insertions(+), 42 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c 
b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
index a78e9a4..5f89c26 100644
--- a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
+++ b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
@@ -168,87 +168,87 @@ static struct mvebu_mpp_mode mv88f6xxx_mpp_modes[] = {
MPP_VAR_FUNCTION(0x0, "gpo", NULL,   V(1, 1, 1, 1, 1, 1)),
MPP_VAR_FUNCTION(0x1, "nand", "io1", V(1, 1, 1, 1, 1, 1))),
MPP_MODE(20,
-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x1, "ts", "mp0",   V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x2, "tdm", "tx0ql",V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x3, "ge1", "txd0", V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x5, "sata1", "act",V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0xb, "lcd", "d0",   V(0, 0, 0, 0, 1, 0)),
-   MPP_VAR_FUNCTION(0xc, "mii", "rxerr",V(1, 0, 0, 0, 0, 0))),
+   MPP_VAR_FUNCTION(0xc, "mii", "rxerr",V(0, 0, 0, 0, 0, 0))),
MPP_MODE(21,
-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x1, "ts", "mp1",   V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x2, "tdm", "rx0ql",V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x3, "ge1", "txd1", V(0, 1, 1, 1, 1, 0)),
-   MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(1, 0, 0, 0, 0, 0)),
+   MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(0, 0, 0, 0, 0, 0)),
MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x5, "sata0", "act",V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0xb, "lcd", "d1",   V(0, 0, 0, 0, 1, 0))),
MPP_MODE(22,
-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x1, "ts", "mp2",   V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x2, "tdm", "tx2ql",V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x3, "ge1", "txd2", V(0, 1, 1, 1, 1, 0)),
-   MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(1, 0, 0, 0, 0, 0)),
+   MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(0, 0, 0, 0, 0, 0)),
MPP_VAR_FUNCTION(0x4, "audio", "rmclk",  V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x5, "sata1", "prsnt",  V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0xb, "lcd", "d2",   V(0, 0, 0, 0, 1, 0))),
MPP_MODE(23,
-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x1, "ts", "mp3",   V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x2, "tdm", "rx2

Re: [PATCH] pinctrl: fix pincontrol definition for marvell

[Sebastian Hesselbarth]

On 16.07.2016 17:07, Andreas Klinger wrote:

On Marvell mv88f6180 with pin control driver one can not use multi
purpose pins 35 through 44.
I'm using this controller on an embedded board and i found that the
pin multiplexing is not the same as in the hardware spezification.
This patch alters the pin description so that mpp pins 0 to 19 as well
as 35 to 44 are usable.

Pin settings i used can be found here:
http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf


Hi Andreas,

sorry for the delay. I double-checked the HW datasheet above and can
confirm that 6180 uses MPP[19:0] and MPP[44:35], i.e. there is a hole
in the middle.

So, looking at your patch, you basically move MPP[n] to MPP[n+15]
starting with MPP[20] to match the HW spec.

That's fine with me, if it works on 6180 Kirkwood.


Signed-off-by: Andreas Klinger 


Reviewed-by: Sebastian Hesselbarth 

And we should probably have a Fixes: tag + stable.

Sebastian


---
  drivers/pinctrl/mvebu/pinctrl-kirkwood.c | 85 
  1 file changed, 43 insertions(+), 42 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c 
b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
index a78e9a4..5f89c26 100644
--- a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
+++ b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
@@ -168,87 +168,87 @@ static struct mvebu_mpp_mode mv88f6xxx_mpp_modes[] = {
MPP_VAR_FUNCTION(0x0, "gpo", NULL,   V(1, 1, 1, 1, 1, 1)),
MPP_VAR_FUNCTION(0x1, "nand", "io1", V(1, 1, 1, 1, 1, 1))),
MPP_MODE(20,
-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x1, "ts", "mp0",   V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x2, "tdm", "tx0ql",V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x3, "ge1", "txd0", V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x5, "sata1", "act",V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0xb, "lcd", "d0",   V(0, 0, 0, 0, 1, 0)),
-   MPP_VAR_FUNCTION(0xc, "mii", "rxerr",V(1, 0, 0, 0, 0, 0))),
+   MPP_VAR_FUNCTION(0xc, "mii", "rxerr",V(0, 0, 0, 0, 0, 0))),
MPP_MODE(21,
-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x1, "ts", "mp1",   V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x2, "tdm", "rx0ql",V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x3, "ge1", "txd1", V(0, 1, 1, 1, 1, 0)),
-   MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(1, 0, 0, 0, 0, 0)),
+   MPP_VAR_FUNCTION(0x4, "audio", "spdifi", V(0, 0, 0, 0, 0, 0)),
MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x5, "sata0", "act",V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0xb, "lcd", "d1",   V(0, 0, 0, 0, 1, 0))),
MPP_MODE(22,
-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x1, "ts", "mp2",   V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x2, "tdm", "tx2ql",V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x3, "ge1", "txd2", V(0, 1, 1, 1, 1, 0)),
-   MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(1, 0, 0, 0, 0, 0)),
+   MPP_VAR_FUNCTION(0x4, "audio", "spdifo", V(0, 0, 0, 0, 0, 0)),
MPP_VAR_FUNCTION(0x4, "audio", "rmclk",  V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x5, "sata1", "prsnt",  V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0xb, "lcd", "d2",   V(0, 0, 0, 0, 1, 0))),
MPP_MODE(23,
-   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(1, 1, 1, 1, 1, 0)),
+   MPP_VAR_FUNCTION(0x0, "gpio", NULL,  V(0, 1, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x1, "ts", "mp3",   V(0, 0, 1, 1, 1, 0)),
MPP_VAR_FUNCTION(0x2, "tdm", "rx2ql",V(0, 0, 1, 1, 1, 0)),
MPP_

Re: [PATCH] arm64: dts: berlin4ct: Add L2 cache topology

[Sebastian Hesselbarth]

On 07.07.2016 07:48, Jisheng Zhang wrote:
> On Wed, 6 Jul 2016 19:49:01 +0200 Sebastian Hesselbarth wrote:
>> On 16.06.2016 10:40, Jisheng Zhang wrote:
>>> This patch adds the L2 cache topology for berlin4ct which has 1MB L2
>>> cache.
>>>
>>> Signed-off-by: Jisheng Zhang <jszh...@marvell.com>
>>> ---
>>>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
>>> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
>>> index 099ad93..c9e3a98 100644
>>> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
>>> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi  
>> [...]
>>> @@ -92,9 +95,14 @@
>>> device_type = "cpu";
>>> reg = <0x3>;
>>> enable-method = "psci";
>>> +   next-level-cache = <_0>;
>>> cpu-idle-states = <_SLEEP_0>;
>>> };
>>>  
>>> +   L2_0: l2-cache0 {  
>>
>> The node name should just have a generic name that reflects
>> the purpose of the unit it represents, i.e.
>> s/l2-cache0/cache/
> 
> IMHO, "cache" is too generic, this is L2 cache topology, so in v2, I use 
> "l2-cache" instead. what do you think?
> 
> PS: I found other arm64 SoCs also use "l2-cache" as the node name.

Yeah, I realized that too. Anyway, the node name should be as generic
as possible. Moreover, the more specific compatible string below also
is "cache", too. So I see no reason why the node name should be more
specific than the compatible.

>>> +   compatible = "cache";
>>> +   };

If you want to have the cache-level represented in the node, I guess
you can use cache-level property. However, I cannot find any cache
related binding documentation other than for arm(32) and powerpc that
mentions cache-level property.

If you are fine with it, I can pick up the v2 you sent earlier, rename
the node to "cache" only, and add a cache-level = <2>; property while
applying.

Sebastian

>>> idle-states {
>>> entry-method = "psci";
>>> CPU_SLEEP_0: cpu-sleep-0 {
>>>   
>>
> 

Re: [PATCH] arm64: dts: berlin4ct: Add L2 cache topology

[Sebastian Hesselbarth]

On 07.07.2016 07:48, Jisheng Zhang wrote:
> On Wed, 6 Jul 2016 19:49:01 +0200 Sebastian Hesselbarth wrote:
>> On 16.06.2016 10:40, Jisheng Zhang wrote:
>>> This patch adds the L2 cache topology for berlin4ct which has 1MB L2
>>> cache.
>>>
>>> Signed-off-by: Jisheng Zhang 
>>> ---
>>>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
>>> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
>>> index 099ad93..c9e3a98 100644
>>> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
>>> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi  
>> [...]
>>> @@ -92,9 +95,14 @@
>>> device_type = "cpu";
>>> reg = <0x3>;
>>> enable-method = "psci";
>>> +   next-level-cache = <_0>;
>>> cpu-idle-states = <_SLEEP_0>;
>>> };
>>>  
>>> +   L2_0: l2-cache0 {  
>>
>> The node name should just have a generic name that reflects
>> the purpose of the unit it represents, i.e.
>> s/l2-cache0/cache/
> 
> IMHO, "cache" is too generic, this is L2 cache topology, so in v2, I use 
> "l2-cache" instead. what do you think?
> 
> PS: I found other arm64 SoCs also use "l2-cache" as the node name.

Yeah, I realized that too. Anyway, the node name should be as generic
as possible. Moreover, the more specific compatible string below also
is "cache", too. So I see no reason why the node name should be more
specific than the compatible.

>>> +   compatible = "cache";
>>> +   };

If you want to have the cache-level represented in the node, I guess
you can use cache-level property. However, I cannot find any cache
related binding documentation other than for arm(32) and powerpc that
mentions cache-level property.

If you are fine with it, I can pick up the v2 you sent earlier, rename
the node to "cache" only, and add a cache-level = <2>; property while
applying.

Sebastian

>>> idle-states {
>>> entry-method = "psci";
>>> CPU_SLEEP_0: cpu-sleep-0 {
>>>   
>>
> 

Re: [PATCH v2] arm64: dts: berlin4ct: switch to Cortex-A53 specific pmu nodes

[Sebastian Hesselbarth]

On 16.12.2015 21:30, Sebastian Hesselbarth wrote:
> On 15.12.2015 15:57, Jisheng Zhang wrote:
>> Commit ac82d1277215 ("arm64: perf: add Cortex-A53 support") adds the
>> cortex A53 PMU support, thus instead of using the generic armv8-pmuv3
>> compatibility use the more specific Cortex A53 compatibility.
>>
>> Signed-off-by: Jisheng Zhang <jszh...@marvell.com>
>> ---
>> Since v1:
>>  - keep "arm,armv8-pmuv3" as a fallback in the compatible list. Thank
>>Arnd and Mark.
> 
> Applied to berlin64/dt with an updated commit message that
> reflects v2 changes.

Unfortunately, I was too busy to get this upstream earlier.
I re-applied this to the current berlin64/dt.

Sebastian

>>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
>> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
>> index 099ad93..f926256 100644
>> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
>> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
>> @@ -115,7 +115,7 @@
>>  };
>>  
>>  pmu {
>> -compatible = "arm,armv8-pmuv3";
>> +compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
>>  interrupts = ,
>>   ,
>>   ,
>>
> 

Re: [PATCH v2] arm64: dts: berlin4ct: switch to Cortex-A53 specific pmu nodes

[Sebastian Hesselbarth]

On 16.12.2015 21:30, Sebastian Hesselbarth wrote:
> On 15.12.2015 15:57, Jisheng Zhang wrote:
>> Commit ac82d1277215 ("arm64: perf: add Cortex-A53 support") adds the
>> cortex A53 PMU support, thus instead of using the generic armv8-pmuv3
>> compatibility use the more specific Cortex A53 compatibility.
>>
>> Signed-off-by: Jisheng Zhang 
>> ---
>> Since v1:
>>  - keep "arm,armv8-pmuv3" as a fallback in the compatible list. Thank
>>Arnd and Mark.
> 
> Applied to berlin64/dt with an updated commit message that
> reflects v2 changes.

Unfortunately, I was too busy to get this upstream earlier.
I re-applied this to the current berlin64/dt.

Sebastian

>>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
>> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
>> index 099ad93..f926256 100644
>> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
>> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
>> @@ -115,7 +115,7 @@
>>  };
>>  
>>  pmu {
>> -compatible = "arm,armv8-pmuv3";
>> +compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
>>  interrupts = ,
>>   ,
>>   ,
>>
> 

Re: [PATCH 0/3] arm: dts: berlin: enable all dw_wdt nodes unconditionally

[Sebastian Hesselbarth]

On 06.07.2016 08:41, Jisheng Zhang wrote:
> When we add watchdog dt nodes into berlin dtsi, the dw_wdt driver can't
> support multiple variants, so we have to keep one enabled and others
> disabled. After commit f29a72c24ad4 ("watchdog: dw_wdt: Convert to use
> watchdog infrastructure"), the dw_wdt driver can support multiple
> variants, so we can unconditionally enable all dw_wdt nodes now.
> 
> Jisheng Zhang (3):
>   arm: dts: berlin2: enable all wdt nodes unconditionally
>   arm: dts: berlin2q: enable all wdt nodes unconditionally
>   arm64: dts: berlin4ct: enable all wdt nodes unconditionally

Applied all three to berlin/dt and berlin64/dt respectively.

Thanks!

Sebastian

>  arch/arm/boot/dts/berlin2.dtsi | 2 --
>  arch/arm/boot/dts/berlin2q.dtsi| 2 --
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 2 --
>  3 files changed, 6 deletions(-)
> 

Re: [PATCH 0/3] arm: dts: berlin: enable all dw_wdt nodes unconditionally

[Sebastian Hesselbarth]

On 06.07.2016 08:41, Jisheng Zhang wrote:
> When we add watchdog dt nodes into berlin dtsi, the dw_wdt driver can't
> support multiple variants, so we have to keep one enabled and others
> disabled. After commit f29a72c24ad4 ("watchdog: dw_wdt: Convert to use
> watchdog infrastructure"), the dw_wdt driver can support multiple
> variants, so we can unconditionally enable all dw_wdt nodes now.
> 
> Jisheng Zhang (3):
>   arm: dts: berlin2: enable all wdt nodes unconditionally
>   arm: dts: berlin2q: enable all wdt nodes unconditionally
>   arm64: dts: berlin4ct: enable all wdt nodes unconditionally

Applied all three to berlin/dt and berlin64/dt respectively.

Thanks!

Sebastian

>  arch/arm/boot/dts/berlin2.dtsi | 2 --
>  arch/arm/boot/dts/berlin2q.dtsi| 2 --
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 2 --
>  3 files changed, 6 deletions(-)
> 

Re: [PATCH] arm64: dts: berlin4ct: Add L2 cache topology

[Sebastian Hesselbarth]

On 16.06.2016 10:40, Jisheng Zhang wrote:
> This patch adds the L2 cache topology for berlin4ct which has 1MB L2
> cache.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index 099ad93..c9e3a98 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
[...]
> @@ -92,9 +95,14 @@
>   device_type = "cpu";
>   reg = <0x3>;
>   enable-method = "psci";
> + next-level-cache = <_0>;
>   cpu-idle-states = <_SLEEP_0>;
>   };
>  
> + L2_0: l2-cache0 {

Jisheng,

The node name should just have a generic name that reflects
the purpose of the unit it represents, i.e.
s/l2-cache0/cache/

nits:
- What is that "0" for? Please remove if there is no good reason.
- Does the node label need to be upper-case? Please make it lower case.

Sebastian

> + compatible = "cache";
> + };
> +
>   idle-states {
>   entry-method = "psci";
>   CPU_SLEEP_0: cpu-sleep-0 {
> 

Re: [PATCH] arm64: dts: berlin4ct: Add L2 cache topology

[Sebastian Hesselbarth]

On 16.06.2016 10:40, Jisheng Zhang wrote:
> This patch adds the L2 cache topology for berlin4ct which has 1MB L2
> cache.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index 099ad93..c9e3a98 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
[...]
> @@ -92,9 +95,14 @@
>   device_type = "cpu";
>   reg = <0x3>;
>   enable-method = "psci";
> + next-level-cache = <_0>;
>   cpu-idle-states = <_SLEEP_0>;
>   };
>  
> + L2_0: l2-cache0 {

Jisheng,

The node name should just have a generic name that reflects
the purpose of the unit it represents, i.e.
s/l2-cache0/cache/

nits:
- What is that "0" for? Please remove if there is no good reason.
- Does the node label need to be upper-case? Please make it lower case.

Sebastian

> + compatible = "cache";
> + };
> +
>   idle-states {
>   entry-method = "psci";
>   CPU_SLEEP_0: cpu-sleep-0 {
> 

Re: [PATCH v2] arm64: dts: berlin4ct: switch to Cortex-A53 specific pmu nodes

[Sebastian Hesselbarth]

On 15.12.2015 15:57, Jisheng Zhang wrote:
> Commit ac82d1277215 ("arm64: perf: add Cortex-A53 support") adds the
> cortex A53 PMU support, thus instead of using the generic armv8-pmuv3
> compatibility use the more specific Cortex A53 compatibility.
> 
> Signed-off-by: Jisheng Zhang 
> ---
> Since v1:
>  - keep "arm,armv8-pmuv3" as a fallback in the compatible list. Thank
>Arnd and Mark.

Applied to berlin64/dt with an updated commit message that
reflects v2 changes.

Sebastian

>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index 099ad93..f926256 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -115,7 +115,7 @@
>   };
>  
>   pmu {
> - compatible = "arm,armv8-pmuv3";
> + compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
>   interrupts = ,
>,
>,
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] arm64: dts: berlin4ct: switch to Cortex-A53 specific pmu nodes

[Sebastian Hesselbarth]

On 15.12.2015 15:57, Jisheng Zhang wrote:
> Commit ac82d1277215 ("arm64: perf: add Cortex-A53 support") adds the
> cortex A53 PMU support, thus instead of using the generic armv8-pmuv3
> compatibility use the more specific Cortex A53 compatibility.
> 
> Signed-off-by: Jisheng Zhang 
> ---
> Since v1:
>  - keep "arm,armv8-pmuv3" as a fallback in the compatible list. Thank
>Arnd and Mark.

Applied to berlin64/dt with an updated commit message that
reflects v2 changes.

Sebastian

>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index 099ad93..f926256 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -115,7 +115,7 @@
>   };
>  
>   pmu {
> - compatible = "arm,armv8-pmuv3";
> + compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
>   interrupts = ,
>,
>,
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MAINTAINERS: Add missing platform maintainers for dts files

[Sebastian Hesselbarth]

On 11.12.2015 00:38, Rob Herring wrote:

Platform dts files need to be reviewed primarily by the platform
maintainers as dts files typically go in thru their trees. Add the missing
paths where there are existing maintainers listed.

Signed-off-by: Rob Herring 
---
  MAINTAINERS | 20 +++-
  1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 69c8a9c..415b731 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS

[...]

@@ -1270,6 +1278,7 @@ L:linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
  S:Maintained
  F:arch/arm/mach-berlin/
  F:arch/arm/boot/dts/berlin*
+F: arch/arm64/boot/dts/marvell/berlin*


For Berlin,

Acked-by: Sebastian Hesselbarth 

Thanks!


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MAINTAINERS: Add missing platform maintainers for dts files

[Sebastian Hesselbarth]

On 11.12.2015 00:38, Rob Herring wrote:

Platform dts files need to be reviewed primarily by the platform
maintainers as dts files typically go in thru their trees. Add the missing
paths where there are existing maintainers listed.

Signed-off-by: Rob Herring <r...@kernel.org>
---
  MAINTAINERS | 20 +++-
  1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 69c8a9c..415b731 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS

[...]

@@ -1270,6 +1278,7 @@ L:linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
  S:Maintained
  F:arch/arm/mach-berlin/
  F:arch/arm/boot/dts/berlin*
+F: arch/arm64/boot/dts/marvell/berlin*


For Berlin,

Acked-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>

Thanks!


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] arm: dts: berlin: fix BG2Q sdhci clk

[Sebastian Hesselbarth]

On 07.12.2015 14:09, Jisheng Zhang wrote:
> CLKID_SDIO is used as the 2nd optional clk for all sdhci hosts in BG2Q.
> We removed CLK_IGNORE_UNUSED from CLKID_SDIO's flag. These two patches
> fixes this clk issue.
> 
> Jisheng Zhang (2):
>   ARM: dts: berlin: correct BG2Q's sdhci2 2nd clock
>   ARM: dts: berlin: add 2nd clock for BG2Q sdhci0 and sdhci1
> 
>  arch/arm/boot/dts/berlin2q.dtsi | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 

Series applied to berlin/fixes.

Thanks!

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] arm: dts: berlin: fix BG2Q sdhci clk

[Sebastian Hesselbarth]

On 07.12.2015 14:09, Jisheng Zhang wrote:
> CLKID_SDIO is used as the 2nd optional clk for all sdhci hosts in BG2Q.
> We removed CLK_IGNORE_UNUSED from CLKID_SDIO's flag. These two patches
> fixes this clk issue.
> 
> Jisheng Zhang (2):
>   ARM: dts: berlin: correct BG2Q's sdhci2 2nd clock
>   ARM: dts: berlin: add 2nd clock for BG2Q sdhci0 and sdhci1
> 
>  arch/arm/boot/dts/berlin2q.dtsi | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 

Series applied to berlin/fixes.

Thanks!

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 PART-RESEND 0/2] berlin sdhci clock clean up

[Sebastian Hesselbarth]

On 19.11.2015 21:31, Sebastian Hesselbarth wrote:
> On 16.11.2015 11:56, Jisheng Zhang wrote:
>> Add or fix the optional clock property, then remove the CLK_IGNORE_UNUSED
>> flag for sdio clk(s).
>>
>> This is a partialy resend of 
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/379457.html
>>
>> patch3, patch4 has been merged.
> 
> Great! Really!
> 
> As they have been taken without my Acked-by, ignoring my request to
> _not_ remove the CLK_IGNORE_UNUSED flags _before_ these two, the
> remaining patches now become fixes.
> 
> Please resend the patches with a proper description what and why they
> are fixes now.

Is this going to be resolved anytime soon?

If not, I am going to send a revert for the CLK_IGNORE_UNUSED patch
and we start this from the beginning.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm64: dts: berlin4ct: support cpuidle-dt

[Sebastian Hesselbarth]

On 30.11.2015 14:41, Jisheng Zhang wrote:
> This patch adds an idle-states node to describe the berlin4ct idle
> states and also adds references to the idle-states node in all CPU
> nodes. After this patch cpuidle is enabled.
> 
> Signed-off-by: Jisheng Zhang 

Applied to berlin64/dt with Lorenzo's Ack.

Thanks!

Sebastian

> ---
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index 39d0676..3649cea 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -69,6 +69,7 @@
>   device_type = "cpu";
>   reg = <0x0>;
>   enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
>   };
>  
>   cpu1: cpu@1 {
> @@ -76,6 +77,7 @@
>   device_type = "cpu";
>   reg = <0x1>;
>   enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
>   };
>  
>   cpu2: cpu@2 {
> @@ -83,6 +85,7 @@
>   device_type = "cpu";
>   reg = <0x2>;
>   enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
>   };
>  
>   cpu3: cpu@3 {
> @@ -90,6 +93,19 @@
>   device_type = "cpu";
>   reg = <0x3>;
>   enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> + };
> +
> + idle-states {
> + entry-method = "psci";
> + CPU_SLEEP_0: cpu-sleep-0 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + arm,psci-suspend-param = <0x001>;
> + entry-latency-us = <75>;
> + exit-latency-us = <155>;
> + min-residency-us = <1000>;
> + };
>   };
>   };
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm: dts: berlin2q-marvell-dmp: add sdhci1 fully functionality

[Sebastian Hesselbarth]

On 30.11.2015 14:54, Jisheng Zhang wrote:
> The sdhci1 on Marvell BG2Q DMP board is used as sdcard interface, we
> have gpios for card detection, write-protect, vqmmc and vmmc.
> 
> This patch adds pinmux for this sdcard interface, then adds regulators
> for vmmc and vqmmc, lastly adds cd-gpios, wp-gpios properties.
> 
> Signed-off-by: Jisheng Zhang 

Applied to berlin/dt.

> ---
> since v1:

Please also increment the patch subject version next time.

Thanks!

Sebastian

>  - move sd1_pmux to soc dtsi
>  - remove cd-inverted and make cd-gpio GPIO_ACTIVE_LOW
> 
>  arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 37 
> --
>  arch/arm/boot/dts/berlin2q.dtsi|  5 
>  2 files changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts 
> b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> index cdcf89b..33b2875 100644
> --- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> +++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> @@ -84,12 +84,45 @@
>   gpio = < 12 GPIO_ACTIVE_HIGH>;
>   enable-active-high;
>   };
> +
> + reg_sdio1_vmmc: regulator@3 {
> + compatible = "regulator-fixed";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "sdio1_vmmc";
> + enable-active-high;
> + regulator-boot-on;
> + gpio = < 21 GPIO_ACTIVE_HIGH>;
> + };
> +
> + reg_sdio1_vqmmc: regulator@4 {
> + compatible = "regulator-gpio";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "sdio1_vqmmc";
> + regulator-type = "voltage";
> + enable-active-high;
> + gpios = < 16 GPIO_ACTIVE_HIGH>;
> + states = <330 0x1
> +   180 0x0>;
> + };
> + };
> +};
> +
> +_pinctrl {
> + sd1gpio_pmux: sd1pwr-pmux {
> + groups = "G23", "G32";
> + function = "gpio";
>   };
>  };
>  
>   {
> - broken-cd;
> - sdhci,wp-inverted;
> + vmmc-supply = <_sdio1_vmmc>;
> + vqmmc-supply = <_sdio1_vqmmc>;
> + cd-gpios = < 30 GPIO_ACTIVE_LOW>;
> + wp-gpios = < 0 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <_pmux>, <_pmux>;
> + pinctrl-names = "default";
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
> index 8ea177f..73a9362 100644
> --- a/arch/arm/boot/dts/berlin2q.dtsi
> +++ b/arch/arm/boot/dts/berlin2q.dtsi
> @@ -417,6 +417,11 @@
>   soc_pinctrl: pin-controller {
>   compatible = "marvell,berlin2q-soc-pinctrl";
>  
> + sd1_pmux: sd1-pmux {
> + groups = "G31";
> + function = "sd1";
> + };
> +
>   twsi0_pmux: twsi0-pmux {
>   groups = "G6";
>   function = "twsi0";
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 PART-RESEND 0/2] berlin sdhci clock clean up

[Sebastian Hesselbarth]

On 19.11.2015 21:31, Sebastian Hesselbarth wrote:
> On 16.11.2015 11:56, Jisheng Zhang wrote:
>> Add or fix the optional clock property, then remove the CLK_IGNORE_UNUSED
>> flag for sdio clk(s).
>>
>> This is a partialy resend of 
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/379457.html
>>
>> patch3, patch4 has been merged.
> 
> Great! Really!
> 
> As they have been taken without my Acked-by, ignoring my request to
> _not_ remove the CLK_IGNORE_UNUSED flags _before_ these two, the
> remaining patches now become fixes.
> 
> Please resend the patches with a proper description what and why they
> are fixes now.

Is this going to be resolved anytime soon?

If not, I am going to send a revert for the CLK_IGNORE_UNUSED patch
and we start this from the beginning.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm: dts: berlin2q-marvell-dmp: add sdhci1 fully functionality

[Sebastian Hesselbarth]

On 30.11.2015 14:54, Jisheng Zhang wrote:
> The sdhci1 on Marvell BG2Q DMP board is used as sdcard interface, we
> have gpios for card detection, write-protect, vqmmc and vmmc.
> 
> This patch adds pinmux for this sdcard interface, then adds regulators
> for vmmc and vqmmc, lastly adds cd-gpios, wp-gpios properties.
> 
> Signed-off-by: Jisheng Zhang 

Applied to berlin/dt.

> ---
> since v1:

Please also increment the patch subject version next time.

Thanks!

Sebastian

>  - move sd1_pmux to soc dtsi
>  - remove cd-inverted and make cd-gpio GPIO_ACTIVE_LOW
> 
>  arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 37 
> --
>  arch/arm/boot/dts/berlin2q.dtsi|  5 
>  2 files changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts 
> b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> index cdcf89b..33b2875 100644
> --- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> +++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> @@ -84,12 +84,45 @@
>   gpio = < 12 GPIO_ACTIVE_HIGH>;
>   enable-active-high;
>   };
> +
> + reg_sdio1_vmmc: regulator@3 {
> + compatible = "regulator-fixed";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "sdio1_vmmc";
> + enable-active-high;
> + regulator-boot-on;
> + gpio = < 21 GPIO_ACTIVE_HIGH>;
> + };
> +
> + reg_sdio1_vqmmc: regulator@4 {
> + compatible = "regulator-gpio";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "sdio1_vqmmc";
> + regulator-type = "voltage";
> + enable-active-high;
> + gpios = < 16 GPIO_ACTIVE_HIGH>;
> + states = <330 0x1
> +   180 0x0>;
> + };
> + };
> +};
> +
> +_pinctrl {
> + sd1gpio_pmux: sd1pwr-pmux {
> + groups = "G23", "G32";
> + function = "gpio";
>   };
>  };
>  
>   {
> - broken-cd;
> - sdhci,wp-inverted;
> + vmmc-supply = <_sdio1_vmmc>;
> + vqmmc-supply = <_sdio1_vqmmc>;
> + cd-gpios = < 30 GPIO_ACTIVE_LOW>;
> + wp-gpios = < 0 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <_pmux>, <_pmux>;
> + pinctrl-names = "default";
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
> index 8ea177f..73a9362 100644
> --- a/arch/arm/boot/dts/berlin2q.dtsi
> +++ b/arch/arm/boot/dts/berlin2q.dtsi
> @@ -417,6 +417,11 @@
>   soc_pinctrl: pin-controller {
>   compatible = "marvell,berlin2q-soc-pinctrl";
>  
> + sd1_pmux: sd1-pmux {
> + groups = "G31";
> + function = "sd1";
> + };
> +
>   twsi0_pmux: twsi0-pmux {
>   groups = "G6";
>   function = "twsi0";
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm64: dts: berlin4ct: support cpuidle-dt

[Sebastian Hesselbarth]

On 30.11.2015 14:41, Jisheng Zhang wrote:
> This patch adds an idle-states node to describe the berlin4ct idle
> states and also adds references to the idle-states node in all CPU
> nodes. After this patch cpuidle is enabled.
> 
> Signed-off-by: Jisheng Zhang 

Applied to berlin64/dt with Lorenzo's Ack.

Thanks!

Sebastian

> ---
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index 39d0676..3649cea 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -69,6 +69,7 @@
>   device_type = "cpu";
>   reg = <0x0>;
>   enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
>   };
>  
>   cpu1: cpu@1 {
> @@ -76,6 +77,7 @@
>   device_type = "cpu";
>   reg = <0x1>;
>   enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
>   };
>  
>   cpu2: cpu@2 {
> @@ -83,6 +85,7 @@
>   device_type = "cpu";
>   reg = <0x2>;
>   enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
>   };
>  
>   cpu3: cpu@3 {
> @@ -90,6 +93,19 @@
>   device_type = "cpu";
>   reg = <0x3>;
>   enable-method = "psci";
> + cpu-idle-states = <_SLEEP_0>;
> + };
> +
> + idle-states {
> + entry-method = "psci";
> + CPU_SLEEP_0: cpu-sleep-0 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + arm,psci-suspend-param = <0x001>;
> + entry-latency-us = <75>;
> + exit-latency-us = <155>;
> + min-residency-us = <1000>;
> + };
>   };
>   };
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] ARM: dt: mvebu: ix4-300d: Add ECC properties to NAND flash

[Sebastian Hesselbarth]

On 29.11.2015 15:35, Thomas Petazzoni wrote:

Adding Ezequiel Garcia in Cc.

On Sat, 28 Nov 2015 12:14:08 +0100, Sebastian Hesselbarth wrote:

The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection.
Add the corresponding properties to the NAND node.


If the ONFI information from the NAND flash say that it requires 4 bits
per 512, then there should be no need to add this information to the
Device Tree as the pxa3xx_nand driver by default uses the ONFI
information.


Thomas,

as said in the cover letter, this is also DT cleanup with barebox
bootloader in mind. I do not accept what Linux' pxa3xx_nand driver
is doing as a reference here ;)


Those properties are only needed when for some reason the vendor has
chosen to use a ECC strength that doesn't match with the one advertised
by the flash in its ONFI information (either stronger or weaker). But
in this case, your commit log is confusing, because it says that the
"NAND device ... uses 4-bit BCH ECC protection". If it really does,
then the patch is not needed :-)


I agree that if ONFI is already advertising 4/512 ECC (and it is), we
do not need the properties. Anyway, IIRC barebox does not yet properly
parse ONFI or at least it does not derive minimum ECC settings from it.

I'll have to have a closer look at barebox' ONFI parsing capabilites
and can live with this patch not applied even though it does no harm.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] ARM: dt: mvebu: ix4-300d: Add ECC properties to NAND flash

[Sebastian Hesselbarth]

On 29.11.2015 15:35, Thomas Petazzoni wrote:

Adding Ezequiel Garcia in Cc.

On Sat, 28 Nov 2015 12:14:08 +0100, Sebastian Hesselbarth wrote:

The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection.
Add the corresponding properties to the NAND node.


If the ONFI information from the NAND flash say that it requires 4 bits
per 512, then there should be no need to add this information to the
Device Tree as the pxa3xx_nand driver by default uses the ONFI
information.


Thomas,

as said in the cover letter, this is also DT cleanup with barebox
bootloader in mind. I do not accept what Linux' pxa3xx_nand driver
is doing as a reference here ;)


Those properties are only needed when for some reason the vendor has
chosen to use a ECC strength that doesn't match with the one advertised
by the flash in its ONFI information (either stronger or weaker). But
in this case, your commit log is confusing, because it says that the
"NAND device ... uses 4-bit BCH ECC protection". If it really does,
then the patch is not needed :-)


I agree that if ONFI is already advertising 4/512 ECC (and it is), we
do not need the properties. Anyway, IIRC barebox does not yet properly
parse ONFI or at least it does not derive minimum ECC settings from it.

I'll have to have a closer look at barebox' ONFI parsing capabilites
and can live with this patch not applied even though it does no harm.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] ARM: dt: mvebu: ix4-300d: move partitions to partition sub-node

[Sebastian Hesselbarth]

On 28.11.2015 18:00, Andrew Lunn wrote:
> On Sat, Nov 28, 2015 at 12:14:06PM +0100, Sebastian Hesselbarth wrote:
>> NAND flash partitions should be part of a partitions sub-node
>> not the flash node itself. Move the partitions which will also
>> allow different bootloaders get rid of the stock partitions
>> easily by removing the partitions node.
>>
>> Signed-off-by: Sebastian Hesselbarth 
> 
> Humm, did not know that. Quoting 
> Documentation/devicetree/bindings/mtd/partition.txt:
> 
>   The partition table should be a subnode of the mtd node and
>   should be named 'partitions'. Partitions are defined in subnodes
>   of the partitions node.
> 
>   For backwards compatibility partitions as direct subnodes of the
>   mtd device are supported. This use is discouraged.
> 
> It also looks like none of the other MVEBU maintainers know that
> either, since a quick look at the .dts files shows very few have a
> partitions node.

Me neither, Linus Walleij's latest contribution to the pogoplug
series showed it to me. And while I am working on barebox support
for the ix4, I always wanted to remove the stock partitions easily.

Barebox always uses internal registers at 0xf100 so it will
never boot that stupid stock kernel that depends on 0xd000
registers.

> Acked-by: Andrew Lunn 
> 
> Thanks
>   Andrew

ditto ;)

Sebastian

>> ---
>> Cc: Jason Cooper  
>> Cc: Andrew Lunn 
>> Cc: Gregory Clement  
>> Cc: Rob Herring  
>> Cc: Pawel Moll  
>> Cc: Mark Rutland  
>> Cc: Ian Campbell  
>> Cc: Kumar Gala  
>> Cc: Russell King  
>> Cc: Benoit Masson 
>> Cc: linux-arm-ker...@lists.infradead.org 
>> Cc: devicet...@vger.kernel.org 
>> Cc: linux-kernel@vger.kernel.org 
>> ---
>>  arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 67 
>> +
>>  1 file changed, 36 insertions(+), 31 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts 
>> b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
>> index 30a0a6eac645..76781fd18624 100644
>> --- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
>> +++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
>> @@ -151,37 +151,42 @@
>>  marvell,nand-enable-arbiter;
>>  nand-on-flash-bbt;
>>  
>> -partition@0 {
>> -label = "u-boot";
>> -reg = <0x000 0xe>;
>> -read-only;
>> -};
>> -
>> -partition@e {
>> -label = "u-boot-env";
>> -reg = <0xe 0x2>;
>> -read-only;
>> -};
>> -
>> -partition@10 {
>> -label = "u-boot-env2";
>> -reg = <0x10 0x2>;
>> -read-only;
>> -};
>> -
>> -partition@12 {
>> -label = "zImage";
>> -reg = <0x12 0x40>;
>> -};
>> -
>> -partition@52 {
>> -label = "initrd";
>> -reg = <0x52 0x40>;
>> -};
>> -
>> -partition@xE0 {
>> -label = "boot";
>> -reg = <0xE0 0x3F20>;
>> +partitions {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +
>> +partition@0 {
>> +label = "u-boot";
>> +reg = <0x000 0xe>;
>> +read-only;
>> +};
>> +
>> +partition@e {
>> +label = "u-boot-env";
>> + 

Re: [PATCH 1/4] ARM: dt: mvebu: ix4-300d: remove whole flash partition

[Sebastian Hesselbarth]

On 28.11.2015 17:52, Andrew Lunn wrote:
> On Sat, Nov 28, 2015 at 12:14:05PM +0100, Sebastian Hesselbarth wrote:
>> Current NAND node has an additional flash partition for the whole
>> flash overlapping with real partitions. Remove this partition as
>> the whole flash is already represented by the NAND device itself.
> 
> If i remember correctly, we discussed this when the contribution was
> made. I think the stock firmware might use this for applying updates.
> Maybe Benoit can comment?

Yes, please.

> If so, removing this will break compatibility with stock firmware. Do
> we want to do that? There are a few other mvebu dts files with a
> partition spanning the whole flash. Should we remove them as well?

Well, there is already a mtd device that spans the whole flash so
what is the purpose of another "partition" that isn't a part but
all of the device? Actually, I doubt that a FW update will wipe
the flash as a whole, i.e. including boot loader, boot env, user
config.

Anyway, let's see if Benoit can shed some light on this.

FWIW, neither single partitions nor a combined partitions node
should be a direct sub-node of the _controller_ but a NAND
_device_ node instead. Luckily, multi-device systems are not that
common, so I guess we wait with it until such a system pops up for
testing.

Sebastian


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND 1/8] arm: dts: berlin2q: add watchdog nodes

[Sebastian Hesselbarth]

On 23.11.2015 05:59, Jisheng Zhang wrote:
> On Fri, 20 Nov 2015 21:19:46 +0100
> Sebastian Hesselbarth wrote:
>> On 20.11.2015 04:34, Jisheng Zhang wrote:
>>> On Thu, 19 Nov 2015 21:47:05 +0100
>>> Sebastian Hesselbarth wrote:  
>>>> On 16.11.2015 12:09, Jisheng Zhang wrote:  
>>>>> The Marvell Berlin BG2Q has 3 watchdogs which are compatible with the
>>>>> snps,dw-wdt driver sit in the sysmgr domain. This patch adds the
>>>>> corresponding device tree nodes.
>>>>>
>>>>> Signed-off-by: Jisheng Zhang 
>>>>> ---
[...]
>>>>> + wdt0: watchdog@1000 {
>>>>> + compatible = "snps,dw-wdt";
>>>>> + reg = <0x1000 0x100>;
>>>>> + clocks = <>;
>>>>> + interrupts = <0>;
>>>>> + status = "disabled";
>>>>
>>>> as the watchdogs are internal and cannot be clock gated
>>>> at all, how about we remove the status = "disabled" and
>>>> make them always available?  
>>>
>>> there are two issues here:
>>>
>>> 1. the dw-wdt can't support multiple variants now. I have rewrite the driver
>>> with watchdog core supplied framework, but the patch isn't sent out and
>>> may be need time to clean up and review.  
>>
>> Ok.
>>
>>> 2. not all dw-wdt devices are available and functional. This depends on
>>> board design and configuration.  
>>
>> I understand that "board design and configuration" may hinder the wdt
>> to issue a hard reset. But all others are able to issue a soft reset
>> or just an interrupt, right?
>>
>> So, I still don't see why we should disable wdt nodes by default
>> except for the driver issue above.
>>
>>> So IMHO status=disabled and patch5-8 is necessary, what do you think?  
>>
>> No. I'd agree to enable wdt0 by default and leave wdt[1,2] disabled
>> because of the driver issue. Patches 5-8 only enable wdt0 anyway.
> 
> That's fine.

Jisheng,

I amended your SoC dtsi watchdog patches accordingly. wdt0 is
now always enabled, while the others are disabled.

So, with the changes Patches 1-4 applied to berlin/dt and berlin64/dt
respectively. Patches 5-8 dropped.

>> As soon as the driver issue is resolved, we enable all wdt nodes
>> unconditionally.
> 
> I will submit patch for the wdt driver and hope it will be merged
> in v4.5.

Ok. Feel free to add a patch that removes the status disabled properties
again if berlin[64]/dt has already hit mainline in the meantime.

If not, keep me posted on the DW wdt patch outcome.

Thanks,

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] pinctrl: berlin: guard sub-directory with CONFIG_PINCTRL_BERLIN

[Sebastian Hesselbarth]

On 24.11.2015 13:02, Jisheng Zhang wrote:
> On Tue, 24 Nov 2015 20:45:22 +0900
> Masahiro Yamada wrote:
> 
>> CONFIG_PINCTRL_BERLIN is more suitable than CONFIG_ARCH_BERLIN
>> to guard the drivers/pinctrl/berlin/ directory.
>>
>> Signed-off-by: Masahiro Yamada 
> 
> I'm not maintainers, but this patch looks good to me. So if you need, 
> 
> Acked-by: Jisheng Zhang 

And here comes the maintainer's

Acked-by: Sebastian Hesselbarth 

Thanks!

>> ---
>>
>>  drivers/pinctrl/Makefile| 2 +-
>>  drivers/pinctrl/berlin/Makefile | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
>> index 738cb49..17c0206 100644
>> --- a/drivers/pinctrl/Makefile
>> +++ b/drivers/pinctrl/Makefile
>> @@ -41,7 +41,7 @@ obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
>>  obj-$(CONFIG_PINCTRL_ZYNQ)  += pinctrl-zynq.o
>>  
>>  obj-$(CONFIG_ARCH_BCM)  += bcm/
>> -obj-$(CONFIG_ARCH_BERLIN)   += berlin/
>> +obj-$(CONFIG_PINCTRL_BERLIN)+= berlin/
>>  obj-y   += freescale/
>>  obj-$(CONFIG_X86)   += intel/
>>  obj-$(CONFIG_PLAT_ORION)+= mvebu/
>> diff --git a/drivers/pinctrl/berlin/Makefile 
>> b/drivers/pinctrl/berlin/Makefile
>> index 06f9402..6f641ce 100644
>> --- a/drivers/pinctrl/berlin/Makefile
>> +++ b/drivers/pinctrl/berlin/Makefile
>> @@ -1,4 +1,4 @@
>> -obj-$(CONFIG_PINCTRL_BERLIN)+= berlin.o
>> +obj-y   += berlin.o
>>  obj-$(CONFIG_PINCTRL_BERLIN_BG2)+= berlin-bg2.o
>>  obj-$(CONFIG_PINCTRL_BERLIN_BG2CD)  += berlin-bg2cd.o
>>  obj-$(CONFIG_PINCTRL_BERLIN_BG2Q)   += berlin-bg2q.o
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm: dts: berlin2q-marvell-dmp: add sdhci1 fully functionality

[Sebastian Hesselbarth]

On 26.11.2015 14:13, Jisheng Zhang wrote:
> The sdhci1 on Marvell BG2Q DMP board is used as sdcard interface, we
> have gpios for card detection, write-protect, vqmmc and vmmc.
> 
> This patch adds pinmux for this sdcard interface, then adds regulators
> for vmmc and vqmmc, lastly adds cd-gpios, wp-gpios properties.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 43 
> --
>  1 file changed, 41 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts 
> b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> index cdcf89b..1fdc1d7 100644
> --- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> +++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> @@ -84,12 +84,51 @@
>   gpio = < 12 GPIO_ACTIVE_HIGH>;
>   enable-active-high;
>   };
> +
> + reg_sdio1_vmmc: regulator@3 {
> + compatible = "regulator-fixed";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "sdio1_vmmc";
> + enable-active-high;
> + regulator-boot-on;
> + gpio = < 21 GPIO_ACTIVE_HIGH>;
> + };
> +
> + reg_sdio1_vqmmc: regulator@4 {
> + compatible = "regulator-gpio";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "sdio1_vqmmc";
> + regulator-type = "voltage";
> + enable-active-high;
> + gpios = < 16 GPIO_ACTIVE_HIGH>;
> + states = <330 0x1
> +   180 0x0>;
> + };
> + };
> +};
> +
> +_pinctrl {
> + sd1gpio_pmux: sd1pwr-pmux {
> + groups = "G23", "G32";
> + function = "gpio";
> + };
> +
> + sd1_pmux: sd1-pmux {
> + groups = "G31";
> + function = "sd1";

Jisheng,

while having the sd1gpio_pmux in the board file, I think the
sd1_pmux is best kept in the SoC.dtsi.

>   };
>  };
>  
>   {
> - broken-cd;
> - sdhci,wp-inverted;
> + vmmc-supply = <_sdio1_vmmc>;
> + vqmmc-supply = <_sdio1_vqmmc>;
> + cd-inverted;
> + cd-gpios = < 30 GPIO_ACTIVE_HIGH>;

How about removing cd-inverted and make cd-gpio GPIO_ACTIVE_LOW
instead?

Sebastian

> + wp-gpios = < 0 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <_pmux>, <_pmux>;
> + pinctrl-names = "default";
>   status = "okay";
>  };
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] ARM: dt: mvebu: ix4-300d: Add ECC properties to NAND flash

[Sebastian Hesselbarth]

The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection.
Add the corresponding properties to the NAND node.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper  
Cc: Andrew Lunn 
Cc: Gregory Clement  
Cc: Rob Herring  
Cc: Pawel Moll  
Cc: Mark Rutland  
Cc: Ian Campbell  
Cc: Kumar Gala  
Cc: Russell King  
Cc: Benoit Masson 
Cc: linux-arm-ker...@lists.infradead.org 
Cc: devicet...@vger.kernel.org 
Cc: linux-kernel@vger.kernel.org 
---
 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts 
b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index 13cf69a8d0fb..e4bf83c4bd2f 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -150,6 +150,8 @@
marvell,nand-keep-config;
marvell,nand-enable-arbiter;
nand-on-flash-bbt;
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
 
partitions {
#address-cells = <1>;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] ARM: dt: mvebu: ix4-300d: NAND cleanup and ECC

[Sebastian Hesselbarth]

This is a list of patches cleaning up some things I noticed while
working with barebox boot loader support for NAND node of Lenovo ix4-300d.

Patch 1 removes a flash partition node for the whole flash. The flash
as a whole is already best represented by the NAND device itself.

Patch 2 moves the stock flash partitions to a partitions sub-node. This
will also ease removal of stock flash partition layout for barebox and
other boot loaders.

Patch 3 cleans the flash partitions ranges by prefixing them to 32-bit
lower-case hex numbers. Also, a stale 'x' is removed from one partition
name offset.

Patch 4 finally adds ECC properties for 4-bit BCH ECC used by the ix4-300d
flash.

Sebastian

Sebastian Hesselbarth (4):
  ARM: dt: mvebu: ix4-300d: remove whole flash partition
  ARM: dt: mvebu: ix4-300d: move partitions to partition sub-node
  ARM: dt: mvebu: ix4-300d: Cleanup NAND partition ranges
  ARM: dt: mvebu: ix4-300d: Add ECC properties to NAND flash

 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 76 +
 1 file changed, 39 insertions(+), 37 deletions(-)

---
Cc: Jason Cooper  
Cc: Andrew Lunn 
Cc: Gregory Clement  
Cc: Rob Herring  
Cc: Pawel Moll  
Cc: Mark Rutland  
Cc: Ian Campbell  
Cc: Kumar Gala  
Cc: Russell King  
Cc: Benoit Masson 
Cc: linux-arm-ker...@lists.infradead.org 
Cc: devicet...@vger.kernel.org 
Cc: linux-kernel@vger.kernel.org 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] ARM: dt: mvebu: ix4-300d: move partitions to partition sub-node

[Sebastian Hesselbarth]

NAND flash partitions should be part of a partitions sub-node
not the flash node itself. Move the partitions which will also
allow different bootloaders get rid of the stock partitions
easily by removing the partitions node.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper  
Cc: Andrew Lunn 
Cc: Gregory Clement  
Cc: Rob Herring  
Cc: Pawel Moll  
Cc: Mark Rutland  
Cc: Ian Campbell  
Cc: Kumar Gala  
Cc: Russell King  
Cc: Benoit Masson 
Cc: linux-arm-ker...@lists.infradead.org 
Cc: devicet...@vger.kernel.org 
Cc: linux-kernel@vger.kernel.org 
---
 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 67 +
 1 file changed, 36 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts 
b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index 30a0a6eac645..76781fd18624 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -151,37 +151,42 @@
marvell,nand-enable-arbiter;
nand-on-flash-bbt;
 
-   partition@0 {
-   label = "u-boot";
-   reg = <0x000 0xe>;
-   read-only;
-   };
-
-   partition@e {
-   label = "u-boot-env";
-   reg = <0xe 0x2>;
-   read-only;
-   };
-
-   partition@10 {
-   label = "u-boot-env2";
-   reg = <0x10 0x2>;
-   read-only;
-   };
-
-   partition@12 {
-   label = "zImage";
-   reg = <0x12 0x40>;
-   };
-
-   partition@52 {
-   label = "initrd";
-   reg = <0x52 0x40>;
-   };
-
-   partition@xE0 {
-   label = "boot";
-   reg = <0xE0 0x3F20>;
+   partitions {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x000 0xe>;
+   read-only;
+   };
+
+   partition@e {
+   label = "u-boot-env";
+   reg = <0xe 0x2>;
+   read-only;
+   };
+
+   partition@10 {
+   label = "u-boot-env2";
+   reg = <0x10 0x2>;
+   read-only;
+   };
+
+   partition@12 {
+   label = "zImage";
+   reg = <0x12 0x40>;
+   };
+
+   partition@52 {
+   label = "initrd";
+   reg = <0x52 0x40>;
+   };
+
+   partition@xE0 {
+   label = "boot";
+   reg = <0xE0 0x3F20>;
+   };
};
};
};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] ARM: dt: mvebu: ix4-300d: Cleanup NAND partition ranges

[Sebastian Hesselbarth]

Prefix all partition reg properties to 32-bit to ease readability.
While at it, also remove a stale x in front of boot partition
offset and make some upper-case hex numbers lower-case.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper  
Cc: Andrew Lunn 
Cc: Gregory Clement  
Cc: Rob Herring  
Cc: Pawel Moll  
Cc: Mark Rutland  
Cc: Ian Campbell  
Cc: Kumar Gala  
Cc: Russell King  
Cc: Benoit Masson 
Cc: linux-arm-ker...@lists.infradead.org 
Cc: devicet...@vger.kernel.org 
Cc: linux-kernel@vger.kernel.org 
---
 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts 
b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index 76781fd18624..13cf69a8d0fb 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -157,35 +157,35 @@
 
partition@0 {
label = "u-boot";
-   reg = <0x000 0xe>;
+   reg = <0x 0x000e>;
read-only;
};
 
partition@e {
label = "u-boot-env";
-   reg = <0xe 0x2>;
+   reg = <0x000e 0x0002>;
read-only;
};
 
partition@10 {
label = "u-boot-env2";
-   reg = <0x10 0x2>;
+   reg = <0x0010 0x0002>;
read-only;
};
 
partition@12 {
label = "zImage";
-   reg = <0x12 0x40>;
+   reg = <0x0012 0x0040>;
};
 
partition@52 {
label = "initrd";
-   reg = <0x52 0x40>;
+   reg = <0x0052 0x0040>;
};
 
-   partition@xE0 {
+   partition@e0 {
label = "boot";
-   reg = <0xE0 0x3F20>;
+   reg = <0x00e0 0x3f20>;
};
};
};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] ARM: dt: mvebu: ix4-300d: remove whole flash partition

[Sebastian Hesselbarth]

Current NAND node has an additional flash partition for the whole
flash overlapping with real partitions. Remove this partition as
the whole flash is already represented by the NAND device itself.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Russell King 
Cc: Benoit Masson 
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts 
b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index 58b500873bfd..30a0a6eac645 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -183,11 +183,6 @@
label = "boot";
reg = <0xE0 0x3F20>;
};
-
-   partition@flash {
-   label = "flash";
-   reg = <0x0 0x4000>;
-   };
};
};
};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] pinctrl: mvebu: complain about missing group after checking variant

[Sebastian Hesselbarth]

Common MVEBU pinctrl driver core gets an array of controls to modify
a specific set of registers and an array of modes for each pingroup
from each of the different SoC families of MVEBU.

Some SoC families comprise different variants that differ in available
pingroups and also controls, but to ease driver development, we can
pass a variant mask to disable specific pingroups for some variants.
However, controls are limited to the true number of pinctrl groups
avaiable on a variant.

Now, when pinctrl core driver parses over above arrays, it tries to
match modes with available controls and complains about missing
controls for modes that are passed to the core but actually are not
avaiable on a variant with:

kirkwood-pinctrl f101.pin-controller: unknown pinctrl group 36

This warning is a false-positive and annoying, so move the warning
after we checked the variant mask for each mode setting. Also, if
there is no supported setting for this variant, do not complain at
all.

Signed-off-by: Sebastian Hesselbarth 
Reported-by: Linus Walleij 
---
Changelog:
v1->v2:
- modify settings loop to allow to check for !num_settings

Cc: Linus Walleij 
Cc: Simon Guinot 
Cc: Thomas Petazzoni 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: linux-g...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-mvebu.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c 
b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index 77d2221d379d..e4d473811bb3 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -663,28 +663,20 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
/* assign mpp modes to groups */
for (n = 0; n < soc->nmodes; n++) {
struct mvebu_mpp_mode *mode = >modes[n];
-   struct mvebu_pinctrl_group *grp =
-   mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
+   struct mvebu_mpp_ctrl_setting *set = >settings[0];
+   struct mvebu_pinctrl_group *grp;
unsigned num_settings;
 
-   if (!grp) {
-   dev_warn(>dev, "unknown pinctrl group %d\n",
-   mode->pid);
-   continue;
-   }
-
-   for (num_settings = 0; ;) {
-   struct mvebu_mpp_ctrl_setting *set =
-   >settings[num_settings];
-
+   for (num_settings = 0; ; set++) {
if (!set->name)
break;
-   num_settings++;
 
/* skip unsupported settings for this variant */
if (pctl->variant && !(pctl->variant & set->variant))
continue;
 
+   num_settings++;
+
/* find gpio/gpo/gpi settings */
if (strcmp(set->name, "gpio") == 0)
set->flags = MVEBU_SETTING_GPI |
@@ -695,6 +687,17 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
set->flags = MVEBU_SETTING_GPI;
}
 
+   /* skip modes with no settings for this variant */
+   if (!num_settings)
+   continue;
+
+   grp = mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
+   if (!grp) {
+   dev_warn(>dev, "unknown pinctrl group %d\n",
+   mode->pid);
+   continue;
+   }
+
grp->settings = mode->settings;
grp->num_settings = num_settings;
}
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: mvebu: complain about missing group after checking variant

[Sebastian Hesselbarth]

On 28.11.2015 11:14, Sebastian Hesselbarth wrote:
> Common MVEBU pinctrl driver core gets an array of controls to modify
> a specific set of registers and an array of modes for each pingroup
> from each of the different SoC families of MVEBU.
> 
> Some SoC families comprise different variants that differ in available
> pingroups and also controls, but to ease driver development, we can
> pass a variant mask to disable specific pingroups for some variants.
> However, controls are limited to the true number of pinctrl groups
> available on a variant.
> 
> Now, when pinctrl core driver parses over above arrays, it tries to
> match modes with available controls and complains about missing
> controls for modes that are passed to the core but actually are not
> available on a variant with:
> 
> kirkwood-pinctrl f101.pin-controller: unknown pinctrl group 36
> 
> This warning is a false-positive and annoying, so move the warning
> after we checked the variant mask for each mode setting. Also, if
> there is no supported setting for this variant, do not complain at
> all.
> 
> Signed-off-by: Sebastian Hesselbarth 
> Reported-by: Linus Walleij 
> ---
> Cc: Linus Walleij 
> Cc: Simon Guinot 
> Cc: Thomas Petazzoni 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: linux-g...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/pinctrl/mvebu/pinctrl-mvebu.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c 
> b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
> index 77d2221d379d..dbc95369317a 100644
> --- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
> +++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
> @@ -663,16 +663,9 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
>   /* assign mpp modes to groups */
>   for (n = 0; n < soc->nmodes; n++) {
>   struct mvebu_mpp_mode *mode = >modes[n];
> - struct mvebu_pinctrl_group *grp =
> - mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
> + struct mvebu_pinctrl_group *grp;
>   unsigned num_settings;
>  
> - if (!grp) {
> - dev_warn(>dev, "unknown pinctrl group %d\n",
> - mode->pid);
> - continue;
> - }
> -
>   for (num_settings = 0; ;) {
>   struct mvebu_mpp_ctrl_setting *set =
>   >settings[num_settings];
> @@ -695,6 +688,17 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
>   set->flags = MVEBU_SETTING_GPI;
>   }
>  
> + /* skip modes with no settings for this variant */

Erm, dammit. This does not work as expected.
The loop right over this does increment num_settings unconditionally.

I'll have to find a better solution...

Sebastian

> + if (!num_settings)
> + continue;
> +
> + grp = mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
> + if (!grp) {
> + dev_warn(>dev, "unknown pinctrl group %d\n",
> + mode->pid);
> + continue;
> + }
> +
>   grp->settings = mode->settings;
>   grp->num_settings = num_settings;
>   }
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] pinctrl: mvebu: complain about missing group after checking variant

[Sebastian Hesselbarth]

Common MVEBU pinctrl driver core gets an array of controls to modify
a specific set of registers and an array of modes for each pingroup
from each of the different SoC families of MVEBU.

Some SoC families comprise different variants that differ in available
pingroups and also controls, but to ease driver development, we can
pass a variant mask to disable specific pingroups for some variants.
However, controls are limited to the true number of pinctrl groups
available on a variant.

Now, when pinctrl core driver parses over above arrays, it tries to
match modes with available controls and complains about missing
controls for modes that are passed to the core but actually are not
available on a variant with:

kirkwood-pinctrl f101.pin-controller: unknown pinctrl group 36

This warning is a false-positive and annoying, so move the warning
after we checked the variant mask for each mode setting. Also, if
there is no supported setting for this variant, do not complain at
all.

Signed-off-by: Sebastian Hesselbarth 
Reported-by: Linus Walleij 
---
Cc: Linus Walleij 
Cc: Simon Guinot 
Cc: Thomas Petazzoni 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: linux-g...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-mvebu.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c 
b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index 77d2221d379d..dbc95369317a 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -663,16 +663,9 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
/* assign mpp modes to groups */
for (n = 0; n < soc->nmodes; n++) {
struct mvebu_mpp_mode *mode = >modes[n];
-   struct mvebu_pinctrl_group *grp =
-   mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
+   struct mvebu_pinctrl_group *grp;
unsigned num_settings;
 
-   if (!grp) {
-   dev_warn(>dev, "unknown pinctrl group %d\n",
-   mode->pid);
-   continue;
-   }
-
for (num_settings = 0; ;) {
struct mvebu_mpp_ctrl_setting *set =
>settings[num_settings];
@@ -695,6 +688,17 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
set->flags = MVEBU_SETTING_GPI;
}
 
+   /* skip modes with no settings for this variant */
+   if (!num_settings)
+   continue;
+
+   grp = mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
+   if (!grp) {
+   dev_warn(>dev, "unknown pinctrl group %d\n",
+   mode->pid);
+   continue;
+   }
+
grp->settings = mode->settings;
grp->num_settings = num_settings;
}
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] ARM: dt: mvebu: ix4-300d: Cleanup NAND partition ranges

[Sebastian Hesselbarth]

Prefix all partition reg properties to 32-bit to ease readability.
While at it, also remove a stale x in front of boot partition
offset and make some upper-case hex numbers lower-case.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
---
Cc: Jason Cooper <ja...@lakedaemon.net> 
Cc: Andrew Lunn <and...@lunn.ch>
Cc: Gregory Clement <gregory.clem...@free-electrons.com> 
Cc: Rob Herring <robh...@kernel.org> 
Cc: Pawel Moll <pawel.m...@arm.com> 
Cc: Mark Rutland <mark.rutl...@arm.com> 
Cc: Ian Campbell <ijc+devicet...@hellion.org.uk> 
Cc: Kumar Gala <ga...@codeaurora.org> 
Cc: Russell King <li...@arm.linux.org.uk> 
Cc: Benoit Masson <ya...@perenite.com>
Cc: linux-arm-ker...@lists.infradead.org 
Cc: devicet...@vger.kernel.org 
Cc: linux-kernel@vger.kernel.org 
---
 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts 
b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index 76781fd18624..13cf69a8d0fb 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -157,35 +157,35 @@
 
partition@0 {
label = "u-boot";
-   reg = <0x000 0xe>;
+   reg = <0x 0x000e>;
read-only;
};
 
partition@e {
label = "u-boot-env";
-   reg = <0xe 0x2>;
+   reg = <0x000e 0x0002>;
read-only;
};
 
partition@10 {
label = "u-boot-env2";
-   reg = <0x10 0x2>;
+   reg = <0x0010 0x0002>;
read-only;
};
 
partition@12 {
label = "zImage";
-   reg = <0x12 0x40>;
+   reg = <0x0012 0x0040>;
};
 
partition@52 {
label = "initrd";
-   reg = <0x52 0x40>;
+   reg = <0x0052 0x0040>;
};
 
-   partition@xE0 {
+   partition@e0 {
label = "boot";
-   reg = <0xE0 0x3F20>;
+   reg = <0x00e0 0x3f20>;
};
};
};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] ARM: dt: mvebu: ix4-300d: remove whole flash partition

[Sebastian Hesselbarth]

Current NAND node has an additional flash partition for the whole
flash overlapping with real partitions. Remove this partition as
the whole flash is already represented by the NAND device itself.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
---
Cc: Jason Cooper <ja...@lakedaemon.net>
Cc: Andrew Lunn <and...@lunn.ch>
Cc: Gregory Clement <gregory.clem...@free-electrons.com>
Cc: Rob Herring <robh...@kernel.org>
Cc: Pawel Moll <pawel.m...@arm.com>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Ian Campbell <ijc+devicet...@hellion.org.uk>
Cc: Kumar Gala <ga...@codeaurora.org>
Cc: Russell King <li...@arm.linux.org.uk>
Cc: Benoit Masson <ya...@perenite.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts 
b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index 58b500873bfd..30a0a6eac645 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -183,11 +183,6 @@
label = "boot";
reg = <0xE0 0x3F20>;
};
-
-   partition@flash {
-   label = "flash";
-   reg = <0x0 0x4000>;
-   };
};
};
};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] pinctrl: mvebu: complain about missing group after checking variant

[Sebastian Hesselbarth]

Common MVEBU pinctrl driver core gets an array of controls to modify
a specific set of registers and an array of modes for each pingroup
from each of the different SoC families of MVEBU.

Some SoC families comprise different variants that differ in available
pingroups and also controls, but to ease driver development, we can
pass a variant mask to disable specific pingroups for some variants.
However, controls are limited to the true number of pinctrl groups
available on a variant.

Now, when pinctrl core driver parses over above arrays, it tries to
match modes with available controls and complains about missing
controls for modes that are passed to the core but actually are not
available on a variant with:

kirkwood-pinctrl f101.pin-controller: unknown pinctrl group 36

This warning is a false-positive and annoying, so move the warning
after we checked the variant mask for each mode setting. Also, if
there is no supported setting for this variant, do not complain at
all.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
Reported-by: Linus Walleij <linus.wall...@linaro.org>
---
Cc: Linus Walleij <linus.wall...@linaro.org>
Cc: Simon Guinot <simon.gui...@sequanux.org>
Cc: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
Cc: Jason Cooper <ja...@lakedaemon.net>
Cc: Andrew Lunn <and...@lunn.ch>
Cc: Gregory Clement <gregory.clem...@free-electrons.com>
Cc: linux-g...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-mvebu.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c 
b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index 77d2221d379d..dbc95369317a 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -663,16 +663,9 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
/* assign mpp modes to groups */
for (n = 0; n < soc->nmodes; n++) {
struct mvebu_mpp_mode *mode = >modes[n];
-   struct mvebu_pinctrl_group *grp =
-   mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
+   struct mvebu_pinctrl_group *grp;
unsigned num_settings;
 
-   if (!grp) {
-   dev_warn(>dev, "unknown pinctrl group %d\n",
-   mode->pid);
-   continue;
-   }
-
for (num_settings = 0; ;) {
struct mvebu_mpp_ctrl_setting *set =
>settings[num_settings];
@@ -695,6 +688,17 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
set->flags = MVEBU_SETTING_GPI;
}
 
+   /* skip modes with no settings for this variant */
+   if (!num_settings)
+   continue;
+
+   grp = mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
+   if (!grp) {
+   dev_warn(>dev, "unknown pinctrl group %d\n",
+   mode->pid);
+   continue;
+   }
+
grp->settings = mode->settings;
grp->num_settings = num_settings;
}
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] pinctrl: mvebu: complain about missing group after checking variant

[Sebastian Hesselbarth]

Common MVEBU pinctrl driver core gets an array of controls to modify
a specific set of registers and an array of modes for each pingroup
from each of the different SoC families of MVEBU.

Some SoC families comprise different variants that differ in available
pingroups and also controls, but to ease driver development, we can
pass a variant mask to disable specific pingroups for some variants.
However, controls are limited to the true number of pinctrl groups
avaiable on a variant.

Now, when pinctrl core driver parses over above arrays, it tries to
match modes with available controls and complains about missing
controls for modes that are passed to the core but actually are not
avaiable on a variant with:

kirkwood-pinctrl f101.pin-controller: unknown pinctrl group 36

This warning is a false-positive and annoying, so move the warning
after we checked the variant mask for each mode setting. Also, if
there is no supported setting for this variant, do not complain at
all.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
Reported-by: Linus Walleij <linus.wall...@linaro.org>
---
Changelog:
v1->v2:
- modify settings loop to allow to check for !num_settings

Cc: Linus Walleij <linus.wall...@linaro.org>
Cc: Simon Guinot <simon.gui...@sequanux.org>
Cc: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
Cc: Jason Cooper <ja...@lakedaemon.net>
Cc: Andrew Lunn <and...@lunn.ch>
Cc: Gregory Clement <gregory.clem...@free-electrons.com>
Cc: linux-g...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-mvebu.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c 
b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index 77d2221d379d..e4d473811bb3 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -663,28 +663,20 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
/* assign mpp modes to groups */
for (n = 0; n < soc->nmodes; n++) {
struct mvebu_mpp_mode *mode = >modes[n];
-   struct mvebu_pinctrl_group *grp =
-   mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
+   struct mvebu_mpp_ctrl_setting *set = >settings[0];
+   struct mvebu_pinctrl_group *grp;
unsigned num_settings;
 
-   if (!grp) {
-   dev_warn(>dev, "unknown pinctrl group %d\n",
-   mode->pid);
-   continue;
-   }
-
-   for (num_settings = 0; ;) {
-   struct mvebu_mpp_ctrl_setting *set =
-   >settings[num_settings];
-
+   for (num_settings = 0; ; set++) {
if (!set->name)
break;
-   num_settings++;
 
/* skip unsupported settings for this variant */
if (pctl->variant && !(pctl->variant & set->variant))
continue;
 
+   num_settings++;
+
/* find gpio/gpo/gpi settings */
if (strcmp(set->name, "gpio") == 0)
set->flags = MVEBU_SETTING_GPI |
@@ -695,6 +687,17 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
set->flags = MVEBU_SETTING_GPI;
}
 
+   /* skip modes with no settings for this variant */
+   if (!num_settings)
+   continue;
+
+   grp = mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
+   if (!grp) {
+   dev_warn(>dev, "unknown pinctrl group %d\n",
+   mode->pid);
+   continue;
+   }
+
grp->settings = mode->settings;
grp->num_settings = num_settings;
}
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] pinctrl: berlin: guard sub-directory with CONFIG_PINCTRL_BERLIN

[Sebastian Hesselbarth]

On 24.11.2015 13:02, Jisheng Zhang wrote:
> On Tue, 24 Nov 2015 20:45:22 +0900
> Masahiro Yamada wrote:
> 
>> CONFIG_PINCTRL_BERLIN is more suitable than CONFIG_ARCH_BERLIN
>> to guard the drivers/pinctrl/berlin/ directory.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
> 
> I'm not maintainers, but this patch looks good to me. So if you need, 
> 
> Acked-by: Jisheng Zhang <jszh...@marvell.com>

And here comes the maintainer's

Acked-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>

Thanks!

>> ---
>>
>>  drivers/pinctrl/Makefile| 2 +-
>>  drivers/pinctrl/berlin/Makefile | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
>> index 738cb49..17c0206 100644
>> --- a/drivers/pinctrl/Makefile
>> +++ b/drivers/pinctrl/Makefile
>> @@ -41,7 +41,7 @@ obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
>>  obj-$(CONFIG_PINCTRL_ZYNQ)  += pinctrl-zynq.o
>>  
>>  obj-$(CONFIG_ARCH_BCM)  += bcm/
>> -obj-$(CONFIG_ARCH_BERLIN)   += berlin/
>> +obj-$(CONFIG_PINCTRL_BERLIN)+= berlin/
>>  obj-y   += freescale/
>>  obj-$(CONFIG_X86)   += intel/
>>  obj-$(CONFIG_PLAT_ORION)+= mvebu/
>> diff --git a/drivers/pinctrl/berlin/Makefile 
>> b/drivers/pinctrl/berlin/Makefile
>> index 06f9402..6f641ce 100644
>> --- a/drivers/pinctrl/berlin/Makefile
>> +++ b/drivers/pinctrl/berlin/Makefile
>> @@ -1,4 +1,4 @@
>> -obj-$(CONFIG_PINCTRL_BERLIN)+= berlin.o
>> +obj-y   += berlin.o
>>  obj-$(CONFIG_PINCTRL_BERLIN_BG2)+= berlin-bg2.o
>>  obj-$(CONFIG_PINCTRL_BERLIN_BG2CD)  += berlin-bg2cd.o
>>  obj-$(CONFIG_PINCTRL_BERLIN_BG2Q)   += berlin-bg2q.o
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] ARM: dt: mvebu: ix4-300d: Add ECC properties to NAND flash

[Sebastian Hesselbarth]

The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection.
Add the corresponding properties to the NAND node.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
---
Cc: Jason Cooper <ja...@lakedaemon.net> 
Cc: Andrew Lunn <and...@lunn.ch>
Cc: Gregory Clement <gregory.clem...@free-electrons.com> 
Cc: Rob Herring <robh...@kernel.org> 
Cc: Pawel Moll <pawel.m...@arm.com> 
Cc: Mark Rutland <mark.rutl...@arm.com> 
Cc: Ian Campbell <ijc+devicet...@hellion.org.uk> 
Cc: Kumar Gala <ga...@codeaurora.org> 
Cc: Russell King <li...@arm.linux.org.uk> 
Cc: Benoit Masson <ya...@perenite.com>
Cc: linux-arm-ker...@lists.infradead.org 
Cc: devicet...@vger.kernel.org 
Cc: linux-kernel@vger.kernel.org 
---
 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts 
b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index 13cf69a8d0fb..e4bf83c4bd2f 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -150,6 +150,8 @@
marvell,nand-keep-config;
marvell,nand-enable-arbiter;
nand-on-flash-bbt;
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
 
partitions {
#address-cells = <1>;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] ARM: dt: mvebu: ix4-300d: NAND cleanup and ECC

[Sebastian Hesselbarth]

This is a list of patches cleaning up some things I noticed while
working with barebox boot loader support for NAND node of Lenovo ix4-300d.

Patch 1 removes a flash partition node for the whole flash. The flash
as a whole is already best represented by the NAND device itself.

Patch 2 moves the stock flash partitions to a partitions sub-node. This
will also ease removal of stock flash partition layout for barebox and
other boot loaders.

Patch 3 cleans the flash partitions ranges by prefixing them to 32-bit
lower-case hex numbers. Also, a stale 'x' is removed from one partition
name offset.

Patch 4 finally adds ECC properties for 4-bit BCH ECC used by the ix4-300d
flash.

Sebastian

Sebastian Hesselbarth (4):
  ARM: dt: mvebu: ix4-300d: remove whole flash partition
  ARM: dt: mvebu: ix4-300d: move partitions to partition sub-node
  ARM: dt: mvebu: ix4-300d: Cleanup NAND partition ranges
  ARM: dt: mvebu: ix4-300d: Add ECC properties to NAND flash

 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 76 +
 1 file changed, 39 insertions(+), 37 deletions(-)

---
Cc: Jason Cooper <ja...@lakedaemon.net> 
Cc: Andrew Lunn <and...@lunn.ch>
Cc: Gregory Clement <gregory.clem...@free-electrons.com> 
Cc: Rob Herring <robh...@kernel.org> 
Cc: Pawel Moll <pawel.m...@arm.com> 
Cc: Mark Rutland <mark.rutl...@arm.com> 
Cc: Ian Campbell <ijc+devicet...@hellion.org.uk> 
Cc: Kumar Gala <ga...@codeaurora.org> 
Cc: Russell King <li...@arm.linux.org.uk> 
Cc: Benoit Masson <ya...@perenite.com>
Cc: linux-arm-ker...@lists.infradead.org 
Cc: devicet...@vger.kernel.org 
Cc: linux-kernel@vger.kernel.org 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] ARM: dt: mvebu: ix4-300d: move partitions to partition sub-node

[Sebastian Hesselbarth]

NAND flash partitions should be part of a partitions sub-node
not the flash node itself. Move the partitions which will also
allow different bootloaders get rid of the stock partitions
easily by removing the partitions node.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
---
Cc: Jason Cooper <ja...@lakedaemon.net> 
Cc: Andrew Lunn <and...@lunn.ch>
Cc: Gregory Clement <gregory.clem...@free-electrons.com> 
Cc: Rob Herring <robh...@kernel.org> 
Cc: Pawel Moll <pawel.m...@arm.com> 
Cc: Mark Rutland <mark.rutl...@arm.com> 
Cc: Ian Campbell <ijc+devicet...@hellion.org.uk> 
Cc: Kumar Gala <ga...@codeaurora.org> 
Cc: Russell King <li...@arm.linux.org.uk> 
Cc: Benoit Masson <ya...@perenite.com>
Cc: linux-arm-ker...@lists.infradead.org 
Cc: devicet...@vger.kernel.org 
Cc: linux-kernel@vger.kernel.org 
---
 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 67 +
 1 file changed, 36 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts 
b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
index 30a0a6eac645..76781fd18624 100644
--- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -151,37 +151,42 @@
marvell,nand-enable-arbiter;
nand-on-flash-bbt;
 
-   partition@0 {
-   label = "u-boot";
-   reg = <0x000 0xe>;
-   read-only;
-   };
-
-   partition@e {
-   label = "u-boot-env";
-   reg = <0xe 0x2>;
-   read-only;
-   };
-
-   partition@10 {
-   label = "u-boot-env2";
-   reg = <0x10 0x2>;
-   read-only;
-   };
-
-   partition@12 {
-   label = "zImage";
-   reg = <0x12 0x40>;
-   };
-
-   partition@52 {
-   label = "initrd";
-   reg = <0x52 0x40>;
-   };
-
-   partition@xE0 {
-   label = "boot";
-   reg = <0xE0 0x3F20>;
+   partitions {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x000 0xe>;
+   read-only;
+   };
+
+   partition@e {
+   label = "u-boot-env";
+   reg = <0xe 0x2>;
+   read-only;
+   };
+
+   partition@10 {
+   label = "u-boot-env2";
+   reg = <0x10 0x2>;
+   read-only;
+   };
+
+   partition@12 {
+   label = "zImage";
+   reg = <0x12 0x40>;
+   };
+
+   partition@52 {
+   label = "initrd";
+   reg = <0x52 0x40>;
+   };
+
+   partition@xE0 {
+   label = "boot";
+   reg = <0xE0 0x3F20>;
+   };
};
};
};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm: dts: berlin2q-marvell-dmp: add sdhci1 fully functionality

[Sebastian Hesselbarth]

On 26.11.2015 14:13, Jisheng Zhang wrote:
> The sdhci1 on Marvell BG2Q DMP board is used as sdcard interface, we
> have gpios for card detection, write-protect, vqmmc and vmmc.
> 
> This patch adds pinmux for this sdcard interface, then adds regulators
> for vmmc and vqmmc, lastly adds cd-gpios, wp-gpios properties.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 43 
> --
>  1 file changed, 41 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts 
> b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> index cdcf89b..1fdc1d7 100644
> --- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> +++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> @@ -84,12 +84,51 @@
>   gpio = < 12 GPIO_ACTIVE_HIGH>;
>   enable-active-high;
>   };
> +
> + reg_sdio1_vmmc: regulator@3 {
> + compatible = "regulator-fixed";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "sdio1_vmmc";
> + enable-active-high;
> + regulator-boot-on;
> + gpio = < 21 GPIO_ACTIVE_HIGH>;
> + };
> +
> + reg_sdio1_vqmmc: regulator@4 {
> + compatible = "regulator-gpio";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "sdio1_vqmmc";
> + regulator-type = "voltage";
> + enable-active-high;
> + gpios = < 16 GPIO_ACTIVE_HIGH>;
> + states = <330 0x1
> +   180 0x0>;
> + };
> + };
> +};
> +
> +_pinctrl {
> + sd1gpio_pmux: sd1pwr-pmux {
> + groups = "G23", "G32";
> + function = "gpio";
> + };
> +
> + sd1_pmux: sd1-pmux {
> + groups = "G31";
> + function = "sd1";

Jisheng,

while having the sd1gpio_pmux in the board file, I think the
sd1_pmux is best kept in the SoC.dtsi.

>   };
>  };
>  
>   {
> - broken-cd;
> - sdhci,wp-inverted;
> + vmmc-supply = <_sdio1_vmmc>;
> + vqmmc-supply = <_sdio1_vqmmc>;
> + cd-inverted;
> + cd-gpios = < 30 GPIO_ACTIVE_HIGH>;

How about removing cd-inverted and make cd-gpio GPIO_ACTIVE_LOW
instead?

Sebastian

> + wp-gpios = < 0 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <_pmux>, <_pmux>;
> + pinctrl-names = "default";
>   status = "okay";
>  };
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: mvebu: complain about missing group after checking variant

[Sebastian Hesselbarth]

On 28.11.2015 11:14, Sebastian Hesselbarth wrote:
> Common MVEBU pinctrl driver core gets an array of controls to modify
> a specific set of registers and an array of modes for each pingroup
> from each of the different SoC families of MVEBU.
> 
> Some SoC families comprise different variants that differ in available
> pingroups and also controls, but to ease driver development, we can
> pass a variant mask to disable specific pingroups for some variants.
> However, controls are limited to the true number of pinctrl groups
> available on a variant.
> 
> Now, when pinctrl core driver parses over above arrays, it tries to
> match modes with available controls and complains about missing
> controls for modes that are passed to the core but actually are not
> available on a variant with:
> 
> kirkwood-pinctrl f101.pin-controller: unknown pinctrl group 36
> 
> This warning is a false-positive and annoying, so move the warning
> after we checked the variant mask for each mode setting. Also, if
> there is no supported setting for this variant, do not complain at
> all.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
> Reported-by: Linus Walleij <linus.wall...@linaro.org>
> ---
> Cc: Linus Walleij <linus.wall...@linaro.org>
> Cc: Simon Guinot <simon.gui...@sequanux.org>
> Cc: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
> Cc: Jason Cooper <ja...@lakedaemon.net>
> Cc: Andrew Lunn <and...@lunn.ch>
> Cc: Gregory Clement <gregory.clem...@free-electrons.com>
> Cc: linux-g...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/pinctrl/mvebu/pinctrl-mvebu.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c 
> b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
> index 77d2221d379d..dbc95369317a 100644
> --- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
> +++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
> @@ -663,16 +663,9 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
>   /* assign mpp modes to groups */
>   for (n = 0; n < soc->nmodes; n++) {
>   struct mvebu_mpp_mode *mode = >modes[n];
> - struct mvebu_pinctrl_group *grp =
> - mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
> + struct mvebu_pinctrl_group *grp;
>   unsigned num_settings;
>  
> - if (!grp) {
> - dev_warn(>dev, "unknown pinctrl group %d\n",
> - mode->pid);
> - continue;
> - }
> -
>   for (num_settings = 0; ;) {
>   struct mvebu_mpp_ctrl_setting *set =
>   >settings[num_settings];
> @@ -695,6 +688,17 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
>   set->flags = MVEBU_SETTING_GPI;
>   }
>  
> + /* skip modes with no settings for this variant */

Erm, dammit. This does not work as expected.
The loop right over this does increment num_settings unconditionally.

I'll have to find a better solution...

Sebastian

> + if (!num_settings)
> + continue;
> +
> + grp = mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
> + if (!grp) {
> + dev_warn(>dev, "unknown pinctrl group %d\n",
> + mode->pid);
> + continue;
> + }
> +
>   grp->settings = mode->settings;
>   grp->num_settings = num_settings;
>   }
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND 1/8] arm: dts: berlin2q: add watchdog nodes

[Sebastian Hesselbarth]

On 23.11.2015 05:59, Jisheng Zhang wrote:
> On Fri, 20 Nov 2015 21:19:46 +0100
> Sebastian Hesselbarth wrote:
>> On 20.11.2015 04:34, Jisheng Zhang wrote:
>>> On Thu, 19 Nov 2015 21:47:05 +0100
>>> Sebastian Hesselbarth wrote:  
>>>> On 16.11.2015 12:09, Jisheng Zhang wrote:  
>>>>> The Marvell Berlin BG2Q has 3 watchdogs which are compatible with the
>>>>> snps,dw-wdt driver sit in the sysmgr domain. This patch adds the
>>>>> corresponding device tree nodes.
>>>>>
>>>>> Signed-off-by: Jisheng Zhang <jszh...@marvell.com>
>>>>> ---
[...]
>>>>> + wdt0: watchdog@1000 {
>>>>> + compatible = "snps,dw-wdt";
>>>>> + reg = <0x1000 0x100>;
>>>>> + clocks = <>;
>>>>> + interrupts = <0>;
>>>>> + status = "disabled";
>>>>
>>>> as the watchdogs are internal and cannot be clock gated
>>>> at all, how about we remove the status = "disabled" and
>>>> make them always available?  
>>>
>>> there are two issues here:
>>>
>>> 1. the dw-wdt can't support multiple variants now. I have rewrite the driver
>>> with watchdog core supplied framework, but the patch isn't sent out and
>>> may be need time to clean up and review.  
>>
>> Ok.
>>
>>> 2. not all dw-wdt devices are available and functional. This depends on
>>> board design and configuration.  
>>
>> I understand that "board design and configuration" may hinder the wdt
>> to issue a hard reset. But all others are able to issue a soft reset
>> or just an interrupt, right?
>>
>> So, I still don't see why we should disable wdt nodes by default
>> except for the driver issue above.
>>
>>> So IMHO status=disabled and patch5-8 is necessary, what do you think?  
>>
>> No. I'd agree to enable wdt0 by default and leave wdt[1,2] disabled
>> because of the driver issue. Patches 5-8 only enable wdt0 anyway.
> 
> That's fine.

Jisheng,

I amended your SoC dtsi watchdog patches accordingly. wdt0 is
now always enabled, while the others are disabled.

So, with the changes Patches 1-4 applied to berlin/dt and berlin64/dt
respectively. Patches 5-8 dropped.

>> As soon as the driver issue is resolved, we enable all wdt nodes
>> unconditionally.
> 
> I will submit patch for the wdt driver and hope it will be merged
> in v4.5.

Ok. Feel free to add a patch that removes the status disabled properties
again if berlin[64]/dt has already hit mainline in the meantime.

If not, keep me posted on the DW wdt patch outcome.

Thanks,

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] ARM: dt: mvebu: ix4-300d: move partitions to partition sub-node

[Sebastian Hesselbarth]

On 28.11.2015 18:00, Andrew Lunn wrote:
> On Sat, Nov 28, 2015 at 12:14:06PM +0100, Sebastian Hesselbarth wrote:
>> NAND flash partitions should be part of a partitions sub-node
>> not the flash node itself. Move the partitions which will also
>> allow different bootloaders get rid of the stock partitions
>> easily by removing the partitions node.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>
> 
> Humm, did not know that. Quoting 
> Documentation/devicetree/bindings/mtd/partition.txt:
> 
>   The partition table should be a subnode of the mtd node and
>   should be named 'partitions'. Partitions are defined in subnodes
>   of the partitions node.
> 
>   For backwards compatibility partitions as direct subnodes of the
>   mtd device are supported. This use is discouraged.
> 
> It also looks like none of the other MVEBU maintainers know that
> either, since a quick look at the .dts files shows very few have a
> partitions node.

Me neither, Linus Walleij's latest contribution to the pogoplug
series showed it to me. And while I am working on barebox support
for the ix4, I always wanted to remove the stock partitions easily.

Barebox always uses internal registers at 0xf100 so it will
never boot that stupid stock kernel that depends on 0xd000
registers.

> Acked-by: Andrew Lunn <and...@lunn.ch>
> 
> Thanks
>   Andrew

ditto ;)

Sebastian

>> ---
>> Cc: Jason Cooper <ja...@lakedaemon.net> 
>> Cc: Andrew Lunn <and...@lunn.ch>
>> Cc: Gregory Clement <gregory.clem...@free-electrons.com> 
>> Cc: Rob Herring <robh...@kernel.org> 
>> Cc: Pawel Moll <pawel.m...@arm.com> 
>> Cc: Mark Rutland <mark.rutl...@arm.com> 
>> Cc: Ian Campbell <ijc+devicet...@hellion.org.uk> 
>> Cc: Kumar Gala <ga...@codeaurora.org> 
>> Cc: Russell King <li...@arm.linux.org.uk> 
>> Cc: Benoit Masson <ya...@perenite.com>
>> Cc: linux-arm-ker...@lists.infradead.org 
>> Cc: devicet...@vger.kernel.org 
>> Cc: linux-kernel@vger.kernel.org 
>> ---
>>  arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 67 
>> +
>>  1 file changed, 36 insertions(+), 31 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts 
>> b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
>> index 30a0a6eac645..76781fd18624 100644
>> --- a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
>> +++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
>> @@ -151,37 +151,42 @@
>>  marvell,nand-enable-arbiter;
>>  nand-on-flash-bbt;
>>  
>> -partition@0 {
>> -label = "u-boot";
>> -reg = <0x000 0xe>;
>> -read-only;
>> -};
>> -
>> -partition@e {
>> -label = "u-boot-env";
>> -reg = <0xe 0x2>;
>> -read-only;
>> -};
>> -
>> -partition@10 {
>> -label = "u-boot-env2";
>> -reg = <0x10 0x2>;
>> -read-only;
>> -};
>> -
>> -partition@12 {
>> -label = "zImage";
>> -reg = <0x12 0x40>;
>> -};
>> -
>> -partition@52 {
>> -label = "initrd";
>> -reg = <0x52 0x40>;
>> -};
>> -
>> -partition@xE0 {
>> -label = "boot";
>> -reg = <0xE0 0x3F20>;
>> +partitions {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +
>> +partition@0 {
>> +label = "u-boot";
>> +

Re: [PATCH 1/4] ARM: dt: mvebu: ix4-300d: remove whole flash partition

[Sebastian Hesselbarth]

On 28.11.2015 17:52, Andrew Lunn wrote:
> On Sat, Nov 28, 2015 at 12:14:05PM +0100, Sebastian Hesselbarth wrote:
>> Current NAND node has an additional flash partition for the whole
>> flash overlapping with real partitions. Remove this partition as
>> the whole flash is already represented by the NAND device itself.
> 
> If i remember correctly, we discussed this when the contribution was
> made. I think the stock firmware might use this for applying updates.
> Maybe Benoit can comment?

Yes, please.

> If so, removing this will break compatibility with stock firmware. Do
> we want to do that? There are a few other mvebu dts files with a
> partition spanning the whole flash. Should we remove them as well?

Well, there is already a mtd device that spans the whole flash so
what is the purpose of another "partition" that isn't a part but
all of the device? Actually, I doubt that a FW update will wipe
the flash as a whole, i.e. including boot loader, boot env, user
config.

Anyway, let's see if Benoit can shed some light on this.

FWIW, neither single partitions nor a combined partitions node
should be a direct sub-node of the _controller_ but a NAND
_device_ node instead. Luckily, multi-device systems are not that
common, so I guess we wait with it until such a system pops up for
testing.

Sebastian


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 6/6] arm64: dts: berlin4ct: add pll and clock nodes

[Sebastian Hesselbarth]

On 24.11.2015 03:35, Jisheng Zhang wrote:

On Mon, 23 Nov 2015 16:54:44 +0800
Jisheng Zhang wrote:

On Mon, 23 Nov 2015 09:30:42 +0100
Sebastian Hesselbarth wrote:

On 23.11.2015 08:21, Jisheng Zhang wrote:

On Fri, 20 Nov 2015 22:06:59 +0100
Sebastian Hesselbarth wrote:

On 20.11.2015 09:42, Jisheng Zhang wrote:

Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.

Signed-off-by: Jisheng Zhang 
---

[...]

+   syspll: syspll {
+   compatible = "marvell,berlin-pll";
+   reg = <0xea0200 0x14>, <0xea0710 4>;
+   #clock-cells = <0>;
+   clocks = <>;
+   bypass-shift = /bits/ 8 <0>;
+   };
+
+   gateclk: gateclk {
+   compatible = "marvell,berlin4ct-gateclk";
+   reg = <0xea0700 4>;
+   #clock-cells = <1>;
+   };
+
+   clk: clk {
+   compatible = "marvell,berlin4ct-clk";
+   reg = <0xea0720 0x144>;


Looking at the reg ranges, I'd say that they are all clock related
and pretty close to each other:

gateclk: reg = <0xea0700 4>;
bypass:  reg = <0xea0710 4>;
clk: reg = <0xea0720 0x144>;


Although these ranges sit close, but we should represent HW structure as you
said.


Then how do you argue that you have to share the gate clock register
with every PLL? The answer is quite simple: You are not separating by
HW either but existing SW API.


No, PLLs don't share register any more. You can find what all clock nodes will
look like in:


Jisheng,

referring to the sunxi clock related thread, I am glad you finally
picked up the idea of merging clock nodes. Before you start reworking
bg4 clocks, I think I should be a little bit more clear about what I
expect to be the outcome.

When I said "one single clock complex node", I was referring to the
clocks located within the system-controller reg region, i.e. those at
0xea. With bg2x we came to the conclusion that those registers
cannot be not cleanly separated by functions, so we decided to have
a single system-controller simple-mfd node with sub-nodes for
pinctrl, clock, reset, and whatever we will find there in the future.

Please also follow this scheme for bg4 because when you start looking
at reset, you'll likely see the same issues we were facing: Either you
have a reset controller node with a plethora of reg property entries
or you constantly undermine the concept of requested resources by using
of_iomap().

Using simple-mfd is a compromise between detailed HW description and
usability. It will also automatically deal with concurrent accesses to
the same register for e.g. clock and reset because simple-mfd and syscon
install an access lock for the reg region. Even though there may be no
real concurrent accesses to the same register, it does no real harm
because we are locking resisters that aren't supposed to be used in
high-speed applications. Some of them are touched once at boot, most
of them are never touched by Linux at all.

For the other PLLs at <0x922000 0x14> and <0x940034 0x14>, I do accept
that they are not part of the system-controller sub-node. For the short
run, I would accept separate nodes for the PLLs alone, but on the long
run they should be hidden within the functional node they belong to,
i.e. mempll should be a clock provided by some memory-controller node.
As soon as you look at power saving modes for the memory-controller,
you would need access to memory-controller register _and_ mempll anyway.

We do have our DT tagged unstable, so we still can easily revert our
limited view of some nodes later.

BTW, if the clock provided by mempll is used to generate peripheral
clocks that are dealt with in the sysctrl clock complex, you should,
of course, expose that relation in DT, e.g.:

sysctrl: system-controller {
reg = <0xea0700 0xfoo>;

sysclk: clock {
#clock-cells = <1>;
clocks = <>, < 0>;
clock-names = "osc", "mempll";
};
};

memctrl: memory-controller {
reg = <0x92 0xbar>;
/*
 * clock-cells can also be 0
 * if there is no other clock provided
 */
#clock-cells = <1>;

clocks = <>;
clock-names = "osc";
};

some-peripheral: bla {
clocks = < SOME_PERIPHERAL_CLOCK_ID>;
};

Sebastian


If you would really want to just describe the HW, then you'd have to
have a single node for _all_ clocks that get controlled by 0xea0700/0x4,
feed some 32+ clocks into the node, and out again. Obviously, this
isn't what we want, right?


I represented the HW by "kind", for example, gateclks, common-clks, pllclk.
And let common PLLs follow this rule as we

Re: [PATCH v2 6/6] arm64: dts: berlin4ct: add pll and clock nodes

[Sebastian Hesselbarth]

On 24.11.2015 03:35, Jisheng Zhang wrote:

On Mon, 23 Nov 2015 16:54:44 +0800
Jisheng Zhang wrote:

On Mon, 23 Nov 2015 09:30:42 +0100
Sebastian Hesselbarth wrote:

On 23.11.2015 08:21, Jisheng Zhang wrote:

On Fri, 20 Nov 2015 22:06:59 +0100
Sebastian Hesselbarth wrote:

On 20.11.2015 09:42, Jisheng Zhang wrote:

Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.

Signed-off-by: Jisheng Zhang <jszh...@marvell.com>
---

[...]

+   syspll: syspll {
+   compatible = "marvell,berlin-pll";
+   reg = <0xea0200 0x14>, <0xea0710 4>;
+   #clock-cells = <0>;
+   clocks = <>;
+   bypass-shift = /bits/ 8 <0>;
+   };
+
+   gateclk: gateclk {
+   compatible = "marvell,berlin4ct-gateclk";
+   reg = <0xea0700 4>;
+   #clock-cells = <1>;
+   };
+
+   clk: clk {
+   compatible = "marvell,berlin4ct-clk";
+   reg = <0xea0720 0x144>;


Looking at the reg ranges, I'd say that they are all clock related
and pretty close to each other:

gateclk: reg = <0xea0700 4>;
bypass:  reg = <0xea0710 4>;
clk: reg = <0xea0720 0x144>;


Although these ranges sit close, but we should represent HW structure as you
said.


Then how do you argue that you have to share the gate clock register
with every PLL? The answer is quite simple: You are not separating by
HW either but existing SW API.


No, PLLs don't share register any more. You can find what all clock nodes will
look like in:


Jisheng,

referring to the sunxi clock related thread, I am glad you finally
picked up the idea of merging clock nodes. Before you start reworking
bg4 clocks, I think I should be a little bit more clear about what I
expect to be the outcome.

When I said "one single clock complex node", I was referring to the
clocks located within the system-controller reg region, i.e. those at
0xea. With bg2x we came to the conclusion that those registers
cannot be not cleanly separated by functions, so we decided to have
a single system-controller simple-mfd node with sub-nodes for
pinctrl, clock, reset, and whatever we will find there in the future.

Please also follow this scheme for bg4 because when you start looking
at reset, you'll likely see the same issues we were facing: Either you
have a reset controller node with a plethora of reg property entries
or you constantly undermine the concept of requested resources by using
of_iomap().

Using simple-mfd is a compromise between detailed HW description and
usability. It will also automatically deal with concurrent accesses to
the same register for e.g. clock and reset because simple-mfd and syscon
install an access lock for the reg region. Even though there may be no
real concurrent accesses to the same register, it does no real harm
because we are locking resisters that aren't supposed to be used in
high-speed applications. Some of them are touched once at boot, most
of them are never touched by Linux at all.

For the other PLLs at <0x922000 0x14> and <0x940034 0x14>, I do accept
that they are not part of the system-controller sub-node. For the short
run, I would accept separate nodes for the PLLs alone, but on the long
run they should be hidden within the functional node they belong to,
i.e. mempll should be a clock provided by some memory-controller node.
As soon as you look at power saving modes for the memory-controller,
you would need access to memory-controller register _and_ mempll anyway.

We do have our DT tagged unstable, so we still can easily revert our
limited view of some nodes later.

BTW, if the clock provided by mempll is used to generate peripheral
clocks that are dealt with in the sysctrl clock complex, you should,
of course, expose that relation in DT, e.g.:

sysctrl: system-controller {
reg = <0xea0700 0xfoo>;

sysclk: clock {
#clock-cells = <1>;
clocks = <>, < 0>;
clock-names = "osc", "mempll";
};
};

memctrl: memory-controller {
reg = <0x92 0xbar>;
/*
 * clock-cells can also be 0
 * if there is no other clock provided
 */
#clock-cells = <1>;

clocks = <>;
clock-names = "osc";
};

some-peripheral: bla {
clocks = < SOME_PERIPHERAL_CLOCK_ID>;
};

Sebastian


If you would really want to just describe the HW, then you'd have to
have a single node for _all_ clocks that get controlled by 0xea0700/0x4,
feed some 32+ clocks into the node, and out again. Obviously, this
isn't what we want, right?


I represented the HW by "kind", for example, gateclks, common-clks, pllclk.
And let commo

Re: [PATCH v2 6/6] arm64: dts: berlin4ct: add pll and clock nodes

[Sebastian Hesselbarth]

On 23.11.2015 08:21, Jisheng Zhang wrote:

On Fri, 20 Nov 2015 22:06:59 +0100
Sebastian Hesselbarth wrote:

On 20.11.2015 09:42, Jisheng Zhang wrote:

Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.

Signed-off-by: Jisheng Zhang 
---

[...]

+   syspll: syspll {
+   compatible = "marvell,berlin-pll";
+   reg = <0xea0200 0x14>, <0xea0710 4>;
+   #clock-cells = <0>;
+   clocks = <>;
+   bypass-shift = /bits/ 8 <0>;
+   };
+
+   gateclk: gateclk {
+   compatible = "marvell,berlin4ct-gateclk";
+   reg = <0xea0700 4>;
+   #clock-cells = <1>;
+   };
+
+   clk: clk {
+   compatible = "marvell,berlin4ct-clk";
+   reg = <0xea0720 0x144>;


Looking at the reg ranges, I'd say that they are all clock related
and pretty close to each other:

gateclk: reg = <0xea0700 4>;
bypass:  reg = <0xea0710 4>;
clk: reg = <0xea0720 0x144>;


Although these ranges sit close, but we should represent HW structure as you
said.


Then how do you argue that you have to share the gate clock register
with every PLL? The answer is quite simple: You are not separating by
HW either but existing SW API.

If you would really want to just describe the HW, then you'd have to
have a single node for _all_ clocks that get controlled by 0xea0700/0x4,
feed some 32+ clocks into the node, and out again. Obviously, this
isn't what we want, right?

So, the idea of berlin2 sysctrl nodes (and similar other SoCs) is: Some
SoCs just dump some functions into a bunch of registers with no
particular order. We'd never find a good representation for that in DT,
so we don't bother to try but let the driver implementation deal with
the mess. Using "simple-mfd" is a nice solution to scattered registers
please have a look at it and come up with a cleaner separation for bg4
clock.


First of all, let me describe the clks/plls in BG4CT. BG4CT contains:

two kinds of PLL: normal PLL and AVPLL. These PLLs are put with their users
together. For example: mempll pll registers <0xf7940034, 0x14> is put together
with mem controller registers. AVPLL control registers are put with AV devices.


Why didn't you choose to have a memory-controller node that provides
mempll clock then? I am open to having multiple nodes providing clocks
but having a node for every clock in any subsystem is something I'll
not even think about.


You can also check mempll, cpupll and syspll ranges:

cpupll: <0x922000 0x14>

mempll: <0x940034 0x14>

syspll: <0xea0200 0x14>


We have three normal PLLS: cpupll, mempll and syspll. All these three PLLs use
25MHZ osc as clocksource. These plls can be bypassed. when syspll is bypassed
the 25MHZ osc is directly output to syspllclk. When mempll/cpupll is bypassed,
its corresponding fastrefclk is directly output to ddrphyclk/cpuclk:


---25MHZ osc--|\
| |-- syspllclk
---| SYSPLL |-|/



---cpufastrefclk--|\
| |-- cpuclk
---| CPUPLL |-|/


---memfastrefclk--|\
| |-- ddrphyclk
---| MEMPLL |-|/

NOTE: the fastrefclk is the so called normal clk below.



two kinds of clk: normal clk and gate clk. The normal clk supports changing
divider, selecting clock source, disabling/enabling etc. The gate clk only
supports disabling/enabling. normal clks use syspllclk as clocksource, while
gate clks use perifsysclk as clocksource.


So what's the representing HW structure in fact? Here is my proposal:
1. have mempll, cpupll and syspll node in dts


No.


2. one gateclk node in dts for gateclks


No.


3. one normalclk node in dts for normal clks


No.


4. one ccf clock-mux for cpuclk, ddrphyclk and syspllclk.


No.


what do you think?


I think that the current separation is not a good one. I am open for
suggestions but I am not accepting single PLL/clock nodes.


 From another side, let's have a look at driver/clk/mvebu. As can be seen,
different clks register are close each other, for example, gateclk and coreclk
in arch/arm/boot/dts/armada-xp.dtsi.

And drivers/clk/sunxi, arch/arm/boot/dts/sun7i-a20.dtsi, the pll4, pll12, gt_clk
and ahb*, apb* etc...

why these SoCs don't merge clocks/gates/plls to a single clock complex node?
I think that's because they are representing real HW structure.


These SoC (at least mvebu) didn't merge them into a single clock
complex node because nobody had a better idea or an impression of
the consequences. Looking back with the idea of syscon/simple-mfd
we probably would have chosen to separate differently.


So, please just follow the OF/driver struc

Re: [PATCH 2/2] arm64: dts: berlin4ct: enable all i2c nodes for the STB board

[Sebastian Hesselbarth]

On 23.11.2015 03:49, Jisheng Zhang wrote:

On Fri, 20 Nov 2015 22:19:32 +0100
Sebastian Hesselbarth wrote:

On 20.11.2015 10:47, Jisheng Zhang wrote:

Enable all i2c nodes for the Marvell berlin BG4CT STB board.

Signed-off-by: Jisheng Zhang 
---
  arch/arm64/boot/dts/marvell/berlin4ct-stb.dts | 50 +++
  1 file changed, 50 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts 
b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
index 348c37e..9e8e2e0 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
+++ b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
@@ -61,6 +61,56 @@
};
  };

+_pinctrl {
+   twsi1_pmux: twsi1-pmux {
+   groups = "TX_EDDC_SCL", "TX_EDDC_SDA";
+   function = "tx_eddc";
+   };


Please keep the pinmux sub-nodes in the SoC dtsi as long
as they are not strictly board specific, i.e. gpios.


Hmm, seems all boards configure this pin for EDDC usage, so it's fine
to move to soc




+};
+
+ {
+   status = "okay";
+   pinctrl-0 = <_pmux>;
+   pinctrl-names = "default";


If there is only one (or a default) pinctrl-0 option for i2c0,
you can also move it to the SoC dtsi.


Some board may not use i2c0, i2c2, i2c3 host and use the pin as gpio for other
purpose. Considering the above twsi1_pmux usage, what's the better solution?
move twsi1_pmux to soc's dtsi and leave i2c0, i2c2, i2c3 pinctrl in board dts?


If some boards don't use i2cN, they do not enable the node in their
board dts. That is sufficient to not configure the pinmux as it will
only be set if a driver is loaded for that node.

If there is only one or two different pinmux settings for a specific
function _always_ move the pinmux setting into SoC dtsi. If there is
a well known default out of two or more possible settings, we may also
have that pinmux as a default in the i2c node and only overwrite it
when we have a board that uses a different setting.

So, for i2c: Move all pinctrl/pinctrl-names properties to the SoC
dtsi.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: dts: berlin4ct: enable all i2c nodes for the STB board

[Sebastian Hesselbarth]

On 23.11.2015 03:49, Jisheng Zhang wrote:

On Fri, 20 Nov 2015 22:19:32 +0100
Sebastian Hesselbarth wrote:

On 20.11.2015 10:47, Jisheng Zhang wrote:

Enable all i2c nodes for the Marvell berlin BG4CT STB board.

Signed-off-by: Jisheng Zhang <jszh...@marvell.com>
---
  arch/arm64/boot/dts/marvell/berlin4ct-stb.dts | 50 +++
  1 file changed, 50 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts 
b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
index 348c37e..9e8e2e0 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
+++ b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
@@ -61,6 +61,56 @@
};
  };

+_pinctrl {
+   twsi1_pmux: twsi1-pmux {
+   groups = "TX_EDDC_SCL", "TX_EDDC_SDA";
+   function = "tx_eddc";
+   };


Please keep the pinmux sub-nodes in the SoC dtsi as long
as they are not strictly board specific, i.e. gpios.


Hmm, seems all boards configure this pin for EDDC usage, so it's fine
to move to soc




+};
+
+ {
+   status = "okay";
+   pinctrl-0 = <_pmux>;
+   pinctrl-names = "default";


If there is only one (or a default) pinctrl-0 option for i2c0,
you can also move it to the SoC dtsi.


Some board may not use i2c0, i2c2, i2c3 host and use the pin as gpio for other
purpose. Considering the above twsi1_pmux usage, what's the better solution?
move twsi1_pmux to soc's dtsi and leave i2c0, i2c2, i2c3 pinctrl in board dts?


If some boards don't use i2cN, they do not enable the node in their
board dts. That is sufficient to not configure the pinmux as it will
only be set if a driver is loaded for that node.

If there is only one or two different pinmux settings for a specific
function _always_ move the pinmux setting into SoC dtsi. If there is
a well known default out of two or more possible settings, we may also
have that pinmux as a default in the i2c node and only overwrite it
when we have a board that uses a different setting.

So, for i2c: Move all pinctrl/pinctrl-names properties to the SoC
dtsi.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 6/6] arm64: dts: berlin4ct: add pll and clock nodes

[Sebastian Hesselbarth]

On 23.11.2015 08:21, Jisheng Zhang wrote:

On Fri, 20 Nov 2015 22:06:59 +0100
Sebastian Hesselbarth wrote:

On 20.11.2015 09:42, Jisheng Zhang wrote:

Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.

Signed-off-by: Jisheng Zhang <jszh...@marvell.com>
---

[...]

+   syspll: syspll {
+   compatible = "marvell,berlin-pll";
+   reg = <0xea0200 0x14>, <0xea0710 4>;
+   #clock-cells = <0>;
+   clocks = <>;
+   bypass-shift = /bits/ 8 <0>;
+   };
+
+   gateclk: gateclk {
+   compatible = "marvell,berlin4ct-gateclk";
+   reg = <0xea0700 4>;
+   #clock-cells = <1>;
+   };
+
+   clk: clk {
+   compatible = "marvell,berlin4ct-clk";
+   reg = <0xea0720 0x144>;


Looking at the reg ranges, I'd say that they are all clock related
and pretty close to each other:

gateclk: reg = <0xea0700 4>;
bypass:  reg = <0xea0710 4>;
clk: reg = <0xea0720 0x144>;


Although these ranges sit close, but we should represent HW structure as you
said.


Then how do you argue that you have to share the gate clock register
with every PLL? The answer is quite simple: You are not separating by
HW either but existing SW API.

If you would really want to just describe the HW, then you'd have to
have a single node for _all_ clocks that get controlled by 0xea0700/0x4,
feed some 32+ clocks into the node, and out again. Obviously, this
isn't what we want, right?

So, the idea of berlin2 sysctrl nodes (and similar other SoCs) is: Some
SoCs just dump some functions into a bunch of registers with no
particular order. We'd never find a good representation for that in DT,
so we don't bother to try but let the driver implementation deal with
the mess. Using "simple-mfd" is a nice solution to scattered registers
please have a look at it and come up with a cleaner separation for bg4
clock.


First of all, let me describe the clks/plls in BG4CT. BG4CT contains:

two kinds of PLL: normal PLL and AVPLL. These PLLs are put with their users
together. For example: mempll pll registers <0xf7940034, 0x14> is put together
with mem controller registers. AVPLL control registers are put with AV devices.


Why didn't you choose to have a memory-controller node that provides
mempll clock then? I am open to having multiple nodes providing clocks
but having a node for every clock in any subsystem is something I'll
not even think about.


You can also check mempll, cpupll and syspll ranges:

cpupll: <0x922000 0x14>

mempll: <0x940034 0x14>

syspll: <0xea0200 0x14>


We have three normal PLLS: cpupll, mempll and syspll. All these three PLLs use
25MHZ osc as clocksource. These plls can be bypassed. when syspll is bypassed
the 25MHZ osc is directly output to syspllclk. When mempll/cpupll is bypassed,
its corresponding fastrefclk is directly output to ddrphyclk/cpuclk:


---25MHZ osc--|\
| |-- syspllclk
---| SYSPLL |-|/



---cpufastrefclk--|\
| |-- cpuclk
---| CPUPLL |-|/


---memfastrefclk--|\
| |-- ddrphyclk
---| MEMPLL |-|/

NOTE: the fastrefclk is the so called normal clk below.



two kinds of clk: normal clk and gate clk. The normal clk supports changing
divider, selecting clock source, disabling/enabling etc. The gate clk only
supports disabling/enabling. normal clks use syspllclk as clocksource, while
gate clks use perifsysclk as clocksource.


So what's the representing HW structure in fact? Here is my proposal:
1. have mempll, cpupll and syspll node in dts


No.


2. one gateclk node in dts for gateclks


No.


3. one normalclk node in dts for normal clks


No.


4. one ccf clock-mux for cpuclk, ddrphyclk and syspllclk.


No.


what do you think?


I think that the current separation is not a good one. I am open for
suggestions but I am not accepting single PLL/clock nodes.


 From another side, let's have a look at driver/clk/mvebu. As can be seen,
different clks register are close each other, for example, gateclk and coreclk
in arch/arm/boot/dts/armada-xp.dtsi.

And drivers/clk/sunxi, arch/arm/boot/dts/sun7i-a20.dtsi, the pll4, pll12, gt_clk
and ahb*, apb* etc...

why these SoCs don't merge clocks/gates/plls to a single clock complex node?
I think that's because they are representing real HW structure.


These SoC (at least mvebu) didn't merge them into a single clock
complex node because nobody had a better idea or an impression of
the consequences. Looking back with the idea of syscon/simple-mfd
we probably would have chosen to separate differently.


So, please just follow t

Re: [PATCH 1/2] arm64: dts: berlin4ct: add I2C nodes for BG4CT

[Sebastian Hesselbarth]

On 20.11.2015 10:47, Jisheng Zhang wrote:
> The Marvell Berlin BG4CT SoC has 4 TWSI which are compatible with the
> Synopsys DesignWare I2C driver. Add the corresponding nodes.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 52 
> ++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index cca4c41..39d0676 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -232,6 +232,32 @@
>   };
>   };
>  
> + i2c0: i2c@1400 {
> + compatible = "snps,designware-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x1400 0x100>;
> + clocks = < CLK_APBCORE>;

This patch looks fine to me, except that clock node naming and
clock indices may change. We should really postpone this series
until we worked out clock.

Sebastian

> + i2c-sda-hold-time-ns = <35>;
> + i2c-sda-falling-time-ns = <425>;
> + i2c-scl-falling-time-ns = <205>;
> + interrupts = <4>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@1800 {
> + compatible = "snps,designware-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x1800 0x100>;
> + clocks = < CLK_APBCORE>;
> + i2c-sda-hold-time-ns = <35>;
> + i2c-sda-falling-time-ns = <425>;
> + i2c-scl-falling-time-ns = <205>;
> + interrupts = <5>;
> + status = "disabled";
> + };
> +
>   aic: interrupt-controller@3800 {
>   compatible = "snps,dw-apb-ictl";
>   reg = <0x3800 0x30>;
> @@ -319,6 +345,32 @@
>   };
>   };
>  
> + i2c2: i2c@b000 {
> + compatible = "snps,designware-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0xb000 0x100>;
> + clocks = <>;
> + i2c-sda-hold-time-ns = <140>;
> + i2c-sda-falling-time-ns = <500>;
> + i2c-scl-falling-time-ns = <220>;
> + interrupts = <6>;
> + status = "disabled";
> + };
> +
> + i2c3: i2c@c000 {
> + compatible = "snps,designware-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0xc000 0x100>;
> + clocks = <>;
> + i2c-sda-hold-time-ns = <140>;
> + i2c-sda-falling-time-ns = <500>;
> + i2c-scl-falling-time-ns = <220>;
> + interrupts = <7>;
> + status = "disabled";
> + };
> +
>   uart0: uart@d000 {
>   compatible = "snps,dw-apb-uart";
>   reg = <0xd000 0x100>;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: dts: berlin4ct: enable all i2c nodes for the STB board

[Sebastian Hesselbarth]

On 20.11.2015 10:47, Jisheng Zhang wrote:
> Enable all i2c nodes for the Marvell berlin BG4CT STB board.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  arch/arm64/boot/dts/marvell/berlin4ct-stb.dts | 50 
> +++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts 
> b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> index 348c37e..9e8e2e0 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> @@ -61,6 +61,56 @@
>   };
>  };
>  
> +_pinctrl {
> + twsi1_pmux: twsi1-pmux {
> + groups = "TX_EDDC_SCL", "TX_EDDC_SDA";
> + function = "tx_eddc";
> + };

Please keep the pinmux sub-nodes in the SoC dtsi as long
as they are not strictly board specific, i.e. gpios.

> +};
> +
> + {
> + status = "okay";
> + pinctrl-0 = <_pmux>;
> + pinctrl-names = "default";

If there is only one (or a default) pinctrl-0 option for i2c0,
you can also move it to the SoC dtsi.

> +};
> +
> + {
> + status = "okay";
> + pinctrl-0 = <_pmux>;
> + pinctrl-names = "default";

ditto.

> +};
> +
> + {
> + status = "okay";
> + pinctrl-0 = <_pmux>;
> + pinctrl-names = "default";

ditto.

> +};
> +
> + {
> + status = "okay";
> + pinctrl-0 = <_pmux>;
> + pinctrl-names = "default";

ditto.

> +};
> +
> +_pinctrl {
> + twsi0_pmux: twsi0-pmux {
> + groups = "TW0_SCL", "TW0_SDA";
> + function = "tw0";
> + };

Same comment about moving pinmux nodes to SoC dtsi.

> +};
> +
> +_pinctrl {
> + twsi2_pmux: twsi2-pmux {
> + groups = "SM_TW2_SCL", "SM_TW2_SDA";
> + function = "tw2";
> + };
> +
> + twsi3_pmux: twsi3-pmux {
> + groups = "SM_TW3_SCL", "SM_TW3_SDA";
> + function = "tw3";
> + };

ditto.

Sebastian

> +};
> +
>   {
>   status = "okay";
>  };
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 6/6] arm64: dts: berlin4ct: add pll and clock nodes

[Sebastian Hesselbarth]

On 20.11.2015 09:42, Jisheng Zhang wrote:
> Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 38 
> ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index a4a1876..808a997 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -42,6 +42,7 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
> +#include 
>  #include 
>  
>  / {
> @@ -135,6 +136,22 @@
>   interrupts =  IRQ_TYPE_LEVEL_HIGH)>;
>   };
>  
> + cpupll: cpupll {
> + compatible = "marvell,berlin-pll";
> + reg = <0x922000 0x14>, <0xea0710 4>;
> + #clock-cells = <0>;
> + clocks = <>, < CLK_CPUFASTREF>;
> + bypass-shift = /bits/ 8 <2>;
> + };
> +
> + mempll: mempll {
> + compatible = "marvell,berlin-pll";
> + reg = <0x940034 0x14>, <0xea0710 4>;

Whenever you see overlapping/repeating reg ranges, e.g. <0xea0710 4>
you can be sure you are not representing HW structure but driver
structure here.

Please merge clocks/gates/plls to a single clock complex node
and deal with the internals by using "simple-mfd" and "syscon" regmaps.

> + #clock-cells = <0>;
> + clocks = <>, < CLK_MEMFASTREF>;
> + bypass-shift = /bits/ 8 <1>;
> + };
> +
>   apb@e8 {
>   compatible = "simple-bus";
>   #address-cells = <1>;
> @@ -225,6 +242,27 @@
>   };
>   };
>  
> + syspll: syspll {
> + compatible = "marvell,berlin-pll";
> + reg = <0xea0200 0x14>, <0xea0710 4>;
> + #clock-cells = <0>;
> + clocks = <>;
> + bypass-shift = /bits/ 8 <0>;
> + };
> +
> + gateclk: gateclk {
> + compatible = "marvell,berlin4ct-gateclk";
> + reg = <0xea0700 4>;
> + #clock-cells = <1>;
> + };
> +
> + clk: clk {
> + compatible = "marvell,berlin4ct-clk";
> + reg = <0xea0720 0x144>;

Looking at the reg ranges, I'd say that they are all clock related
and pretty close to each other:

gateclk: reg = <0xea0700 4>;
bypass:  reg = <0xea0710 4>;
clk: reg = <0xea0720 0x144>;

So, please just follow the OF/driver structure we already
have for Berlin2.

Sebastian

> + #clock-cells = <1>;
> + clocks = <>;
> + };
> +
>   soc_pinctrl: pin-controller@ea8000 {
>   compatible = "marvell,berlin4ct-soc-pinctrl";
>   reg = <0xea8000 0x14>;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/6] clk: berlin: add clk support for berlin4ct

[Sebastian Hesselbarth]

On 20.11.2015 09:42, Jisheng Zhang wrote:
> This patch supports the gateclk and berlin-clk in berlin4ct SoC.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/clk/berlin/Makefile|  2 +-
>  drivers/clk/berlin/clk-berlin4ct.c | 97 
> ++
>  2 files changed, 98 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/berlin/clk-berlin4ct.c
> 
> diff --git a/drivers/clk/berlin/Makefile b/drivers/clk/berlin/Makefile
> index fc92151..accfc3a 100644
> --- a/drivers/clk/berlin/Makefile
> +++ b/drivers/clk/berlin/Makefile
> @@ -1,5 +1,5 @@
>  obj-y += berlin2-avpll.o berlin2-pll.o berlin2-div.o
> -obj-y += pll.o clk.o gate.o
> +obj-y += pll.o clk.o gate.o clk-berlin4ct.o

This will always compile clk-berlin4ct unconditionally on bg2x too.

Also, keep the naming style.

Sebastian

>  obj-$(CONFIG_MACH_BERLIN_BG2)+= bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2CD)  += bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2Q)   += bg2q.o
> diff --git a/drivers/clk/berlin/clk-berlin4ct.c 
> b/drivers/clk/berlin/clk-berlin4ct.c
> new file mode 100644
> index 000..0d994a4
> --- /dev/null
> +++ b/drivers/clk/berlin/clk-berlin4ct.c
> @@ -0,0 +1,97 @@
> +/*
> + * Copyright (c) 2015 Marvell Technology Group Ltd.
> + *
> + * Author: Jisheng Zhang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +
> +#include "clk.h"
> +
> +static struct clk_onecell_data gateclk_data;
> +static struct clk_onecell_data clk_data;
> +
> +static const struct gateclk_desc berlin4ct_gates[] __initconst = {
> + { "tspsysclk",  "perifsysclk",  0 },
> + { "usb0coreclk","perifsysclk",  1 },
> + { "zspsysclk",  "perifsysclk",  2 },
> + { "sdiosysclk", "perifsysclk",  3 },
> + { "ethcoreclk", "perifsysclk",  4 },
> + { "pcie0sys",   "perifsysclk",  6 },
> + { "sata0core",  "perifsysclk",  7 },
> + { "nfcsysclk",  "perifsysclk",  8 },
> + { "emmcsysclk", "perifsysclk",  9 },
> + { "ihb0sysclk", "perifsysclk",  10 },
> +};
> +
> +static void __init berlin4ct_gateclk_setup(struct device_node *np)
> +{
> + int n = ARRAY_SIZE(berlin4ct_gates);
> +
> + berlin_gateclk_setup(np, berlin4ct_gates, _data, n);
> +}
> +CLK_OF_DECLARE(berlin4ct_gateclk, "marvell,berlin4ct-gateclk",
> +berlin4ct_gateclk_setup);
> +
> +static const struct clk_desc berlin4ct_descs[] __initconst = {
> + { "cpufastrefclk",  0x0 },
> + { "memfastrefclk",  0x4 },
> + { "cfgclk", 0x20,   CLK_IGNORE_UNUSED },
> + { "perifsysclk",0x24,   CLK_IGNORE_UNUSED },
> + { "hbclk",  0x28 },
> + { "atbclk", 0x2c },
> + { "decoderclk", 0x40 },
> + { "decoderm3clk",   0x44 },
> + { "decoderpcubeclk",0x48 },
> + { "encoderclk", 0x4c },
> + { "ovpcoreclk", 0x50 },
> + { "gfx2dcoreclk",   0x60 },
> + { "gfx3dcoreclk",   0x64 },
> + { "gfx3dshclk", 0x68 },
> + { "gfx3dsysclk",0x6c },
> + { "gfx2dsysclk",0x70 },
> + { "aviosysclk", 0x80 },
> + { "vppsysclk",  0x84 },
> + { "eddcclk",0x88 },
> + { "aviobiuclk", 0x8c },
> + { "zspclk", 0xa0 },
> + { "tspclk", 0xc0 },
> + { "tsprefclk",  0xc4 },
> + { "ndsclk", 0xc8 },
> + { "nocsclk",0xcc },
> + { "apbcoreclk", 0xd0,   CLK_IGNORE_UNUSED },
> + { "emmcclk",0xe0 },
> + { "sd0clk", 0xe4 },
> + { "sd1clk", 0xe8 },
> + { "dllmstrefclk",   0xec },
> + { "gethrgmiiclk",   0xf0 },
> + { "gethrgmiisysclk",0xf4 },
> + { "usim0clk",   0x100 },
> + { "pcietestclk",0x110 },
> + { "usb2testclk",0x120 },
> + { "usb3testclk",0x124 },
> + { "usb3coreclk",0x128 },
> + { "nfceccclk",  0x130 },
> + { "bcmclk", 0x140 },
> +};
> +
> +static void __init berlin4ct_clk_setup(struct device_node *np)
> +{
> + int n = ARRAY_SIZE(berlin4ct_descs);
> +
> + berlin_clk_setup(np, berlin4ct_descs, _data, n);
> +}
> +CLK_OF_DECLARE(berlin4ct_clk, "marvell,berlin4ct-clk",
> +berlin4ct_clk_setup);
> 

--
To unsubscribe from 

Re: [PATCH v2 2/6] clk: berlin: add common clk driver for newer SoCs

[Sebastian Hesselbarth]

On 20.11.2015 09:42, Jisheng Zhang wrote:
> Add common clk driver for Marvell SoCs newer than BG2, BG2CD, BG2Q.
> berlin_clk_setup() is provided to setup and register such kind of clks.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/clk/berlin/Makefile |   2 +-
>  drivers/clk/berlin/clk.c| 203 
> 
>  drivers/clk/berlin/clk.h|  33 +++
>  3 files changed, 237 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/berlin/clk.c
>  create mode 100644 drivers/clk/berlin/clk.h
> 
> diff --git a/drivers/clk/berlin/Makefile b/drivers/clk/berlin/Makefile
> index eee42b0..ee2e09d 100644
> --- a/drivers/clk/berlin/Makefile
> +++ b/drivers/clk/berlin/Makefile
> @@ -1,5 +1,5 @@
>  obj-y += berlin2-avpll.o berlin2-pll.o berlin2-div.o
> -obj-y += pll.o
> +obj-y += pll.o clk.o

Same comment about the naming convention.

>  obj-$(CONFIG_MACH_BERLIN_BG2)+= bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2CD)  += bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2Q)   += bg2q.o
> diff --git a/drivers/clk/berlin/clk.c b/drivers/clk/berlin/clk.c
> new file mode 100644
> index 000..70f2b9d
> --- /dev/null
> +++ b/drivers/clk/berlin/clk.c
> @@ -0,0 +1,203 @@
> +/*
> + * Copyright (c) 2015 Marvell Technology Group Ltd.
> + *
> + * Author: Jisheng Zhang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "clk.h"
> +
> +#define CLKEN(1 << 0)

#define CLKEN   BIT(0)

> +#define CLKPLLSEL_MASK   7

Please use hex numbers for the mask.

> +#define CLKPLLSEL_SHIFT  1
> +#define CLKPLLSWITCH (1 << 4)
> +#define CLKSWITCH(1 << 5)
> +#define CLKD3SWITCH  (1 << 6)

BIT() again.

> +#define CLKSEL_MASK  7

Hex again.

> +#define CLKSEL_SHIFT 7
> +
> +#define CLK_SOURCE_MAX   5
> +
> +struct berlin_clk {
> + struct clk_hw hw;
> + void __iomem *base;
> +};
> +
> +#define to_berlin_clk(hw)container_of(hw, struct berlin_clk, hw)
> +
> +static u8 clk_div[] = {1, 2, 4, 6, 8, 12, 1, 1};

Hmm, this pretty much looks like berlin2-div dividers...

> +static unsigned long berlin_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + u32 val, divider;
> + struct berlin_clk *clk = to_berlin_clk(hw);
> +
> + val = readl_relaxed(clk->base);
> + if (val & CLKD3SWITCH)
> + divider = 3;

and this looks like berlin2-div structure, doesn't it?

Again, please reuse what is already available.

Sebastian

> + else {
> + if (val & CLKSWITCH) {
> + val >>= CLKSEL_SHIFT;
> + val &= CLKSEL_MASK;
> + divider = clk_div[val];
> + } else
> + divider = 1;
> + }
> +
> + return parent_rate / divider;
> +}
> +
> +static u8 berlin_clk_get_parent(struct clk_hw *hw)
> +{
> + u32 val;
> + struct berlin_clk *clk = to_berlin_clk(hw);
> +
> + val = readl_relaxed(clk->base);
> + if (val & CLKPLLSWITCH) {
> + val >>= CLKPLLSEL_SHIFT;
> + val &= CLKPLLSEL_MASK;
> + return val;
> + }
> +
> + return 0;
> +}
> +
> +static int berlin_clk_enable(struct clk_hw *hw)
> +{
> + u32 val;
> + struct berlin_clk *clk = to_berlin_clk(hw);
> +
> + val = readl_relaxed(clk->base);
> + val |= CLKEN;
> + writel_relaxed(val, clk->base);
> +
> + return 0;
> +}
> +
> +static void berlin_clk_disable(struct clk_hw *hw)
> +{
> + u32 val;
> + struct berlin_clk *clk = to_berlin_clk(hw);
> +
> + val = readl_relaxed(clk->base);
> + val &= ~CLKEN;
> + writel_relaxed(val, clk->base);
> +}
> +
> +static int berlin_clk_is_enabled(struct clk_hw *hw)
> +{
> + u32 val;
> + struct berlin_clk *clk = to_berlin_clk(hw);
> +
> + val = readl_relaxed(clk->base);
> + val &= CLKEN;
> +
> + return val ? 1 : 0;
> +}
> +
> +static const struct clk_ops berlin_clk_ops = {
> + .recalc_rate= berlin_clk_recalc_rate,
> + .get_parent = berlin_clk_get_parent,
> + .enable = berlin_clk_enable,
> + .disable= berlin_clk_disable,
> + .is_enabled = berlin_clk_is_enabled,
> +};
> +
> +static struct clk * __init
> +berlin_clk_register(const char *name, int num_parents,
> + const char **parent_names, 

Re: [PATCH v2 1/6] clk: berlin: add common pll driver

[Sebastian Hesselbarth]

On 20.11.2015 09:42, Jisheng Zhang wrote:
> Add pll driver for Marvell SoCs newer than BG2, BG2CD, BG2Q.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/clk/berlin/Makefile |   1 +
>  drivers/clk/berlin/pll.c| 133 
> 
>  2 files changed, 134 insertions(+)
>  create mode 100644 drivers/clk/berlin/pll.c
> 
> diff --git a/drivers/clk/berlin/Makefile b/drivers/clk/berlin/Makefile
> index 2a36ab7..eee42b0 100644
> --- a/drivers/clk/berlin/Makefile
> +++ b/drivers/clk/berlin/Makefile
> @@ -1,4 +1,5 @@
>  obj-y += berlin2-avpll.o berlin2-pll.o berlin2-div.o
> +obj-y += pll.o

Jisheng,

please keep the naming style of files as we already have,
e.g. at least name the files for this driver berlin4-pll.

Even better you find the differences and merge it with
the berlin2-pll driver.

In general, I am not going to Ack any Berlin clock drivers
that expose the clock tree in any way. We recently merged
the Berlin2 clock stuff to a common OF node, I am not going
through the same mess for BG4 again.

>  obj-$(CONFIG_MACH_BERLIN_BG2)+= bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2CD)  += bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2Q)   += bg2q.o
> diff --git a/drivers/clk/berlin/pll.c b/drivers/clk/berlin/pll.c
> new file mode 100644
> index 000..435445e
> --- /dev/null
> +++ b/drivers/clk/berlin/pll.c
> @@ -0,0 +1,133 @@
> +/*
> + * Copyright (c) 2015 Marvell Technology Group Ltd.
> + *
> + * Author: Jisheng Zhang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PLL_CTRL00x0
> +#define PLL_CTRL10x4
> +#define PLL_CTRL20x8
> +#define PLL_CTRL30xC
> +#define PLL_CTRL40x10
> +#define PLL_STATUS   0x14
> +
> +#define PLL_SOURCE_MAX   2
> +
> +struct berlin_pll {
> + struct clk_hw   hw;
> + void __iomem*ctrl;
> + void __iomem*bypass;
> + u8  bypass_shift;
> +};
> +
> +#define to_berlin_pll(hw)   container_of(hw, struct berlin_pll, hw)
> +
> +static unsigned long berlin_pll_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + u32 val, fbdiv, rfdiv, vcodivsel, bypass;
> + struct berlin_pll *pll = to_berlin_pll(hw);
> +
> + bypass = readl_relaxed(pll->bypass);
> + if (bypass & (1 << pll->bypass_shift))
> + return parent_rate;

Bypass could be modelled as a ccf clock-mux:

REF ---+|\
   |_   | |-- OUT
   +---| PLL |--|/

Please reuse what is already available.

> + val = readl_relaxed(pll->ctrl + PLL_CTRL0);
> + fbdiv = (val >> 12) & 0x1FF;
> + rfdiv = (val >> 3) & 0x1FF;

Please get rid of any magic numbers.

> + val = readl_relaxed(pll->ctrl + PLL_CTRL1);
> + vcodivsel = (val >> 9) & 0x7;
> + return parent_rate * fbdiv * 4 / rfdiv /
> + (1 << vcodivsel);

A comment at the top of recalc_rate how output frequency is
calculated would be great.

> +}
> +
> +static u8 berlin_pll_get_parent(struct clk_hw *hw)
> +{
> + struct berlin_pll *pll = to_berlin_pll(hw);
> + u32 bypass = readl_relaxed(pll->bypass);
> +
> + return !!(bypass & (1 << pll->bypass_shift));
> +}
> +
> +static const struct clk_ops berlin_pll_ops = {
> + .recalc_rate= berlin_pll_recalc_rate,
> + .get_parent = berlin_pll_get_parent,
> +};
> +
> +static void __init berlin_pll_setup(struct device_node *np)
> +{
> + struct clk_init_data init;
> + struct berlin_pll *pll;
> + const char *parent_names[PLL_SOURCE_MAX];
> + struct clk *clk;
> + int ret, num_parents;
> + u8 bypass_shift;
> +
> + num_parents = of_clk_get_parent_count(np);
> + if (num_parents <= 0 || num_parents > PLL_SOURCE_MAX)
> + return;
> +
> + ret = of_property_read_u8(np, "bypass-shift", _shift);
> + if (ret)
> + return;

The name "bypass" implies you can either choose to output the PLL
generated clock or pass the parent clock, i.e. bypass the PLL.

How can you choose from two parents then?

> + of_clk_parent_fill(np, parent_names, num_parents);
> +
> + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> + if (!pll)
> + return;
> +
> + pll->ctrl = of_iomap(np, 0);
> + if (WARN_ON(!pll->ctrl))
> + goto err_iomap_ctrl;
> +
> + pll->bypass = 

Re: [PATCH RESEND 1/8] arm: dts: berlin2q: add watchdog nodes

[Sebastian Hesselbarth]

On 20.11.2015 04:34, Jisheng Zhang wrote:
> On Thu, 19 Nov 2015 21:47:05 +0100
> Sebastian Hesselbarth wrote:
>> On 16.11.2015 12:09, Jisheng Zhang wrote:
>>> The Marvell Berlin BG2Q has 3 watchdogs which are compatible with the
>>> snps,dw-wdt driver sit in the sysmgr domain. This patch adds the
>>> corresponding device tree nodes.
>>>
>>> Signed-off-by: Jisheng Zhang 
>>> ---
>>>  arch/arm/boot/dts/berlin2q.dtsi | 24 
>>>  1 file changed, 24 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/berlin2q.dtsi 
>>> b/arch/arm/boot/dts/berlin2q.dtsi
>>> index a3ecde5..fac4315 100644
>>> --- a/arch/arm/boot/dts/berlin2q.dtsi
>>> +++ b/arch/arm/boot/dts/berlin2q.dtsi
>>> @@ -483,6 +483,30 @@
>>> ranges = <0 0xfc 0x1>;
>>> interrupt-parent = <>;
>>>  
>>> +   wdt0: watchdog@1000 {
>>> +   compatible = "snps,dw-wdt";
>>> +   reg = <0x1000 0x100>;
>>> +   clocks = <>;
>>> +   interrupts = <0>;
>>> +   status = "disabled";  
>>
>> as the watchdogs are internal and cannot be clock gated
>> at all, how about we remove the status = "disabled" and
>> make them always available?
> 
> there are two issues here:
> 
> 1. the dw-wdt can't support multiple variants now. I have rewrite the driver
> with watchdog core supplied framework, but the patch isn't sent out and
> may be need time to clean up and review.

Ok.

> 2. not all dw-wdt devices are available and functional. This depends on
> board design and configuration.

I understand that "board design and configuration" may hinder the wdt
to issue a hard reset. But all others are able to issue a soft reset
or just an interrupt, right?

So, I still don't see why we should disable wdt nodes by default
except for the driver issue above.

> So IMHO status=disabled and patch5-8 is necessary, what do you think?

No. I'd agree to enable wdt0 by default and leave wdt[1,2] disabled
because of the driver issue. Patches 5-8 only enable wdt0 anyway.

As soon as the driver issue is resolved, we enable all wdt nodes
unconditionally.

Sebastian

>> I have applied patches 1-4 with the status property removed.
>> This also renders patches 5-8 useless.
>>
>> So, for now tentatively
>>
>> Appled to berlin/dt and berlin64/dt respectivly
>>
>> with status property removed.
>>
>> Sebastian
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] clk: si5351: Add PLL soft reset

[Sebastian Hesselbarth]

On 20.11.2015 18:22, Jacob Siverskog wrote:

This is according to figure 12 ("I2C Programming Procedure") in
"Si5351A/B/C Data Sheet"
(https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351-B.pdf).

Without the PLL soft reset, we were unable to get three outputs
working at the same time.

According to Silicon Labs support, performing PLL soft reset will only
be noticeable if the PLL parameters have been changed.

Signed-off-by: Jacob Siverskog 
Signed-off-by: Jens Rudberg 
---
  drivers/clk/clk-si5351.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index e346b22..984c058 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -1091,6 +1091,12 @@ static int si5351_clkout_set_rate(struct clk_hw *hw, 
unsigned long rate,
si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
SI5351_CLK_POWERDOWN, 0);

+   /* do a pll soft reset on both plls, needed in some cases to get all
+* outputs running
+*/


Common convention for multi-line comments usually is:

/*
 * Do a PLL soft reset on both PLLs required to get
 * all outputs running.
 */

After you fixed the style issue, you can add my

Acked-by: Sebastian Hesselbarth 

Thanks!


+   si5351_reg_write(hwdata->drvdata, SI5351_PLL_RESET,
+SI5351_PLL_RESET_A | SI5351_PLL_RESET_B);
+
dev_dbg(>drvdata->client->dev,
"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
__func__, clk_hw_get_name(hw), (1 << rdiv),



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] clk: si5351: Add PLL soft reset

[Sebastian Hesselbarth]

On 20.11.2015 18:22, Jacob Siverskog wrote:

This is according to figure 12 ("I2C Programming Procedure") in
"Si5351A/B/C Data Sheet"
(https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351-B.pdf).

Without the PLL soft reset, we were unable to get three outputs
working at the same time.

According to Silicon Labs support, performing PLL soft reset will only
be noticeable if the PLL parameters have been changed.

Signed-off-by: Jacob Siverskog <jacob@teenage.engineering>
Signed-off-by: Jens Rudberg <jens@teenage.engineering>
---
  drivers/clk/clk-si5351.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index e346b22..984c058 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -1091,6 +1091,12 @@ static int si5351_clkout_set_rate(struct clk_hw *hw, 
unsigned long rate,
si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
SI5351_CLK_POWERDOWN, 0);

+   /* do a pll soft reset on both plls, needed in some cases to get all
+* outputs running
+*/


Common convention for multi-line comments usually is:

/*
 * Do a PLL soft reset on both PLLs required to get
 * all outputs running.
 */

After you fixed the style issue, you can add my

Acked-by: Sebastian Hesselbarth <sebastian.hesselba...@gmail.com>

Thanks!


+   si5351_reg_write(hwdata->drvdata, SI5351_PLL_RESET,
+SI5351_PLL_RESET_A | SI5351_PLL_RESET_B);
+
dev_dbg(>drvdata->client->dev,
"%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
__func__, clk_hw_get_name(hw), (1 << rdiv),



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/6] clk: berlin: add common pll driver

[Sebastian Hesselbarth]

On 20.11.2015 09:42, Jisheng Zhang wrote:
> Add pll driver for Marvell SoCs newer than BG2, BG2CD, BG2Q.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/clk/berlin/Makefile |   1 +
>  drivers/clk/berlin/pll.c| 133 
> 
>  2 files changed, 134 insertions(+)
>  create mode 100644 drivers/clk/berlin/pll.c
> 
> diff --git a/drivers/clk/berlin/Makefile b/drivers/clk/berlin/Makefile
> index 2a36ab7..eee42b0 100644
> --- a/drivers/clk/berlin/Makefile
> +++ b/drivers/clk/berlin/Makefile
> @@ -1,4 +1,5 @@
>  obj-y += berlin2-avpll.o berlin2-pll.o berlin2-div.o
> +obj-y += pll.o

Jisheng,

please keep the naming style of files as we already have,
e.g. at least name the files for this driver berlin4-pll.

Even better you find the differences and merge it with
the berlin2-pll driver.

In general, I am not going to Ack any Berlin clock drivers
that expose the clock tree in any way. We recently merged
the Berlin2 clock stuff to a common OF node, I am not going
through the same mess for BG4 again.

>  obj-$(CONFIG_MACH_BERLIN_BG2)+= bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2CD)  += bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2Q)   += bg2q.o
> diff --git a/drivers/clk/berlin/pll.c b/drivers/clk/berlin/pll.c
> new file mode 100644
> index 000..435445e
> --- /dev/null
> +++ b/drivers/clk/berlin/pll.c
> @@ -0,0 +1,133 @@
> +/*
> + * Copyright (c) 2015 Marvell Technology Group Ltd.
> + *
> + * Author: Jisheng Zhang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PLL_CTRL00x0
> +#define PLL_CTRL10x4
> +#define PLL_CTRL20x8
> +#define PLL_CTRL30xC
> +#define PLL_CTRL40x10
> +#define PLL_STATUS   0x14
> +
> +#define PLL_SOURCE_MAX   2
> +
> +struct berlin_pll {
> + struct clk_hw   hw;
> + void __iomem*ctrl;
> + void __iomem*bypass;
> + u8  bypass_shift;
> +};
> +
> +#define to_berlin_pll(hw)   container_of(hw, struct berlin_pll, hw)
> +
> +static unsigned long berlin_pll_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + u32 val, fbdiv, rfdiv, vcodivsel, bypass;
> + struct berlin_pll *pll = to_berlin_pll(hw);
> +
> + bypass = readl_relaxed(pll->bypass);
> + if (bypass & (1 << pll->bypass_shift))
> + return parent_rate;

Bypass could be modelled as a ccf clock-mux:

REF ---+|\
   |_   | |-- OUT
   +---| PLL |--|/

Please reuse what is already available.

> + val = readl_relaxed(pll->ctrl + PLL_CTRL0);
> + fbdiv = (val >> 12) & 0x1FF;
> + rfdiv = (val >> 3) & 0x1FF;

Please get rid of any magic numbers.

> + val = readl_relaxed(pll->ctrl + PLL_CTRL1);
> + vcodivsel = (val >> 9) & 0x7;
> + return parent_rate * fbdiv * 4 / rfdiv /
> + (1 << vcodivsel);

A comment at the top of recalc_rate how output frequency is
calculated would be great.

> +}
> +
> +static u8 berlin_pll_get_parent(struct clk_hw *hw)
> +{
> + struct berlin_pll *pll = to_berlin_pll(hw);
> + u32 bypass = readl_relaxed(pll->bypass);
> +
> + return !!(bypass & (1 << pll->bypass_shift));
> +}
> +
> +static const struct clk_ops berlin_pll_ops = {
> + .recalc_rate= berlin_pll_recalc_rate,
> + .get_parent = berlin_pll_get_parent,
> +};
> +
> +static void __init berlin_pll_setup(struct device_node *np)
> +{
> + struct clk_init_data init;
> + struct berlin_pll *pll;
> + const char *parent_names[PLL_SOURCE_MAX];
> + struct clk *clk;
> + int ret, num_parents;
> + u8 bypass_shift;
> +
> + num_parents = of_clk_get_parent_count(np);
> + if (num_parents <= 0 || num_parents > PLL_SOURCE_MAX)
> + return;
> +
> + ret = of_property_read_u8(np, "bypass-shift", _shift);
> + if (ret)
> + return;

The name "bypass" implies you can either choose to output the PLL
generated clock or pass the parent clock, i.e. bypass the PLL.

How can you choose from two parents then?

> + of_clk_parent_fill(np, parent_names, num_parents);
> +
> + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> + if (!pll)
> + return;
> +
> + pll->ctrl = of_iomap(np, 0);
> + if (WARN_ON(!pll->ctrl))
> + goto 

Re: [PATCH RESEND 1/8] arm: dts: berlin2q: add watchdog nodes

[Sebastian Hesselbarth]

On 20.11.2015 04:34, Jisheng Zhang wrote:
> On Thu, 19 Nov 2015 21:47:05 +0100
> Sebastian Hesselbarth wrote:
>> On 16.11.2015 12:09, Jisheng Zhang wrote:
>>> The Marvell Berlin BG2Q has 3 watchdogs which are compatible with the
>>> snps,dw-wdt driver sit in the sysmgr domain. This patch adds the
>>> corresponding device tree nodes.
>>>
>>> Signed-off-by: Jisheng Zhang <jszh...@marvell.com>
>>> ---
>>>  arch/arm/boot/dts/berlin2q.dtsi | 24 
>>>  1 file changed, 24 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/berlin2q.dtsi 
>>> b/arch/arm/boot/dts/berlin2q.dtsi
>>> index a3ecde5..fac4315 100644
>>> --- a/arch/arm/boot/dts/berlin2q.dtsi
>>> +++ b/arch/arm/boot/dts/berlin2q.dtsi
>>> @@ -483,6 +483,30 @@
>>> ranges = <0 0xfc 0x1>;
>>> interrupt-parent = <>;
>>>  
>>> +   wdt0: watchdog@1000 {
>>> +   compatible = "snps,dw-wdt";
>>> +   reg = <0x1000 0x100>;
>>> +   clocks = <>;
>>> +   interrupts = <0>;
>>> +   status = "disabled";  
>>
>> as the watchdogs are internal and cannot be clock gated
>> at all, how about we remove the status = "disabled" and
>> make them always available?
> 
> there are two issues here:
> 
> 1. the dw-wdt can't support multiple variants now. I have rewrite the driver
> with watchdog core supplied framework, but the patch isn't sent out and
> may be need time to clean up and review.

Ok.

> 2. not all dw-wdt devices are available and functional. This depends on
> board design and configuration.

I understand that "board design and configuration" may hinder the wdt
to issue a hard reset. But all others are able to issue a soft reset
or just an interrupt, right?

So, I still don't see why we should disable wdt nodes by default
except for the driver issue above.

> So IMHO status=disabled and patch5-8 is necessary, what do you think?

No. I'd agree to enable wdt0 by default and leave wdt[1,2] disabled
because of the driver issue. Patches 5-8 only enable wdt0 anyway.

As soon as the driver issue is resolved, we enable all wdt nodes
unconditionally.

Sebastian

>> I have applied patches 1-4 with the status property removed.
>> This also renders patches 5-8 useless.
>>
>> So, for now tentatively
>>
>> Appled to berlin/dt and berlin64/dt respectivly
>>
>> with status property removed.
>>
>> Sebastian
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/6] clk: berlin: add common clk driver for newer SoCs

[Sebastian Hesselbarth]

On 20.11.2015 09:42, Jisheng Zhang wrote:
> Add common clk driver for Marvell SoCs newer than BG2, BG2CD, BG2Q.
> berlin_clk_setup() is provided to setup and register such kind of clks.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/clk/berlin/Makefile |   2 +-
>  drivers/clk/berlin/clk.c| 203 
> 
>  drivers/clk/berlin/clk.h|  33 +++
>  3 files changed, 237 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/berlin/clk.c
>  create mode 100644 drivers/clk/berlin/clk.h
> 
> diff --git a/drivers/clk/berlin/Makefile b/drivers/clk/berlin/Makefile
> index eee42b0..ee2e09d 100644
> --- a/drivers/clk/berlin/Makefile
> +++ b/drivers/clk/berlin/Makefile
> @@ -1,5 +1,5 @@
>  obj-y += berlin2-avpll.o berlin2-pll.o berlin2-div.o
> -obj-y += pll.o
> +obj-y += pll.o clk.o

Same comment about the naming convention.

>  obj-$(CONFIG_MACH_BERLIN_BG2)+= bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2CD)  += bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2Q)   += bg2q.o
> diff --git a/drivers/clk/berlin/clk.c b/drivers/clk/berlin/clk.c
> new file mode 100644
> index 000..70f2b9d
> --- /dev/null
> +++ b/drivers/clk/berlin/clk.c
> @@ -0,0 +1,203 @@
> +/*
> + * Copyright (c) 2015 Marvell Technology Group Ltd.
> + *
> + * Author: Jisheng Zhang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "clk.h"
> +
> +#define CLKEN(1 << 0)

#define CLKEN   BIT(0)

> +#define CLKPLLSEL_MASK   7

Please use hex numbers for the mask.

> +#define CLKPLLSEL_SHIFT  1
> +#define CLKPLLSWITCH (1 << 4)
> +#define CLKSWITCH(1 << 5)
> +#define CLKD3SWITCH  (1 << 6)

BIT() again.

> +#define CLKSEL_MASK  7

Hex again.

> +#define CLKSEL_SHIFT 7
> +
> +#define CLK_SOURCE_MAX   5
> +
> +struct berlin_clk {
> + struct clk_hw hw;
> + void __iomem *base;
> +};
> +
> +#define to_berlin_clk(hw)container_of(hw, struct berlin_clk, hw)
> +
> +static u8 clk_div[] = {1, 2, 4, 6, 8, 12, 1, 1};

Hmm, this pretty much looks like berlin2-div dividers...

> +static unsigned long berlin_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + u32 val, divider;
> + struct berlin_clk *clk = to_berlin_clk(hw);
> +
> + val = readl_relaxed(clk->base);
> + if (val & CLKD3SWITCH)
> + divider = 3;

and this looks like berlin2-div structure, doesn't it?

Again, please reuse what is already available.

Sebastian

> + else {
> + if (val & CLKSWITCH) {
> + val >>= CLKSEL_SHIFT;
> + val &= CLKSEL_MASK;
> + divider = clk_div[val];
> + } else
> + divider = 1;
> + }
> +
> + return parent_rate / divider;
> +}
> +
> +static u8 berlin_clk_get_parent(struct clk_hw *hw)
> +{
> + u32 val;
> + struct berlin_clk *clk = to_berlin_clk(hw);
> +
> + val = readl_relaxed(clk->base);
> + if (val & CLKPLLSWITCH) {
> + val >>= CLKPLLSEL_SHIFT;
> + val &= CLKPLLSEL_MASK;
> + return val;
> + }
> +
> + return 0;
> +}
> +
> +static int berlin_clk_enable(struct clk_hw *hw)
> +{
> + u32 val;
> + struct berlin_clk *clk = to_berlin_clk(hw);
> +
> + val = readl_relaxed(clk->base);
> + val |= CLKEN;
> + writel_relaxed(val, clk->base);
> +
> + return 0;
> +}
> +
> +static void berlin_clk_disable(struct clk_hw *hw)
> +{
> + u32 val;
> + struct berlin_clk *clk = to_berlin_clk(hw);
> +
> + val = readl_relaxed(clk->base);
> + val &= ~CLKEN;
> + writel_relaxed(val, clk->base);
> +}
> +
> +static int berlin_clk_is_enabled(struct clk_hw *hw)
> +{
> + u32 val;
> + struct berlin_clk *clk = to_berlin_clk(hw);
> +
> + val = readl_relaxed(clk->base);
> + val &= CLKEN;
> +
> + return val ? 1 : 0;
> +}
> +
> +static const struct clk_ops berlin_clk_ops = {
> + .recalc_rate= berlin_clk_recalc_rate,
> + .get_parent = berlin_clk_get_parent,
> + .enable = berlin_clk_enable,
> + .disable= berlin_clk_disable,
> + .is_enabled = berlin_clk_is_enabled,
> +};
> +
> +static struct clk * __init
> +berlin_clk_register(const char *name, int num_parents,
> +   

Re: [PATCH v2 4/6] clk: berlin: add clk support for berlin4ct

[Sebastian Hesselbarth]

On 20.11.2015 09:42, Jisheng Zhang wrote:
> This patch supports the gateclk and berlin-clk in berlin4ct SoC.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/clk/berlin/Makefile|  2 +-
>  drivers/clk/berlin/clk-berlin4ct.c | 97 
> ++
>  2 files changed, 98 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/berlin/clk-berlin4ct.c
> 
> diff --git a/drivers/clk/berlin/Makefile b/drivers/clk/berlin/Makefile
> index fc92151..accfc3a 100644
> --- a/drivers/clk/berlin/Makefile
> +++ b/drivers/clk/berlin/Makefile
> @@ -1,5 +1,5 @@
>  obj-y += berlin2-avpll.o berlin2-pll.o berlin2-div.o
> -obj-y += pll.o clk.o gate.o
> +obj-y += pll.o clk.o gate.o clk-berlin4ct.o

This will always compile clk-berlin4ct unconditionally on bg2x too.

Also, keep the naming style.

Sebastian

>  obj-$(CONFIG_MACH_BERLIN_BG2)+= bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2CD)  += bg2.o
>  obj-$(CONFIG_MACH_BERLIN_BG2Q)   += bg2q.o
> diff --git a/drivers/clk/berlin/clk-berlin4ct.c 
> b/drivers/clk/berlin/clk-berlin4ct.c
> new file mode 100644
> index 000..0d994a4
> --- /dev/null
> +++ b/drivers/clk/berlin/clk-berlin4ct.c
> @@ -0,0 +1,97 @@
> +/*
> + * Copyright (c) 2015 Marvell Technology Group Ltd.
> + *
> + * Author: Jisheng Zhang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +
> +#include "clk.h"
> +
> +static struct clk_onecell_data gateclk_data;
> +static struct clk_onecell_data clk_data;
> +
> +static const struct gateclk_desc berlin4ct_gates[] __initconst = {
> + { "tspsysclk",  "perifsysclk",  0 },
> + { "usb0coreclk","perifsysclk",  1 },
> + { "zspsysclk",  "perifsysclk",  2 },
> + { "sdiosysclk", "perifsysclk",  3 },
> + { "ethcoreclk", "perifsysclk",  4 },
> + { "pcie0sys",   "perifsysclk",  6 },
> + { "sata0core",  "perifsysclk",  7 },
> + { "nfcsysclk",  "perifsysclk",  8 },
> + { "emmcsysclk", "perifsysclk",  9 },
> + { "ihb0sysclk", "perifsysclk",  10 },
> +};
> +
> +static void __init berlin4ct_gateclk_setup(struct device_node *np)
> +{
> + int n = ARRAY_SIZE(berlin4ct_gates);
> +
> + berlin_gateclk_setup(np, berlin4ct_gates, _data, n);
> +}
> +CLK_OF_DECLARE(berlin4ct_gateclk, "marvell,berlin4ct-gateclk",
> +berlin4ct_gateclk_setup);
> +
> +static const struct clk_desc berlin4ct_descs[] __initconst = {
> + { "cpufastrefclk",  0x0 },
> + { "memfastrefclk",  0x4 },
> + { "cfgclk", 0x20,   CLK_IGNORE_UNUSED },
> + { "perifsysclk",0x24,   CLK_IGNORE_UNUSED },
> + { "hbclk",  0x28 },
> + { "atbclk", 0x2c },
> + { "decoderclk", 0x40 },
> + { "decoderm3clk",   0x44 },
> + { "decoderpcubeclk",0x48 },
> + { "encoderclk", 0x4c },
> + { "ovpcoreclk", 0x50 },
> + { "gfx2dcoreclk",   0x60 },
> + { "gfx3dcoreclk",   0x64 },
> + { "gfx3dshclk", 0x68 },
> + { "gfx3dsysclk",0x6c },
> + { "gfx2dsysclk",0x70 },
> + { "aviosysclk", 0x80 },
> + { "vppsysclk",  0x84 },
> + { "eddcclk",0x88 },
> + { "aviobiuclk", 0x8c },
> + { "zspclk", 0xa0 },
> + { "tspclk", 0xc0 },
> + { "tsprefclk",  0xc4 },
> + { "ndsclk", 0xc8 },
> + { "nocsclk",0xcc },
> + { "apbcoreclk", 0xd0,   CLK_IGNORE_UNUSED },
> + { "emmcclk",0xe0 },
> + { "sd0clk", 0xe4 },
> + { "sd1clk", 0xe8 },
> + { "dllmstrefclk",   0xec },
> + { "gethrgmiiclk",   0xf0 },
> + { "gethrgmiisysclk",0xf4 },
> + { "usim0clk",   0x100 },
> + { "pcietestclk",0x110 },
> + { "usb2testclk",0x120 },
> + { "usb3testclk",0x124 },
> + { "usb3coreclk",0x128 },
> + { "nfceccclk",  0x130 },
> + { "bcmclk", 0x140 },
> +};
> +
> +static void __init berlin4ct_clk_setup(struct device_node *np)
> +{
> + int n = ARRAY_SIZE(berlin4ct_descs);
> +
> + berlin_clk_setup(np, berlin4ct_descs, _data, n);
> +}
> +CLK_OF_DECLARE(berlin4ct_clk, "marvell,berlin4ct-clk",
> +

Re: [PATCH v2 6/6] arm64: dts: berlin4ct: add pll and clock nodes

[Sebastian Hesselbarth]

On 20.11.2015 09:42, Jisheng Zhang wrote:
> Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 38 
> ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index a4a1876..808a997 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -42,6 +42,7 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
> +#include 
>  #include 
>  
>  / {
> @@ -135,6 +136,22 @@
>   interrupts =  IRQ_TYPE_LEVEL_HIGH)>;
>   };
>  
> + cpupll: cpupll {
> + compatible = "marvell,berlin-pll";
> + reg = <0x922000 0x14>, <0xea0710 4>;
> + #clock-cells = <0>;
> + clocks = <>, < CLK_CPUFASTREF>;
> + bypass-shift = /bits/ 8 <2>;
> + };
> +
> + mempll: mempll {
> + compatible = "marvell,berlin-pll";
> + reg = <0x940034 0x14>, <0xea0710 4>;

Whenever you see overlapping/repeating reg ranges, e.g. <0xea0710 4>
you can be sure you are not representing HW structure but driver
structure here.

Please merge clocks/gates/plls to a single clock complex node
and deal with the internals by using "simple-mfd" and "syscon" regmaps.

> + #clock-cells = <0>;
> + clocks = <>, < CLK_MEMFASTREF>;
> + bypass-shift = /bits/ 8 <1>;
> + };
> +
>   apb@e8 {
>   compatible = "simple-bus";
>   #address-cells = <1>;
> @@ -225,6 +242,27 @@
>   };
>   };
>  
> + syspll: syspll {
> + compatible = "marvell,berlin-pll";
> + reg = <0xea0200 0x14>, <0xea0710 4>;
> + #clock-cells = <0>;
> + clocks = <>;
> + bypass-shift = /bits/ 8 <0>;
> + };
> +
> + gateclk: gateclk {
> + compatible = "marvell,berlin4ct-gateclk";
> + reg = <0xea0700 4>;
> + #clock-cells = <1>;
> + };
> +
> + clk: clk {
> + compatible = "marvell,berlin4ct-clk";
> + reg = <0xea0720 0x144>;

Looking at the reg ranges, I'd say that they are all clock related
and pretty close to each other:

gateclk: reg = <0xea0700 4>;
bypass:  reg = <0xea0710 4>;
clk: reg = <0xea0720 0x144>;

So, please just follow the OF/driver structure we already
have for Berlin2.

Sebastian

> + #clock-cells = <1>;
> + clocks = <>;
> + };
> +
>   soc_pinctrl: pin-controller@ea8000 {
>   compatible = "marvell,berlin4ct-soc-pinctrl";
>   reg = <0xea8000 0x14>;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm64: dts: berlin4ct: enable all i2c nodes for the STB board

[Sebastian Hesselbarth]

On 20.11.2015 10:47, Jisheng Zhang wrote:
> Enable all i2c nodes for the Marvell berlin BG4CT STB board.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  arch/arm64/boot/dts/marvell/berlin4ct-stb.dts | 50 
> +++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts 
> b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> index 348c37e..9e8e2e0 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> @@ -61,6 +61,56 @@
>   };
>  };
>  
> +_pinctrl {
> + twsi1_pmux: twsi1-pmux {
> + groups = "TX_EDDC_SCL", "TX_EDDC_SDA";
> + function = "tx_eddc";
> + };

Please keep the pinmux sub-nodes in the SoC dtsi as long
as they are not strictly board specific, i.e. gpios.

> +};
> +
> + {
> + status = "okay";
> + pinctrl-0 = <_pmux>;
> + pinctrl-names = "default";

If there is only one (or a default) pinctrl-0 option for i2c0,
you can also move it to the SoC dtsi.

> +};
> +
> + {
> + status = "okay";
> + pinctrl-0 = <_pmux>;
> + pinctrl-names = "default";

ditto.

> +};
> +
> + {
> + status = "okay";
> + pinctrl-0 = <_pmux>;
> + pinctrl-names = "default";

ditto.

> +};
> +
> + {
> + status = "okay";
> + pinctrl-0 = <_pmux>;
> + pinctrl-names = "default";

ditto.

> +};
> +
> +_pinctrl {
> + twsi0_pmux: twsi0-pmux {
> + groups = "TW0_SCL", "TW0_SDA";
> + function = "tw0";
> + };

Same comment about moving pinmux nodes to SoC dtsi.

> +};
> +
> +_pinctrl {
> + twsi2_pmux: twsi2-pmux {
> + groups = "SM_TW2_SCL", "SM_TW2_SDA";
> + function = "tw2";
> + };
> +
> + twsi3_pmux: twsi3-pmux {
> + groups = "SM_TW3_SCL", "SM_TW3_SDA";
> + function = "tw3";
> + };

ditto.

Sebastian

> +};
> +
>   {
>   status = "okay";
>  };
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] arm64: dts: berlin4ct: add I2C nodes for BG4CT

[Sebastian Hesselbarth]

On 20.11.2015 10:47, Jisheng Zhang wrote:
> The Marvell Berlin BG4CT SoC has 4 TWSI which are compatible with the
> Synopsys DesignWare I2C driver. Add the corresponding nodes.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 52 
> ++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index cca4c41..39d0676 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -232,6 +232,32 @@
>   };
>   };
>  
> + i2c0: i2c@1400 {
> + compatible = "snps,designware-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x1400 0x100>;
> + clocks = < CLK_APBCORE>;

This patch looks fine to me, except that clock node naming and
clock indices may change. We should really postpone this series
until we worked out clock.

Sebastian

> + i2c-sda-hold-time-ns = <35>;
> + i2c-sda-falling-time-ns = <425>;
> + i2c-scl-falling-time-ns = <205>;
> + interrupts = <4>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@1800 {
> + compatible = "snps,designware-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x1800 0x100>;
> + clocks = < CLK_APBCORE>;
> + i2c-sda-hold-time-ns = <35>;
> + i2c-sda-falling-time-ns = <425>;
> + i2c-scl-falling-time-ns = <205>;
> + interrupts = <5>;
> + status = "disabled";
> + };
> +
>   aic: interrupt-controller@3800 {
>   compatible = "snps,dw-apb-ictl";
>   reg = <0x3800 0x30>;
> @@ -319,6 +345,32 @@
>   };
>   };
>  
> + i2c2: i2c@b000 {
> + compatible = "snps,designware-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0xb000 0x100>;
> + clocks = <>;
> + i2c-sda-hold-time-ns = <140>;
> + i2c-sda-falling-time-ns = <500>;
> + i2c-scl-falling-time-ns = <220>;
> + interrupts = <6>;
> + status = "disabled";
> + };
> +
> + i2c3: i2c@c000 {
> + compatible = "snps,designware-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0xc000 0x100>;
> + clocks = <>;
> + i2c-sda-hold-time-ns = <140>;
> + i2c-sda-falling-time-ns = <500>;
> + i2c-scl-falling-time-ns = <220>;
> + interrupts = <7>;
> + status = "disabled";
> + };
> +
>   uart0: uart@d000 {
>   compatible = "snps,dw-apb-uart";
>   reg = <0xd000 0x100>;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: si5351: Add setup steps

[Sebastian Hesselbarth]

On 19.11.2015 14:40, Jacob Siverskog wrote:
> This is according to figure 12 ("I2C Programming Procedure") in
> "Si5351A/B/C Data Sheet"
> (https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351-B.pdf).
> 
> Without the PLL soft reset, we were unable to get three outputs
> working at the same time.
> 
> According to Silicon Labs support, performing PLL soft reset will only
> be noticable if the PLL parameters have been changed.
> 
> Signed-off-by: Jacob Siverskog 
> Signed-off-by: Jens Rudberg 
> ---
>  drivers/clk/clk-si5351.c | 13 +
>  1 file changed, 13 insertions(+)

Jacob,

thanks for the patches! However, besides Mareks comments I have
some more below.

> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> index e346b22..110de35 100644
> --- a/drivers/clk/clk-si5351.c
> +++ b/drivers/clk/clk-si5351.c
> @@ -1091,6 +1091,11 @@ static int si5351_clkout_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>   si5351_set_bits(hwdata->drvdata, SI5351_CLK0_CTRL + hwdata->num,
>   SI5351_CLK_POWERDOWN, 0);
>  
> + /* do a pll soft reset on both plls, needed in some cases to get all
> +  * outputs running */
> + si5351_reg_write(hwdata->drvdata, SI5351_PLL_RESET,
> +  SI5351_PLL_RESET_A | SI5351_PLL_RESET_B);
> +
>   dev_dbg(>drvdata->client->dev,
>   "%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n",
>   __func__, clk_hw_get_name(hw), (1 << rdiv),
> @@ -1359,6 +1364,14 @@ static int si5351_i2c_probe(struct i2c_client *client,
>   return PTR_ERR(drvdata->regmap);
>   }
>  
> + /* Disable outputs */
> + si5351_reg_write(drvdata, SI5351_OUTPUT_ENABLE_CTRL, 0xff);
> +
> + /* Power down all output drivers */
> + for (n = 0; n < 8; n++) {
> + si5351_reg_write(drvdata, SI5351_CLK0_CTRL + n, 0x80);
> + }

Is disabling outputs and clock drivers required?

If we disable the clocks here unconditionally, it will
break those systems that require specific outputs to be always
enabled. Consider one clock output driving your SoC or similar.

If it is really required, you'll have to mention that in the
patch description and we need to find a way to tag specific
outputs to be never disabled.

Sebastian

>   /* Disable interrupts */
>   si5351_reg_write(drvdata, SI5351_INTERRUPT_MASK, 0xf0);
>   /* Ensure pll select is on XTAL for Si5351A/B */
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm64: dts: berlin: PSCI-1.0 support

[Sebastian Hesselbarth]

On 16.11.2015 12:37, Jisheng Zhang wrote:
> The firmware can support PSCI-1.0 in fact. This change also enables
> suspend to ram on Marvell berlin arm64 SoC.
> 
> Signed-off-by: Jisheng Zhang 

Appled to berlin64/dt.

Thanks!

> ---
>  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index 8eddf10..a87f1a2 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -55,7 +55,7 @@
>   };
>  
>   psci {
> - compatible = "arm,psci-0.2";
> + compatible = "arm,psci-1.0", "arm,psci-0.2";
>   method = "smc";
>   };
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/7] phy: berlin-sata: add missing of_node_put

[Sebastian Hesselbarth]

On 16.11.2015 12:33, Julia Lawall wrote:
> for_each_available_child_of_node performs an of_node_get on each iteration,
> so a return from the middle of the loop requires an of_node_put.
> 
> A simplified version of the semantic patch that finds this problem is as
> follows (http://coccinelle.lip6.fr):
> 
> // 
> @@
> expression root,e;
> local idexpression child;
> @@
> 
>  for_each_available_child_of_node(root, child) {
>... when != of_node_put(child)
>when != e = child
> (
>return child;
> |
> *  return ...;
> )
>    ...
>  }
> // 
> 
> Signed-off-by: Julia Lawall 

Acked-by: Sebastian Hesselbarth 

Thanks!

> ---
>  drivers/phy/phy-berlin-sata.c |   20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/phy/phy-berlin-sata.c b/drivers/phy/phy-berlin-sata.c
> index 77a2e05..f84a33a 100644
> --- a/drivers/phy/phy-berlin-sata.c
> +++ b/drivers/phy/phy-berlin-sata.c
> @@ -195,7 +195,7 @@ static int phy_berlin_sata_probe(struct platform_device 
> *pdev)
>   struct phy_provider *phy_provider;
>   struct phy_berlin_priv *priv;
>   struct resource *res;
> - int i = 0;
> + int ret, i = 0;
>   u32 phy_id;
>  
>   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> @@ -237,22 +237,27 @@ static int phy_berlin_sata_probe(struct platform_device 
> *pdev)
>   if (of_property_read_u32(child, "reg", _id)) {
>   dev_err(dev, "missing reg property in node %s\n",
>   child->name);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto put_child;
>   }
>  
>   if (phy_id >= ARRAY_SIZE(phy_berlin_power_down_bits)) {
>   dev_err(dev, "invalid reg in node %s\n", child->name);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto put_child;
>   }
>  
>   phy_desc = devm_kzalloc(dev, sizeof(*phy_desc), GFP_KERNEL);
> - if (!phy_desc)
> - return -ENOMEM;
> + if (!phy_desc) {
> + ret = -ENOMEM;
> + goto put_child;
> + }
>  
>   phy = devm_phy_create(dev, NULL, _berlin_sata_ops);
>   if (IS_ERR(phy)) {
>   dev_err(dev, "failed to create PHY %d\n", phy_id);
> - return PTR_ERR(phy);
> + ret = PTR_ERR(phy);
> + goto put_child;
>   }
>  
>   phy_desc->phy = phy;
> @@ -269,6 +274,9 @@ static int phy_berlin_sata_probe(struct platform_device 
> *pdev)
>   phy_provider =
>   devm_of_phy_provider_register(dev, phy_berlin_sata_phy_xlate);
>   return PTR_ERR_OR_ZERO(phy_provider);
> +put_child:
> + of_node_put(child);
> + return ret;
>  }
>  
>  static const struct of_device_id phy_berlin_sata_of_match[] = {
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND 1/8] arm: dts: berlin2q: add watchdog nodes

[Sebastian Hesselbarth]

On 16.11.2015 12:09, Jisheng Zhang wrote:
> The Marvell Berlin BG2Q has 3 watchdogs which are compatible with the
> snps,dw-wdt driver sit in the sysmgr domain. This patch adds the
> corresponding device tree nodes.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  arch/arm/boot/dts/berlin2q.dtsi | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
> index a3ecde5..fac4315 100644
> --- a/arch/arm/boot/dts/berlin2q.dtsi
> +++ b/arch/arm/boot/dts/berlin2q.dtsi
> @@ -483,6 +483,30 @@
>   ranges = <0 0xfc 0x1>;
>   interrupt-parent = <>;
>  
> + wdt0: watchdog@1000 {
> + compatible = "snps,dw-wdt";
> + reg = <0x1000 0x100>;
> + clocks = <>;
> + interrupts = <0>;
> + status = "disabled";

Jisheng,

as the watchdogs are internal and cannot be clock gated
at all, how about we remove the status = "disabled" and
make them always available?

I have applied patches 1-4 with the status property removed.
This also renders patches 5-8 useless.

So, for now tentatively

Appled to berlin/dt and berlin64/dt respectivly

with status property removed.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 PART-RESEND 0/2] berlin sdhci clock clean up

[Sebastian Hesselbarth]

On 16.11.2015 11:56, Jisheng Zhang wrote:
> Add or fix the optional clock property, then remove the CLK_IGNORE_UNUSED
> flag for sdio clk(s).
> 
> This is a partialy resend of 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/379457.html
> 
> patch3, patch4 has been merged.

Great! Really!

As they have been taken without my Acked-by, ignoring my request to
_not_ remove the CLK_IGNORE_UNUSED flags _before_ these two, the
remaining patches now become fixes.

Please resend the patches with a proper description what and why they
are fixes now.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] arm: dts: berlin2q: remove duplicated interrupt-parent

[Sebastian Hesselbarth]

On 16.11.2015 11:46, Jisheng Zhang wrote:
> The default interrupt-parent has been set in the upper layer, apb@e8
> and apb@fc for example. So if the interrupt-parent isn't changed, we
> don't need to set it again. This patch removes the dumplicated
> interrupt-parent settings.
> 
> Signed-off-by: Jisheng Zhang 

Applied to berlin64/dt.

Thanks!

> ---
>  arch/arm/boot/dts/berlin2q.dtsi | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
> index 8ea177f..155430a 100644
> --- a/arch/arm/boot/dts/berlin2q.dtsi
> +++ b/arch/arm/boot/dts/berlin2q.dtsi
> @@ -309,7 +309,6 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x1400 0x100>;
> - interrupt-parent = <>;
>   interrupts = <4>;
>   clocks = <_clk CLKID_CFG>;
>   pinctrl-0 = <_pmux>;
> @@ -322,7 +321,6 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x1800 0x100>;
> - interrupt-parent = <>;
>   interrupts = <5>;
>   clocks = <_clk CLKID_CFG>;
>   pinctrl-0 = <_pmux>;
> @@ -528,7 +526,6 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x7000 0x100>;
> - interrupt-parent = <>;
>   interrupts = <6>;
>   clocks = <>;
>   pinctrl-0 = <_pmux>;
> @@ -541,7 +538,6 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x8000 0x100>;
> - interrupt-parent = <>;
>   interrupts = <7>;
>   clocks = <>;
>   pinctrl-0 = <_pmux>;
> @@ -552,7 +548,6 @@
>   uart0: uart@9000 {
>   compatible = "snps,dw-apb-uart";
>   reg = <0x9000 0x100>;
> - interrupt-parent = <>;
>   interrupts = <8>;
>   clocks = <>;
>   reg-shift = <2>;
> @@ -564,7 +559,6 @@
>   uart1: uart@a000 {
>   compatible = "snps,dw-apb-uart";
>   reg = <0xa000 0x100>;
> - interrupt-parent = <>;
>   interrupts = <9>;
>   clocks = <>;
>   reg-shift = <2>;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] arm: dts: berlin2q-marvell-dmp: remove broken-cd from eMMC node

[Sebastian Hesselbarth]

On 16.11.2015 11:43, Jisheng Zhang wrote:
> The eMMC is non-removable so is marked with the non-removable DT
> property to avoid having to redetect it after a suspend/resume.
> 
> But it also has the broken-cd property which is wrong since only
> one of the DT properties for card detection should be used
> 
> Signed-off-by: Jisheng Zhang 

Applied to berlin64/dt.

Thanks!

> ---
>  arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts 
> b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> index da28c97..cdcf89b 100644
> --- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> +++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> @@ -94,7 +94,6 @@
>  };
>  
>   {
> - broken-cd;
>   bus-width = <8>;
>   non-removable;
>   status = "okay";
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Documentation: arm: update Berlin family info in Marvell README

[Sebastian Hesselbarth]

On 15.11.2015 03:36, Tom Hebb wrote:
> These are a few changes to bring the Marvell Berlin family documentation
> up to date. The old URLs were no longer redirecting properly, so I
> changed them to the current ones. I also added what information I could
> find about the new BG2CDP chip used in the Chromecast 2015.
> 
> Thomas Hebb (3):
>   Documentation: arm: update homepage URLs for Marvell Berlin SoCs
>   Documentation: arm: add Marvell Armada 1500 Mini Plus to SoC list
>   Documentation: arm: remove hyphen from BG2Q in Marvell Berlin docs
> 
>  Documentation/arm/Marvell/README | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 

Thomas,

thanks for the cleanup and update! Somehow, your series
misses the in-reply-to tag which makes the individual
patches kind of hard to track.

I have applied all 3 patches (v2 for 2/3) to berlin/doc that
I can send a PR for to Jonathan.

If Jonathan prefers to pick-up the patches himself, feel free
to add my

Acked-by: Sebastian Hesselbarth 

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/