from:"Sebastian Hesselbarth"


On 04/08/2013 02:17 AM, Guenter Roeck wrote:

On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:

On 04/08/2013 12:50 AM, Guenter Roeck wrote:

On Fri, Apr 05, 2013 at 05:23:35AM -, Sebastian Hesselbarth wrote:

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
Tested-by: Daniel Mackzon...@gmail.com


[ ... ]


+static inline void _si5351_msynth_set_pll_master(
+   struct si5351_driver_data *drvdata, unsigned char num, int is_master)
+{
+   unsigned long flags;
+
+   if (num   8 ||
+   (drvdata-variant == SI5351_VARIANT_A3   num   3))
+   return;
+
+   flags = __clk_get_flags(drvdata-msynth[num].hw.clk);
+   if (is_master)
+   flags |= CLK_SET_RATE_PARENT;
+   else
+   flags= ~CLK_SET_RATE_PARENT;
+   __clk_set_flags(drvdata-msynth[num].hw.clk, flags);
+}
+

Unless I am missing something, neither __clk_get_flags() nor the new
__clk_set_flags is exported.

Did you try to build and load the driver as module ?


Well, good catch. I didn't try to build v5 as a module, but I guess it
will fail. But I consider this as something that has to be addressed in
clk framework itself, not in this patch. There will be other
clk-providers built as module in the future for sure.


Sure, but you provided the patch to make __clk_set_flags global. To avoid
build failures, I would suggest to either submit a patch to export the
missing functions, or to remove the ability to build the driver as module.


Actually, I knew that __clk_set_flags patch will not be accepted before 
posting it ;)



On a side note, do you happen to know anyone working on drivers for Si5319 or
Si5368 ?


No.


Thanks,
Guenter


--
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: add helper to set flags for clk-provider


On 04/08/2013 05:59 AM, Mike Turquette wrote:

Quoting Sebastian Hesselbarth (2013-04-04 22:22:12)

Clock providers are not allowed to mess with struct clk internals directly
but using helpers provided by clk-provider.h. This patch adds a helper to
allow to set flags of a clock after registration. This is useful, if clock
flags change during runtime, e.g. ability to set parent clock after mux
switch.


Hi Sebastian,

I do not like this change.  There are a few reasons why.  Firstly the
clk flags have never been advertised as changing at runtime.  On that
note, can you expand your example of ability to set parent clock after
mux switch?  I do not follow what you mean.


Mike,

I knew you wouldn't like it. I just wanted to raise this discussion.

Consider a clock mux like in si5351 where each output clock can be muxed
to either it's own pll clock divider, the pll clock divider of clk0,
xtal, or clkin. And consider you want to allow to configure the mux at
runtime (si5351 driver doesn't, but just think about it).

Now, for it's own pll clock divider you want CLK_SET_PARENT_RATE while
for clk0's pll clock divider you want ~CLK_SET_PARENT_RATE because it
will break clk0's output rate. How can you have two sets of flags in the
current API?


Secondly, it is possible to need flags during __clk_init.  This exists
today for root clocks that use the CLK_IS_ROOT flag.  So setting that
flag after registration is too late.


Sure, but some others work just fine if you change them during runtime.


Finally, how can we make sure that this api is not abused?  I'm
concerned about drivers which use __clk_set_flags in a hacky way, when
in fact the flags are supposed to be permanent properties of that clock.


How can you ever make sure, the API is not abused? For the si5351 patch
at least, you pointed out not to use clk-private.h and now rejected v5
again.

I am asking, if those clock flags are really permanent properties? Not
that any current driver uses this, but especially clk muxes are meant
to switch to another clock that may have/require different flags.


Do you truly need the ability to change clock flags at runtime, or do
you instead need a way to express flags in DT?  I'm sure the clock
bindings are not the first binding to run up against flags or properties
that do not strictly match the hardware description.  Maybe solving that
problem is the right way?


Of course, I can parse the flags prior registration and store them in
some struct. I was just re-working v4 of si5351 patch and wanted this
discussion first.

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: [v5] clk: add si5351 i2c common clock driver

On Mon, Apr 8, 2013 at 4:54 PM, Guenter Roeck li...@roeck-us.net wrote:
 On Mon, Apr 08, 2013 at 08:11:38AM +0200, Sebastian Hesselbarth wrote:
 On 04/08/2013 02:17 AM, Guenter Roeck wrote:
 On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
 On 04/08/2013 12:50 AM, Guenter Roeck wrote:
 On Fri, Apr 05, 2013 at 05:23:35AM -, Sebastian Hesselbarth wrote:
 This patch adds a common clock driver for Silicon Labs Si5351a/b/c
 i2c programmable clock generators. Currently, the driver supports
 DT kernels only and VXCO feature of si5351b is not implemented. DT
 bindings selectively allow to overwrite stored Si5351 configuration
 which is very helpful for clock generators with empty eeprom
 configuration. Corresponding device tree binding documentation is
 also added.
 
 Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
 Tested-by: Daniel Mackzon...@gmail.com
 
 [ ... ]
 
 +static inline void _si5351_msynth_set_pll_master(
 + struct si5351_driver_data *drvdata, unsigned char num, int is_master)
 +{
 + unsigned long flags;
 +
 + if (num   8 ||
 + (drvdata-variant == SI5351_VARIANT_A3   num   3))
 + return;
 +
 + flags = __clk_get_flags(drvdata-msynth[num].hw.clk);
 + if (is_master)
 + flags |= CLK_SET_RATE_PARENT;
 + else
 + flags= ~CLK_SET_RATE_PARENT;
 + __clk_set_flags(drvdata-msynth[num].hw.clk, flags);
 +}
 +
 Unless I am missing something, neither __clk_get_flags() nor the new
 __clk_set_flags is exported.
 
 Did you try to build and load the driver as module ?
 
 Well, good catch. I didn't try to build v5 as a module, but I guess it
 will fail. But I consider this as something that has to be addressed in
 clk framework itself, not in this patch. There will be other
 clk-providers built as module in the future for sure.
 
 Sure, but you provided the patch to make __clk_set_flags global. To avoid
 build failures, I would suggest to either submit a patch to export the
 missing functions, or to remove the ability to build the driver as module.

 Actually, I knew that __clk_set_flags patch will not be accepted
 before posting it ;)

 Ah, but part of that is to get you to think about it again, and to defend it 
 if
 it is really needed. After all, it can be abused applies to pretty much 
 every
 API.

Guenter,

I already thought about it a lot and I consider clk api broken in a way here.

 Key question is if you _really_ need run-time flag modifications, or if you 
 can
 live with initialization-time settings. If you really need it, you'll have to
 explain the reasons.

The question is not if _I_ really need run-time flags but why the api allows to
perform run-time modifications of the clock hierarchy without allowing different
flags? There is clk_set_parent() so I guess clk api knows about run-time changes
already, but you cannot have different flags per parent. And with
__clk_set_flags()
rejected, you are not allowed to change the flags.

I understand that some flags are permanent and required at registration, but
CLK_SET_PARENT_RATE is not. It is not limited by hardware but limited by api.
One way would be a more generic clk-mux with per parent flags, but for
the current
implementation, I cannot see how clk-mux can be exploited here.

I can live with it, because then dynamic muxing of clock hierarchy
within clk-si5351
is just not supported or will break function. Currently, there is no
support for dynamic
muxing, so everything is fine.

 On a side note, do you happen to know anyone working on drivers for Si5319 
 or
 Si5368 ?

 No.

 Too bad ... I may have to write that code myself then.

Well, if clk-si5351 will ever get in mainline kernel, feel free to use
it as a template ;)

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/

[PATCH] clk: export __clk_get_flags for modular clock providers

The common clock api provides some helpers for clk-providers but does
not export these helpers. This hinders clk-providers to be built as modules.
This patch adds __clk_get_flags() to the list of exported symbols.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Mike Turquette mturque...@linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/clk/clk.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ed87b24..3e478b8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -450,6 +450,7 @@ unsigned long __clk_get_flags(struct clk *clk)
 {
return !clk ? 0 : clk-flags;
 }
+EXPORT_SYMBOL_GPL(__clk_get_flags);
 
 bool __clk_is_enabled(struct clk *clk)
 {
-- 
1.7.10.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 v6] clk: add si5351 i2c common clock driver


On 04/08/2013 07:46 PM, Guenter Roeck wrote:

On Mon, Apr 08, 2013 at 06:46:57PM +0200, Sebastian Hesselbarth wrote:

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver does not
support VXCO feature of si5351b. Passing platform_data or DT bindings
selectively allow to overwrite stored Si5351 configuration which is
very helpful for clock generators with empty eeprom configuration.
Corresponding device tree binding documentation is also added.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com


[ ... ]


+
+/*
+ * Si5351 i2c probe and DT
+ */
+#ifdef CONFIG_OF
+static const struct of_device_id si5351_dt_ids[] = {
+   { .compatible = silabs,si5351a, .data = (void *)SI5351_VARIANT_A, },
+   { .compatible = silabs,si5351a-msop,
+.data = (void *)SI5351_VARIANT_A3, },
+   { .compatible = silabs,si5351b, .data = (void *)SI5351_VARIANT_B, },
+   { .compatible = silabs,si5351c, .data = (void *)SI5351_VARIANT_C, },
+   { }
+};
+MODULE_DEVICE_TABLE(of, si5351_dt_ids);
+
+static int si5351_dt_parse(struct i2c_client *client)
+{
+   struct device_node *child, *np = client-dev.of_node;
+   struct si5351_platform_data *pdata;
+   const struct of_device_id *match;
+   struct property *prop;
+   const __be32 *p;
+   int num = 0;
+   u32 val;
+
+   if (np == NULL)
+   return 0;
+
+   match = of_match_node(si5351_dt_ids, np);
+   if (match == NULL)
+   return -EINVAL;
+
+   pdata = devm_kzalloc(client-dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+
+   pdata-variant = (enum si5351_variant)match-data;
+   pdata-clk_xtal = of_clk_get(np, 0);
+   if (!IS_ERR(pdata-clk_xtal))
+   clk_put(pdata-clk_xtal);
+   pdata-clk_clkin = of_clk_get(np, 1);
+   if (!IS_ERR(pdata-clk_clkin))
+   clk_put(pdata-clk_clkin);
+
+   /*
+* property silabs,pll-source :num src, [..]
+* allow to selectively set pll source
+*/
+   of_property_for_each_u32(np, silabs,pll-source, prop, p, num) {
+   if (num= 2) {
+   dev_err(client-dev,
+   invalid pll %d on pll-source prop\n, num);
+   break;


You report dev_err here, but you don't return an error to the caller.
Is this on purpose ? If it is not a fatal error, maybe it should be dev_info ?


This shouldn't break but continue with one u32 skipped. Actually, it is
a warning because somebody passed an invalid value and should be 
dev_warn(). But see my note below, I will make them all fatal.



+   }
+
+   p = of_prop_next_u32(prop, p,val);
+   if (!p)
+   break;
+
+   switch (val) {
+   case 0:
+   pdata-pll_src[num] = SI5351_PLL_SRC_XTAL;
+   break;
+   case 1:
+   pdata-pll_src[num] = SI5351_PLL_SRC_CLKIN;
+   break;
+   default:
+   dev_warn(client-dev,
+invalid parent %d for pll %d\n, val, num);
+   continue;


Same here, and a couple of times below. Given the context, I think it would
be better if the error cases would return an error. After all, the condition
suggests that the device tree data is wrong, meaning one has to assume it
won't work anyway and should be fixed in the device tree and not be ignored
by the driver.


I am skipping invalid DT data enties here, but I can make them all
fatal. I will also add more variant checks in the corresponding
_si5351_* functions.


+   }
+   }
+
+   /* per clkout properties */
+   num = of_get_child_count(np);
+
+   if (num == 0)
+   return 0;
+


This doesn't set client-dev.platform_data yet returns no error, meaning the
calling code will either use provided platform data or fail after all if it is
NULL. That seems to be inconsistent, given that a dt entry was already detected.
The user might end up wondering why the provided device tree data is not used,
not realizing that it is incomplete.

If children are not mandatory, you could just drop the code above and go through
for_each_child_of_node() anyway; it won't do anything and set
client-dev.platform_data at the end. If children are mandatory, it might make
sense to return an eror here (if there is dt information, it should be complete
and consistent).


Not having children is valid as you only provide them if you want to
overwrite the current config stored in the eeprom. But yes, skipping
for_each_child_of_node below is a left-over from an implementation where
I used dynamically allocated -pll/-clkout.


+   for_each_child_of_node(np, child) {
+   if (of_property_read_u32(child, reg,num

Re: [v5] clk: add si5351 i2c common clock driver


On 04/08/2013 07:36 PM, Mike Turquette wrote:

Quoting Sebastian Hesselbarth (2013-04-08 08:38:44)

On Mon, Apr 8, 2013 at 4:54 PM, Guenter Roeckli...@roeck-us.net  wrote:

On Mon, Apr 08, 2013 at 08:11:38AM +0200, Sebastian Hesselbarth wrote:

On 04/08/2013 02:17 AM, Guenter Roeck wrote:

On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:

On 04/08/2013 12:50 AM, Guenter Roeck wrote:

On Fri, Apr 05, 2013 at 05:23:35AM -, Sebastian Hesselbarth wrote:

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
Tested-by: Daniel Mackzon...@gmail.com


[ ... ]


+static inline void _si5351_msynth_set_pll_master(
+ struct si5351_driver_data *drvdata, unsigned char num, int is_master)
+{
+ unsigned long flags;
+
+ if (num8 ||
+ (drvdata-variant == SI5351_VARIANT_A3num3))
+ return;
+
+ flags = __clk_get_flags(drvdata-msynth[num].hw.clk);
+ if (is_master)
+ flags |= CLK_SET_RATE_PARENT;
+ else
+ flags= ~CLK_SET_RATE_PARENT;
+ __clk_set_flags(drvdata-msynth[num].hw.clk, flags);
+}
+

Unless I am missing something, neither __clk_get_flags() nor the new
__clk_set_flags is exported.

Did you try to build and load the driver as module ?


Well, good catch. I didn't try to build v5 as a module, but I guess it
will fail. But I consider this as something that has to be addressed in
clk framework itself, not in this patch. There will be other
clk-providers built as module in the future for sure.


Sure, but you provided the patch to make __clk_set_flags global. To avoid
build failures, I would suggest to either submit a patch to export the
missing functions, or to remove the ability to build the driver as module.


Actually, I knew that __clk_set_flags patch will not be accepted
before posting it ;)


Ah, but part of that is to get you to think about it again, and to defend it if
it is really needed. After all, it can be abused applies to pretty much every
API.


Guenter,

I already thought about it a lot and I consider clk api broken in a way here.


Key question is if you _really_ need run-time flag modifications, or if you can
live with initialization-time settings. If you really need it, you'll have to
explain the reasons.


The question is not if _I_ really need run-time flags but why the api allows to
perform run-time modifications of the clock hierarchy without allowing different
flags? There is clk_set_parent() so I guess clk api knows about run-time changes
already, but you cannot have different flags per parent. And with
__clk_set_flags()
rejected, you are not allowed to change the flags.

I understand that some flags are permanent and required at registration, but
CLK_SET_PARENT_RATE is not. It is not limited by hardware but limited by api.
One way would be a more generic clk-mux with per parent flags, but for
the current
implementation, I cannot see how clk-mux can be exploited here.



There are a couple of ways to get past this issue.  One is removal of
some of the flags.  I have never liked CLK_SET_RATE_PARENT, since I
think the ability to propagate a rate-change request up to the parent
should be enabled for all clocks.  This is in the interest of the driver
author who does not care to know intimate details of the clock
hierarchy.

When I developed the rate-change propagation code I was likely too hasty
in defining a per-clock flag for that behavior.  It might have been
enough to simply compare thebest_parent_rate value from .round_rate
and compare it against clk-parent-rate.  This means that no flag is
necessary.

This assumes that the .round_rate implementation has enough knowledge to
know whether or not to propagate the rate-change request up to the
parent.  This may not not true for the common divider type.

I'll make some tests on removing this flag (and potentially other flags)
to see how painful it is.


Mike,

another good thing would be to have implementation independent building 
blocks for clk drivers. I think clk-fixed-rate, clk-gate, clk-mux and

some clk-synth should be enough. The current core clk templates in the
api are almost all special implementations.

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] clk: si5351: Add gapless tuning for SI5351 PLL

2013-04-09 Thread Sebastian Hesselbarth

On Tue, Apr 9, 2013 at 10:26 AM, Michal Bachraty
michal.bachr...@streamunlimited.com wrote:
 For gapless tuning, there is no need for PLL reset and clkout power-down
 when tuning output. silabs,gapless-tuning parameter enables gapless tuning
 for specific clock output.

Michal,

does gapless tuning have any constraints? Can we use it for all rate
changes or determine the
need for pll reset by rate offset?

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 v7] clk: add si5351 i2c common clock driver


Hooray Google!

Thanks for removing plain text sending from gmail web-frontend.. *sigh*
Sorry for resending this, but HTML mails get rejected by linux mailing lists.

On 04/10/2013 04:48 PM, Michal Bachraty wrote:

Hi Sebastian,
This driver doesn't work for me. In my case, u-boot initializes si-5351 and
power down unused clocks while booting kernel.  there is need for power up
clocks as was in previous versions of your driver.
See patch, whre the problem is fixed:

@@ -992,6 +992,10 @@ static long si5351_clkout_round_rate(struct clk_hw *hw,
unsigned long rate,
} while (1);
}
rate = *parent_rate  rdiv;
+   
+   /* powerup clkout */
+   si5351_set_bits(hwdata-drvdata, SI5351_CLK0_CTRL + hwdata-num,
+   SI5351_CLK_POWERDOWN, 0);

dev_dbg(hwdata-drvdata-client-dev,
%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n,

With this lines, driver works well.


Hmm, is there any driver using the clock output? Does it clk_prepare_enable() 
the clock?
I tend not to mess with anything the bootloader or eeprom config left disabled. 
It works
for me, but here the driver will prepare/enable the clock prior use.


Also,


+==Example==
+
+/* 25MHz reference crystal */
+ref25: ref25M {
+   compatible = fixed-clock;
+   #clock-cells =0;
+   clock-frequency =2500;
+};
+
+i2c-master-node {
+
+   /* Si5351a msop10 i2c clock generator */
+   si5351a: clock-generator@60 {
+   compatible = silabs,si5351a-msop;
+   reg =0x60;
+   #address-cells =1;
+   #size-cells =0;
+   #clock-cells =1;
+
+   /* connect xtal input to 25MHz reference */
+   clocks =ref25;
+
+   /* connect xtal input as source of pll0 and pll1 */
+   silabs,pll-source =0 0,1 0;
+
+   /*
+* overwrite clkout0 configuration with:
+* - 8mA output drive strength
+* - pll0 as clock source of multisynth0
+* - multisynth0 as clock source of output divider
+* - multisynth0 can change pll0
+* - set initial clock frequency of 74.25MHz
+*/
+   clkout0 {
+   reg =0;
+   silabs,drive-strength =8;
+   silabs,multisynth-source =0;
+   silabs,clock-source =0;
+   silabs,pll-master;
+   clock-frequency =7425;
+   };
+
+   /*
+* overwrite clkout1 configuration with:
+* - 4mA output drive strength
+* - pll1 as clock source of multisynth1
+* - multisynth1 as clock source of output divider
+* - multisynth1 can change pll1
+*/
+   clkout1 {
+   reg =1;
+   silabs,drive-strength =4;
+   silabs,multisynth-source =1;
+   silabs,clock-source =0;
+   pll-master;
+   };
+

  Is definition of pll-master in clkout1 correct? should not be silabs,pll-
master ?


Good catch.

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/

[PATCH] net: mvmdio: add clocks property to binding documentation

Patch net: mvmdio: get and enable optional clock was missing an
update of the corresponding device tree binding documentation. This
patch adds the clocks property to mvmdio binding documentation.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: David S. Miller da...@davemloft.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: net...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/net/marvell-orion-mdio.txt |1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt 
b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 052b5f2..9417e54 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -11,6 +11,7 @@ Required properties:
 
 Optional properties:
 - interrupts: interrupt line number for the SMI error/done interrupt
+- clocks: Phandle to the clock control device and gate bit
 
 The child nodes of the MDIO driver are the individual PHY devices
 connected to this MDIO bus. They must have a reg property given the
-- 
1.7.10.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] net: mv643xx_eth: add shared clk and cleanup existing clk handling

This patch adds an optional shared block clock to avoid lockups on
clock gated controllers. Besides the new clock, clock handling for
existing clocks is cleaned up and moved to devm_clk_get. Device
tree binding documentation is updated for the new clocks property.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: net...@vger.kernel.org
---
 Documentation/devicetree/bindings/marvell.txt |3 +++
 drivers/net/ethernet/marvell/mv643xx_eth.c|   27 ++---
 2 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/marvell.txt 
b/Documentation/devicetree/bindings/marvell.txt
index f1533d9..f7a0da6 100644
--- a/Documentation/devicetree/bindings/marvell.txt
+++ b/Documentation/devicetree/bindings/marvell.txt
@@ -115,6 +115,9 @@ prefixed with the string marvell,, for Marvell Technology 
Group Ltd.
  - compatible : marvell,mv64360-eth-block
  - reg : Offset and length of the register set for this block
 
+   Optional properties:
+ - clocks : Phandle to the clock control device and gate bit
+
Example Discovery Ethernet block node:
  ethernet-block@2000 {
 #address-cells = 1;
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index aedbd82..bbe6104 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -268,7 +268,7 @@ struct mv643xx_eth_shared_private {
int extended_rx_coal_limit;
int tx_bw_control;
int tx_csum_limit;
-
+   struct clk *clk;
 };
 
 #define TX_BW_CONTROL_ABSENT   0
@@ -410,9 +410,7 @@ struct mv643xx_eth_private {
/*
 * Hardware-specific parameters.
 */
-#if defined(CONFIG_HAVE_CLK)
struct clk *clk;
-#endif
unsigned int t_clk;
 };
 
@@ -2569,6 +2567,10 @@ static int mv643xx_eth_shared_probe(struct 
platform_device *pdev)
if (msp-base == NULL)
goto out_free;
 
+   msp-clk = devm_clk_get(pdev-dev, NULL);
+   if (!IS_ERR(msp-clk))
+   clk_prepare_enable(msp-clk);
+
/*
 * (Re-)program MBUS remapping windows if we are asked to.
 */
@@ -2595,6 +2597,8 @@ static int mv643xx_eth_shared_remove(struct 
platform_device *pdev)
struct mv643xx_eth_shared_private *msp = platform_get_drvdata(pdev);
 
iounmap(msp-base);
+   if (!IS_ERR(msp-clk))
+   clk_disable_unprepare(msp-clk);
kfree(msp);
 
return 0;
@@ -2801,13 +2805,12 @@ static int mv643xx_eth_probe(struct platform_device 
*pdev)
 * it to override the default.
 */
mp-t_clk = 13300;
-#if defined(CONFIG_HAVE_CLK)
-   mp-clk = clk_get(pdev-dev, (pdev-id ? 1 : 0));
+   mp-clk = devm_clk_get(pdev-dev, NULL);
if (!IS_ERR(mp-clk)) {
clk_prepare_enable(mp-clk);
mp-t_clk = clk_get_rate(mp-clk);
}
-#endif
+
set_params(mp, pd);
netif_set_real_num_tx_queues(dev, mp-txq_count);
netif_set_real_num_rx_queues(dev, mp-rxq_count);
@@ -2889,12 +2892,8 @@ static int mv643xx_eth_probe(struct platform_device 
*pdev)
return 0;
 
 out:
-#if defined(CONFIG_HAVE_CLK)
-   if (!IS_ERR(mp-clk)) {
+   if (!IS_ERR(mp-clk))
clk_disable_unprepare(mp-clk);
-   clk_put(mp-clk);
-   }
-#endif
free_netdev(dev);
 
return err;
@@ -2909,12 +2908,8 @@ static int mv643xx_eth_remove(struct platform_device 
*pdev)
phy_detach(mp-phy);
cancel_work_sync(mp-tx_timeout_task);
 
-#if defined(CONFIG_HAVE_CLK)
-   if (!IS_ERR(mp-clk)) {
+   if (!IS_ERR(mp-clk))
clk_disable_unprepare(mp-clk);
-   clk_put(mp-clk);
-   }
-#endif
 
free_netdev(mp-dev);
 
-- 
1.7.10.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] net: mv643xx_eth: use managed devm_kzalloc

This patch moves shared private data kzalloc to managed devm_kzalloc and
cleans now unneccessary kfree and error handling.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Note that there is also an ioremap call, that could be transferred to
devm_ioremap_resource. But as long as mv643xx_eth and mvmdio iomem
resources overlap, this will throw -EBUSY.

Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/net/ethernet/marvell/mv643xx_eth.c |   17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index bbe6104..955baab 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2547,25 +2547,22 @@ static int mv643xx_eth_shared_probe(struct 
platform_device *pdev)
struct mv643xx_eth_shared_private *msp;
const struct mbus_dram_target_info *dram;
struct resource *res;
-   int ret;
 
if (!mv643xx_eth_version_printed++)
pr_notice(MV-643xx 10/100/1000 ethernet driver version %s\n,
  mv643xx_eth_driver_version);
 
-   ret = -EINVAL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
-   goto out;
+   return -EINVAL;
 
-   ret = -ENOMEM;
-   msp = kzalloc(sizeof(*msp), GFP_KERNEL);
+   msp = devm_kzalloc(pdev-dev, sizeof(*msp), GFP_KERNEL);
if (msp == NULL)
-   goto out;
+   return -ENOMEM;
 
msp-base = ioremap(res-start, resource_size(res));
if (msp-base == NULL)
-   goto out_free;
+   return -EADDRNOTAVAIL;
 
msp-clk = devm_clk_get(pdev-dev, NULL);
if (!IS_ERR(msp-clk))
@@ -2585,11 +2582,6 @@ static int mv643xx_eth_shared_probe(struct 
platform_device *pdev)
platform_set_drvdata(pdev, msp);
 
return 0;
-
-out_free:
-   kfree(msp);
-out:
-   return ret;
 }
 
 static int mv643xx_eth_shared_remove(struct platform_device *pdev)
@@ -2599,7 +2591,6 @@ static int mv643xx_eth_shared_remove(struct 
platform_device *pdev)
iounmap(msp-base);
if (!IS_ERR(msp-clk))
clk_disable_unprepare(msp-clk);
-   kfree(msp);
 
return 0;
 }
-- 
1.7.10.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] net: mv643xx_eth: use managed devm_kzalloc


On 04/10/2013 08:41 PM, Sergei Shtylyov wrote:

Hello.

On 04/10/2013 09:38 PM, Sebastian Hesselbarth wrote:


This patch moves shared private data kzalloc to managed devm_kzalloc and
cleans now unneccessary kfree and error handling.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Note that there is also an ioremap call, that could be transferred to
devm_ioremap_resource. But as long as mv643xx_eth and mvmdio iomem
resources overlap, this will throw -EBUSY.

Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index bbe6104..955baab 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2547,25 +2547,22 @@ static int mv643xx_eth_shared_probe(struct
platform_device *pdev)
struct mv643xx_eth_shared_private *msp;
const struct mbus_dram_target_info *dram;
struct resource *res;
- int ret;
if (!mv643xx_eth_version_printed++)
pr_notice(MV-643xx 10/100/1000 ethernet driver version %s\n,
mv643xx_eth_driver_version);
- ret = -EINVAL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
- goto out;
+ return -EINVAL;
- ret = -ENOMEM;
- msp = kzalloc(sizeof(*msp), GFP_KERNEL);
+ msp = devm_kzalloc(pdev-dev, sizeof(*msp), GFP_KERNEL);
if (msp == NULL)
- goto out;
+ return -ENOMEM;
msp-base = ioremap(res-start, resource_size(res));
if (msp-base == NULL)
- goto out_free;
+ return -EADDRNOTAVAIL;


-ENOMEM usually.


Sergei,

I was looking at the example for devm_request_and_ioremap() in
lib/devres.c. There it is -EADDRNOTAVAIL which is returned on
failing ioremap.

Actually, I was hoping to also use devm_ioremap_resource() for
the above, but that is too early as mv643xx_eth and mvmdio have
overlapping mem resources. Changing this will require some more
step-by-step patches that get also tested on arch/ppc and others
using platform mv643xx_eth.

But, I can send an updated patch with -ENOMEM above if required.

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/

[PATCH v2] net: mv643xx_eth: use managed devm_kzalloc

This patch moves shared private data kzalloc to managed devm_kzalloc and
cleans now unneccessary kfree and error handling.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changes from v1:
- replaced EADDRNOTAVAIL with ENOMEM on failing ioremap (Reported by
  Sergei Shtylyov)

Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/net/ethernet/marvell/mv643xx_eth.c |   17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index bbe6104..305038f 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2547,25 +2547,22 @@ static int mv643xx_eth_shared_probe(struct 
platform_device *pdev)
struct mv643xx_eth_shared_private *msp;
const struct mbus_dram_target_info *dram;
struct resource *res;
-   int ret;
 
if (!mv643xx_eth_version_printed++)
pr_notice(MV-643xx 10/100/1000 ethernet driver version %s\n,
  mv643xx_eth_driver_version);
 
-   ret = -EINVAL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
-   goto out;
+   return -EINVAL;
 
-   ret = -ENOMEM;
-   msp = kzalloc(sizeof(*msp), GFP_KERNEL);
+   msp = devm_kzalloc(pdev-dev, sizeof(*msp), GFP_KERNEL);
if (msp == NULL)
-   goto out;
+   return -ENOMEM;
 
msp-base = ioremap(res-start, resource_size(res));
if (msp-base == NULL)
-   goto out_free;
+   return -ENOMEM;
 
msp-clk = devm_clk_get(pdev-dev, NULL);
if (!IS_ERR(msp-clk))
@@ -2585,11 +2582,6 @@ static int mv643xx_eth_shared_probe(struct 
platform_device *pdev)
platform_set_drvdata(pdev, msp);
 
return 0;
-
-out_free:
-   kfree(msp);
-out:
-   return ret;
 }
 
 static int mv643xx_eth_shared_remove(struct platform_device *pdev)
@@ -2599,7 +2591,6 @@ static int mv643xx_eth_shared_remove(struct 
platform_device *pdev)
iounmap(msp-base);
if (!IS_ERR(msp-clk))
clk_disable_unprepare(msp-clk);
-   kfree(msp);
 
return 0;
 }
-- 
1.7.10.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 v2] net: mv643xx_eth: use managed devm_kzalloc

On 04/11/2013 05:39 AM, David Miller wrote:

From: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
Date: Wed, 10 Apr 2013 22:42:07 +0200

This patch moves shared private data kzalloc to managed devm_kzalloc and
cleans now unneccessary kfree and error handling.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com

This doesn't apply cleanly to the net-next tree.

Yeah. I sent two single patches for mv643xx_eth, while they should
have been sent together in one patch set. I'll prepare a cover letter
and resend both in one patch set.

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 v7] clk: add si5351 i2c common clock driver

On Thu, Apr 11, 2013 at 9:44 AM, Michal Bachraty
michal.bachr...@streamunlimited.com wrote:
 On Wednesday, April 10, 2013 19:27:25 Sebastian Hesselbarth wrote:
 Hmm, is there any driver using the clock output? Does it
 clk_prepare_enable() the clock? I tend not to mess with anything the
 bootloader or eeprom config left disabled. It works for me, but here the
 driver will prepare/enable the clock prior use.

 For my case, disabled clock outputs in bootloader are correct. I'm working on
 module board with lot of purposes. For one I need to tune frequncy, for other
 not. In some cases I can use  clk_prepare_enable. For now, I need to tune clk,
 so I can't use clk_prepare_enable. Si5351 chip has no problem with enabling
 clock output multiple times, when calling clk_set_rate. So if this feature
 will not be in driver, I need to stay with patch upon driver.

Michal,

after thinking about it, I will re-add the power-on on rate change.
Not because I
want to have a workaround for not using clk_prepare_enable() before
clk_set_rate(),
but clkout will remain disabled if you set clock-frequency by DT.
There will be no
superfluous writes to i2c resisters anyway, because clk-si5351 is
using regmap-i2c
that takes care of caching.

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/

[PATCH v2] net: mvmdio: add clocks property to binding documentation

Commit 3d604da1e9547c09c9dcc0ee443c306c9ae1a480
  (net: mvmdio: get and enable optional clock)

was missing an update of the corresponding device tree binding
documentation. This patch adds the clocks property to mvmdio
binding documentation.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changes from v1:
- name commit and hash in commit message

Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: David S. Miller da...@davemloft.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: net...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/net/marvell-orion-mdio.txt |1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt 
b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 052b5f2..9417e54 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -11,6 +11,7 @@ Required properties:
 
 Optional properties:
 - interrupts: interrupt line number for the SMI error/done interrupt
+- clocks: Phandle to the clock control device and gate bit
 
 The child nodes of the MDIO driver are the individual PHY devices
 connected to this MDIO bus. They must have a reg property given the
-- 
1.7.10.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 2/2] net: mv643xx_eth: use managed devm_kzalloc

This patch moves shared private data kzalloc to managed devm_kzalloc and
cleans now unneccessary kfree and error handling.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changes from v1:
- replaced EADDRNOTAVAIL with ENOMEM on failing ioremap (Reported by
  Sergei Shtylyov)

Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: net...@vger.kernel.org
---
 drivers/net/ethernet/marvell/mv643xx_eth.c |   17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index bbe6104..305038f 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2547,25 +2547,22 @@ static int mv643xx_eth_shared_probe(struct 
platform_device *pdev)
struct mv643xx_eth_shared_private *msp;
const struct mbus_dram_target_info *dram;
struct resource *res;
-   int ret;
 
if (!mv643xx_eth_version_printed++)
pr_notice(MV-643xx 10/100/1000 ethernet driver version %s\n,
  mv643xx_eth_driver_version);
 
-   ret = -EINVAL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
-   goto out;
+   return -EINVAL;
 
-   ret = -ENOMEM;
-   msp = kzalloc(sizeof(*msp), GFP_KERNEL);
+   msp = devm_kzalloc(pdev-dev, sizeof(*msp), GFP_KERNEL);
if (msp == NULL)
-   goto out;
+   return -ENOMEM;
 
msp-base = ioremap(res-start, resource_size(res));
if (msp-base == NULL)
-   goto out_free;
+   return -ENOMEM;
 
msp-clk = devm_clk_get(pdev-dev, NULL);
if (!IS_ERR(msp-clk))
@@ -2585,11 +2582,6 @@ static int mv643xx_eth_shared_probe(struct 
platform_device *pdev)
platform_set_drvdata(pdev, msp);
 
return 0;
-
-out_free:
-   kfree(msp);
-out:
-   return ret;
 }
 
 static int mv643xx_eth_shared_remove(struct platform_device *pdev)
@@ -2599,7 +2591,6 @@ static int mv643xx_eth_shared_remove(struct 
platform_device *pdev)
iounmap(msp-base);
if (!IS_ERR(msp-clk))
clk_disable_unprepare(msp-clk);
-   kfree(msp);
 
return 0;
 }
-- 
1.7.10.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/2] net: mv643xx_eth: use managed clk and allocation

With introduction of common clock framework and the ability to provide
gated clocks, mv643xx_eth required calls to get and enable these clock
gates on some platforms. Back then, common clock framework api wasn't
safe for architectures without support for common clocks. This has
changed now and there are also managed (devm_) counterparts for clock
related functions.

The second patch in this series, also converts kzalloc to devm_kzalloc
where applicable.

Both patches have been sent to the corresponding mailing lists as
individual patches before. To get the order required to apply them right,
this patch set combines both patches into one set.

Sebastian Hesselbarth (2):
  net: mv643xx_eth: add shared clk and cleanup existing clk handling
  net: mv643xx_eth: use managed devm_kzalloc

 Documentation/devicetree/bindings/marvell.txt |3 ++
 drivers/net/ethernet/marvell/mv643xx_eth.c|   44 +
 2 files changed, 18 insertions(+), 29 deletions(-)

---
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: net...@vger.kernel.org
-- 
1.7.10.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/2] net: mv643xx_eth: add shared clk and cleanup existing clk handling

This patch adds an optional shared block clock to avoid lockups on
clock gated controllers. Besides the new clock, clock handling for
existing clocks is cleaned up and moved to devm_clk_get. Device
tree binding documentation is updated for the new clocks property.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: net...@vger.kernel.org
---
 Documentation/devicetree/bindings/marvell.txt |3 +++
 drivers/net/ethernet/marvell/mv643xx_eth.c|   27 ++---
 2 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/marvell.txt 
b/Documentation/devicetree/bindings/marvell.txt
index f1533d9..f7a0da6 100644
--- a/Documentation/devicetree/bindings/marvell.txt
+++ b/Documentation/devicetree/bindings/marvell.txt
@@ -115,6 +115,9 @@ prefixed with the string marvell,, for Marvell Technology 
Group Ltd.
  - compatible : marvell,mv64360-eth-block
  - reg : Offset and length of the register set for this block
 
+   Optional properties:
+ - clocks : Phandle to the clock control device and gate bit
+
Example Discovery Ethernet block node:
  ethernet-block@2000 {
 #address-cells = 1;
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index aedbd82..bbe6104 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -268,7 +268,7 @@ struct mv643xx_eth_shared_private {
int extended_rx_coal_limit;
int tx_bw_control;
int tx_csum_limit;
-
+   struct clk *clk;
 };
 
 #define TX_BW_CONTROL_ABSENT   0
@@ -410,9 +410,7 @@ struct mv643xx_eth_private {
/*
 * Hardware-specific parameters.
 */
-#if defined(CONFIG_HAVE_CLK)
struct clk *clk;
-#endif
unsigned int t_clk;
 };
 
@@ -2569,6 +2567,10 @@ static int mv643xx_eth_shared_probe(struct 
platform_device *pdev)
if (msp-base == NULL)
goto out_free;
 
+   msp-clk = devm_clk_get(pdev-dev, NULL);
+   if (!IS_ERR(msp-clk))
+   clk_prepare_enable(msp-clk);
+
/*
 * (Re-)program MBUS remapping windows if we are asked to.
 */
@@ -2595,6 +2597,8 @@ static int mv643xx_eth_shared_remove(struct 
platform_device *pdev)
struct mv643xx_eth_shared_private *msp = platform_get_drvdata(pdev);
 
iounmap(msp-base);
+   if (!IS_ERR(msp-clk))
+   clk_disable_unprepare(msp-clk);
kfree(msp);
 
return 0;
@@ -2801,13 +2805,12 @@ static int mv643xx_eth_probe(struct platform_device 
*pdev)
 * it to override the default.
 */
mp-t_clk = 13300;
-#if defined(CONFIG_HAVE_CLK)
-   mp-clk = clk_get(pdev-dev, (pdev-id ? 1 : 0));
+   mp-clk = devm_clk_get(pdev-dev, NULL);
if (!IS_ERR(mp-clk)) {
clk_prepare_enable(mp-clk);
mp-t_clk = clk_get_rate(mp-clk);
}
-#endif
+
set_params(mp, pd);
netif_set_real_num_tx_queues(dev, mp-txq_count);
netif_set_real_num_rx_queues(dev, mp-rxq_count);
@@ -2889,12 +2892,8 @@ static int mv643xx_eth_probe(struct platform_device 
*pdev)
return 0;
 
 out:
-#if defined(CONFIG_HAVE_CLK)
-   if (!IS_ERR(mp-clk)) {
+   if (!IS_ERR(mp-clk))
clk_disable_unprepare(mp-clk);
-   clk_put(mp-clk);
-   }
-#endif
free_netdev(dev);
 
return err;
@@ -2909,12 +2908,8 @@ static int mv643xx_eth_remove(struct platform_device 
*pdev)
phy_detach(mp-phy);
cancel_work_sync(mp-tx_timeout_task);
 
-#if defined(CONFIG_HAVE_CLK)
-   if (!IS_ERR(mp-clk)) {
+   if (!IS_ERR(mp-clk))
clk_disable_unprepare(mp-clk);
-   clk_put(mp-clk);
-   }
-#endif
 
free_netdev(mp-dev);
 
-- 
1.7.10.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] net: mv643xx_eth: Add GRO support

This patch adds GRO support to mv643xx_eth by making it invoke
napi_gro_receive instead of netif_receive_skb.

Signed-off-by: Soeren Moch sm...@web.de
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: David S. Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Dale Farnsworth d...@farnsworth.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/net/ethernet/marvell/mv643xx_eth.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 305038f..c850d04 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
lro_receive_skb(rxq-lro_mgr, skb, (void *)cmd_sts);
lro_flush_needed = 1;
} else
-   netif_receive_skb(skb);
+   napi_gro_receive(mp-napi, skb);
 
continue;
 
-- 
1.7.10.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] net: mv643xx_eth: Add GRO support

On Thu, Apr 11, 2013 at 3:13 PM, Willy Tarreau w...@1wt.eu wrote:
 On Thu, Apr 11, 2013 at 02:40:23PM +0200, Sebastian Hesselbarth wrote:
 This patch adds GRO support to mv643xx_eth by making it invoke
 napi_gro_receive instead of netif_receive_skb.

 Signed-off-by: Soeren Moch sm...@web.de
 Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
 ---
 Cc: David S. Miller da...@davemloft.net
 Cc: Lennert Buytenhek buyt...@wantstofly.org
 Cc: Andrew Lunn and...@lunn.ch
 Cc: Jason Cooper ja...@lakedaemon.net
 Cc: Florian Fainelli flor...@openwrt.org
 Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
 Cc: Paul Mackerras pau...@samba.org
 Cc: Dale Farnsworth d...@farnsworth.org
 Cc: net...@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linuxppc-...@lists.ozlabs.org
 Cc: linux-kernel@vger.kernel.org
 ---
  drivers/net/ethernet/marvell/mv643xx_eth.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
 b/drivers/net/ethernet/marvell/mv643xx_eth.c
 index 305038f..c850d04 100644
 --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
 +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
 @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
   lro_receive_skb(rxq-lro_mgr, skb, (void *)cmd_sts);
   lro_flush_needed = 1;
   } else
 - netif_receive_skb(skb);
 + napi_gro_receive(mp-napi, skb);

   continue;

 I remember having experimented with this on 3.6 a few months ago with this
 driver and finally switching back to something like this instead which
 showed better performance on my tests :

if (skb-ip_summed == CHECKSUM_UNNECESSARY)
napi_gro_receive(napi, skb);
else
netif_receive_skb(skb);

 Unfortunately I don't have more details as my commit message was rather
 short due to this resulting from experimentation. Did you verify that
 you did not lose any performance in various workloads ? I was playing
 with bridges at this time, it's possible that I got better performance
 on bridging with netif_receive_skb() than with napi_gro_receive().

Hi Willy,

I did some simple tests on Dove/Cubox with 'netperf -cCD' and
gso/gro/lro options on
mv643xx_eth. The tests may not be sufficient, as I am not that into
net performance
testing.

I tried todays net-next on top of 3.9-rc6 without any gro patch, with
the initial
patch (Soeren) and your proposed patch (Willy). The results show that
both patches
allow a significant increase in throughput compared to
netif_receive_skb (!gro, !lro)
alone. Having gro with lro disabled gives some 2% more throughput
compared to lro only.

Sebastian

Recv   SendSend  Utilization   Service Demand
Socket Socket  Message  Elapsed  Send Recv SendRecv
Size   SizeSize Time Throughput  localremote   local   remote
bytes  bytes   bytessecs.10^6bits/s  % S  % S  us/KB   us/KB

 87380  16384  1638410.02   615.65   19.1599.905.097
13.293 (3.9-rc6: gso)
 87380  16384  1638410.02   615.82   19.0599.905.067
13.289 (3.9-rc6: gso, gro)
 87380  16384  1638410.03   747.44   23.1799.805.079
10.938 (3.9-rc6: gso, lro)
 87380  16384  1638410.02   745.28   22.5799.804.963
10.970 (3.9.rc6: gso, gro, lro)

 87380  16384  1638410.02   600.34   19.1099.905.211
13.632 (3.9-rc6+soeren: gso)
 87380  16384  1638410.02   764.23   23.4299.805.021
10.698 (3.9-rc6+soeren: gso, gro)
 87380  16384  1638410.02   749.81   23.1399.805.055
10.904 (3.9-rc6+soeren: gso, lro)
 87380  16384  1638410.02   745.84   22.3499.804.907
10.962 (3.9.rc6+soeren: gso, gro, lro)

 87380  16384  1638410.02   605.79   18.79100.00   5.082
13.523 (3.9-rc6+willy: gso)
 87380  16384  1638410.02   765.64   24.6899.805.281
10.678 (3.9-rc6+willy: gso, gro)
 87380  16384  1638410.02   750.30   26.0299.805.682
10.897 (3.9-rc6+willy: gso, lro)
 87380  16384  1638410.03   749.40   21.8699.804.778
10.910 (3.9.rc6+willy: gso, gro, lro)
--
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] net: mv643xx_eth: Add GRO support

On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau w...@1wt.eu wrote:
 On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
 I tried todays net-next on top of 3.9-rc6 without any gro patch, with
 the initial
 patch (Soeren) and your proposed patch (Willy). The results show that
 both patches
 allow a significant increase in throughput compared to
 netif_receive_skb (!gro, !lro)
 alone. Having gro with lro disabled gives some 2% more throughput
 compared to lro only.

 Indeed this is consistent with my memories, since Eric improved the
 GRO path, it became faster than LRO on this chip.

I don't have a strong opinion on whether Soeren's or your proposal should
be submitted. But I insist on having one of them in, as GRO significantly
improves the common use case, is enabled by default, and not as
constrained as LRO.

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] net: mv643xx_eth: Add GRO support

On Thu, Apr 11, 2013 at 5:32 PM, Willy Tarreau w...@1wt.eu wrote:
 On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
 I don't have a strong opinion on whether Soeren's or your proposal should
 be submitted. But I insist on having one of them in, as GRO significantly
 improves the common use case, is enabled by default, and not as
 constrained as LRO.

 I agree, use yours first, but we should keep an eye on this. Since you have
 everything to run a test, please try to see if you can get netperf to run
 over IPv6, I'm sure the NIC doesn't handle it.

Willy,

out of curiosity I replayed all tests using netperf/netserver with -6 which
enables ipv6. The overall results remain quite the same here:
enabling support for GRO gives a huge improvement in achievable
throughput, and the difference between Soeren's and your patch is
neglectible.

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] net: mv643xx_eth: Add GRO support


On 04/11/2013 07:55 PM, Ben Hutchings wrote:

On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:

This patch adds GRO support to mv643xx_eth by making it invoke
napi_gro_receive instead of netif_receive_skb.


The inet_lro support should be removed at the same time; inet_lro is now
deprecated and there should be no need to keep both of them.


Ben,

I agree on removing it asap, but I also like to see GRO support
in. Maybe, we postpone lro removal just a little bit. I have just
started to look at mv643xx_eth and remember Marvell Orion SoCs are
not the only platform using it. I haven't heard a single word from
ppc guys, yet.

Willy just posted an experimental patch to remove lro. I'll have
a look at it and test it out on Dove.

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/

[PATCH] net: mv643xx_eth: remove deprecated inet_lro support

With recent support for GRO, there is no need to keep both LRO and
GRO. This patch therefore removes the deprecated inet_lro support
from mv643xx_eth. This is work is based on an experimental patch
provided by Eric Dumazet and Willy Tarreau.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Based-on-patch-by: Eric Dumazet eric.duma...@gmail.com
Based-on-patch-by: Willy Tarreau w...@1wt.eu
---
Note: This patch is based upon recent cleanup patches and GRO support
patch for mv643xx_eth.

Cc: David S. Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Dale Farnsworth d...@farnsworth.org
Cc: Ben Hutchings bhutchi...@solarflare.com
Cc: Soeren Moch sm...@web.de
Cc: Eric Dumazet eric.duma...@gmail.com
Cc: Willy Tarreau w...@1wt.eu
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/net/ethernet/marvell/mv643xx_eth.c |   97 +---
 1 file changed, 3 insertions(+), 94 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index c850d04..d0afeea 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -56,8 +56,8 @@
 #include linux/phy.h
 #include linux/mv643xx_eth.h
 #include linux/io.h
+#include linux/interrupt.h
 #include linux/types.h
-#include linux/inet_lro.h
 #include linux/slab.h
 #include linux/clk.h
 
@@ -316,12 +316,6 @@ struct mib_counters {
u32 rx_overrun;
 };
 
-struct lro_counters {
-   u32 lro_aggregated;
-   u32 lro_flushed;
-   u32 lro_no_desc;
-};
-
 struct rx_queue {
int index;
 
@@ -335,9 +329,6 @@ struct rx_queue {
dma_addr_t rx_desc_dma;
int rx_desc_area_size;
struct sk_buff **rx_skb;
-
-   struct net_lro_mgr lro_mgr;
-   struct net_lro_desc lro_arr[8];
 };
 
 struct tx_queue {
@@ -373,8 +364,6 @@ struct mv643xx_eth_private {
spinlock_t mib_counters_lock;
struct mib_counters mib_counters;
 
-   struct lro_counters lro_counters;
-
struct work_struct tx_timeout_task;
 
struct napi_struct napi;
@@ -503,42 +492,12 @@ static void txq_maybe_wake(struct tx_queue *txq)
}
 }
 
-
-/* rx napi **/
-static int
-mv643xx_get_skb_header(struct sk_buff *skb, void **iphdr, void **tcph,
-  u64 *hdr_flags, void *priv)
-{
-   unsigned long cmd_sts = (unsigned long)priv;
-
-   /*
-* Make sure that this packet is Ethernet II, is not VLAN
-* tagged, is IPv4, has a valid IP header, and is TCP.
-*/
-   if ((cmd_sts  (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-  RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_MASK |
-  RX_PKT_IS_VLAN_TAGGED)) !=
-   (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_TCP_IPV4))
-   return -1;
-
-   skb_reset_network_header(skb);
-   skb_set_transport_header(skb, ip_hdrlen(skb));
-   *iphdr = ip_hdr(skb);
-   *tcph = tcp_hdr(skb);
-   *hdr_flags = LRO_IPV4 | LRO_TCP;
-
-   return 0;
-}
-
 static int rxq_process(struct rx_queue *rxq, int budget)
 {
struct mv643xx_eth_private *mp = rxq_to_mp(rxq);
struct net_device_stats *stats = mp-dev-stats;
-   int lro_flush_needed;
int rx;
 
-   lro_flush_needed = 0;
rx = 0;
while (rx  budget  rxq-rx_desc_count) {
struct rx_desc *rx_desc;
@@ -599,12 +558,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
skb-ip_summed = CHECKSUM_UNNECESSARY;
skb-protocol = eth_type_trans(skb, mp-dev);
 
-   if (skb-dev-features  NETIF_F_LRO 
-   skb-ip_summed == CHECKSUM_UNNECESSARY) {
-   lro_receive_skb(rxq-lro_mgr, skb, (void *)cmd_sts);
-   lro_flush_needed = 1;
-   } else
-   napi_gro_receive(mp-napi, skb);
+   napi_gro_receive(mp-napi, skb);
 
continue;
 
@@ -624,9 +578,6 @@ err:
dev_kfree_skb(skb);
}
 
-   if (lro_flush_needed)
-   lro_flush_all(rxq-lro_mgr);
-
if (rx  budget)
mp-work_rx = ~(1  rxq-index);
 
@@ -1118,26 +1069,6 @@ static struct net_device_stats 
*mv643xx_eth_get_stats(struct net_device *dev)
return stats;
 }
 
-static void mv643xx_eth_grab_lro_stats(struct mv643xx_eth_private *mp)
-{
-   u32 lro_aggregated = 0;
-   u32 lro_flushed = 0;
-   u32 lro_no_desc = 0;
-   int i;
-
-   for (i = 0; i  mp-rxq_count; i

Re: [PATCH] net: mv643xx_eth: remove deprecated inet_lro support


On 04/11/2013 09:46 PM, Eric Dumazet wrote:

On Thu, 2013-04-11 at 21:11 +0200, Sebastian Hesselbarth wrote:

With recent support for GRO, there is no need to keep both LRO and
GRO. This patch therefore removes the deprecated inet_lro support
from mv643xx_eth. This is work is based on an experimental patch
provided by Eric Dumazet and Willy Tarreau.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
Based-on-patch-by: Eric Dumazeteric.duma...@gmail.com
Based-on-patch-by: Willy Tarreauw...@1wt.eu
---
Note: This patch is based upon recent cleanup patches and GRO support
patch for mv643xx_eth.

Cc: David S. Millerda...@davemloft.net
Cc: Lennert Buytenhekbuyt...@wantstofly.org
Cc: Andrew Lunnand...@lunn.ch
Cc: Jason Cooperja...@lakedaemon.net
Cc: Florian Fainelliflor...@openwrt.org
Cc: Benjamin Herrenschmidtb...@kernel.crashing.org
Cc: Paul Mackerraspau...@samba.org
Cc: Dale Farnsworthd...@farnsworth.org
Cc: Ben Hutchingsbhutchi...@solarflare.com
Cc: Soeren Mochsm...@web.de
Cc: Eric Dumazeteric.duma...@gmail.com
Cc: Willy Tarreauw...@1wt.eu
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
  drivers/net/ethernet/marvell/mv643xx_eth.c |   97 +---
  1 file changed, 3 insertions(+), 94 deletions(-)


Seems fine to me, but you also could remove select INET_LRO
from drivers/net/ethernet/marvell/Kconfig


Ok, I will wait for tomorrow to see if there are more objections and
respin a v2.

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/

[PATCH v2] net: mv643xx_eth: remove deprecated inet_lro support

2013-04-12 Thread Sebastian Hesselbarth

With recent support for GRO, there is no need to keep both LRO and
GRO. This patch therefore removes the deprecated inet_lro support
from mv643xx_eth. This is work is based on an experimental patch
provided by Eric Dumazet and Willy Tarreau.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Based-on-patch-by: Eric Dumazet eric.duma...@gmail.com
Based-on-patch-by: Willy Tarreau w...@1wt.eu
---
Changes from v1:
- also remove INET_LRO from Kconfig (Reported by Eric Dumazet)

Cc: David S. Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Florian Fainelli flor...@openwrt.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Dale Farnsworth d...@farnsworth.org
Cc: Ben Hutchings bhutchi...@solarflare.com
Cc: Soeren Moch sm...@web.de
Cc: Eric Dumazet eric.duma...@gmail.com
Cc: Willy Tarreau w...@1wt.eu
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/net/ethernet/marvell/Kconfig   |1 -
 drivers/net/ethernet/marvell/mv643xx_eth.c |   97 +---
 2 files changed, 3 insertions(+), 95 deletions(-)

diff --git a/drivers/net/ethernet/marvell/Kconfig 
b/drivers/net/ethernet/marvell/Kconfig
index 5170ecb..0051f0e 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -21,7 +21,6 @@ if NET_VENDOR_MARVELL
 config MV643XX_ETH
tristate Marvell Discovery (643XX) and Orion ethernet support
depends on (MV64X60 || PPC32 || PLAT_ORION)  INET
-   select INET_LRO
select PHYLIB
select MVMDIO
---help---
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index c850d04..d0afeea 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -56,8 +56,8 @@
 #include linux/phy.h
 #include linux/mv643xx_eth.h
 #include linux/io.h
+#include linux/interrupt.h
 #include linux/types.h
-#include linux/inet_lro.h
 #include linux/slab.h
 #include linux/clk.h
 
@@ -316,12 +316,6 @@ struct mib_counters {
u32 rx_overrun;
 };
 
-struct lro_counters {
-   u32 lro_aggregated;
-   u32 lro_flushed;
-   u32 lro_no_desc;
-};
-
 struct rx_queue {
int index;
 
@@ -335,9 +329,6 @@ struct rx_queue {
dma_addr_t rx_desc_dma;
int rx_desc_area_size;
struct sk_buff **rx_skb;
-
-   struct net_lro_mgr lro_mgr;
-   struct net_lro_desc lro_arr[8];
 };
 
 struct tx_queue {
@@ -373,8 +364,6 @@ struct mv643xx_eth_private {
spinlock_t mib_counters_lock;
struct mib_counters mib_counters;
 
-   struct lro_counters lro_counters;
-
struct work_struct tx_timeout_task;
 
struct napi_struct napi;
@@ -503,42 +492,12 @@ static void txq_maybe_wake(struct tx_queue *txq)
}
 }
 
-
-/* rx napi **/
-static int
-mv643xx_get_skb_header(struct sk_buff *skb, void **iphdr, void **tcph,
-  u64 *hdr_flags, void *priv)
-{
-   unsigned long cmd_sts = (unsigned long)priv;
-
-   /*
-* Make sure that this packet is Ethernet II, is not VLAN
-* tagged, is IPv4, has a valid IP header, and is TCP.
-*/
-   if ((cmd_sts  (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-  RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_MASK |
-  RX_PKT_IS_VLAN_TAGGED)) !=
-   (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_TCP_IPV4))
-   return -1;
-
-   skb_reset_network_header(skb);
-   skb_set_transport_header(skb, ip_hdrlen(skb));
-   *iphdr = ip_hdr(skb);
-   *tcph = tcp_hdr(skb);
-   *hdr_flags = LRO_IPV4 | LRO_TCP;
-
-   return 0;
-}
-
 static int rxq_process(struct rx_queue *rxq, int budget)
 {
struct mv643xx_eth_private *mp = rxq_to_mp(rxq);
struct net_device_stats *stats = mp-dev-stats;
-   int lro_flush_needed;
int rx;
 
-   lro_flush_needed = 0;
rx = 0;
while (rx  budget  rxq-rx_desc_count) {
struct rx_desc *rx_desc;
@@ -599,12 +558,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
skb-ip_summed = CHECKSUM_UNNECESSARY;
skb-protocol = eth_type_trans(skb, mp-dev);
 
-   if (skb-dev-features  NETIF_F_LRO 
-   skb-ip_summed == CHECKSUM_UNNECESSARY) {
-   lro_receive_skb(rxq-lro_mgr, skb, (void *)cmd_sts);
-   lro_flush_needed = 1;
-   } else
-   napi_gro_receive(mp-napi, skb);
+   napi_gro_receive(mp-napi, skb);
 
continue;
 
@@ -624,9 +578,6 @@ err:
dev_kfree_skb(skb

Re: [PATCH] clk: si5351: Add gapless tuning for SI5351 PLL

2013-04-12 Thread Sebastian Hesselbarth


On 04/12/2013 08:38 PM, Mike Turquette wrote:

Quoting Michal Bachraty (2013-04-09 01:26:15)

For gapless tuning, there is no need for PLL reset and clkout power-down
when tuning output. silabs,gapless-tuning parameter enables gapless tuning
for specific clock output.

Signed-off-by: Michal Bachratymichal.bachr...@streamunlimited.com


Hi Michal,

This did not apply cleanly on the latest (v8) si5351 clk driver.  Can
you refresh it?  I do not plan on taking any more patches for 3.10 after
3.9-rc7 drops (likely on Sunday or Monday).  So this patch may need to
wait until after the merge window.


Mike,

I have integrated the above function into clk-si5351 during development
(see clk-si5351 changelog from v6-v7). I think we can drop this patch,
as Michal added his Tested-by to clk-si5351.

Regards,
  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: dove: fix Dove cpu type from V7 to PJ4

2013-03-28 Thread Sebastian Hesselbarth


On 03/28/2013 07:14 PM, Russell King - ARM Linux wrote:

On Thu, Mar 28, 2013 at 01:06:54PM -0400, Jason Cooper wrote:

On Sat, Mar 23, 2013 at 04:06:51PM +0100, Sebastian Hesselbarth wrote:

The CPU used in Marvell Dove SoCs is a PJ4 Sheeva core. Using
CONFIG_CPU_PJ4 instead of CONFIG_CPU_V7 will also allow to enable
iWMMXt extensions on Dove.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
---
Cc: Russell Kingli...@arm.linux.org.uk
Cc: Jason Cooperja...@lakedaemon.net
Cc: Andrew Lunnand...@lunn.ch
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
  arch/arm/Kconfig |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Hmmm, I'm getting (with dove_defconfig):

arch/arm/kernel/built-in.o: In function `iwmmxt_do':
/.../arch/arm/kernel/pj4-cp0.c:36: undefined reference to `iwmmxt_task_release'
/.../arch/arm/kernel/pj4-cp0.c:40: undefined reference to `iwmmxt_task_switch'
make: *** [vmlinux] Error 1


Looks to me like PJ4 IWMMXT support wasn't properly tested out when it
was submitted - it's possible to end up with pj4-cp0.c built without
the IWMMXT code that it depends on being built...


Russel, Jason,

do we force iWMMXt on CPU_PJ4 or should there be some #ifdef'ery if 
IWMMXT is not selected?


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 v4] clk: add si5351 i2c common clock driver

2013-04-03 Thread Sebastian Hesselbarth

On Wed, Apr 3, 2013 at 1:46 AM, Mike Turquette mturque...@linaro.org wrote:
 Quoting Sebastian Hesselbarth (2013-03-23 07:46:50)
 diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
 new file mode 100644
 index 000..9d0c210
 --- /dev/null
 +++ b/drivers/clk/clk-si5351.c
 @@ -0,0 +1,1411 @@
 +/*
 + * clk-si5351.c: Silicon Laboratories Si5351A/B/C I2C Clock Generator
 + *
 + * Sebastian Hesselbarth sebastian.hesselba...@gmail.com
 + * Rabeeh Khoury rab...@solid-run.com
 + *
 + * References:
 + * [1] Si5351A/B/C Data Sheet
 + * http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
 + * [2] Manually Generating an Si5351 Register Map
 + * http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf
 + *
 + * This program is free software; you can redistribute  it and/or modify it
 + * under  the terms of  the GNU General  Public License as published by the
 + * Free Software Foundation;  either version 2 of the  License, or (at your
 + * option) any later version.
 + */
 +
 +#include linux/module.h
 +#include linux/kernel.h
 +#include linux/clk-private.h

 I hope that this is supposed to be clk-provider.h.  I don't plan on
 taking in any more clock drivers that depend on clk-private.h.  I didn't
 see any reason for this patch to not use clk-provider.h.

True except for two things:
- The driver sets clk flags for the hierarchy after parsing the DT and
there is no helper __clk_set_flags()
- For single parent clks (pxtal, pclkin) I reuse clk-name for .parent_names

For the latter I would have to add two static char *[1] somewhere, not
a big deal. But the for the flags,
I guess there will be no __clk_set_flags helper? Then I'd have to
parse the DT in advance to have the
correct flags ready at clk registration.

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/

[PATCH v3] clk: add si5351 i2c common clock driver

2013-03-18 Thread Sebastian Hesselbarth

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changes from v2:
- add curly brackets to if-else-statements (Reported by Daniel Mack)
- fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
- fix parameter address calculation for clk6/clk7

Changes from v1:
- remove .is_enabled functions as they read from i2c
  (Reported by Daniel Mack)
- add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
  its own multisync

Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Mike Turquette mturque...@linaro.org
Cc: Stephen Warren swar...@nvidia.com
Cc: Thierry Reding thierry.red...@avionic-design.de
Cc: Dom Cobley popcorn...@gmail.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Andrew Morton a...@linux-foundation.org
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: Daniel Mack zon...@gmail.com
Cc: Jean-Francois Moine moin...@free.fr
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../devicetree/bindings/clock/silabs,si5351.txt|  114 ++
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 drivers/clk/Kconfig|9 +
 drivers/clk/Makefile   |1 +
 drivers/clk/clk-si5351.c   | 1429 
 drivers/clk/clk-si5351.h   |  155 +++
 6 files changed, 1709 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
 create mode 100644 drivers/clk/clk-si5351.c
 create mode 100644 drivers/clk/clk-si5351.h

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt 
b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
new file mode 100644
index 000..f73d2d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -0,0 +1,114 @@
+Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
+
+Reference
+[1] Si5351A/B/C Data Sheet
+http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+
+The Si5351a/b/c are programmable i2c clock generators with upto 8 output
+clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
+3 output clocks are accessible. The internal structure of the clock
+generators can be found in [1].
+
+==I2C device node==
+
+Required properties:
+- compatible: shall be one of silabs,si5351{a,a-msop,b,c}.
+- reg: i2c device address, shall be 0x60 or 0x61.
+- #clock-cells: from common clock binding; shall be set to 1.
+- clocks: from common clock binding; list of parent clock
+  handles, shall be xtal reference clock or xtal and clkin for
+  si5351c only.
+- #address-cells: shall be set to 1.
+- #size-cells: shall be set to 0.
+
+Optional properties:
+- pll-source: pair of (number, source) for each pll. Allows
+  to overwrite clock source of pll A (number=0) or B (number=1).
+
+==Child nodes==
+
+Each of the clock outputs can be overwritten individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, the eeprom configuration is not overwritten.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- clock-source: source clock of the output divider stage N, shall be
+  0 = multisynth N
+  1 = multisynth 0 for output clocks 0-3, else multisynth4
+  2 = xtal
+  3 = clkin (si5351c only)
+- drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
+- multisynth-source: source pll A(0) or B(1) of corresponding multisynth
+  divider.
+- pll-master: boolean, multisynth can change pll frequency.
+
+==Example==
+
+/* 25MHz reference crystal */
+ref25: ref25M {
+   compatible = fixed-clock;
+   #clock-cells = 0;
+   clock-frequency = 2500;
+};
+
+i2c-master-node {
+
+   /* Si5351a msop10 i2c clock generator */
+   si5351a: clock-generator@60 {
+   compatible = silabs,si5351a-msop;
+   reg = 0x60;
+   #address-cells = 1;
+   #size-cells = 0;
+   #clock-cells = 1;
+
+   /* connect xtal input to 25MHz reference */
+   clocks = ref25;
+
+   /* connect xtal input as source of pll0 and pll1 */
+   pll-source = 0 0, 1 0;
+
+   /*
+* overwrite clkout0 configuration with:
+* - 8mA output drive strength

Re: [PATCH] clk: add DT test clock consumer driver

2013-03-19 Thread Sebastian Hesselbarth


On 03/19/2013 02:54 AM, Mike Turquette wrote:

Quoting Arnd Bergmann (2013-03-16 07:56:54)

On Saturday 16 March 2013, Sebastian Hesselbarth wrote:

This driver adds a DT test clock consumer that exposes debugfs files to
enable/disable and set/get rate of the attached programmable clock.
During development of a i2c-attached clock generator I found it useful
to debug the clock generator's internal pll settings by enforcing clock
rates through debugfs.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com


It sounds a little clumsy to have a device driver to match a device that
you create just for matching the driver.

Would it be possible to separate the debugging logic from the platform
device logic? I think it may be useful to have a debugfs or sysfs
inteface for all clocks in the system, even if that is disabled by
default or only available after manually loading a module implementing
that functionality.



I agree that a generic approach is needed here.  I have been meaning to
break the existing debugfs stuff out into clk-debug.c.  I'll do that
soon and maybe you can add a new Kconfig entry for
COMMON_CLK_DEBUG_USERSPACE (or something like that) which implements
this?


Mike,

I agree with you and Arnd about clumsiness and a generic approach, but
this driver is a little different from controlling _all_ clocks within
the tree. It just adds one consumer that can _request_ a new rate.

Nevertheless, I can have a look at clk-debug and adding the functionality.


On the other hand this sort of stuff really scares me.  I know for a
fact that a debug interface to enable/disable clocks and set clock rate
would ship on real devices.  Quite likely some android phones out there
would be controlling hardware clocks from some horrible userspace
utility.

*shudder*


This will happen for sure.


Sebastian, another small nitpick, can you change the enable attribute
to be named prepare_enable?  This more accurately reflects what is
going on.


On a generic approach I would rather have a look at the actual ops that
are provided and name the files accordingly. That will also allow us
_not_ to set the rate of crystal oscillators ;)


I also wonder how simple it would be to add a parent attribute here
that allows one to call clk_set_parent from the debugfs interface?  To
make it easy on you, the interface could accept an integer as the index
of the clk-parents[] array.  This is a bad interface design as it
requires the user to look into the code to know which index corresponds
to which parent clock; however I do not want people to use this
interface for anything other than debug/testing, so I am ok with this
interface being a PITA to use.


Sure, but it will not help much against userspace hardware clock
utilities ;)

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 v3] clk: add si5351 i2c common clock driver

2013-03-20 Thread Sebastian Hesselbarth


On 03/20/2013 01:26 AM, Mike Turquette wrote:

Quoting Sebastian Hesselbarth (2013-03-18 03:43:17)

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
---
Changes from v2:
- add curly brackets to if-else-statements (Reported by Daniel Mack)
- fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
- fix parameter address calculation for clk6/clk7

Changes from v1:
- remove .is_enabled functions as they read from i2c
   (Reported by Daniel Mack)
- add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
   its own multisync



I've just pushed out a new clk-next branch which includes Ulf Hansson's
series to introduce the .is_prepared callback.  Perhaps you can use that
where you were previously using .is_enabled?


Mike,

thanks for the info, but I think having .prepare_enable and regmap caching
is just fine for now. When .is_prepared is in mainline, I will re-add the
callbacks.

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 v3] clk: add si5351 i2c common clock driver

2013-03-21 Thread Sebastian Hesselbarth


On 03/21/2013 07:09 PM, Lars-Peter Clausen wrote:

On 03/18/2013 11:43 AM, Sebastian Hesselbarth wrote:

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com


Hi,

Couple of comments inside.


Lars-Peter,

thanks for the review.


---

[...]

+==Child nodes==
+
+Each of the clock outputs can be overwritten individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, the eeprom configuration is not overwritten.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- clock-source: source clock of the output divider stage N, shall be
+  0 = multisynth N
+  1 = multisynth 0 for output clocks 0-3, else multisynth4
+  2 = xtal
+  3 = clkin (si5351c only)
+- drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
+- multisynth-source: source pll A(0) or B(1) of corresponding multisynth
+  divider.
+- pll-master: boolean, multisynth can change pll frequency.


Custom properties need a vendor prefix.


Good catch, I will add silabs prefix here.


[...]


diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
new file mode 100644
index 000..38540e7
--- /dev/null
+++ b/drivers/clk/clk-si5351.c
@@ -0,0 +1,1429 @@

[...]

+
+/*
+ * Si5351 vxco clock input (Si5351B only)
+ */
+
+static int si5351_vxco_prepare(struct clk_hw *hw)
+{
+   struct si5351_hw_data *hwdata =
+   container_of(hw, struct si5351_hw_data, hw);
+
+   dev_warn(hwdata-drvdata-client-dev, VXCO currently unsupported\n);


Wouldn't it be better to not add the vxco clock if it is not supported?


Hmm, I thought about that already and knew someone will suggest to remove it.
But, IMHO it is better to leave that functions there for two reasons:

1. It is only a small part of one of three supported si5351 variant and doesn't
take much space.

2. The most common user of this driver is a hardware engineer and I want him/her
to help to add support. No warning, no note.

I can make the clock registration fail, if that is what you suggest.


[..]

+
+static const struct of_device_id si5351_dt_ids[] = {
+   { .compatible = silabs,si5351a, .data = (void *)SI5351_VARIANT_A, },
+   { .compatible = silabs,si5351a-msop,
+.data = (void *)SI5351_VARIANT_A3, },
+   { .compatible = silabs,si5351b, .data = (void *)SI5351_VARIANT_B, },
+   { .compatible = silabs,si5351c, .data = (void *)SI5351_VARIANT_C, },
+   { }
+};
+MODULE_DEVICE_TABLE(i2c, si5351_dt_ids);


MODULE_DEVICE_TABLE(of,  


Ack.


+static int si5351_i2c_probe(
+   struct i2c_client *client, const struct i2c_device_id *id)


This should easily fit in one line.


Ack.


+{
+   struct si5351_driver_data *drvdata;
+   struct clk_init_data init;
+   struct clk *clk;
+   const char *parent_names[4];
+   u8 num_parents, num_clocks;
+   int ret, n;
+
+   drvdata = devm_kzalloc(client-dev, sizeof(struct si5351_driver_data),


sizeof(*drvdata) is the preferred way of writing this, same for a few other
similar instances.


Yeah, I will change that.


+  GFP_KERNEL);
+   if (drvdata == NULL) {
+   dev_err(client-dev, unable to allocate driver data\n);
+   return -ENOMEM;
+   }
+

[...]

+   of_clk_add_provider(client-dev.of_node, of_clk_src_onecell_get,
+   drvdata-onecell);


You should check the return value of of_clk_add_provider


Ack.


+
+   dev_info(client-dev, registered si5351 i2c client\n);
+


That's just noise, imagine every driver would print such a line, your bootlog
would be scrolling for hours ;) I'd either remove it or make it dev_dbg


Actually, I understand not to have it, but if you don't want it you can still
boot with quiet, can't you? Having one single line that helps you see it has
been probed helps a lot. But, I don't have a strong opinion on that and can
make it dev_dbg.


+   return 0;
+}
+
+static int si5351_i2c_remove(struct i2c_client *client)
+{
+   i2c_set_clientdata(client, NULL);


This is not required anymore, the core takes care of it these days. I think you
can drop the whole remove callback.


Ok.


+   return 0;
+}
+
+static const struct i2c_device_id si5351_i2c_ids[] = {
+   { silabs,si5351, SI5351_BUS_BASE_ADDR | 0 },
+   { silabs,si5351, SI5351_BUS_BASE_ADDR | 1 },
+   { }
+};


This is not how it is supposed to be used. The second field is not the i2c
address of the device, but device specific data, which you can

Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits

2013-03-21 Thread Sebastian Hesselbarth


On 03/21/2013 10:41 PM, Jason Gunthorpe wrote:

On Thu, Mar 21, 2013 at 10:15:23PM +0100, Thomas Petazzoni wrote:

Dear Jason Gunthorpe,

On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote:


Or, better, locate all the internal registers above 8G and use
contiguous DRAM mapping from 0 -  8GB


I see two potential issues with this idea:

  *) It only works when LPAE is enabled, so we would have to have
 different internal register addresses depending on whether LPAE is
 enabled or not. Probably not impossible, but not very
 straightforward either.


Ideally the internal register space address would come from the DT -
we are getting very close to that on Marvell, I think.. Things like
earlyprintk should ideally early parse the DT, harder I know :(


  *) It would require Linux to change the internal registers address
 (for now the kernel relies on the bootloader). The problem is that
 we can't do it early enough to preserve the earlyprintk
 functionality. Maybe you have suggestions on how to achieve that?


I can't forsee how Linux could do this reprogramming - not only do you
have to move the registers, you'd also have to reprogram the DRAM
bases, while running from the DRAM. Not only does that have to be done
early, but the DT would need to describe the DRAM ranks, and the code
would have to parse it.. On top of that it would have to be very
careful not to wack any DRAM that has already been touched by the
kernel.. Tricky stuff :)


Jason, Lior,

at least for Dove you are missing one important fact:

The Internal Registers Base Address register is within ... the internal
registers. You can't even look it up without knowing where it is.

That doesn't mean we can parse the DT for the current register base
address and move it to where we expect it. But for DRAM, I suggest not
to mess with it. The boot loader is there for a reason.

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 5/5] arm: dts: Convert mvebu device tree files to 64 bits

2013-03-21 Thread Sebastian Hesselbarth


On 03/21/2013 10:31 PM, Arnd Bergmann wrote:

On Thursday 21 March 2013, Thomas Petazzoni wrote:

In the mean time can we do something like:

 soc {
 compatible = simple-bus;
 range =...;

 [... all the peripherals ...]
 };

with the range =...  property converting the peripheral registers
base address (expressed as offsets in the reg =...  properties of the
subnodes) into the absolute physical address?


Yes, that is what Rob suggested you do.


Thomas,

have a look at arch/arm/boot/dts/dove.dtsi, it uses ranges-property
and peripherals encoded as offsets.

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/

[PATCH] ARM: Kirkwood: fix unused mvsdio gpio pins

mvsdio_platform_data allows to pass card detect and write protect gpio
numbers to the driver. Some kirkwood boards don't use both pins as they
are not connected, and don't set the corresponding value in platform_data.

This will leave the unset values in platform_data initialized as 0, which
is in fact a valid gpio pin. mvsdio will grab that pin and configure it as
gpio, which in turn breaks nand controller as mpp0 also carries nand_io2.

This patch fixes the above by initializing unused gpio functions in the
platform_data with an invalid (-1) value.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Reported-by: Soeren Moch sm...@web.de
---
Cc: Soeren Moch sm...@web.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/mach-kirkwood/guruplug-setup.c  |2 ++
 arch/arm/mach-kirkwood/openrd-setup.c|1 +
 arch/arm/mach-kirkwood/rd88f6281-setup.c |1 +
 3 files changed, 4 insertions(+)

diff --git a/arch/arm/mach-kirkwood/guruplug-setup.c 
b/arch/arm/mach-kirkwood/guruplug-setup.c
index 1c6e736..08dd739 100644
--- a/arch/arm/mach-kirkwood/guruplug-setup.c
+++ b/arch/arm/mach-kirkwood/guruplug-setup.c
@@ -53,6 +53,8 @@ static struct mv_sata_platform_data guruplug_sata_data = {
 
 static struct mvsdio_platform_data guruplug_mvsdio_data = {
/* unfortunately the CD signal has not been connected */
+   .gpio_card_detect = -1,
+   .gpio_write_protect = -1,
 };
 
 static struct gpio_led guruplug_led_pins[] = {
diff --git a/arch/arm/mach-kirkwood/openrd-setup.c 
b/arch/arm/mach-kirkwood/openrd-setup.c
index 8ddd69f..6a6eb54 100644
--- a/arch/arm/mach-kirkwood/openrd-setup.c
+++ b/arch/arm/mach-kirkwood/openrd-setup.c
@@ -55,6 +55,7 @@ static struct mv_sata_platform_data openrd_sata_data = {
 
 static struct mvsdio_platform_data openrd_mvsdio_data = {
.gpio_card_detect = 29, /* MPP29 used as SD card detect */
+   .gpio_write_protect = -1,
 };
 
 static unsigned int openrd_mpp_config[] __initdata = {
diff --git a/arch/arm/mach-kirkwood/rd88f6281-setup.c 
b/arch/arm/mach-kirkwood/rd88f6281-setup.c
index c7d93b4..d242231 100644
--- a/arch/arm/mach-kirkwood/rd88f6281-setup.c
+++ b/arch/arm/mach-kirkwood/rd88f6281-setup.c
@@ -69,6 +69,7 @@ static struct mv_sata_platform_data rd88f6281_sata_data = {
 
 static struct mvsdio_platform_data rd88f6281_mvsdio_data = {
.gpio_card_detect = 28,
+   .gpio_write_protect = -1,
 };
 
 static unsigned int rd88f6281_mpp_config[] __initdata = {
-- 
1.7.10.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] ARM: kirkwood: make use of DT mvsdio on guruplug board

Device tree based guruplug boards still use mvsdio platform_data and
kirkwood_sdio_init to enable sdio. DT support for sdio is already there,
so make use of it.

This also fixes mvsdio accidentially breaking nand by configuring mpp0
to gpio, while used also by nand (nand_io2 on mpp0).

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Tested-by: Soeren Moch sm...@web.de
---
Cc: Soeren Moch sm...@web.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Russell King li...@arm.linux.org.uk
Cc: Willy Tarreau w...@1wt.eu
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts |4 
 arch/arm/mach-kirkwood/board-guruplug.c |6 --
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts 
b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
index 9555a86..44fd97d 100644
--- a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
+++ b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
@@ -69,6 +69,10 @@
status = okay;
nr-ports = 1;
};
+
+   mvsdio@9 {
+   status = okay;
+   };
};
 
gpio-leds {
diff --git a/arch/arm/mach-kirkwood/board-guruplug.c 
b/arch/arm/mach-kirkwood/board-guruplug.c
index 0a0df45..a857163 100644
--- a/arch/arm/mach-kirkwood/board-guruplug.c
+++ b/arch/arm/mach-kirkwood/board-guruplug.c
@@ -13,7 +13,6 @@
 #include linux/init.h
 #include linux/mv643xx_eth.h
 #include linux/gpio.h
-#include linux/platform_data/mmc-mvsdio.h
 #include common.h
 
 static struct mv643xx_eth_platform_data guruplug_ge00_data = {
@@ -24,10 +23,6 @@ static struct mv643xx_eth_platform_data guruplug_ge01_data = 
{
.phy_addr   = MV643XX_ETH_PHY_ADDR(1),
 };
 
-static struct mvsdio_platform_data guruplug_mvsdio_data = {
-   /* unfortunately the CD signal has not been connected */
-};
-
 void __init guruplug_dt_init(void)
 {
/*
@@ -35,5 +30,4 @@ void __init guruplug_dt_init(void)
 */
kirkwood_ge00_init(guruplug_ge00_data);
kirkwood_ge01_init(guruplug_ge01_data);
-   kirkwood_sdio_init(guruplug_mvsdio_data);
 }
-- 
1.7.10.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] ARM: kirkwood: add MACH_GURUPLUG_DT to defconfig

This patch just adds the missing MACH_GURUPLUG_DT to kirkwood_defconfig.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Reported-by: Soeren Moch sm...@web.de
---
Cc: Soeren Moch sm...@web.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Russell King li...@arm.linux.org.uk
Cc: Stefan Peter s.pe...@mpl.ch
Cc: Nobuhiro Iwamatsu iwama...@nigauri.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/configs/kirkwood_defconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/kirkwood_defconfig 
b/arch/arm/configs/kirkwood_defconfig
index 13482ea..5e40f96 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -24,6 +24,7 @@ CONFIG_MACH_IB62X0_DT=y
 CONFIG_MACH_TS219_DT=y
 CONFIG_MACH_DOCKSTAR_DT=y
 CONFIG_MACH_GOFLEXNET_DT=y
+CONFIG_MACH_GURUPLUG_DT=y
 CONFIG_MACH_LSXL_DT=y
 CONFIG_MACH_IOMEGA_IX2_200_DT=y
 CONFIG_MACH_KM_KIRKWOOD_DT=y
-- 
1.7.10.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 v4] clk: add si5351 i2c common clock driver

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Tested-by: Daniel Mack zon...@gmail.com
---
Changes from v3:
- add silabs prefix to custom DT properties (Reported by Lars-Peter Clausen)
- use sizeof(*foo) instead of sizeof(struct bar) (Reported by Lars-Peter 
Clausen)
- check return value of of_clk_add_provider (Reported by Lars-Peter Clausen)
- clean up i2c client init (Reported by Lars-Peter Clausen)
- silence successful probe (Suggested by Lars-Peter Clausen)
- make CONFIG_CLK_SI5351 depend on CONFIG_OF

Changes from v2:
- add curly brackets to if-else-statements (Reported by Daniel Mack)
- fix div-by-zero for clk6/clk7 (Reported by Daniel Mack)
- fix parameter address calculation for clk6/clk7

Changes from v1:
- remove .is_enabled functions as they read from i2c
  (Reported by Daniel Mack)
- add CLK_SET_RATE_PARENT on clkout reparent if clkout uses
  its own multisync

Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Mike Turquette mturque...@linaro.org
Cc: Stephen Warren swar...@nvidia.com
Cc: Thierry Reding thierry.red...@avionic-design.de
Cc: Dom Cobley popcorn...@gmail.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Andrew Morton a...@linux-foundation.org
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: Daniel Mack zon...@gmail.com
Cc: Jean-Francois Moine moin...@free.fr
Cc: Lars-Peter Clausen l...@metafoo.de
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../devicetree/bindings/clock/silabs,si5351.txt|  114 ++
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 drivers/clk/Kconfig|   10 +
 drivers/clk/Makefile   |1 +
 drivers/clk/clk-si5351.c   | 1411 
 drivers/clk/clk-si5351.h   |  155 +++
 6 files changed, 1692 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
 create mode 100644 drivers/clk/clk-si5351.c
 create mode 100644 drivers/clk/clk-si5351.h

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt 
b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
new file mode 100644
index 000..cc37465
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -0,0 +1,114 @@
+Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
+
+Reference
+[1] Si5351A/B/C Data Sheet
+http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+
+The Si5351a/b/c are programmable i2c clock generators with upto 8 output
+clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
+3 output clocks are accessible. The internal structure of the clock
+generators can be found in [1].
+
+==I2C device node==
+
+Required properties:
+- compatible: shall be one of silabs,si5351{a,a-msop,b,c}.
+- reg: i2c device address, shall be 0x60 or 0x61.
+- #clock-cells: from common clock binding; shall be set to 1.
+- clocks: from common clock binding; list of parent clock
+  handles, shall be xtal reference clock or xtal and clkin for
+  si5351c only.
+- #address-cells: shall be set to 1.
+- #size-cells: shall be set to 0.
+
+Optional properties:
+- silabs,pll-source: pair of (number, source) for each pll. Allows
+  to overwrite clock source of pll A (number=0) or B (number=1).
+
+==Child nodes==
+
+Each of the clock outputs can be overwritten individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, the eeprom configuration is not overwritten.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- silabs,clock-source: source clock of the output divider stage N, shall be
+  0 = multisynth N
+  1 = multisynth 0 for output clocks 0-3, else multisynth4
+  2 = xtal
+  3 = clkin (si5351c only)
+- silabs,drive-strength: output drive strength in mA, shall be one of 
{2,4,6,8}.
+- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
+  divider.
+- silabs,pll-master: boolean, multisynth can change pll frequency.
+
+==Example==
+
+/* 25MHz reference crystal */
+ref25: ref25M {
+   compatible = fixed-clock;
+   #clock-cells = 0;
+   clock-frequency = 2500;
+};
+
+i2c-master-node {
+
+   /* Si5351a msop10 i2c clock generator */
+   si5351a: clock-generator

[PATCH] ARM: dove: fix Dove cpu type from V7 to PJ4

The CPU used in Marvell Dove SoCs is a PJ4 Sheeva core. Using
CONFIG_CPU_PJ4 instead of CONFIG_CPU_V7 will also allow to enable
iWMMXt extensions on Dove.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Russell King li...@arm.linux.org.uk
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c3bdce..4fc9bca 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -556,7 +556,7 @@ config ARCH_IXP4XX
 config ARCH_DOVE
bool Marvell Dove
select ARCH_REQUIRE_GPIOLIB
-   select CPU_V7
+   select CPU_PJ4
select GENERIC_CLOCKEVENTS
select MIGHT_HAVE_PCI
select PINCTRL
-- 
1.7.10.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: Kirkwood: fix unused mvsdio gpio pins


On 03/23/2013 04:17 PM, Thomas Petazzoni wrote:

On Sat, 23 Mar 2013 13:56:58 +0100, Sebastian Hesselbarth wrote:

mvsdio_platform_data allows to pass card detect and write protect gpio
numbers to the driver. Some kirkwood boards don't use both pins as
they are not connected, and don't set the corresponding value in
platform_data.

This will leave the unset values in platform_data initialized as 0,
which is in fact a valid gpio pin. mvsdio will grab that pin and
configure it as gpio, which in turn breaks nand controller as mpp0
also carries nand_io2.

This patch fixes the above by initializing unused gpio functions in
the platform_data with an invalid (-1) value.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
Reported-by: Soeren Mochsm...@web.de


This somewhat conflicts with the patch I've submitted on the mvsdio
driver to exclude 0 as a valid GPIO, see
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/157157.html.
This patch ensures that the mvsdio driver behaves as it was behaving
before 3.9 as far as legacy probing is concerned.


Thomas,

I understand that you proposed patch fixes mvsdio grab mpp0 by accident.
But what if you have a kirkwood board where cd-gpio _is_ connected to mpp0?

Not that there is one I know of, but IMHO the only useful patch is to
set passed values to an invalid gpio number.


That said, I have nothing against explicitly setting those GPIO values
to an invalid value. Maybe -EINVAL would make more sense than just -1 ?


Every invalid gpio number will be sufficient. But -EINVAL doesn't make
more sense than -1 does. Having no cd-gpio is not an Invalid argument.

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: Kirkwood: fix unused mvsdio gpio pins


On 03/23/2013 05:30 PM, Thomas Petazzoni wrote:

Dear Sebastian Hesselbarth,

On Sat, 23 Mar 2013 16:25:54 +0100, Sebastian Hesselbarth wrote:


I understand that you proposed patch fixes mvsdio grab mpp0 by accident.
But what if you have a kirkwood board where cd-gpio _is_ connected to mpp0?


It didn't work with the existing mvsdio driver, so the purpose of my
patch was merely to restore the old behavior, in order to avoid having
to change all the instances of mvsdio_platform_data, knowing that those
would anyway go away as we convert boards to the Device Tree.


Thomas,

I agree both approaches fix the same issue. I haven't seen your patch
earlier and was just proposing a patch for the same issue. You or Jason
are free to choose whatever patch you like.


Not that there is one I know of, but IMHO the only useful patch is to
set passed values to an invalid gpio number.


To me, it remains a fragile way of doing things. Let's say tomorrow you
add a new int foo_gpio field in mvsdio_platform_data. The whole
purpose of C99 struct initializers is that you don't have to change all
instances of the structure because all fields that are not initialized
with .field  =value  are guaranteed to be zero. If you need to set
foo_gpio to -1 everywhere when you add this field, it becomes quite
annoying.


I understand that struct initialization with zero is done for a purpose.
But gpio = 0 is a valid gpio number and engineers will always count from
zero ;)

Given the fact that .gpio = 0 is valid, you would have to add some
.really_use_that_number_i_was_too_lazy_to_set = 1.. but mvsdio_plaform_data
won't stay long as you already pointed out, and I am happy with any fix
for the issue.


That said, I have nothing against explicitly setting those GPIO values
to an invalid value. Maybe -EINVAL would make more sense than just -1 ?


Every invalid gpio number will be sufficient. But -EINVAL doesn't make
more sense than -1 does. Having no cd-gpio is not an Invalid argument.


It's just that I've seen -EINVAL being used on some other platforms, at
least mach-at91/, but I agree it's not an invalid argument per se.


If you don't like -1, you can choose -ENOENT. But -1 has been used for ages
as invalid or unused so it was my first guess.

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 v3] clk: add si5351 i2c common clock driver

2013-03-25 Thread Sebastian Hesselbarth

On Wed, Mar 20, 2013 at 5:48 PM, Daniel Mack zon...@gmail.com wrote:
On 20.03.2013 14:55, michal.bachr...@gmail.com wrote:
Thanks for writing this driver! I have tested your si5351 clock
driver and his tuning capabilities. It works well, it generates
proper clock frequency, but when new frequency is generated, little
clock gap (1ms) is generated. Si5351 datasheet and WP claims, clock
tuning can be without gaps -
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5350-51-Frequency-Shifting-WP.pdf

I made some tests with Si5351A chip and I found that when tuning touch
only Multisynth registers, it can tune without gaps. There is no need
for soft PLL reset. I found also, accessing Multisynth registers is not
atomic, so there can be another frequency at output, while not all
registers are written. Writing only to one register seems to be atomic.

Michael,

if you don't configure the clock output to modify the pll, changing output
frequency will not alter pll config and there will be no reset of pll.

Yeah, but limiting possible changes to the PLLs to one single register
also means that you cannot offer to generate all the frequencies any
more. What could probably be done is refine the algorithm so that it
stays 'as close as possible' to the former values, but I'm not sure how
much work that implies.

Can you provide a patch against Sebastian's v3 to do that? Then it can
be cleanly applied on top of the driver later.

Ack. Feel free to post a patch on top of v4 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: Question about fixed-clock

2013-03-09 Thread Sebastian Hesselbarth


On 03/08/2013 02:30 PM, Daniel Mack wrote:

On 08.03.2013 03:15, Mark Brown wrote:

On Thu, Mar 07, 2013 at 11:31:59PM +0100, Daniel Mack wrote:

On 07.03.2013 19:42, Afzal Mohammed wrote:
Grep'ing through arch/arm, it seems that the imx arch does the same
thing my patch does, but I could also imagine that it should be done
somewhere from the DT core. I copied Grant, Rob and Mark for more comments.


Wouldn't this just be set up by the DT in the same way that other
off-SoC hardware is?


 [...]


I don't know the clock framework well enough, but it seems that either
all DT boards are supposed to do the same in their generic bits (which
sounds like a lot of code duplication), or the fixed-clock driver should
behave like any other driver wrt its probing from DT. I'm open to
suggestions :)


Daniel,

the current common clock framework does not register any of its core
clocks, i.e. fixed-clock, et.al. I haven't had a look at the way regulator
api registers them. But if you find the way reasonable, why not propose
a patch for ccf that registers at least a set of the core clocks itself?

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: memory leak and other oddness in pinctrl-mvebu.c

2013-03-09 Thread Sebastian Hesselbarth


On 03/08/2013 04:58 PM, David Woodhouse wrote:

I'm just looking through the kernel for krealloc() abuse, and the
'interesting' code in mvebu_pinctrl_build_functions() came to my
attention.

First it allocates an array 'funcs' as follows:
/* we allocate functions for number of pins and hope
 * there are less unique functions than pins available */
funcs = devm_kzalloc(pdev-dev, pctl-desc.npins *
 sizeof(struct mvebu_pinctrl_function), GFP_KERNEL);

(note: s/less/fewer/ in the comment).

Then it populates the array, seemly trusting to its hope and just
going off the end of the array if there are more unique functions than
pins?

And then finally it reallocates the array to the correct size:

/* with the number of unique functions and it's groups known,
   reallocate functions and assign group names */
funcs = krealloc(funcs, num * sizeof(struct mvebu_pinctrl_function),
 GFP_KERNEL);

(note: s/it's/its/)

So... if krealloc fails, we *leak* the originally-allocated 'funcs'.
Except actually we don't because it was allocated with devm_kzalloc() so
that's OK.


David,

the purpose of the above code is to build up a list of unique functions
and the pins supporting this function. This is a requirement of the pinctrl
API and we had a lengthy discussion with Steven and LinusW back then as
the hardware works just the other way round, i.e. a list of pins with a
set of functions.

The idea was to first assume there will be no more unique functions than
pins available and use that array to store the unique function names. After
that shrink the array to the actual number of unique functions. BTW, this
array isn't used within the driver at all, except to fulfill API requirements
for debugfs.


If krealloc *succeeds* then I think we should get a double-free because
it doesn't free the old 'funcs' via devm_kfree() so when the device is
eventually released, won't devres_release_all() free it again?


I understand that using devm_kzalloc and krealloc will lead to either
double-free or ignored krealloc failure. Is there any other/more correct
way of reallocating that pointer? The fix I would prefer is to allocate
the array but not realloc it to the correct size.


I'm not entirely sure what that krealloc is *for*, anyway. Apart from
retrospectively reallocating the array to the size that we've already
*scribbled* over? Some kind of request for forgiveness, perhaps?

We should probably make the standard kfree() (and hence krealloc())
actually fail when handed pointers which were allocated with
devm_kzalloc()?

This completely untested patch attempts to fix it by counting the
maximum number of functions in advance, then allocating the array at
that size. In practice it may overallocate if there are name collisions
and _add_function() returns -EEXIST. Is that something we really need to
lose sleep over?


I agree that counting all potential unique functions is safe here, but
will lead to overallocation for sure. Actually, the number of unique functions
is known in advance for each SoC but first the information is already there
in what the driver uses for controlling the HW (pins with functions) but with
multiarch kernels in mind, we chose to built that list on runtime.

I don't have a strong opinion on that, but I prefer not to have the list
statically in the SoC specific drivers. I think counting the number of
unique functions for each SoC specific driver once and verify the above
heuristic (fewer unique functions than pins) is still valid. Then drop
the krealloc and leave the array the way it is allocated on devm_kzalloc.

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: memory leak and other oddness in pinctrl-mvebu.c

2013-03-09 Thread Sebastian Hesselbarth

David,

I will not be able to test before mid-week ealiest. I added Andrew Lunn to
the list. He and Thomas can test your patch for Kirkwood and Armada XP/370
respectively. I will test on Dove asap.

Sebastian

On Sat, Mar 9, 2013 at 8:02 PM, David Woodhouse dw...@infradead.org wrote:
 On Sat, 2013-03-09 at 09:49 +0100, Sebastian Hesselbarth wrote:
 I don't have a strong opinion on that, but I prefer not to have the list
 statically in the SoC specific drivers. I think counting the number of
 unique functions for each SoC specific driver once and verify the above
 heuristic (fewer unique functions than pins) is still valid. Then drop
 the krealloc and leave the array the way it is allocated on devm_kzalloc.

 Yeah. If you stick a check in the loop and make it warn if it *would*
 have run over the end of the array, that sounds like it ought to be
 fine. Something like this, perhaps? Still untested but otherwise
 Signed-off-by: David Woodhouse david.woodho...@intel.com

 diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c 
 b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
 index c689c04..55d55d5 100644
 --- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
 +++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
 @@ -478,7 +478,8 @@ static struct pinctrl_ops mvebu_pinctrl_ops = {
 .dt_free_map = mvebu_pinctrl_dt_free_map,
  };

 -static int _add_function(struct mvebu_pinctrl_function *funcs, const char 
 *name)
 +static int _add_function(struct mvebu_pinctrl_function *funcs, int nr_funcs,
 +const char *name)
  {
 while (funcs-num_groups) {
 /* function already there */
 @@ -487,7 +488,11 @@ static int _add_function(struct mvebu_pinctrl_function 
 *funcs, const char *name)
 return -EEXIST;
 }
 funcs++;
 +   nr_funcs--;
 }
 +   if (!nr_funcs)
 +   return -EOVERFLOW;
 +
 funcs-name = name;
 funcs-num_groups = 1;
 return 0;
 @@ -501,7 +506,7 @@ static int mvebu_pinctrl_build_functions(struct 
 platform_device *pdev,
 int n, s;

 /* we allocate functions for number of pins and hope
 -* there are less unique functions than pins available */
 +* there are fewer unique functions than pins available */
 funcs = devm_kzalloc(pdev-dev, pctl-desc.npins *
  sizeof(struct mvebu_pinctrl_function), 
 GFP_KERNEL);
 if (!funcs)
 @@ -510,26 +515,27 @@ static int mvebu_pinctrl_build_functions(struct 
 platform_device *pdev,
 for (n = 0; n  pctl-num_groups; n++) {
 struct mvebu_pinctrl_group *grp = pctl-groups[n];
 for (s = 0; s  grp-num_settings; s++) {
 +   int ret;
 +
 /* skip unsupported settings on this variant */
 if (pctl-variant 
 !(pctl-variant  grp-settings[s].variant))
 continue;

 /* check for unique functions and count groups */
 -   if (_add_function(funcs, grp-settings[s].name))
 +   ret = _add_function(funcs, pctl-desc.npins,
 +   grp-settings[s].name);
 +   if (ret == -EOVERFLOW)
 +   dev_err(pdev-dev,
 +   More functions than pins(%d)\n,
 +   pctl-desc.npins);
 +   if (ret)
 continue;

 num++;
 }
 }

 -   /* with the number of unique functions and it's groups known,
 -  reallocate functions and assign group names */
 -   funcs = krealloc(funcs, num * sizeof(struct mvebu_pinctrl_function),
 -GFP_KERNEL);
 -   if (!funcs)
 -   return -ENOMEM;
 -
 pctl-num_functions = num;
 pctl-functions = funcs;



 --
 dwmw2

--
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: prevent walking off the end of group array

2013-03-13 Thread Sebastian Hesselbarth


On 03/13/2013 06:35 PM, Jason Cooper wrote:

From: David Woodhousedw...@infradead.org

While investigating (ab)use of krealloc, David found this bug.  It's
unlikely to occur, but now we detect the condition and error out
appropriately.

Signed-off-by: David Woodhousedavid.woodho...@intel.com
Signed-off-by: Jason Cooperja...@lakedaemon.net
---
David, please double check that this is as you intended.  I had to hand-jam it 
in due to some peculiarities on my side.



Jason,

thanks for preparing that patch. I ll test (and Ack) asap but that will not be
before this weekend. If Thomas and Andrew ack it before me, consider it good.

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: dove: Fix typo COMMON_CLK_DOVE

2013-03-05 Thread Sebastian Hesselbarth


On 03/05/2013 10:34 AM, Paul Bolle wrote:

Commit 5b03df9ace680d7cdd34a69dfd85ca5f74159d18 (ARM: dove: switch to
DT clock providers) added select COMMON_CLK_DOVE to Marvell Dove's
Kconfig entry. But there's no Kconfig symbol COMMON_CLK_DOVE, which
makes this select statement a nop. Since the Marvell Dove code includes
linux/clk-provider.h  we can assume that this entry needs to select
COMMON_CLK instead.

Signed-off-by: Paul Bollepebo...@tiscali.nl
---
Untested.

  arch/arm/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5b71469..31acce7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -556,7 +556,7 @@ config ARCH_IXP4XX
  config ARCH_DOVE
bool Marvell Dove
select ARCH_REQUIRE_GPIOLIB
-   select COMMON_CLK_DOVE
+   select COMMON_CLK
select CPU_V7
select GENERIC_CLOCKEVENTS
select MIGHT_HAVE_PCI


Paul,

thanks for the patch but I guess COMMON_CLK_DOVE is a left-over
from early DT experiments with Dove. It should just be removed
from arm/Kconfig.

Thanks for pointing it out, and it would be great to update
your patch accordingly.

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/2] ARM: Dove: Add pinctrl clock to DT

2012-12-01 Thread Sebastian Hesselbarth


On 12/01/2012 07:13 PM, Jason Cooper wrote:

On Sat, Dec 01, 2012 at 06:07:06PM +0100, Linus Walleij wrote:

On Mon, Nov 26, 2012 at 10:18 AM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com  wrote:


During merge of the mvebu patches a clock gate for pinctrl was
lost. This patch just readds the clock gate.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com


Acked-by: Linus Walleijlinus.wall...@linaro.org

So who's supposed to merge this patch? Me? The MVEBU-maintainer?


I'll take it and merge it in once v3.8-rc1 drops.


Linus, Jason,

I agree to take it through Jason's tree but please take v2 of
the patch as there has been a small change in one of the patches.

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] media: rc: gpio-ir-recv: add support for device tree parsing

2013-02-08 Thread Sebastian Hesselbarth

On Fri, Feb 8, 2013 at 6:57 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em Wed, 06 Feb 2013 18:18:22 +0100
 Sebastian Hesselbarth sebastian.hesselba...@gmail.com escreveu:
 On 02/06/2013 02:48 PM, Sylwester Nawrocki wrote:
  On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:
  This patch adds device tree parsing for gpio_ir_recv platform_data and
  the mandatory binding documentation. It basically follows what we already
  have for e.g. gpio_keys. All required device tree properties are OS
  independent but optional properties allow linux specific support for rc
  protocols and maps.
 
  There was a similar patch sent by Matus Ujhelyi but that discussion
  died after the first reviews.
 
  Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
  ---
  ...
  diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt 
  b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
  new file mode 100644
  index 000..937760c
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
  @@ -0,0 +1,20 @@
  +Device-Tree bindings for GPIO IR receiver
  +
  +Required properties:
  +  - compatible = gpio-ir-receiver;
  +  - gpios: OF device-tree gpio specification.
  +
  +Optional properties:
  +  - linux,allowed-rc-protocols: Linux specific u64 bitmask of allowed
  +  rc protocols.
 
  You likely need to specify in these bindings documentation which bit
  corresponds to which RC protocol.
 
  I'm not very familiar with the RC internals, but why it has to be
  specified statically in the device tree, when decoding seems to be
  mostly software defined ? I might be missing something though..

 Sylwester,

 I am not familiar with RC internals either. Maybe somebody with more
 insight in media/rc can clarify the specific needs for the rc subsystem.
 I was just transferring the DT support approach taken by gpio_keys to
 gpio_ir_recv as I will be using it on mach-dove/cubox soon.

 The allowed rc protocol field are there for devices with hardware IR
 support, where only a limited set of remote protocols can be decoded.

 For software decoders RC_BIT_ALL is the proper setup. Users of course
 can change it via sysfs at runtime, or a software decoder may be
 disabled at compilation time by not selecting its CONFIG_* var.

Mauro,

thanks for the clarification! So for v2 of the patch, you all agree on removing
linux,allowed-rc-protocols from device node properties?

  Couldn't this be configured at run time, with all protocols allowed
  as the default ?

 Actually, this is how the internal rc code works. If there is nothing
 defined for allowed_protocols it assumes that all protocols are supported.
 That is why above node properties are optional.

 About the binding documentation of allowed_protocols, rc_map, or the
 default behavior of current linux code, I don't think they will stay
 in-sync for long.

 Why not? The rc_map name is used either by Kernelspace or by Userspace,
 in order to provide the IR keycode name that matches a given keytable.

 There's no plans to change it, even in the long term.

Actually, I wasn't referring to changing names or bitmasks but updating
the binding documentation with new allowed protocols or supported map
names.

For linux,rc-map-name property it should be enough to just write that it
relates to linux rc subsystem rc_map name - how to actually
set it to a useful name is documented in rc subsystem. And if the
property is not set at all, DT parsing in gpio_ir_recv assumes the
subsystem (or gpio_ir_recv platform) default, IIRC rc-none.

I'll respin a v2 without allowed-protocols property soon.

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] media: rc: gpio-ir-recv: add support for device tree parsing

2013-02-08 Thread Sebastian Hesselbarth


On 02/08/2013 10:26 PM, Sylwester Nawrocki wrote:

On 02/08/2013 09:38 PM, Sebastian Hesselbarth wrote:

This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but an optional property allow linux specific support for rc
maps.

There was a similar patch sent by Matus Ujhelyi but that discussion
died after the first reviews.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
---
Changelog

v1-v2:
- get rid of ptr returned by _get_devtree_pdata()
- check for of_node instead for NULL pdata
- remove unneccessary double check for gpios property
- remove unneccessary #ifdef CONFIG_OF around match table

Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Rob Herringrob.herr...@calxeda.com
Cc: Rob Landleyr...@landley.net
Cc: Mauro Carvalho Chehabmche...@redhat.com
Cc: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
Cc: Benoit Thebaudeaubenoit.thebaud...@advansee.com
Cc: David Hardemanda...@hardeman.nu
Cc: Trilok Sonits...@codeaurora.org
Cc: Sylwester Nawrockis.nawro...@samsung.com
Cc: Matus Ujhelyiujhely...@gmail.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
.../devicetree/bindings/media/gpio-ir-receiver.txt | 16 ++
drivers/media/rc/gpio-ir-recv.c | 57 
2 files changed, 73 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/gpio-ir-receiver.txt

diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
new file mode 100644
index 000..8589f30
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -0,0 +1,16 @@
+Device-Tree bindings for GPIO IR receiver
+
+Required properties:
+ - compatible = gpio-ir-receiver;
+ - gpios: OF device-tree gpio specification.


Perhaps:
- compatible: should be gpio-ir-receiver;
- gpios: specifies GPIO used for IR signal reception.
?


Ok, i'll change that.


+
+Optional properties:
+ - linux,rc-map-name: Linux specific remote control map name.
+
+Example node:
+
+ ir: ir-receiver {
+ compatible = gpio-ir-receiver;
+ gpios =gpio0 19 1;
+ linux,rc-map-name = rc-rc6-mce;
+ };
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 4f71a7d..3c62006 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -16,6 +16,7 @@
#includelinux/interrupt.h
#includelinux/gpio.h
#includelinux/slab.h
+#includelinux/of_gpio.h
#includelinux/platform_device.h
#includelinux/irq.h
#includemedia/rc-core.h
@@ -30,6 +31,50 @@ struct gpio_rc_dev {
bool active_low;
};

+#ifdef CONFIG_OF
+/*
+ * Translate OpenFirmware node properties into platform_data
+ */
+static int gpio_ir_recv_get_devtree_pdata(struct device *dev,
+ struct gpio_ir_recv_platform_data *pdata)
+{
+ struct device_node *np = dev-of_node;
+ enum of_gpio_flags flags;
+ int gpio;
+
+ gpio = of_get_gpio_flags(np, 0,flags);
+ if (gpio 0) {
+ if (gpio != -EPROBE_DEFER)
+ dev_err(dev, Failed to get gpio flags, error: %d\n,
+ gpio);


dev_err(dev, Failed to get gpio flags (%d)\n, gpio);
?


Ack.


+ return gpio;
+ }
+
+ pdata-gpio_nr = gpio;
+ pdata-active_low = (flags OF_GPIO_ACTIVE_LOW) ? true : false;


This could be simplified to:

pdata-active_low = (flags  OF_GPIO_ACTIVE_LOW);


Ack.


+ /* probe() takes care of map_name == NULL or allowed_protos == 0 */
+ pdata-map_name = of_get_property(np, linux,rc-map-name, NULL);
+ pdata-allowed_protos = 0;
+
+ return 0;
+}
+
+static struct of_device_id gpio_ir_recv_of_match[] = {
+ { .compatible = gpio-ir-receiver, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, gpio_ir_recv_of_match);
+
+#else /* !CONFIG_OF */
+
+static inline struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)


Please check how it compiles with CONFIG_OF disabled ;)


Grrrml ;) I'll fix that of course...


You could also make it:

#define gpio_ir_recv_get_devtree_pdata (-ENOSYS)


Hmm, does that also play with parameter passing of the
CONFIG_OF gpio_ir_recv_get_devtree_pdata() ?


+{
+ return ERR_PTR(-ENODEV);
+}
+
+#endif
+
static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
{
struct gpio_rc_dev *gpio_dev = dev_id;
@@ -66,6 +111,17 @@ static int gpio_ir_recv_probe(struct platform_device *pdev)
pdev-dev.platform_data;
int rc;

+ if (pdev-dev.of_node) {
+ struct gpio_ir_recv_platform_data *dtpdata =


I think you could use pdata here instead, as previously. But I'm fine with
as it is now as well.


Yeah, but pdata is const and I will change it within _get_devtree_pdata().
I could cast the const away when passing it to gpio_ir_recv_get_devtree_pdata()
but it is almost the same amount of code.. and it is cleaner this way.




+ devm_kzalloc(pdev-dev, sizeof(*dtpdata), GFP_KERNEL);
+ if (!dtpdata)
+ return -ENOMEM;
+ rc

Re: [PATCH v2] media: rc: gpio-ir-recv: add support for device tree parsing

2013-02-08 Thread Sebastian Hesselbarth


On 02/09/2013 01:03 AM, Mauro Carvalho Chehab wrote:

Em Fri,  8 Feb 2013 21:38:07 +0100
Sebastian Hesselbarthsebastian.hesselba...@gmail.com  escreveu:


This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but an optional property allow linux specific support for rc
maps.

There was a similar patch sent by Matus Ujhelyi but that discussion
died after the first reviews.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
---
Changelog

v1-v2:
- get rid of ptr returned by _get_devtree_pdata()
- check for of_node instead for NULL pdata
- remove unneccessary double check for gpios property
- remove unneccessary #ifdef CONFIG_OF around match table

Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Rob Herringrob.herr...@calxeda.com
Cc: Rob Landleyr...@landley.net
Cc: Mauro Carvalho Chehabmche...@redhat.com
Cc: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
Cc: Benoit Thebaudeaubenoit.thebaud...@advansee.com
Cc: David Hardemanda...@hardeman.nu
Cc: Trilok Sonits...@codeaurora.org
Cc: Sylwester Nawrockis.nawro...@samsung.com
Cc: Matus Ujhelyiujhely...@gmail.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
  .../devicetree/bindings/media/gpio-ir-receiver.txt |   16 ++
  drivers/media/rc/gpio-ir-recv.c|   57 
  2 files changed, 73 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/media/gpio-ir-receiver.txt

diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt 
b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
new file mode 100644
index 000..8589f30
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -0,0 +1,16 @@
+Device-Tree bindings for GPIO IR receiver
+
+Required properties:
+   - compatible = gpio-ir-receiver;
+   - gpios: OF device-tree gpio specification.
+
+Optional properties:
+   - linux,rc-map-name: Linux specific remote control map name.
+
+Example node:
+
+   ir: ir-receiver {
+   compatible = gpio-ir-receiver;
+   gpios =gpio0 19 1;
+   linux,rc-map-name = rc-rc6-mce;


Please change this to:
linux,rc-map-name = RC_MAP_RC6_MCE;

(as defined at include/media/rc-map.h).


Mauro,

this is not possible in device tree bindings. Device tree properties
can only carry numeric or string types (and some other stuff) but no
OS specific enumerations. So using strings is the only option here.


The idea of having those strings defined at the same header file is to:


Unfortunately, device tree blobs don't know about linux header files.

That leaves two options:
- allow the user to supply a string of the map in his device tree description
  and risk that there may be a broken map name
- remove linux,rc-map-name from DT binding and let the user configure in
  from user space (which is propably best choice anyway)

I tried both, DT supplied map name and ir-keytable from userspace
both work fine.

Sebastian


- make sure that the same keyboard is spelled at the same way on
all places;

- avoid people to duplicate IR keytables, using different names;

- help userspace to get the right table. In the future, the
plan is to remove all keytables from kernelspace, keeping there just the
name of the keytable. The existing userspace code (ir-keytables, part
of v4l-utils) use the keytable name to dynamically load the right table
in runtime and to switch the IR core to only handle the protocol that
it is associated with the loaded keytable.




--
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] clk: add si5351 i2c common clock driver

2013-02-09 Thread Sebastian Hesselbarth

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Notes:
- During development I used a debugfs clock consumer that I can also
  post if there is interest in it.
- With current (3.8-rc6) common clock framework there is two (minor)
  issues:
  * although clocks are registered with devm_clk_register they are not
removed from the clock tree on unloading. That makes reloading of
clk-si5351 as module impossible.
  * potentially there could be more than one different external si5351
generators but clocks are registered with names that do not refer
to e.g. the device name. Maybe common clock framework should
prepend the device name for each registered clock, i.e. 0-0060.clk0.
That would also avoid name collisions with same clock names from
different drivers (clk0 is likely to be used by others ;))
- The driver has been frequency tested for some common video/audio
  clocks and manages it to tune in every frequency successfully. A
  comparison with silabs windows tool shows a different heuristic
  for vco frequencies. The tests have been comfirmed by visual
  check on an 500MHz oscilloscope but no jitter measurements have
  been carried out. I will provide comparison by email on request.

Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Mike Turquette mturque...@linaro.org
Cc: Stephen Warren swar...@nvidia.com
Cc: Thierry Reding thierry.red...@avionic-design.de
Cc: Dom Cobley popcorn...@gmail.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Andrew Morton a...@linux-foundation.org
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../devicetree/bindings/clock/silabs,si5351.txt|  114 ++
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 drivers/clk/Kconfig|9 +
 drivers/clk/Makefile   |1 +
 drivers/clk/clk-si5351.c   | 1447 
 drivers/clk/clk-si5351.h   |  155 +++
 6 files changed, 1727 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si5351.txt
 create mode 100644 drivers/clk/clk-si5351.c
 create mode 100644 drivers/clk/clk-si5351.h

diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt 
b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
new file mode 100644
index 000..3fa3c3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -0,0 +1,114 @@
+Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
+
+Reference
+[1] Si5351A/B/C Data Sheet
+http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+
+The Si5351a/b/c are programmable i2c clock generators with upto 8 output
+clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
+3 output clocks are accessible. The internal structure of the clock
+generators can be found in [1].
+
+==I2C device node==
+
+Required properties:
+- compatible: shall be one of silabs,si5351{a,a-msop,b,c}.
+- reg: i2c device address, shall be 0x60 or 0x61.
+- #clock-cells: from common clock binding; shall be set to 1.
+- clocks: from common clock binding; list of parent clock
+  handles, shall be xtal reference clock or xtal and clkin for
+  si5351c only.
+- #address-cells: shall be set to 1.
+- #size-cells: shall be set to 0.
+
+Optional properties:
+- pll-source: pair of (number, source) for each pll. Allows
+  to overwrite clock source of pll A (number=0) or B (number=1).
+
+==Child nodes==
+
+Each of the clock outputs can be overwritten individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, the eeprom configuration is not overwritten.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- clock-source: source clock of the output divider stage N, shall be
+  0 = multisynth N
+  1 = multisynth 0 for output clocks 0-3, else multisynth4
+  2 = xtal
+  3 = clkin (si5351c only)
+- drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
+- multisynth-source: source pll A(0) or B(1) of corresponding multisynth
+  divider.
+- pll-master: boolean, multisynth can change pll frequency.
+
+==Example==
+
+/* 25MHz reference crystal */
+ref25: ref25M

Re: [PATCH] clk: add si5351 i2c common clock driver

2013-02-11 Thread Sebastian Hesselbarth


On 02/11/2013 06:46 AM, Mike Turquette wrote:

Quoting Sebastian Hesselbarth (2013-02-09 04:59:32)

This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented. DT
bindings selectively allow to overwrite stored Si5351 configuration
which is very helpful for clock generators with empty eeprom
configuration. Corresponding device tree binding documentation is
also added.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
---
Notes:
- During development I used a debugfs clock consumer that I can also
   post if there is interest in it.


Please do.  I have a set of patches that implement a fake clock subtree
for testing the core framework.  I've been thinking of pushing this to
the list once it is more presentable and your work might fit into that
nicely.


Mike,

then I will clean the debugfs driver and post it together with this
patch for 3.9-rc1 as an individual patch.


- With current (3.8-rc6) common clock framework there is two (minor)
   issues:
   * although clocks are registered with devm_clk_register they are not
 removed from the clock tree on unloading. That makes reloading of
 clk-si5351 as module impossible.


This is a known issue.  clk_unregister is a NOP and defining it has
always been deferred until the day that someone needed it.  Care to
take a crack at it?


Ok. I can have a look at it and propose a patch but that will take a
while as other stuff came in between. But IMHO, preparing/enabling
clocks by clock consumers should increase reference count so referenced
modules cannot be unloaded.. but that I have never had a look at, yet ;)


   * potentially there could be more than one different external si5351
 generators but clocks are registered with names that do not refer
 to e.g. the device name. Maybe common clock framework should
 prepend the device name for each registered clock, i.e. 0-0060.clk0.
 That would also avoid name collisions with same clock names from
 different drivers (clk0 is likely to be used by others ;))


More unfinished work, just like clk_unregister above.  I'm sure you are
aware that clk_register takes struct device *dev as input, but does
nothing with it.  It wouldn't take much to concatenate the device name
and clock name if dev is present.  However a complication here is that
the registration code takes a parent string name to match parents up for
discrete subtrees; how could statically defined data know about the
device name ahead of time?


I see. Wrt the above comment about spare time, would prepending DT
clocks be sufficient? Or/And use a fallback mechanism that first tries
a full match, full match with own device name, and relaxed match for
clock name as it is now?


The above design decision took place before the big DT push we have
today and was short-sighted.  It would be better to change the framework
to rely less on string name lookups and DT is one way out of that.

3.8-rc7 is already out and I don't plan to take anything that hasn't
already been submitted for 3.9 now.  Can you resubmit this after 3.9-rc1
comes out?


Sure, but I'll be not available next 2 weeks or so. If 3.8 falls
within that time, I will re-post it later. It is ok for me, if it has
to go in after 3.9 also.

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] media: rc: gpio-ir-recv: add support for device tree parsing

2013-02-06 Thread Sebastian Hesselbarth


On 02/06/2013 02:48 PM, Sylwester Nawrocki wrote:

On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:

This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but optional properties allow linux specific support for rc
protocols and maps.

There was a similar patch sent by Matus Ujhelyi but that discussion
died after the first reviews.

Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
---

...

diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt 
b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
new file mode 100644
index 000..937760c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -0,0 +1,20 @@
+Device-Tree bindings for GPIO IR receiver
+
+Required properties:
+   - compatible = gpio-ir-receiver;
+   - gpios: OF device-tree gpio specification.
+
+Optional properties:
+   - linux,allowed-rc-protocols: Linux specific u64 bitmask of allowed
+   rc protocols.


You likely need to specify in these bindings documentation which bit
corresponds to which RC protocol.

I'm not very familiar with the RC internals, but why it has to be
specified statically in the device tree, when decoding seems to be
mostly software defined ? I might be missing something though..


Sylwester,

I am not familiar with RC internals either. Maybe somebody with more
insight in media/rc can clarify the specific needs for the rc subsystem.
I was just transferring the DT support approach taken by gpio_keys to
gpio_ir_recv as I will be using it on mach-dove/cubox soon.


Couldn't this be configured at run time, with all protocols allowed
as the default ?


Actually, this is how the internal rc code works. If there is nothing
defined for allowed_protocols it assumes that all protocols are supported.
That is why above node properties are optional.

About the binding documentation of allowed_protocols, rc_map, or the
default behavior of current linux code, I don't think they will stay
in-sync for long. I'd rather completely remove those os-specific properties
from DT, but that hits the above statement about the needs of media/rc
subsystem.


+   - linux,rc-map-name: Linux specific remote control map name.
+
+Example node:
+
+   ir: ir-receiver {
+   compatible = gpio-ir-receiver;
+   gpios =gpio0 19 1;
+   /* allow rc protocols 1-4 */
+   linux,allowed-rc-protocols =0x 0x001e;
+   linux,rc-map-name = rc-rc6-mce;
+   };
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 4f71a7d..25e09fa 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -16,6 +16,7 @@
  #includelinux/interrupt.h
  #includelinux/gpio.h
  #includelinux/slab.h
+#includelinux/of_gpio.h
  #includelinux/platform_device.h
  #includelinux/irq.h
  #includemedia/rc-core.h
@@ -30,6 +31,63 @@ struct gpio_rc_dev {
bool active_low;
  };

+#ifdef CONFIG_OF
+/*
+ * Translate OpenFirmware node properties into platform_data
+ */
+static struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+   struct device_node *np = dev-of_node;
+   struct gpio_ir_recv_platform_data *pdata;
+   enum of_gpio_flags flags;
+   int gpio;
+
+   if (!np)
+   return ERR_PTR(-ENODEV);
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return ERR_PTR(-ENOMEM);
+
+   if (!of_find_property(np, gpios, NULL)) {


Why do you need this ? Isn't of_get_gpio_flags() sufficient ?


Ok. Now that you point at it, I agree that this check and the error
below is not needed. It is in gpio_keys, so that explains why it also
moved in here.


+   dev_err(dev, Found gpio-ir-receiver without gpios\n);
+   return ERR_PTR(-EINVAL);
+   }
+
+   gpio = of_get_gpio_flags(np, 0,flags);
+   if (gpio  0) {
+   if (gpio != -EPROBE_DEFER)
+   dev_err(dev, Failed to get gpio flags, error: %d\n,
+   gpio);
+   return ERR_PTR(gpio);
+   }
+
+   pdata-gpio_nr = gpio;
+   pdata-active_low = (flags  OF_GPIO_ACTIVE_LOW) ? true : false;
+   pdata-map_name = of_get_property(np, linux,rc-map-name, NULL);
+   of_property_read_u64(np, linux,allowed-rc-protocols,
+   pdata-allowed_protos);
+
+   return pdata;
+}
+
+static struct of_device_id gpio_ir_recv_of_match[] = {
+   { .compatible = gpio-ir-receiver, },
+   { },
+};
+MODULE_DEVICE_TABLE(of, gpio_ir_recv_of_match);
+
+#else /* !CONFIG_OF */
+
+static inline struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+   return ERR_PTR(-ENODEV);
+}
+
+#endif

Re: [PATCH] clk: add si5351 i2c common clock driver

2013-02-27 Thread Sebastian Hesselbarth

Daniel,

first of all sorry for the late answer but thanks for testing the driver.

On 2/19/13, Daniel Mack zon...@gmail.com wrote:
 Hi Sebastian,

 I did some more tests today and it took me a while to dig for the root
 cause why things were not working for me in the first place - see below.


 On 09.02.2013 13:59, Sebastian Hesselbarth wrote:

 +==Example==
 +
 +/* 25MHz reference crystal */
 +ref25: ref25M {
 +compatible = fixed-clock;
 +#clock-cells = 0;
 +clock-frequency = 2500;
 +};
 +
 +i2c-master-node {
 +
 +/* Si5351a msop10 i2c clock generator */
 +si5351a: clock-generator@60 {
 +compatible = silabs,si5351a-msop;
 +reg = 0x60;
 +#address-cells = 1;
 +#size-cells = 0;
 +#clock-cells = 1;
 +
 +/* connect xtal input to 25MHz reference */
 +clocks = ref25;

 As referred to in another thread, registering the ref25M clock that way
 didn't suffice for me on my platform - but that's a different story.

I guess fixed-clock isn't registered by OMAP's clock init code? I had
to do this on dove, too. Actually, I will come back to clock initialization for
dove later and was hoping that there will be some global way of registering
core common clock drivers (or at least fixed-clock) until then.

 +static void si5351_read_parameters(struct si5351_driver_data *drvdata,
 +unsigned char reg, struct si5351_parameters *params)
 +{
 +unsigned char buf[SI5351_PARAMETERS_LENGTH];

 On a general note, I think you can use u8 instead of unsigned char all
 over the place here, which will save you some indentation trouble.

Ok, I guess I was deriving unsigned char usage from other clock drivers
and never went to u8. But I ll reconsider using u8 when all issues are
worked out.

 +static inline int _si5351_clkout_reparent(struct si5351_driver_data
 *drvdata,
 +  unsigned char num, unsigned char parent)
 +{
 +struct clk *pclk;
 +
 +if (num  8 ||
 +(drvdata-variant == SI5351_VARIANT_A3  num  3))
 +return -EINVAL;
 +
 +switch (parent) {
 +case 0:
 +pclk = drvdata-msynth[num].hw.clk;
 +break;
 +case 1:
 +pclk = drvdata-msynth[0].hw.clk;
 +if (num = 4)
 +pclk = drvdata-msynth[4].hw.clk;
 +break;
 +case 2:
 +pclk = drvdata-xtal.clk;
 +break;
 +case 3:
 +if (drvdata-variant != SI5351_VARIANT_C)
 +return -EINVAL;
 +pclk = drvdata-clkin.clk;
 +break;
 +default:
 +return -EINVAL;
 +}
 +return clk_set_parent(drvdata-clkout[num].hw.clk, pclk);
 +}

 [...]

 +static int si5351_clkout_set_parent(struct clk_hw *hw, u8 index)
 +{
 +struct si5351_hw_data *hwdata =
 +container_of(hw, struct si5351_hw_data, hw);
 +unsigned val;
 +
 +val = 0;
 +hw-clk-flags = ~CLK_SET_RATE_PARENT;
 +switch (index) {
 +case 0:
 +hw-clk-flags |= CLK_SET_RATE_PARENT;
 +val = SI5351_CLK_INPUT_MULTISYNTH_N;
 +break;

 I fugured that _si5351_clkout_reparent() wouldn't actually call
 -set_parent() on the clock, which leads to the fact that
 CLK_SET_RATE_PARENT is not set in the flags. That way, only the clkout
 end leaf is actually supplied with a new rate, which leads to incorrect
 effective clocks, depending on the current multisynth/pll configuration.

Yeah, true. Unfortunately, _clkout_reparent() is more like a dirty hack to
allow to reparent the clock output. At registration internal configuration of
si5351 is not known and when I parse the DT for clock configuration I might
have been already assigned to the same parent clk that you later explicitly
configure.

What I basically want for si5351 (or any other eeprom based programmable
clock gen) is that stored configuration is not touched. But it can be changed
after eeprom contents have been copied into device's sram - and this _is_
mandatory for the si5351 that I use on CuBox where there is no useful config
stored at all.

Anyway, there still seem to be some more issues with doing it right on current
common clk framwork - thanks for pointing it out.

 The reason for this is in clk_set_parent() itself, which bails if the
 parent is already set to the passed value:

   if (clk-parent == parent)
   goto out;

 I fixed that for now by explicitly setting the clock's parent to NULL
 before calling clk_set_parent() in _si5351_clkout_reparent(), so the
 calbacks are triggered. But there might be a nicer way, for example to
 factor out the CLK_SET_RATE_PARENT handling to some function called from
 _si5351_clkout_reparent() or so.

 Anyway, with this hack in place along with the other details I mentioned
 in my first mail, the driver seems to work for me now, which is great. I
 will do more extensive tests later that week when I have access to
 better scopes ...

I am

[PATCH v3 0/9] pinctrl: mvebu: pinctrl driver

This patch set adds a core pinctrl driver for Marvell MVEBU SoCs and
SoC specific stubs for Armada 370, Armada XP, Dove, and Kirkwood.
The SoC specific stubs use the pinctrl-mvebu core driver that handles
pinctrl API and register accesses for common pinctrl registers.

As especially Dove has some pinctrl registers that do not match the
common pinctrl register layout the core driver has been extended by
some callbacks to allow uncommon Dove pinctrl registers.

DT binding documentation is added for all supported SoCs but as
Dove and Kirkwood are not yet ready for full DT support, the pinctrl
driver is only activated for Armada 370 and XP.

The driver has been tested on Dove, 88f6281 variant of Kirkwood,
Armada 370, and XP.

Changelog:
v2:
- rebased on git://git.infradead.org/users/jcooper/linux.git boards-for-3.7
- removed arch/arm/*/Kconfig patches that enable PINCTRL_ on MACH_MVEBU
  (those will be sent as a different patch set)
- reworked patches wrt reviews from Andrew Lunn and Linus Walleij

v3:
- parse functions from SoC specific pin groups instead of DT node
- move kirkwood variants to DT match data
- respect Armada XP variant in DTs
- cleaned whitespaces in DTs
- rebased to jcooper/boards-for-v3.7-v2

Sebastian Hesselbarth (3):
  pinctrl: mvebu: pinctrl driver core
  pinctrl: mvebu: dove pinctrl driver
  pinctrl: mvebu: kirkwood pinctrl driver

Thomas Petazzoni (6):
  pinctrl: mvebu: add pinctrl driver for Armada 370
  pinctrl: mvebu: add pinctrl driver for Armada XP
  ARM: mvebu: add pinctrl device in DT for Armada 370/XP SoCs
  ARM: mvebu: Add pinctrl support to Armada XP SoCs
  ARM: mvebu: Add pinctrl support to Armada 370 SoC
  ARM: mvebu: adjust Armada XP evaluation board DTS

 .../pinctrl/marvell,armada-370-pinctrl.txt |   95 +++
 .../bindings/pinctrl/marvell,armada-xp-pinctrl.txt |  100 +++
 .../bindings/pinctrl/marvell,dove-pinctrl.txt  |   72 ++
 .../bindings/pinctrl/marvell,kirkwood-pinctrl.txt  |  279 
 .../bindings/pinctrl/marvell,mvebu-pinctrl.txt |   45 ++
 arch/arm/Kconfig   |1 +
 arch/arm/boot/dts/armada-370-xp.dtsi   |7 +
 arch/arm/boot/dts/armada-370.dtsi  |4 +
 arch/arm/boot/dts/armada-xp-db.dts |4 +-
 arch/arm/boot/dts/armada-xp-mv78230.dtsi   |   27 +
 arch/arm/boot/dts/armada-xp-mv78260.dtsi   |   27 +
 arch/arm/boot/dts/armada-xp-mv78460.dtsi   |   27 +
 drivers/pinctrl/Kconfig|   22 +
 drivers/pinctrl/Makefile   |5 +
 drivers/pinctrl/pinctrl-armada-370.c   |  421 
 drivers/pinctrl/pinctrl-armada-xp.c|  468 +
 drivers/pinctrl/pinctrl-dove.c |  622 +
 drivers/pinctrl/pinctrl-kirkwood.c |  473 +
 drivers/pinctrl/pinctrl-mvebu.c|  705 
 drivers/pinctrl/pinctrl-mvebu.h|  192 ++
 20 files changed, 3594 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
 create mode 100644 arch/arm/boot/dts/armada-xp-mv78230.dtsi
 create mode 100644 arch/arm/boot/dts/armada-xp-mv78260.dtsi
 create mode 100644 arch/arm/boot/dts/armada-xp-mv78460.dtsi
 create mode 100644 drivers/pinctrl/pinctrl-armada-370.c
 create mode 100644 drivers/pinctrl/pinctrl-armada-xp.c
 create mode 100644 drivers/pinctrl/pinctrl-dove.c
 create mode 100644 drivers/pinctrl/pinctrl-kirkwood.c
 create mode 100644 drivers/pinctrl/pinctrl-mvebu.c
 create mode 100644 drivers/pinctrl/pinctrl-mvebu.h
---
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
-- 
1.7.10.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

[PATCH v3 4/9] pinctrl: mvebu: add pinctrl driver for Armada 370

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

This pinctrl driver is not a full-blown pinctrl driver from scratch:
it relies on the common pinctrl-mvebu driver, which is used for all
Marvell EBU SoCs.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
v2:
- removed arch/arm/*/Kconfig changes and added note about variant = 0

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../pinctrl/marvell,armada-370-pinctrl.txt |   95 +
 drivers/pinctrl/Kconfig|4 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-armada-370.c   |  421 
 4 files changed, 521 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-armada-370.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
new file mode 100644
index 000..01ef408
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
@@ -0,0 +1,95 @@
+* Marvell Armada 370 SoC pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage.
+
+Required properties:
+- compatible: marvell,88f6710-pinctrl
+
+Available mpp pins/groups and functions:
+Note: brackets (x) are not part of the mpp name for marvell,function and given
+only for more detailed description in this document.
+
+name  pins functions
+
+mpp0  0gpio, uart0(rxd)
+mpp1  1gpo, uart0(txd)
+mpp2  2gpio, i2c0(sck), uart0(txd)
+mpp3  3gpio, i2c0(sda), uart0(rxd)
+mpp4  4gpio, cpu_pd(vdd)
+mpp5  5gpo, ge0(txclko), uart1(txd), spi1(clk), audio(mclk)
+mpp6  6gpio, ge0(txd0), sata0(prsnt), tdm(rst), audio(sdo)
+mpp7  7gpo, ge0(txd1), tdm(tdx), audio(lrclk)
+mpp8  8gpio, ge0(txd2), uart0(rts), tdm(drx), audio(bclk)
+mpp9  9gpo, ge0(txd3), uart1(txd), sd0(clk), audio(spdifo)
+mpp10 10   gpio, ge0(txctl), uart0(cts), tdm(fsync), audio(sdi)
+mpp11 11   gpio, ge0(rxd0), uart1(rxd), sd0(cmd), spi0(cs1),
+   sata1(prsnt), spi1(cs1)
+mpp12 12   gpio, ge0(rxd1), i2c1(sda), sd0(d0), spi1(cs0),
+   audio(spdifi)
+mpp13 13   gpio, ge0(rxd2), i2c1(sck), sd0(d1), tdm(pclk),
+   audio(rmclk)
+mpp14 14   gpio, ge0(rxd3), pcie(clkreq0), sd0(d2), spi1(mosi),
+   spi0(cs2)
+mpp15 15   gpio, ge0(rxctl), pcie(clkreq1), sd0(d3), spi1(miso),
+   spi0(cs3)
+mpp16 16   gpio, ge0(rxclk), uart1(rxd), tdm(int), audio(extclk)
+mpp17 17   gpo, ge(mdc)
+mpp18 18   gpio, ge(mdio)
+mpp19 19   gpio, ge0(txclk), ge1(txclkout), tdm(pclk)
+mpp20 20   gpo, ge0(txd4), ge1(txd0)
+mpp21 21   gpo, ge0(txd5), ge1(txd1), uart1(txd)
+mpp22 22   gpo, ge0(txd6), ge1(txd2), uart0(rts)
+mpp23 23   gpo, ge0(txd7), ge1(txd3), spi1(mosi)
+mpp24 24   gpio, ge0(col), ge1(txctl), spi1(cs0)
+mpp25 25   gpio, ge0(rxerr), ge1(rxd0), uart1(rxd)
+mpp26 26   gpio, ge0(crs), ge1(rxd1), spi1(miso)
+mpp27 27   gpio, ge0(rxd4), ge1(rxd2), uart0(cts)
+mpp28 28   gpio, ge0(rxd5), ge1(rxd3)
+mpp29 29   gpio, ge0(rxd6), ge1(rxctl), i2c1(sda)
+mpp30 30   gpio, ge0(rxd7), ge1(rxclk), i2c1(sck)
+mpp31 31   gpio, tclk, ge0(txerr)
+mpp32 32   gpio, spi0(cs0)
+mpp33 33   gpio, dev(bootcs), spi0(cs0)
+mpp34 34   gpo, dev(wen0), spi0(mosi)
+mpp35 35   gpo, dev(oen), spi0(sck)
+mpp36 36   gpo, dev(a1), spi0(miso)
+mpp37 37   gpo, dev(a0), sata0(prsnt)
+mpp38 38   gpio, dev(ready), uart1(cts), uart0(cts)
+mpp39 39   gpo, dev(ad0), audio(spdifo)
+mpp40 40   gpio, dev(ad1), uart1(rts), uart0(rts)
+mpp41

[PATCH v3 2/9] pinctrl: mvebu: dove pinctrl driver

This patch adds a SoC specific pinctrl driver for Marvell Dove SoCs
plus DT binding documentation. This driver will use the mvebu pinctrl
driver core.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
v2:
- restructured pinctrl/Kconfig to hide pinctrl driver as it will be
  always selected by arch/arm/mach-mvebu/Kconfig
- cleaned pinctrl-dove and replaced 'magic numbers' by defines
- use devm_clk_get for (now optional) pdma clock and add to required
  properties in devicetree binding documentation

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../bindings/pinctrl/marvell,dove-pinctrl.txt  |   72 +++
 drivers/pinctrl/Kconfig|4 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-dove.c |  622 
 4 files changed, 699 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-dove.c

diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
new file mode 100644
index 000..a648aaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
@@ -0,0 +1,72 @@
+* Marvell Dove SoC pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage.
+
+Required properties:
+- compatible: marvell,dove-pinctrl
+- clocks: (optional) phandle of pdma clock
+
+Available mpp pins/groups and functions:
+Note: brackets (x) are not part of the mpp name for marvell,function and given
+only for more detailed description in this document.
+
+name  pins functions
+
+mpp0  0gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm)
+mpp1  1gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm)
+mpp2  2gpio, pmu, uart2(txd), sdio0(buspwr), sata(prsnt),
+   uart1(rts)
+mpp3  3gpio, pmu, uart2(rxd), sdio0(ledctrl), sata(act),
+   uart1(cts), lcd-spi(cs1)
+mpp4  4gpio, pmu, uart3(rts), sdio1(cd), spi1(miso)
+mpp5  5gpio, pmu, uart3(cts), sdio1(wp), spi1(cs)
+mpp6  6gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi)
+mpp7  7gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck)
+mpp8  8gpio, pmu, watchdog(rstout)
+mpp9  9gpio, pmu, pex1(clkreq)
+mpp10 10   gpio, pmu, ssp(sclk)
+mpp11 11   gpio, pmu, sata(prsnt), sata-1(act), sdio0(ledctrl),
+   sdio1(ledctrl), pex0(clkreq)
+mpp12 12   gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd), 
sata(act)
+mpp13 13   gpio, pmu, uart2(cts), audio1(extclk), sdio1(wp),
+   ssp(extclk)
+mpp14 14   gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd)
+mpp15 15   gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm)
+mpp16 16   gpio, uart3(rts), sdio0(cd), ac97(sdi1), lcd-spi(cs1)
+mpp17 17   gpio, uart3(cts), sdio0(wp), ac97(sdi2), twsi(sda),
+   ac97-1(sysclko)
+mpp18 18   gpio, uart3(txd), sdio0(buspwr), ac97(sdi3), lcd0(pwm)
+mpp19 19   gpio, uart3(rxd), sdio0(ledctrl), twsi(sck)
+mpp20 20   gpio, sdio0(cd), sdio1(cd), spi1(miso), lcd-spi(miso),
+   ac97(sysclko)
+mpp21 21   gpio, sdio0(wp), sdio1(wp), spi1(cs), lcd-spi(cs0),
+   uart1(cts), ssp(sfrm)
+mpp22 22   gpio, sdio0(buspwr), sdio1(buspwr), spi1(mosi),
+   lcd-spi(mosi), uart1(cts), ssp(txd)
+mpp23 23   gpio, sdio0(ledctrl), sdio1(ledctrl), spi1(sck),
+   lcd-spi(sck), ssp(sclk)
+mpp_camera24-39gpio, camera
+mpp_sdio0 40-45gpio, sdio0
+mpp_sdio1 46-51gpio, sdio1
+mpp_audio152-57gpio, i2s1/spdifo, i2s1, spdifo, twsi, ssp/spdifo, ssp,
+   ssp/twsi
+mpp_spi0  58-61gpio, spi0
+mpp_uart1 62-63gpio, uart1
+mpp_nand  64-71gpo, nand
+audio0-i2s, ac97
+twsi  -none

[PATCH v3 9/9] ARM: mvebu: adjust Armada XP evaluation board DTS

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

The Armada XP evaluation board is based on the MV78460 Armava XP
SoC. Now that we have separate .dtsi files for the three different
SoCs of the Armada XP family, use the appropriate one as include for
the Armada XP evaluation board .dts file.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/boot/dts/armada-xp-db.dts |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-db.dts 
b/arch/arm/boot/dts/armada-xp-db.dts
index f97040d..b1fc728 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,11 +14,11 @@
  */
 
 /dts-v1/;
-/include/ armada-xp.dtsi
+/include/ armada-xp-mv78460.dtsi
 
 / {
model = Marvell Armada XP Evaluation Board;
-   compatible = marvell,axp-db, marvell,armadaxp, 
marvell,armada-370-xp;
+   compatible = marvell,axp-db, marvell,armadaxp-mv78460, 
marvell,armadaxp, marvell,armada-370-xp;
 
chosen {
bootargs = console=ttyS0,115200 earlyprintk;
-- 
1.7.10.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 v3 3/9] pinctrl: mvebu: kirkwood pinctrl driver

This patch adds a SoC specific pinctrl driver for Marvell Kirkwood SoCs
plus DT binding documentation. This driver will use the mvebu pinctrl
driver core.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
v2:
- restructured pinctrl/Kconfig to hide pinctrl driver as it will be
  always selected by arch/arm/mach-mvebu/Kconfig
- use enum for kirkwood variants instead of defines

v3:
- moved variant specific data to DT match struct

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../bindings/pinctrl/marvell,kirkwood-pinctrl.txt  |  279 
 drivers/pinctrl/Kconfig|4 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-kirkwood.c |  473 
 4 files changed, 757 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-kirkwood.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
new file mode 100644
index 000..361bccb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
@@ -0,0 +1,279 @@
+* Marvell Kirkwood SoC pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage.
+
+Required properties:
+- compatible: marvell,88f6180-pinctrl,
+  marvell,88f6190-pinctrl, marvell,88f6192-pinctrl,
+  marvell,88f6281-pinctrl, marvell,88f6282-pinctrl
+
+This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 88f628x.
+
+Available mpp pins/groups and functions:
+Note: brackets (x) are not part of the mpp name for marvell,function and given
+only for more detailed description in this document.
+
+* Marvell Kirkwood 88f6180
+
+name  pins functions
+
+mpp0  0gpio, nand(io2), spi(cs)
+mpp1  1gpo, nand(io3), spi(mosi)
+mpp2  2gpo, nand(io4), spi(sck)
+mpp3  3gpo, nand(io5), spi(miso)
+mpp4  4gpio, nand(io6), uart0(rxd), ptp(clk)
+mpp5  5gpo, nand(io7), uart0(txd), ptp(trig)
+mpp6  6sysrst(out), spi(mosi), ptp(trig)
+mpp7  7gpo, pex(rsto), spi(cs), ptp(trig)
+mpp8  8gpio, twsi0(sda), uart0(rts), uart1(rts), ptp(clk),
+   mii(col)
+mpp9  9gpio, twsi(sck), uart0(cts), uart1(cts), ptp(evreq),
+   mii(crs)
+mpp10 10   gpo, spi(sck), uart0(txd), ptp(trig)
+mpp11 11   gpio, spi(miso), uart0(rxd), ptp(clk), ptp-1(evreq),
+   ptp-2(trig)
+mpp12 12   gpo, sdio(clk)
+mpp13 13   gpio, sdio(cmd), uart1(txd)
+mpp14 14   gpio, sdio(d0), uart1(rxd), mii(col)
+mpp15 15   gpio, sdio(d1), uart0(rts), uart1(txd)
+mpp16 16   gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs)
+mpp17 17   gpio, sdio(d3)
+mpp18 18   gpo, nand(io0)
+mpp19 19   gpo, nand(io1)
+mpp20 20   gpio, mii(rxerr)
+mpp21 21   gpio, audio(spdifi)
+mpp22 22   gpio, audio(spdifo)
+mpp23 23   gpio, audio(rmclk)
+mpp24 24   gpio, audio(bclk)
+mpp25 25   gpio, audio(sdo)
+mpp26 26   gpio, audio(lrclk)
+mpp27 27   gpio, audio(mclk)
+mpp28 28   gpio, audio(sdi)
+mpp29 29   gpio, audio(extclk)
+
+* Marvell Kirkwood 88f6190
+
+name  pins functions
+
+mpp0  0gpio, nand(io2), spi(cs)
+mpp1  1gpo, nand(io3), spi(mosi)
+mpp2  2gpo, nand(io4), spi(sck)
+mpp3  3gpo, nand(io5), spi(miso)
+mpp4  4gpio, nand(io6), uart0(rxd), ptp(clk)
+mpp5  5gpo, nand(io7), uart0(txd), ptp(trig), sata0(act)
+mpp6  6sysrst(out), spi(mosi), ptp(trig)
+mpp7  7gpo, pex(rsto), spi(cs), ptp(trig)
+mpp8  8gpio, twsi0(sda), uart0(rts), uart1

[PATCH v3 8/9] ARM: mvebu: Add pinctrl support to Armada 370 SoC

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

This commits adds the necessary device tree information to define the
compatible property for the pinctrl driver instance of Armada 370 SoC.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
v3:
- cleaned whitespaces

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/boot/dts/armada-370.dtsi |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370.dtsi 
b/arch/arm/boot/dts/armada-370.dtsi
index 3228ccc..b71ab9b 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -31,5 +31,9 @@
compatible = 
marvell,armada-370-xp-system-controller;
reg = 0xd0018200 0x100;
};
+
+   pinctrl@d0018000 {
+   compatible = marvell,mv88f6710-pinctrl;
+   };
};
 };
-- 
1.7.10.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 v3 7/9] ARM: mvebu: Add pinctrl support to Armada XP SoCs

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

This commits adds the necessary device tree information to define the
compatible property for the pinctrl driver instance of Armada XP SoCs.

Until now, the device tree representation considered the Armada XP as
a single SoC. But in fact, there are three different SoCs in the
Armada XP families, with different number of CPU cores, different
number of Ethernet interfaces... and different number of muxable pins
or functions. We therefore introduce three armada-xp-mv78xx0.dtsi for
the three SoCs of the Armada XP family. The current armada-xp-db.dts
evaluation board uses the MV78460 variant of the SoC.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
v3:
- put specific variant into DT model

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   27 +++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   27 +++
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   27 +++
 3 files changed, 81 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-xp-mv78230.dtsi
 create mode 100644 arch/arm/boot/dts/armada-xp-mv78260.dtsi
 create mode 100644 arch/arm/boot/dts/armada-xp-mv78460.dtsi

diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
new file mode 100644
index 000..8bdcd43
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Include file for Marvell Armada XP family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Thomas Petazzoni thomas.petazz...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Contains definitions specific to the Armada XP MV78230 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+/include/ armada-xp.dtsi
+
+/ {
+   model = Marvell Armada XP MV78230 SoC;
+   compatible = marvell,armadaxp-mv78230, marvell,armadaxp, 
marvell,armada-370-xp;
+
+   soc {
+   pinctrl@d0018000 {
+   compatible = marvell,mv78230-pinctrl;
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
new file mode 100644
index 000..e5c108b
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Include file for Marvell Armada XP family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Thomas Petazzoni thomas.petazz...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Contains definitions specific to the Armada XP MV78260 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+/include/ armada-xp.dtsi
+
+/ {
+   model = Marvell Armada XP MV78260 SoC;
+   compatible = marvell,armadaxp-mv78260, marvell,armadaxp, 
marvell,armada-370-xp;
+
+   soc {
+   pinctrl@d0018000 {
+   compatible = marvell,mv78260-pinctrl;
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
new file mode 100644
index 000..22e7fdd
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Include file for Marvell Armada XP family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Thomas Petazzoni thomas.petazz...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Contains definitions specific to the Armada XP MV78460 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+/include/ armada-xp.dtsi
+
+/ {
+   model = Marvell Armada XP MV78460 SoC;
+   compatible = marvell,armadaxp-mv78460, marvell,armadaxp, 
marvell,armada-370-xp;
+
+   soc {
+   pinctrl@d0018000 {
+   compatible = marvell,mv78460-pinctrl

[PATCH v3 6/9] ARM: mvebu: add pinctrl device in DT for Armada 370/XP SoCs

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

The Armada 370 and XP SoCs have configurable muxing for a certain
number of their pins, controlled through a pinctrl driver.

The 'compatible' property is defined in the SoC-specific .dtsi files,
since the compatible string identifies the number of pins and other
SoC-specific properties.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
v3:
- cleaned whitespaces

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/boot/dts/armada-370-xp.dtsi |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 16cc82c..ff1c7a6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -68,6 +68,13 @@
compatible = marvell,armada-addr-decoding-controller;
reg = 0xd002 0x258;
};
+
+   pinctrl@d0018000 {
+   reg = 0xd0018000 0x38;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   };
};
 };
 
-- 
1.7.10.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 v3 5/9] pinctrl: mvebu: add pinctrl driver for Armada XP

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

This pinctrl driver is not a full-blown pinctrl driver from scratch:
it relies on the common pinctrl-mvebu driver, which is used for all
Marvell EBU SoCs.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
v2: replaced variant with enum and used bitops.h

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../bindings/pinctrl/marvell,armada-xp-pinctrl.txt |  100 +
 drivers/pinctrl/Kconfig|4 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-armada-xp.c|  468 
 4 files changed, 573 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-armada-xp.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
new file mode 100644
index 000..bfa0a2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
@@ -0,0 +1,100 @@
+* Marvell Armada XP SoC pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage.
+
+Required properties:
+- compatible: marvell,mv78230-pinctrl, marvell,mv78260-pinctrl,
+  marvell,mv78460-pinctrl
+
+This driver supports all Armada XP variants, i.e. mv78230, mv78260, and 
mv78460.
+
+Available mpp pins/groups and functions:
+Note: brackets (x) are not part of the mpp name for marvell,function and given
+only for more detailed description in this document.
+
+* Marvell Armada XP (all variants)
+
+name  pins functions
+
+mpp0  0gpio, ge0(txclko), lcd(d0)
+mpp1  1gpio, ge0(txd0), lcd(d1)
+mpp2  2gpio, ge0(txd1), lcd(d2)
+mpp3  3gpio, ge0(txd2), lcd(d3)
+mpp4  4gpio, ge0(txd3), lcd(d4)
+mpp5  5gpio, ge0(txctl), lcd(d5)
+mpp6  6gpio, ge0(rxd0), lcd(d6)
+mpp7  7gpio, ge0(rxd1), lcd(d7)
+mpp8  8gpio, ge0(rxd2), lcd(d8)
+mpp9  9gpio, ge0(rxd3), lcd(d9)
+mpp10 10   gpio, ge0(rxctl), lcd(d10)
+mpp11 11   gpio, ge0(rxclk), lcd(d11)
+mpp12 12   gpio, ge0(txd4), ge1(txd0), lcd(d12)
+mpp13 13   gpio, ge0(txd5), ge1(txd1), lcd(d13)
+mpp14 14   gpio, ge0(txd6), ge1(txd2), lcd(d15)
+mpp15 15   gpio, ge0(txd7), ge1(txd3), lcd(d16)
+mpp16 16   gpio, ge0(txd7), ge1(txd3), lcd(d16)
+mpp17 17   gpio, ge0(col), ge1(txctl), lcd(d17)
+mpp18 18   gpio, ge0(rxerr), ge1(rxd0), lcd(d18), ptp(trig)
+mpp19 19   gpio, ge0(crs), ge1(rxd1), lcd(d19), ptp(evreq)
+mpp20 20   gpio, ge0(rxd4), ge1(rxd2), lcd(d20), ptp(clk)
+mpp21 21   gpio, ge0(rxd5), ge1(rxd3), lcd(d21), mem(bat)
+mpp22 22   gpio, ge0(rxd6), ge1(rxctl), lcd(d22), sata0(prsnt)
+mpp23 23   gpio, ge0(rxd7), ge1(rxclk), lcd(d23), sata1(prsnt)
+mpp24 24   gpio, lcd(hsync), sata1(prsnt), nf(bootcs-re), tdm(rst)
+mpp25 25   gpio, lcd(vsync), sata0(prsnt), nf(bootcs-we), tdm(pclk)
+mpp26 26   gpio, lcd(clk), tdm(fsync), vdd(cpu1-pd)
+mpp27 27   gpio, lcd(e), tdm(dtx), ptp(trig)
+mpp28 28   gpio, lcd(pwm), tdm(drx), ptp(evreq)
+mpp29 29   gpio, lcd(ref-clk), tdm(int0), ptp(clk), vdd(cpu0-pd)
+mpp30 30   gpio, tdm(int1), sd0(clk)
+mpp31 31   gpio, tdm(int2), sd0(cmd), vdd(cpu0-pd)
+mpp32 32   gpio, tdm(int3), sd0(d0), vdd(cpu1-pd)
+mpp33 33   gpio, tdm(int4), sd0(d1), mem(bat)
+mpp34 34   gpio, tdm(int5), sd0(d2), sata0(prsnt)
+mpp35 35   gpio, tdm(int6), sd0(d3), sata1(prsnt)
+mpp36 36   gpio, spi(mosi)
+mpp37 37   gpio, spi(miso)
+mpp38 38   gpio, spi(sck)
+mpp39 39   gpio, spi(cs0)
+mpp40 40   gpio, spi(cs1), uart2(cts), lcd(vga-hsync), 
vdd(cpu1-pd),
+   pcie(clkreq0)
+mpp41 41   gpio

[PATCH v3 1/9] pinctrl: mvebu: pinctrl driver core

This patch adds a pinctrl driver core for Marvell SoCs plus DT
binding documentation. This core driver will be used by SoC family
specific drivers, i.e. Armada XP, Armada 370, Dove, Kirkwood, aso.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
v2:
- restructured Kconfig to have a common PINCTRL_MVEBU that are selected by
  SoC specific drivers.
- cleaned pinctrl-mvebu and replaced 'magic numbers' by defines
- make use of of_iomap instead of get_resource/ioremap
- extended include documentation and checked with scripts/kernel-doc
- cleaned devicetree binding documentation

v3:
- list of functions is now built out of pin groups passed to core driver
  instead of parsing DT node.

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../bindings/pinctrl/marvell,mvebu-pinctrl.txt |   45 ++
 arch/arm/Kconfig   |1 +
 drivers/pinctrl/Kconfig|6 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-mvebu.c|  705 
 drivers/pinctrl/pinctrl-mvebu.h|  192 ++
 6 files changed, 950 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-mvebu.c
 create mode 100644 drivers/pinctrl/pinctrl-mvebu.h

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
new file mode 100644
index 000..dc419e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
@@ -0,0 +1,45 @@
+* Marvell SoC pinctrl core driver for mpp
+
+The pinctrl driver enables Marvell SoCs to configure the multi-purpose pins
+(mpp) to a specific function. For each SoC family there is a SoC specific
+driver using this core driver.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase pin configuration node.
+
+A Marvell SoC pin configuration node is a node of a group of pins which can
+be used for a specific device or function. Each node requires one or more
+mpp pins or group of pins and a mpp function common to all pins.
+
+Required properties for pinctrl driver:
+- compatible: marvell,soc-pinctrl
+  Please refer to each marvell,soc-pinctrl.txt binding doc for supported 
SoCs.
+
+Required properties for pin configuration node:
+- marvell,pins: string array of mpp pins or group of pins to be muxed.
+- marvell,function: string representing a function to mux to for all
+marvell,pins given in this pin configuration node. The function has to be
+common for all marvell,pins. Please refer to marvell,soc-pinctrl.txt for
+valid pin/pin group names and available function names for each SoC.
+
+Examples:
+
+uart1: serial@12100 {
+   compatible = ns16550a;
+   reg = 0x12100 0x100;
+   reg-shift = 2;
+   interrupts = 7;
+
+   pinctrl-0 = pmx_uart1_sw;
+};
+
+pinctrl: pinctrl@d0200 {
+   compatible = marvell,dove-pinctrl;
+   reg = 0xd0200 0x20;
+
+   pmx_uart1_sw: pmx-uart1-sw {
+   marvell,pins = mpp_uart1;
+   marvell,function = uart1;
+   };
+};
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a2b6f74..2eb3f6b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -574,6 +574,7 @@ config ARCH_MVEBU
select IRQ_DOMAIN
select COMMON_CLK
select PLAT_ORION
+   select PINCTRL
help
  Support for the Marvell SoC Family with device tree support
 
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 54e3588..20bfdc3 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -145,6 +145,12 @@ config PINCTRL_COH901
  COH 901 335 and COH 901 571/3. They contain 3, 5 or 7
  ports of 8 GPIO pins each.
 
+config PINCTRL_MVEBU
+   bool
+   depends on ARCH_MVEBU
+   select PINMUX
+   select PINCONF
+
 source drivers/pinctrl/spear/Kconfig
 
 endmenu
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f40b1f8..007ed32 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers

Re: [PATCH v3 0/9] pinctrl: mvebu: pinctrl driver


On 09/10/2012 05:45 PM, Linus Walleij wrote:

This all looks good now, will this be pushed through some ARM SoC
tree along with Marvell changes or do you want me to take it all
through the pinctrl tree?


Linus,

thanks for review and ACKs. Jason Cooper will take it through Marvell
tree.

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 00/11] pinctrl: mvebu: pinctrl driver

2012-09-20 Thread Sebastian Hesselbarth


On 09/20/2012 10:13 AM, Linus Walleij wrote:

I've tried to group related implementations together, so if the first four
are dependent we should either:

1. Move all of these to the subdir drivers/pinctrl/mvebu


Linus,

I prefer having a subdirectory as there are three more SoCs related
to mvebu.


Either way it's NO BIG DEAL, so I will take care of this after they
are merged unless you feel like just fixing it in-flight at this moment.


I think integration into Marvell tree is a little bit stalled by other
patches. Hopefully, today I find some time and update the patches accordingly.

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/

[PATCH v4 02/10] pinctrl: mvebu: dove pinctrl driver

This patch adds a SoC specific pinctrl driver for Marvell Dove SoCs
plus DT binding documentation. This driver will use the mvebu pinctrl
driver core.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
v2:
- restructured pinctrl/Kconfig to hide pinctrl driver as it will be
  always selected by arch/arm/mach-mvebu/Kconfig
- cleaned pinctrl-dove and replaced 'magic numbers' by defines
- use devm_clk_get for (now optional) pdma clock and add to required
  properties in devicetree binding documentation

v4:
- choose more precise twsi option names
- assume match on DT node

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../bindings/pinctrl/marvell,dove-pinctrl.txt  |   72 +++
 drivers/pinctrl/Kconfig|4 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-dove.c |  620 
 4 files changed, 697 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-dove.c

diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
new file mode 100644
index 000..a648aaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
@@ -0,0 +1,72 @@
+* Marvell Dove SoC pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage.
+
+Required properties:
+- compatible: marvell,dove-pinctrl
+- clocks: (optional) phandle of pdma clock
+
+Available mpp pins/groups and functions:
+Note: brackets (x) are not part of the mpp name for marvell,function and given
+only for more detailed description in this document.
+
+name  pins functions
+
+mpp0  0gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm)
+mpp1  1gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm)
+mpp2  2gpio, pmu, uart2(txd), sdio0(buspwr), sata(prsnt),
+   uart1(rts)
+mpp3  3gpio, pmu, uart2(rxd), sdio0(ledctrl), sata(act),
+   uart1(cts), lcd-spi(cs1)
+mpp4  4gpio, pmu, uart3(rts), sdio1(cd), spi1(miso)
+mpp5  5gpio, pmu, uart3(cts), sdio1(wp), spi1(cs)
+mpp6  6gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi)
+mpp7  7gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck)
+mpp8  8gpio, pmu, watchdog(rstout)
+mpp9  9gpio, pmu, pex1(clkreq)
+mpp10 10   gpio, pmu, ssp(sclk)
+mpp11 11   gpio, pmu, sata(prsnt), sata-1(act), sdio0(ledctrl),
+   sdio1(ledctrl), pex0(clkreq)
+mpp12 12   gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd), 
sata(act)
+mpp13 13   gpio, pmu, uart2(cts), audio1(extclk), sdio1(wp),
+   ssp(extclk)
+mpp14 14   gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd)
+mpp15 15   gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm)
+mpp16 16   gpio, uart3(rts), sdio0(cd), ac97(sdi1), lcd-spi(cs1)
+mpp17 17   gpio, uart3(cts), sdio0(wp), ac97(sdi2), twsi(sda),
+   ac97-1(sysclko)
+mpp18 18   gpio, uart3(txd), sdio0(buspwr), ac97(sdi3), lcd0(pwm)
+mpp19 19   gpio, uart3(rxd), sdio0(ledctrl), twsi(sck)
+mpp20 20   gpio, sdio0(cd), sdio1(cd), spi1(miso), lcd-spi(miso),
+   ac97(sysclko)
+mpp21 21   gpio, sdio0(wp), sdio1(wp), spi1(cs), lcd-spi(cs0),
+   uart1(cts), ssp(sfrm)
+mpp22 22   gpio, sdio0(buspwr), sdio1(buspwr), spi1(mosi),
+   lcd-spi(mosi), uart1(cts), ssp(txd)
+mpp23 23   gpio, sdio0(ledctrl), sdio1(ledctrl), spi1(sck),
+   lcd-spi(sck), ssp(sclk)
+mpp_camera24-39gpio, camera
+mpp_sdio0 40-45gpio, sdio0
+mpp_sdio1 46-51gpio, sdio1
+mpp_audio152-57gpio, i2s1/spdifo, i2s1, spdifo, twsi, ssp/spdifo, ssp,
+   ssp/twsi
+mpp_spi0  58-61gpio, spi0
+mpp_uart1

[PATCH v4 04/10] pinctrl: mvebu: add pinctrl driver for Armada 370

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

This pinctrl driver is not a full-blown pinctrl driver from scratch:
it relies on the common pinctrl-mvebu driver, which is used for all
Marvell EBU SoCs.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
v2:
- removed arch/arm/*/Kconfig changes and added note about variant = 0

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../pinctrl/marvell,armada-370-pinctrl.txt |   95 +
 drivers/pinctrl/Kconfig|4 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-armada-370.c   |  421 
 4 files changed, 521 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-armada-370.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
new file mode 100644
index 000..01ef408
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
@@ -0,0 +1,95 @@
+* Marvell Armada 370 SoC pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage.
+
+Required properties:
+- compatible: marvell,88f6710-pinctrl
+
+Available mpp pins/groups and functions:
+Note: brackets (x) are not part of the mpp name for marvell,function and given
+only for more detailed description in this document.
+
+name  pins functions
+
+mpp0  0gpio, uart0(rxd)
+mpp1  1gpo, uart0(txd)
+mpp2  2gpio, i2c0(sck), uart0(txd)
+mpp3  3gpio, i2c0(sda), uart0(rxd)
+mpp4  4gpio, cpu_pd(vdd)
+mpp5  5gpo, ge0(txclko), uart1(txd), spi1(clk), audio(mclk)
+mpp6  6gpio, ge0(txd0), sata0(prsnt), tdm(rst), audio(sdo)
+mpp7  7gpo, ge0(txd1), tdm(tdx), audio(lrclk)
+mpp8  8gpio, ge0(txd2), uart0(rts), tdm(drx), audio(bclk)
+mpp9  9gpo, ge0(txd3), uart1(txd), sd0(clk), audio(spdifo)
+mpp10 10   gpio, ge0(txctl), uart0(cts), tdm(fsync), audio(sdi)
+mpp11 11   gpio, ge0(rxd0), uart1(rxd), sd0(cmd), spi0(cs1),
+   sata1(prsnt), spi1(cs1)
+mpp12 12   gpio, ge0(rxd1), i2c1(sda), sd0(d0), spi1(cs0),
+   audio(spdifi)
+mpp13 13   gpio, ge0(rxd2), i2c1(sck), sd0(d1), tdm(pclk),
+   audio(rmclk)
+mpp14 14   gpio, ge0(rxd3), pcie(clkreq0), sd0(d2), spi1(mosi),
+   spi0(cs2)
+mpp15 15   gpio, ge0(rxctl), pcie(clkreq1), sd0(d3), spi1(miso),
+   spi0(cs3)
+mpp16 16   gpio, ge0(rxclk), uart1(rxd), tdm(int), audio(extclk)
+mpp17 17   gpo, ge(mdc)
+mpp18 18   gpio, ge(mdio)
+mpp19 19   gpio, ge0(txclk), ge1(txclkout), tdm(pclk)
+mpp20 20   gpo, ge0(txd4), ge1(txd0)
+mpp21 21   gpo, ge0(txd5), ge1(txd1), uart1(txd)
+mpp22 22   gpo, ge0(txd6), ge1(txd2), uart0(rts)
+mpp23 23   gpo, ge0(txd7), ge1(txd3), spi1(mosi)
+mpp24 24   gpio, ge0(col), ge1(txctl), spi1(cs0)
+mpp25 25   gpio, ge0(rxerr), ge1(rxd0), uart1(rxd)
+mpp26 26   gpio, ge0(crs), ge1(rxd1), spi1(miso)
+mpp27 27   gpio, ge0(rxd4), ge1(rxd2), uart0(cts)
+mpp28 28   gpio, ge0(rxd5), ge1(rxd3)
+mpp29 29   gpio, ge0(rxd6), ge1(rxctl), i2c1(sda)
+mpp30 30   gpio, ge0(rxd7), ge1(rxclk), i2c1(sck)
+mpp31 31   gpio, tclk, ge0(txerr)
+mpp32 32   gpio, spi0(cs0)
+mpp33 33   gpio, dev(bootcs), spi0(cs0)
+mpp34 34   gpo, dev(wen0), spi0(mosi)
+mpp35 35   gpo, dev(oen), spi0(sck)
+mpp36 36   gpo, dev(a1), spi0(miso)
+mpp37 37   gpo, dev(a0), sata0(prsnt)
+mpp38 38   gpio, dev(ready), uart1(cts), uart0(cts)
+mpp39 39   gpo, dev(ad0), audio(spdifo)
+mpp40 40

[PATCH v4 09/10] arm: mvebu: split Kconfig options for Armada 370 and XP

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

Until now, all the code for Armada 370 and XP was common, so we had a
single Kconfig option to support all boards using both SoCs. With the
addition of pinctrl drivers, this situation has changed: those two
SoCs are radically different in terms of pinctrl, so they have two
separate drivers. Since pinctrl drivers are typically select-ed from
the SoC Kconfig option, it makes sense to split the 370/XP option into
two separate options: one for Armada 370 and another for Armada XP.

We keep an hidden option selected by both ARMADA_370 and ARMADA_XP in
order to easily compile common code.

A followup patch actually makes use of this split to select the
appropriate pinctrl drivers.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Gregory Clement gregory.clem...@free-electrons.com
---
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/mach-mvebu/Kconfig |   16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index caa2c5e..5540a8b 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -3,13 +3,23 @@ if ARCH_MVEBU
 menu Marvell SOC with device tree
 
 config MACH_ARMADA_370_XP
-   bool Marvell Armada 370 and Aramada XP boards
+   bool
select ARMADA_370_XP_TIMER
select CPU_V7
+
+config MACH_ARMADA_370
+   bool Marvell Armada 370 boards
+   select MACH_ARMADA_370_XP
help
+ Say 'Y' here if you want your kernel to support boards based
+ on the Marvell Armada 370 SoC with device tree.
 
- Say 'Y' here if you want your kernel to support boards based on
- Marvell Armada 370 or Armada XP with device tree.
+config MACH_ARMADA_XP
+   bool Marvell Armada XP boards
+   select MACH_ARMADA_370_XP
+   help
+ Say 'Y' here if you want your kernel to support boards based
+ on the Marvell Armada XP SoC with device tree.
 
 endmenu
 
-- 
1.7.10.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 v4 10/10] arm: mvebu: select the pinctrl drivers for Armada 370 and Armada XP platforms

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

This patch actually enables pinctrl drivers for Armada 370 and XP.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/mach-mvebu/Kconfig |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5540a8b..a601a0b 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -10,6 +10,7 @@ config MACH_ARMADA_370_XP
 config MACH_ARMADA_370
bool Marvell Armada 370 boards
select MACH_ARMADA_370_XP
+   select PINCTRL_ARMADA_370
help
  Say 'Y' here if you want your kernel to support boards based
  on the Marvell Armada 370 SoC with device tree.
@@ -17,6 +18,7 @@ config MACH_ARMADA_370
 config MACH_ARMADA_XP
bool Marvell Armada XP boards
select MACH_ARMADA_370_XP
+   select PINCTRL_ARMADA_XP
help
  Say 'Y' here if you want your kernel to support boards based
  on the Marvell Armada XP SoC with device tree.
-- 
1.7.10.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 v4 08/10] ARM: mvebu: adjust Armada XP evaluation board DTS

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

The Armada XP evaluation board is based on the MV78460 Armava XP
SoC. Now that we have separate .dtsi files for the three different
SoCs of the Armada XP family, use the appropriate one as include for
the Armada XP evaluation board .dts file.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/boot/dts/armada-xp-db.dts |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-db.dts 
b/arch/arm/boot/dts/armada-xp-db.dts
index f97040d..b1fc728 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,11 +14,11 @@
  */
 
 /dts-v1/;
-/include/ armada-xp.dtsi
+/include/ armada-xp-mv78460.dtsi
 
 / {
model = Marvell Armada XP Evaluation Board;
-   compatible = marvell,axp-db, marvell,armadaxp, 
marvell,armada-370-xp;
+   compatible = marvell,axp-db, marvell,armadaxp-mv78460, 
marvell,armadaxp, marvell,armada-370-xp;
 
chosen {
bootargs = console=ttyS0,115200 earlyprintk;
-- 
1.7.10.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 v4 06/10] ARM: mvebu: Add pinctrl support to Armada XP SoCs

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

This commits adds the necessary device tree information to define the
compatible property for the pinctrl driver instance of Armada XP SoCs.

Until now, the device tree representation considered the Armada XP as
a single SoC. But in fact, there are three different SoCs in the
Armada XP families, with different number of CPU cores, different
number of Ethernet interfaces... and different number of muxable pins
or functions. We therefore introduce three armada-xp-mv78xx0.dtsi for
the three SoCs of the Armada XP family. The current armada-xp-db.dts
evaluation board uses the MV78460 variant of the SoC.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
v3:
- put specific variant into DT model

v4:
- adjust pinctrl DT node of Armada XP SoC

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   28 
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   28 
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   28 
 3 files changed, 84 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-xp-mv78230.dtsi
 create mode 100644 arch/arm/boot/dts/armada-xp-mv78260.dtsi
 create mode 100644 arch/arm/boot/dts/armada-xp-mv78460.dtsi

diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
new file mode 100644
index 000..38ede3d
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Include file for Marvell Armada XP family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Thomas Petazzoni thomas.petazz...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Contains definitions specific to the Armada XP MV78230 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+/include/ armada-xp.dtsi
+
+/ {
+   model = Marvell Armada XP MV78230 SoC;
+   compatible = marvell,armadaxp-mv78230, marvell,armadaxp, 
marvell,armada-370-xp;
+
+   soc {
+   pinctrl {
+   compatible = marvell,mv78230-pinctrl;
+   reg = 0xd0018000 0x38;
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
new file mode 100644
index 000..b2eafcd
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Include file for Marvell Armada XP family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Thomas Petazzoni thomas.petazz...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Contains definitions specific to the Armada XP MV78260 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+/include/ armada-xp.dtsi
+
+/ {
+   model = Marvell Armada XP MV78260 SoC;
+   compatible = marvell,armadaxp-mv78260, marvell,armadaxp, 
marvell,armada-370-xp;
+
+   soc {
+   pinctrl {
+   compatible = marvell,mv78260-pinctrl;
+   reg = 0xd0018000 0x38;
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
new file mode 100644
index 000..cf8624d
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Include file for Marvell Armada XP family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Thomas Petazzoni thomas.petazz...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Contains definitions specific to the Armada XP MV78460 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+/include/ armada-xp.dtsi
+
+/ {
+   model = Marvell Armada XP MV78460 SoC;
+   compatible = marvell,armadaxp-mv78460, marvell,armadaxp, 
marvell,armada-370-xp

[PATCH v4 05/10] pinctrl: mvebu: add pinctrl driver for Armada XP

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

This pinctrl driver is not a full-blown pinctrl driver from scratch:
it relies on the common pinctrl-mvebu driver, which is used for all
Marvell EBU SoCs.

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
v2:
- replaced variant with enum and used bitops.h

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../bindings/pinctrl/marvell,armada-xp-pinctrl.txt |  100 +
 drivers/pinctrl/Kconfig|4 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-armada-xp.c|  468 
 4 files changed, 573 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-armada-xp.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
new file mode 100644
index 000..bfa0a2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
@@ -0,0 +1,100 @@
+* Marvell Armada XP SoC pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage.
+
+Required properties:
+- compatible: marvell,mv78230-pinctrl, marvell,mv78260-pinctrl,
+  marvell,mv78460-pinctrl
+
+This driver supports all Armada XP variants, i.e. mv78230, mv78260, and 
mv78460.
+
+Available mpp pins/groups and functions:
+Note: brackets (x) are not part of the mpp name for marvell,function and given
+only for more detailed description in this document.
+
+* Marvell Armada XP (all variants)
+
+name  pins functions
+
+mpp0  0gpio, ge0(txclko), lcd(d0)
+mpp1  1gpio, ge0(txd0), lcd(d1)
+mpp2  2gpio, ge0(txd1), lcd(d2)
+mpp3  3gpio, ge0(txd2), lcd(d3)
+mpp4  4gpio, ge0(txd3), lcd(d4)
+mpp5  5gpio, ge0(txctl), lcd(d5)
+mpp6  6gpio, ge0(rxd0), lcd(d6)
+mpp7  7gpio, ge0(rxd1), lcd(d7)
+mpp8  8gpio, ge0(rxd2), lcd(d8)
+mpp9  9gpio, ge0(rxd3), lcd(d9)
+mpp10 10   gpio, ge0(rxctl), lcd(d10)
+mpp11 11   gpio, ge0(rxclk), lcd(d11)
+mpp12 12   gpio, ge0(txd4), ge1(txd0), lcd(d12)
+mpp13 13   gpio, ge0(txd5), ge1(txd1), lcd(d13)
+mpp14 14   gpio, ge0(txd6), ge1(txd2), lcd(d15)
+mpp15 15   gpio, ge0(txd7), ge1(txd3), lcd(d16)
+mpp16 16   gpio, ge0(txd7), ge1(txd3), lcd(d16)
+mpp17 17   gpio, ge0(col), ge1(txctl), lcd(d17)
+mpp18 18   gpio, ge0(rxerr), ge1(rxd0), lcd(d18), ptp(trig)
+mpp19 19   gpio, ge0(crs), ge1(rxd1), lcd(d19), ptp(evreq)
+mpp20 20   gpio, ge0(rxd4), ge1(rxd2), lcd(d20), ptp(clk)
+mpp21 21   gpio, ge0(rxd5), ge1(rxd3), lcd(d21), mem(bat)
+mpp22 22   gpio, ge0(rxd6), ge1(rxctl), lcd(d22), sata0(prsnt)
+mpp23 23   gpio, ge0(rxd7), ge1(rxclk), lcd(d23), sata1(prsnt)
+mpp24 24   gpio, lcd(hsync), sata1(prsnt), nf(bootcs-re), tdm(rst)
+mpp25 25   gpio, lcd(vsync), sata0(prsnt), nf(bootcs-we), tdm(pclk)
+mpp26 26   gpio, lcd(clk), tdm(fsync), vdd(cpu1-pd)
+mpp27 27   gpio, lcd(e), tdm(dtx), ptp(trig)
+mpp28 28   gpio, lcd(pwm), tdm(drx), ptp(evreq)
+mpp29 29   gpio, lcd(ref-clk), tdm(int0), ptp(clk), vdd(cpu0-pd)
+mpp30 30   gpio, tdm(int1), sd0(clk)
+mpp31 31   gpio, tdm(int2), sd0(cmd), vdd(cpu0-pd)
+mpp32 32   gpio, tdm(int3), sd0(d0), vdd(cpu1-pd)
+mpp33 33   gpio, tdm(int4), sd0(d1), mem(bat)
+mpp34 34   gpio, tdm(int5), sd0(d2), sata0(prsnt)
+mpp35 35   gpio, tdm(int6), sd0(d3), sata1(prsnt)
+mpp36 36   gpio, spi(mosi)
+mpp37 37   gpio, spi(miso)
+mpp38 38   gpio, spi(sck)
+mpp39 39   gpio, spi(cs0)
+mpp40 40   gpio, spi(cs1), uart2(cts), lcd(vga-hsync), 
vdd(cpu1-pd

[PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

This patch adds a SoC specific pinctrl driver for Marvell Kirkwood SoCs
plus DT binding documentation. This driver will use the mvebu pinctrl
driver core.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
v2:
- restructured pinctrl/Kconfig to hide pinctrl driver as it will be
  always selected by arch/arm/mach-mvebu/Kconfig
- use enum for kirkwood variants instead of defines

v3:
- moved variant specific data to DT match struct

v4:
- fix bogus v3 patch set

Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Russell King li...@arm.linux.org.uk
Cc: Lior Amsalem al...@marvell.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: Ben Dooks ben.do...@codethink.co.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
 .../bindings/pinctrl/marvell,kirkwood-pinctrl.txt  |  279 
 drivers/pinctrl/Kconfig|4 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-kirkwood.c |  472 
 4 files changed, 756 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-kirkwood.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
new file mode 100644
index 000..361bccb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
@@ -0,0 +1,279 @@
+* Marvell Kirkwood SoC pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage.
+
+Required properties:
+- compatible: marvell,88f6180-pinctrl,
+  marvell,88f6190-pinctrl, marvell,88f6192-pinctrl,
+  marvell,88f6281-pinctrl, marvell,88f6282-pinctrl
+
+This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 88f628x.
+
+Available mpp pins/groups and functions:
+Note: brackets (x) are not part of the mpp name for marvell,function and given
+only for more detailed description in this document.
+
+* Marvell Kirkwood 88f6180
+
+name  pins functions
+
+mpp0  0gpio, nand(io2), spi(cs)
+mpp1  1gpo, nand(io3), spi(mosi)
+mpp2  2gpo, nand(io4), spi(sck)
+mpp3  3gpo, nand(io5), spi(miso)
+mpp4  4gpio, nand(io6), uart0(rxd), ptp(clk)
+mpp5  5gpo, nand(io7), uart0(txd), ptp(trig)
+mpp6  6sysrst(out), spi(mosi), ptp(trig)
+mpp7  7gpo, pex(rsto), spi(cs), ptp(trig)
+mpp8  8gpio, twsi0(sda), uart0(rts), uart1(rts), ptp(clk),
+   mii(col)
+mpp9  9gpio, twsi(sck), uart0(cts), uart1(cts), ptp(evreq),
+   mii(crs)
+mpp10 10   gpo, spi(sck), uart0(txd), ptp(trig)
+mpp11 11   gpio, spi(miso), uart0(rxd), ptp(clk), ptp-1(evreq),
+   ptp-2(trig)
+mpp12 12   gpo, sdio(clk)
+mpp13 13   gpio, sdio(cmd), uart1(txd)
+mpp14 14   gpio, sdio(d0), uart1(rxd), mii(col)
+mpp15 15   gpio, sdio(d1), uart0(rts), uart1(txd)
+mpp16 16   gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs)
+mpp17 17   gpio, sdio(d3)
+mpp18 18   gpo, nand(io0)
+mpp19 19   gpo, nand(io1)
+mpp20 20   gpio, mii(rxerr)
+mpp21 21   gpio, audio(spdifi)
+mpp22 22   gpio, audio(spdifo)
+mpp23 23   gpio, audio(rmclk)
+mpp24 24   gpio, audio(bclk)
+mpp25 25   gpio, audio(sdo)
+mpp26 26   gpio, audio(lrclk)
+mpp27 27   gpio, audio(mclk)
+mpp28 28   gpio, audio(sdi)
+mpp29 29   gpio, audio(extclk)
+
+* Marvell Kirkwood 88f6190
+
+name  pins functions
+
+mpp0  0gpio, nand(io2), spi(cs)
+mpp1  1gpo, nand(io3), spi(mosi)
+mpp2  2gpo, nand(io4), spi(sck)
+mpp3  3gpo, nand(io5), spi(miso)
+mpp4  4gpio, nand(io6), uart0(rxd), ptp(clk)
+mpp5  5gpo, nand(io7), uart0(txd), ptp(trig), sata0(act)
+mpp6  6sysrst(out), spi(mosi), ptp(trig)
+mpp7  7gpo, pex(rsto), spi(cs), ptp(trig)
+mpp8  8gpio

[PATCH v4 01/10] pinctrl: mvebu: pinctrl driver core