Re: [PATCH 5/8 v6] thermal: rcar: enable to use thermal-zone on DT

[Kuninori Morimoto]

Hi

ping ?

> From: Kuninori Morimoto 
> 
> This patch enables to use thermal-zone on DT if it was calles as
> "renesas,rcar-thermal-gen2".
> Previous style (= non thermal-zone) is still supported by
> "renesas,rcar-thermal" to keep compatibility for "git bisect".
> 
> Signed-off-by: Kuninori Morimoto 
> ---
> v5 -> v6
> 
>  - "was call" -> "was called"
>  - add reason why it keeps previous style
> 
>  .../devicetree/bindings/thermal/rcar-thermal.txt   | 37 +-
>  drivers/thermal/rcar_thermal.c | 45 
> +++---
>  2 files changed, 75 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> index 332e625..e5ee3f1 100644
> --- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> @@ -1,8 +1,9 @@
>  * Renesas R-Car Thermal
>  
>  Required properties:
> -- compatible : "renesas,thermal-", "renesas,rcar-thermal"
> -   as fallback.
> +- compatible : "renesas,thermal-",
> +"renesas,rcar-gen2-thermal" (with thermal-zone) or
> +"renesas,rcar-thermal" (without thermal-zone) as 
> fallback.
> Examples with soctypes are:
>   - "renesas,thermal-r8a73a4" (R-Mobile APE6)
>   - "renesas,thermal-r8a7779" (R-Car H1)
> @@ -36,3 +37,35 @@ thermal@e61f {
>   0xe61f0300 0x38>;
>   interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
>  };
> +
> +Example (with thermal-zone):
> +
> +thermal-zones {
> + cpu_thermal: cpu-thermal {
> + polling-delay-passive   = <1000>;
> + polling-delay   = <5000>;
> +
> + thermal-sensors = <>;
> +
> + trips {
> + cpu-crit {
> + temperature = <115000>;
> + hysteresis  = <0>;
> + type= "critical";
> + };
> + };
> + cooling-maps {
> + };
> + };
> +};
> +
> +thermal: thermal@e61f {
> + compatible ="renesas,thermal-r8a7790",
> + "renesas,rcar-gen2-thermal",
> + "renesas,rcar-thermal";
> + reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
> + interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <_clks R8A7790_CLK_THERMAL>;
> + power-domains = <_clocks>;
> + #thermal-sensor-cells = <0>;
> +};
> diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
> index 30602f2..e92f29b 100644
> --- a/drivers/thermal/rcar_thermal.c
> +++ b/drivers/thermal/rcar_thermal.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -75,8 +76,10 @@ struct rcar_thermal_priv {
>  #define rcar_has_irq_support(priv)   ((priv)->common->base)
>  #define rcar_id_to_shift(priv)   ((priv)->id * 8)
>  
> +#define USE_OF_THERMAL   1
>  static const struct of_device_id rcar_thermal_dt_ids[] = {
>   { .compatible = "renesas,rcar-thermal", },
> + { .compatible = "renesas,rcar-gen2-thermal", .data = (void 
> *)USE_OF_THERMAL },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
> @@ -200,9 +203,9 @@ err_out_unlock:
>   return ret;
>  }
>  
> -static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
> +static int rcar_thermal_get_current_temp(struct rcar_thermal_priv *priv,
> +  int *temp)
>  {
> - struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
>   int tmp;
>   int ret;
>  
> @@ -226,6 +229,20 @@ static int rcar_thermal_get_temp(struct 
> thermal_zone_device *zone, int *temp)
>   return 0;
>  }
>  
> +static int rcar_thermal_of_get_temp(void *data, int *temp)
> +{
> + struct rcar_thermal_priv *priv = data;
> +
> + return rcar_thermal_get_current_temp(priv, temp);
> +}
> +
> +static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
> +{
> + struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
> +
> + return rcar_thermal_get_current_temp(priv, temp);
> +}
> +
>  static int rcar_thermal_get_trip_type(struct thermal_zone_device *zone,
> int trip, enum thermal_trip_type *type)
>  {
> @@ -282,6 +299,10 @@ static int rcar_thermal_notify(struct 
> thermal_zone_device *zone,
>   return 0;
>  }
>  
> +static const struct thermal_zone_of_device_ops rcar_thermal_zone_of_ops = {
> + .get_temp   = rcar_thermal_of_get_temp,
> +};
> +
>  static struct thermal_zone_device_ops rcar_thermal_zone_ops = {
>   .get_temp   = rcar_thermal_get_temp,
>   .get_trip_type  = 

Re: [PATCH v4 1/6] clk: hisilicon: add CRG driver for hi3519 soc

[Philipp Zabel]

H Jiancheng,

Am Mittwoch, den 30.12.2015, 09:43 +0800 schrieb Jiancheng Xue:
> The CRG(Clock and Reset Generator) block provides clock
> and reset signals for other modules in hi3519 soc.
> 
> Signed-off-by: Jiancheng Xue 
> ---
>  .../devicetree/bindings/clock/hi3519-crg.txt   |  46 +++
>  drivers/clk/hisilicon/Kconfig  |   7 +
>  drivers/clk/hisilicon/Makefile |   2 +
>  drivers/clk/hisilicon/clk-hi3519.c | 103 ++
>  drivers/clk/hisilicon/reset.c  | 149 
> +
>  drivers/clk/hisilicon/reset.h  |  32 +
>  include/dt-bindings/clock/hi3519-clock.h   |  43 ++
>  7 files changed, 382 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
>  create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
>  create mode 100644 drivers/clk/hisilicon/reset.c
>  create mode 100644 drivers/clk/hisilicon/reset.h
>  create mode 100644 include/dt-bindings/clock/hi3519-clock.h
> 
> diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt 
> b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
> new file mode 100644
> index 000..2d23950
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
> @@ -0,0 +1,46 @@
> +* Hisilicon Hi3519 Clock and Reset Generator(CRG)
> +
> +The Hi3519 CRG module provides clock and reset signals to various
> +controllers within the SoC.
> +
> +This binding uses the following bindings:
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +Documentation/devicetree/bindings/reset/reset.txt
> +
> +Required Properties:
> +
> +- compatible: should be one of the following.
> +  - "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
> +
> +- reg: physical base address of the controller and length of memory mapped
> +  region.
> +
> +- #clock-cells: should be 1.
> +
> +Each clock is assigned an identifier and client nodes use this identifier
> +to specify the clock which they consume.
> +
> +All these identifier could be found in .
> +
> +- #reset-cells: should be 2.
> +
> +A reset signal can be controlled by writing a bit register in the CRG module.
> +The reset specifier consists of two cells. The first cell represents the
> +register offset relative to the base address. The second cell represents the
> +bit index in the register.

Are the resets controlled by single bits spread around the register
space? If so, I'm fine with this binding.

> +Example: CRG nodes
> +CRG: clock-reset-controller@1201 {
> + compatible = "hisilicon,hi3519-crg";
> +reg = <0x1201 0x1>;
> +#clock-cells = <1>;
> +#reset-cells = <2>;
> +};
> +
> +Example: consumer nodes
> +i2c0: i2c@1211 {
> + compatible = "hisilicon,hi3519-i2c";
> +reg = <0x1211 0x1000>;
> +clocks = < HI3519_I2C0_RST>;*/
> +resets = < 0xe4 0>;
> +};
> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
> index e434854..b6baebf 100644
> --- a/drivers/clk/hisilicon/Kconfig
> +++ b/drivers/clk/hisilicon/Kconfig
> @@ -1,3 +1,10 @@
> +config COMMON_CLK_HI3519
> + tristate "Clock Driver for Hi3519"
> + depends on ARCH_HISI
> + default y
> + help
> +   Build the clock driver for hi3519.
> +
>  config COMMON_CLK_HI6220
>   bool "Hi6220 Clock Driver"
>   depends on ARCH_HISI || COMPILE_TEST
> diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
> index 74dba31..3f57b09 100644
> --- a/drivers/clk/hisilicon/Makefile
> +++ b/drivers/clk/hisilicon/Makefile
> @@ -4,8 +4,10 @@
>  
>  obj-y+= clk.o clkgate-separated.o clkdivider-hi6220.o
>  
> +obj-$(CONFIG_RESET_CONTROLLER)   += reset.o
>  obj-$(CONFIG_ARCH_HI3xxx)+= clk-hi3620.o
>  obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o
>  obj-$(CONFIG_ARCH_HIX5HD2)   += clk-hix5hd2.o
>  obj-$(CONFIG_COMMON_CLK_HI6220)  += clk-hi6220.o
>  obj-$(CONFIG_STUB_CLK_HI6220)+= clk-hi6220-stub.o
> +obj-$(CONFIG_COMMON_CLK_HI3519)  += clk-hi3519.o
> diff --git a/drivers/clk/hisilicon/clk-hi3519.c 
> b/drivers/clk/hisilicon/clk-hi3519.c
> new file mode 100644
> index 000..e220234
> --- /dev/null
> +++ b/drivers/clk/hisilicon/clk-hi3519.c
> @@ -0,0 +1,103 @@
> +/*
> + * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of 

Re: [PATCH v4 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl

[Philipp Zabel]

Am Mittwoch, den 30.12.2015, 09:43 +0800 schrieb Jiancheng Xue:
> Add device tree bindings for Hi3519 system controller.
> 
> Signed-off-by: Jiancheng Xue 
> ---
>  Documentation/devicetree/bindings/mfd/hi3519.txt | 14 ++
>  1 file changed, 14 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/hi3519.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/hi3519.txt 
> b/Documentation/devicetree/bindings/mfd/hi3519.txt
> new file mode 100644
> index 000..2536edc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/hi3519.txt
> @@ -0,0 +1,14 @@
> +* Hisilicon Hi3519 System Controller Block
> +
> +This bindings use the following binding:
> +Dcumentation/devicetree/bindings/clock/clock-bindings.txt

Typo: "Documentation"
- but I don't see the clock bindings being used here at all.
Maybe just drop this sentence?

> +
> +Required properties:
> +- compatible: "hisilicon,hi3519-sysctrl".
> +- reg: the register region of this block
> +
> +Examples:
> +sysctrl: system-controller@1201 {
> + compatible = "hisilicon,hi3519-sysctrl", "syscon";
> + reg = <0x1201 0x1000>;
> +};

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: export of_default_bus_match_table

[Arnd Bergmann]

On Tuesday 05 January 2016 11:17:53 Masahiro Yamada wrote:
> Currently, drivers/bus/uniphier-system-bus.c is kept from being a
> module due to the unresolved reference to of_default_bus_match_table.
> 
> Refer to commit 326ea45aa827 ("bus: uniphier: allow only built-in
> driver").
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/of/platform.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index af98343..8d103e4 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -31,6 +31,7 @@ const struct of_device_id of_default_bus_match_table[] = {
>  #endif /* CONFIG_ARM_AMBA */
> {} /* Empty terminated list */
>  };
> +EXPORT_SYMBOL(of_default_bus_match_table);

I wonder if the uniphier bus should actually use the default
match table at all. Sorry for not having thought of that when
I did my patch.

What kinds of devices do you see below this bus? Do you have multiple
levels of devices? Are they all platform devices or could they
be AMBA?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/10] i2c-mux: add common core data for every mux instance

[Peter Rosin]

Hi Guenter,

On 2016-01-04 16:37, Guenter Roeck wrote:
> On 01/04/2016 07:10 AM, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> The initial core mux structure starts off small with only the parent
>> adapter pointer, which all muxes have, and a priv pointer for mux
>> driver private data.
>>
>> Add i2c_mux_alloc function to unify the creation of a mux.
>>
>> Where appropriate, pass around the mux core structure instead of the
>> parent adapter or the driver private data.
>>
>> Remove the parent adapter pointer from the driver private data for all
>> mux drivers.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>   drivers/i2c/i2c-mux.c  | 35 
>> -
>>   drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 24 +++-
>>   drivers/i2c/muxes/i2c-mux-gpio.c   | 20 +
>>   drivers/i2c/muxes/i2c-mux-pca9541.c| 36 
>> --
>>   drivers/i2c/muxes/i2c-mux-pca954x.c| 22 +-
>>   drivers/i2c/muxes/i2c-mux-pinctrl.c| 24 +++-
>>   drivers/i2c/muxes/i2c-mux-reg.c| 25 -
>>   include/linux/i2c-mux.h| 14 +++-
>>   8 files changed, 129 insertions(+), 71 deletions(-)
>>

*snip*

>> +struct i2c_mux_core *i2c_mux_alloc(struct device *dev, int sizeof_priv)
>> +{
>> +struct i2c_mux_core *muxc;
>> +
>> +muxc = devm_kzalloc(dev, sizeof(*muxc), GFP_KERNEL);
>> +if (!muxc)
>> +return NULL;
>> +if (sizeof_priv) {
>> +muxc->priv = devm_kzalloc(dev, sizeof_priv, GFP_KERNEL);
>> +if (!muxc->priv)
>> +goto fail;
>> +}
> 
> Why not just allocate sizeof(*muxc) + sizeof_priv in a single operation
> and then assign muxc->priv to muxc + 1 if sizeof_priv > 0 ?

Why indeed, good suggestion.

*snip*

>> @@ -134,13 +134,14 @@ static int i2c_arbitrator_probe(struct platform_device 
>> *pdev)
>>   return -EINVAL;
>>   }
>>
>> -arb = devm_kzalloc(dev, sizeof(*arb), GFP_KERNEL);
>> -if (!arb) {
>> -dev_err(dev, "Cannot allocate i2c_arbitrator_data\n");
>> +muxc = i2c_mux_alloc(dev, sizeof(*arb));
>> +if (!muxc) {
>> +dev_err(dev, "Cannot allocate i2c_mux_core structure\n");
> 
> Unnecessary error message.
> 

Right, I'll remove that (and the others just like it).

I'll see if I can cook up a v2 that also converts the i2c muxes elsewhere in
drivers/ that I wasn't aware of.

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/6] clk: mediatek: Add MT2701 clock support

[Philipp Zabel]

Hi James,

Am Dienstag, den 05.01.2016, 14:30 +0800 schrieb James Liao:
> From: Shunli Wang 
> 
> Add MT2701 clock support, include topckgen, apmixedsys,
> infracfg, pericfg and subsystem clocks.
> 
> Signed-off-by: Shunli Wang 
> Signed-off-by: James Liao 
> ---
>  drivers/clk/mediatek/Kconfig  |8 +
>  drivers/clk/mediatek/Makefile |1 +
>  drivers/clk/mediatek/clk-gate.c   |   56 ++
>  drivers/clk/mediatek/clk-gate.h   |2 +
>  drivers/clk/mediatek/clk-mt2701.c | 1210 
> +
>  drivers/clk/mediatek/clk-mtk.c|   25 +
>  drivers/clk/mediatek/clk-mtk.h|   35 +-
>  7 files changed, 1334 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/clk/mediatek/clk-mt2701.c
> 
> diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> index dc224e6..6c7cdc0 100644
> --- a/drivers/clk/mediatek/Kconfig
> +++ b/drivers/clk/mediatek/Kconfig
> @@ -6,6 +6,14 @@ config COMMON_CLK_MEDIATEK
>   ---help---
> Mediatek SoCs' clock support.
>  
> +config COMMON_CLK_MT2701
> + bool "Clock driver for Mediatek MT2701 and MT7623"
> + depends on COMMON_CLK
> + select COMMON_CLK_MEDIATEK
> + default ARCH_MEDIATEK
> + ---help---
> +   This driver supports Mediatek MT2701 and MT7623 clocks.
> +
>  config COMMON_CLK_MT8135
>   bool "Clock driver for Mediatek MT8135"
>   depends on COMMON_CLK
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index 32e7222..5b2b91b 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o 
> clk-apmixed.o
>  obj-$(CONFIG_RESET_CONTROLLER) += reset.o
> +obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
>  obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
>  obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
> diff --git a/drivers/clk/mediatek/clk-gate.c b/drivers/clk/mediatek/clk-gate.c
> index 576bdb7..38badb4 100644
> --- a/drivers/clk/mediatek/clk-gate.c
> +++ b/drivers/clk/mediatek/clk-gate.c
> @@ -61,6 +61,26 @@ static void mtk_cg_clr_bit(struct clk_hw *hw)
>   regmap_write(cg->regmap, cg->clr_ofs, BIT(cg->bit));
>  }
>  
> +static void mtk_cg_set_bit_no_setclr(struct clk_hw *hw)
> +{
> + struct mtk_clk_gate *cg = to_clk_gate(hw);
> + u32 val;
> +
> + regmap_read(cg->regmap, cg->sta_ofs, );
> + val |= BIT(cg->bit);
> + regmap_write(cg->regmap, cg->sta_ofs, val);

You can use regmap_update_bits here:

u32 bit = BIT(cg->bit);
regmap_update_bits(cg->regmap, cg->sta_ofs, bit, bit);

> +}
> +
> +static void mtk_cg_clr_bit_no_setclr(struct clk_hw *hw)
> +{
> + struct mtk_clk_gate *cg = to_clk_gate(hw);
> + u32 val;
> +
> + regmap_read(cg->regmap, cg->sta_ofs, );
> + val &= ~(BIT(cg->bit));
> + regmap_write(cg->regmap, cg->sta_ofs, val);

and here:

u32 bit = BIT(cg->bit);
regmap_update_bits(cg->regmap, cg->sta_ofs, bit, 0);

best regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/6] clk: mediatek: Add MT2701 clock support

[James Liao]

Hi Philipp,

On Tue, 2016-01-05 at 10:30 +0100, Philipp Zabel wrote:
> Hi James,
> 
> Am Dienstag, den 05.01.2016, 14:30 +0800 schrieb James Liao:
> > From: Shunli Wang 
> > 
> > Add MT2701 clock support, include topckgen, apmixedsys,
> > infracfg, pericfg and subsystem clocks.
> > 
> > Signed-off-by: Shunli Wang 
> > Signed-off-by: James Liao 
> > ---
> >  drivers/clk/mediatek/Kconfig  |8 +
> >  drivers/clk/mediatek/Makefile |1 +
> >  drivers/clk/mediatek/clk-gate.c   |   56 ++
> >  drivers/clk/mediatek/clk-gate.h   |2 +
> >  drivers/clk/mediatek/clk-mt2701.c | 1210 
> > +
> >  drivers/clk/mediatek/clk-mtk.c|   25 +
> >  drivers/clk/mediatek/clk-mtk.h|   35 +-
> >  7 files changed, 1334 insertions(+), 3 deletions(-)
> >  create mode 100644 drivers/clk/mediatek/clk-mt2701.c
> > 
> > diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> > index dc224e6..6c7cdc0 100644
> > --- a/drivers/clk/mediatek/Kconfig
> > +++ b/drivers/clk/mediatek/Kconfig
> > @@ -6,6 +6,14 @@ config COMMON_CLK_MEDIATEK
> > ---help---
> >   Mediatek SoCs' clock support.
> >  
> > +config COMMON_CLK_MT2701
> > +   bool "Clock driver for Mediatek MT2701 and MT7623"
> > +   depends on COMMON_CLK
> > +   select COMMON_CLK_MEDIATEK
> > +   default ARCH_MEDIATEK
> > +   ---help---
> > + This driver supports Mediatek MT2701 and MT7623 clocks.
> > +
> >  config COMMON_CLK_MT8135
> > bool "Clock driver for Mediatek MT8135"
> > depends on COMMON_CLK
> > diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> > index 32e7222..5b2b91b 100644
> > --- a/drivers/clk/mediatek/Makefile
> > +++ b/drivers/clk/mediatek/Makefile
> > @@ -1,4 +1,5 @@
> >  obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o 
> > clk-apmixed.o
> >  obj-$(CONFIG_RESET_CONTROLLER) += reset.o
> > +obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
> >  obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
> >  obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
> > diff --git a/drivers/clk/mediatek/clk-gate.c 
> > b/drivers/clk/mediatek/clk-gate.c
> > index 576bdb7..38badb4 100644
> > --- a/drivers/clk/mediatek/clk-gate.c
> > +++ b/drivers/clk/mediatek/clk-gate.c
> > @@ -61,6 +61,26 @@ static void mtk_cg_clr_bit(struct clk_hw *hw)
> > regmap_write(cg->regmap, cg->clr_ofs, BIT(cg->bit));
> >  }
> >  
> > +static void mtk_cg_set_bit_no_setclr(struct clk_hw *hw)
> > +{
> > +   struct mtk_clk_gate *cg = to_clk_gate(hw);
> > +   u32 val;
> > +
> > +   regmap_read(cg->regmap, cg->sta_ofs, );
> > +   val |= BIT(cg->bit);
> > +   regmap_write(cg->regmap, cg->sta_ofs, val);
> 
> You can use regmap_update_bits here:
> 
>   u32 bit = BIT(cg->bit);
>   regmap_update_bits(cg->regmap, cg->sta_ofs, bit, bit);
> 
> > +}
> > +
> > +static void mtk_cg_clr_bit_no_setclr(struct clk_hw *hw)
> > +{
> > +   struct mtk_clk_gate *cg = to_clk_gate(hw);
> > +   u32 val;
> > +
> > +   regmap_read(cg->regmap, cg->sta_ofs, );
> > +   val &= ~(BIT(cg->bit));
> > +   regmap_write(cg->regmap, cg->sta_ofs, val);
> 
> and here:
> 
>   u32 bit = BIT(cg->bit);
>   regmap_update_bits(cg->regmap, cg->sta_ofs, bit, 0);

OK. I'll change it in next patch. Thanks.


Best regards,

James


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] ARM64: dts: mt8173: Add CPU OPP, clock and regulator supply properties

[Arnd Bergmann]

On Monday 28 December 2015 08:43:40 Viresh Kumar wrote:
> On 27-12-15, 14:21, Pi-Cheng Chen wrote:
> > Add operating-points-v2, clock, and regulator supply properties
> > required by mt8173-cpufreq driver to enable it.
> > 
> > Signed-off-by: Pi-Cheng Chen 
> > ---
> > This patch is based on the patch[1] that adds underlying clock MUX for
> > MT8173 which is needed by mt8173-cpufreq driver but not yet picked.
> > 
> > [1] http://article.gmane.org/gmane.linux.kernel.clk/325
> > ---
> >  arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi| 90 
> > +
> >  2 files changed, 108 insertions(+)
> 
> Acked-by: Viresh Kumar 
> 

This patch is now in linux-next through Rafael's pm tree, and it breaks the
arm64 build:

arm64-defconfig
Error: ../arch/arm64/boot/dts/mediatek/mt8173.dtsi:132.24-25 syntax error


Please revert.

In the future, please send all dts changes through the proper maintainer
channels (-> Mattias -> arm-soc), and make sure they actually build.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] ARM64: dts: mt8173: Add CPU OPP, clock and regulator supply properties

[Viresh Kumar]

On 05-01-16, 11:21, Arnd Bergmann wrote:
> On Monday 28 December 2015 08:43:40 Viresh Kumar wrote:
> > On 27-12-15, 14:21, Pi-Cheng Chen wrote:
> > > Add operating-points-v2, clock, and regulator supply properties
> > > required by mt8173-cpufreq driver to enable it.
> > > 
> > > Signed-off-by: Pi-Cheng Chen 
> > > ---
> > > This patch is based on the patch[1] that adds underlying clock MUX for
> > > MT8173 which is needed by mt8173-cpufreq driver but not yet picked.
> > > 
> > > [1] http://article.gmane.org/gmane.linux.kernel.clk/325
> > > ---
> > >  arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++
> > >  arch/arm64/boot/dts/mediatek/mt8173.dtsi| 90 
> > > +
> > >  2 files changed, 108 insertions(+)
> > 
> > Acked-by: Viresh Kumar 
> > 
> 
> This patch is now in linux-next through Rafael's pm tree, and it breaks the
> arm64 build:
> 
> arm64-defconfig
> Error: ../arch/arm64/boot/dts/mediatek/mt8173.dtsi:132.24-25 syntax error
> 
> 
> Please revert.
> 
> In the future, please send all dts changes through the proper maintainer
> channels (-> Mattias -> arm-soc), and make sure they actually build.

Rafael has already reverted that, AFAIK, after Mark Brown reported the
build issue.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: host: arasan: sdhci-of-arasan: Remove no-hispd and no-cmd23 quirks for sdhci-arasan4.9a

[Rameshwar Sahu]

Hi Ulf,

On Wed, Dec 23, 2015 at 6:59 PM, Rameshswar Prasad Sahu  wrote:
> From: Rameshwar Prasad Sahu 
>
> The Arason SD host controller supports set block count command (cmd23)
> and high speed mode. This patch re-enable both of these features that
> was disabled. For device that doesn't support high speed, it should
> configure its capability register accordingly instead disables it
> explicitly.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/mmc/host/sdhci-of-arasan.c |5 -
>  1 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
> b/drivers/mmc/host/sdhci-of-arasan.c
> index 75379cb..5d9fdb3 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -172,11 +172,6 @@ static int sdhci_arasan_probe(struct platform_device 
> *pdev)
> goto clk_disable_all;
> }
>
> -   if (of_device_is_compatible(pdev->dev.of_node, "arasan,sdhci-4.9a")) {
> -   host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
> -   host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
> -   }
> -
> sdhci_get_of_property(pdev);
> pltfm_host = sdhci_priv(host);
> pltfm_host->priv = sdhci_arasan;
> --
> 1.7.1
>

Any comment on this patch ??
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/6] reset: mediatek: mt2701 reset driver

[Philipp Zabel]

Am Dienstag, den 05.01.2016, 14:30 +0800 schrieb James Liao:
> From: Shunli Wang 
> 
> In infrasys and perifsys, there are many reset
> control bits for kinds of modules. These bits are
> used as actual reset controllers to be registered
> into kernel's generic reset controller framework.
> 
> Signed-off-by: Shunli Wang 

Acked-by: Philipp Zabel 

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/6] reset: mediatek: mt2701 reset controller dt-binding file

[Philipp Zabel]

Am Dienstag, den 05.01.2016, 14:30 +0800 schrieb James Liao:
> From: Shunli Wang 
> 
> Dt-binding file about reset controller is used to provide
> kinds of definition, which is referenced by dts file and
> IC-specified reset controller driver code.
> 
> Signed-off-by: Shunli Wang 
> ---
>  .../dt-bindings/reset-controller/mt2701-resets.h   | 74 
> ++
>  1 file changed, 74 insertions(+)
>  create mode 100644 include/dt-bindings/reset-controller/mt2701-resets.h
> 
> diff --git a/include/dt-bindings/reset-controller/mt2701-resets.h 
> b/include/dt-bindings/reset-controller/mt2701-resets.h

No new files in include/dt-bindings/reset-controller, please.
This should go into include/dt-bindings/reset.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/6] reset: mediatek: mt2701 reset controller dt-binding file

[James Liao]

Hi Philipp,

On Tue, 2016-01-05 at 10:31 +0100, Philipp Zabel wrote:
> Am Dienstag, den 05.01.2016, 14:30 +0800 schrieb James Liao:
> > From: Shunli Wang 
> > 
> > Dt-binding file about reset controller is used to provide
> > kinds of definition, which is referenced by dts file and
> > IC-specified reset controller driver code.
> > 
> > Signed-off-by: Shunli Wang 
> > ---
> >  .../dt-bindings/reset-controller/mt2701-resets.h   | 74 
> > ++
> >  1 file changed, 74 insertions(+)
> >  create mode 100644 include/dt-bindings/reset-controller/mt2701-resets.h
> > 
> > diff --git a/include/dt-bindings/reset-controller/mt2701-resets.h 
> > b/include/dt-bindings/reset-controller/mt2701-resets.h
> 
> No new files in include/dt-bindings/reset-controller, please.
> This should go into include/dt-bindings/reset.

OK, I'll move it to include/dt-bindings/reset/.


Best regards,

James


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V11 4/7] dma: add Qualcomm Technologies HIDMA channel driver

[Sinan Kaya]

On 1/4/2016 1:43 PM, Andy Shevchenko wrote:
>> his patch adds support for hidma engine. The driver consists of two
>> > logical blocks. The DMA engine interface and the low-level interface.
>> > The hardware only supports memcpy/memset and this driver only support
>> > memcpy interface. HW and driver doesn't support slave interface.
>> >
> Looks fine now.
> 
> Reviewed-by: Andy Shevchenko 
> 

Thanks. I'll wait until the end of the week to address your other comments.
I'm hoping to hear from devicetree folks until that time.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/8] i2c-mux: move select and deselect ops to i2c_mux_core

[Peter Rosin]

From: Peter Rosin 

The mux select and deselect ops are common to the mux most of the time,
so store the ops in the mux core.

Change the select and deselect op to work in terms of the mux core instead
of the child adapter. No driver uses the child adapter anyway, and if it
is needed in a future mux driver it can be worked out from the channel id.

i2c-arb-gpio-challenge is special in that it needs the mux device pointer
in the select op, so store that device pointer in the mux core as well.
This pointer is going to get further use in later commits.

i2c-mux-pca954x is special since it does not add its deselect op to all
its child adapters, handle this by adding a mask that makes the deselect
op a no-operation for child adapters not wishing to deselect the mux.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/i2c-mux.c  | 31 ++
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 18 -
 drivers/i2c/muxes/i2c-mux-gpio.c   | 19 +-
 drivers/i2c/muxes/i2c-mux-pca9541.c| 18 +
 drivers/i2c/muxes/i2c-mux-pca954x.c| 30 +
 drivers/i2c/muxes/i2c-mux-pinctrl.c| 20 ---
 drivers/i2c/muxes/i2c-mux-reg.c| 21 +---
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 17 +++-
 drivers/media/dvb-frontends/m88ds3103.c|  8 
 drivers/media/dvb-frontends/rtl2830.c  |  8 
 drivers/media/dvb-frontends/rtl2832.c  | 15 ---
 drivers/media/dvb-frontends/si2168.c   | 13 +++--
 drivers/media/usb/cx231xx/cx231xx-i2c.c| 12 
 drivers/of/unittest.c  |  7 +++
 include/linux/i2c-mux.h| 15 ---
 15 files changed, 118 insertions(+), 134 deletions(-)

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index c2163f6b51d5..6c5cb9f7649b 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -32,13 +32,8 @@ struct i2c_mux_priv {
struct i2c_adapter adap;
struct i2c_algorithm algo;
struct i2c_mux_core *muxc;
-
struct device *mux_dev;
-   void *mux_priv;
u32 chan_id;
-
-   int (*select)(struct i2c_adapter *, void *mux_priv, u32 chan_id);
-   int (*deselect)(struct i2c_adapter *, void *mux_priv, u32 chan_id);
 };
 
 static int i2c_mux_master_xfer(struct i2c_adapter *adap,
@@ -51,11 +46,11 @@ static int i2c_mux_master_xfer(struct i2c_adapter *adap,
 
/* Switch to the right mux port and perform the transfer. */
 
-   ret = priv->select(parent, priv->mux_priv, priv->chan_id);
+   ret = muxc->select(muxc, priv->chan_id);
if (ret >= 0)
ret = __i2c_transfer(parent, msgs, num);
-   if (priv->deselect)
-   priv->deselect(parent, priv->mux_priv, priv->chan_id);
+   if (muxc->deselect)
+   muxc->deselect(muxc, priv->chan_id);
 
return ret;
 }
@@ -72,12 +67,12 @@ static int i2c_mux_smbus_xfer(struct i2c_adapter *adap,
 
/* Select the right mux port and perform the transfer. */
 
-   ret = priv->select(parent, priv->mux_priv, priv->chan_id);
+   ret = muxc->select(muxc, priv->chan_id);
if (ret >= 0)
ret = parent->algo->smbus_xfer(parent, addr, flags,
read_write, command, size, data);
-   if (priv->deselect)
-   priv->deselect(parent, priv->mux_priv, priv->chan_id);
+   if (muxc->deselect)
+   muxc->deselect(muxc, priv->chan_id);
 
return ret;
 }
@@ -113,18 +108,15 @@ struct i2c_mux_core *i2c_mux_alloc(struct device *dev, 
int sizeof_priv)
return NULL;
if (sizeof_priv)
muxc->priv = muxc + 1;
+   muxc->dev = dev;
return muxc;
 }
 EXPORT_SYMBOL_GPL(i2c_mux_alloc);
 
 struct i2c_adapter *i2c_add_mux_adapter(struct i2c_mux_core *muxc,
-   struct device *mux_dev,
-   void *mux_priv, u32 force_nr, u32 chan_id,
-   unsigned int class,
-   int (*select) (struct i2c_adapter *,
-  void *, u32),
-   int (*deselect) (struct i2c_adapter *,
-void *, u32))
+   struct device *mux_dev,
+   u32 force_nr, u32 chan_id,
+   unsigned int class)
 {
struct i2c_adapter *parent = muxc->parent;
struct i2c_mux_priv *priv;
@@ -138,10 +130,7 @@ struct i2c_adapter *i2c_add_mux_adapter(struct 
i2c_mux_core *muxc,
/* Set up private adapter data */
priv->muxc = muxc;
priv->mux_dev = mux_dev;
-   priv->mux_priv = mux_priv;
priv->chan_id = chan_id;
-  

[PATCH v2 1/8] i2c-mux: add common core data for every mux instance

[Peter Rosin]

From: Peter Rosin 

The initial core mux structure starts off small with only the parent
adapter pointer, which all muxes have, and a priv pointer for mux
driver private data.

Add i2c_mux_alloc function to unify the creation of a mux.

Where appropriate, pass around the mux core structure instead of the
parent adapter or the driver private data.

Remove the parent adapter pointer from the driver private data for all
mux drivers.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/i2c-mux.c| 28 +-
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c   | 24 +--
 drivers/i2c/muxes/i2c-mux-gpio.c | 20 
 drivers/i2c/muxes/i2c-mux-pca9541.c  | 35 ++--
 drivers/i2c/muxes/i2c-mux-pca954x.c  | 19 ++-
 drivers/i2c/muxes/i2c-mux-pinctrl.c  | 23 +-
 drivers/i2c/muxes/i2c-mux-reg.c  | 23 ++
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c   | 10 +++-
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h|  1 +
 drivers/media/dvb-frontends/m88ds3103.c  | 10 +++-
 drivers/media/dvb-frontends/m88ds3103_priv.h |  1 +
 drivers/media/dvb-frontends/rtl2830.c| 10 +++-
 drivers/media/dvb-frontends/rtl2830_priv.h   |  1 +
 drivers/media/dvb-frontends/rtl2832.c| 10 +++-
 drivers/media/dvb-frontends/rtl2832_priv.h   |  1 +
 drivers/media/dvb-frontends/si2168.c | 10 +++-
 drivers/media/dvb-frontends/si2168_priv.h|  1 +
 drivers/media/usb/cx231xx/cx231xx-core.c |  3 +++
 drivers/media/usb/cx231xx/cx231xx-i2c.c  | 13 +--
 drivers/media/usb/cx231xx/cx231xx.h  |  2 ++
 drivers/of/unittest.c| 16 +++--
 include/linux/i2c-mux.h  | 14 ++-
 22 files changed, 187 insertions(+), 88 deletions(-)

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 00fc5b1c7b66..c2163f6b51d5 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -31,8 +31,8 @@
 struct i2c_mux_priv {
struct i2c_adapter adap;
struct i2c_algorithm algo;
+   struct i2c_mux_core *muxc;
 
-   struct i2c_adapter *parent;
struct device *mux_dev;
void *mux_priv;
u32 chan_id;
@@ -45,7 +45,8 @@ static int i2c_mux_master_xfer(struct i2c_adapter *adap,
   struct i2c_msg msgs[], int num)
 {
struct i2c_mux_priv *priv = adap->algo_data;
-   struct i2c_adapter *parent = priv->parent;
+   struct i2c_mux_core *muxc = priv->muxc;
+   struct i2c_adapter *parent = muxc->parent;
int ret;
 
/* Switch to the right mux port and perform the transfer. */
@@ -65,7 +66,8 @@ static int i2c_mux_smbus_xfer(struct i2c_adapter *adap,
  int size, union i2c_smbus_data *data)
 {
struct i2c_mux_priv *priv = adap->algo_data;
-   struct i2c_adapter *parent = priv->parent;
+   struct i2c_mux_core *muxc = priv->muxc;
+   struct i2c_adapter *parent = muxc->parent;
int ret;
 
/* Select the right mux port and perform the transfer. */
@@ -84,7 +86,7 @@ static int i2c_mux_smbus_xfer(struct i2c_adapter *adap,
 static u32 i2c_mux_functionality(struct i2c_adapter *adap)
 {
struct i2c_mux_priv *priv = adap->algo_data;
-   struct i2c_adapter *parent = priv->parent;
+   struct i2c_adapter *parent = priv->muxc->parent;
 
return parent->algo->functionality(parent);
 }
@@ -102,7 +104,20 @@ static unsigned int i2c_mux_parent_classes(struct 
i2c_adapter *parent)
return class;
 }
 
-struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter *parent,
+struct i2c_mux_core *i2c_mux_alloc(struct device *dev, int sizeof_priv)
+{
+   struct i2c_mux_core *muxc;
+
+   muxc = devm_kzalloc(dev, sizeof(*muxc) + sizeof_priv, GFP_KERNEL);
+   if (!muxc)
+   return NULL;
+   if (sizeof_priv)
+   muxc->priv = muxc + 1;
+   return muxc;
+}
+EXPORT_SYMBOL_GPL(i2c_mux_alloc);
+
+struct i2c_adapter *i2c_add_mux_adapter(struct i2c_mux_core *muxc,
struct device *mux_dev,
void *mux_priv, u32 force_nr, u32 chan_id,
unsigned int class,
@@ -111,6 +126,7 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter 
*parent,
int (*deselect) (struct i2c_adapter *,
 void *, u32))
 {
+   struct i2c_adapter *parent = muxc->parent;
struct i2c_mux_priv *priv;
char symlink_name[20];
int ret;
@@ -120,7 +136,7 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter 
*parent,
return NULL;
 
/* Set up private adapter data */
-   priv->parent = parent;
+   priv->muxc = muxc;
priv->mux_dev = mux_dev;
priv->mux_priv = 

[PATCH v2 7/8] i2c: muxes always lock the parent adapter

[Peter Rosin]

From: Peter Rosin 

Instead of checking for i2c parent adapters for every lock/unlock, simply
override the locking for muxes to always lock/unlock the parent adapter
directly.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/i2c-core.c | 21 +++--
 drivers/i2c/i2c-mux.c  | 27 +++
 2 files changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 34a7748b4652..4683777f81ca 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -963,12 +963,7 @@ static int i2c_check_addr_busy(struct i2c_adapter 
*adapter, int addr)
  */
 static void i2c_adapter_lock_bus(struct i2c_adapter *adapter, int flags)
 {
-   struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
-
-   if (parent)
-   i2c_lock_adapter(parent);
-   else
-   rt_mutex_lock(>bus_lock);
+   rt_mutex_lock(>bus_lock);
 }
 
 /**
@@ -977,12 +972,7 @@ static void i2c_adapter_lock_bus(struct i2c_adapter 
*adapter, int flags)
  */
 static int i2c_adapter_trylock_bus(struct i2c_adapter *adapter, int flags)
 {
-   struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
-
-   if (parent)
-   return parent->trylock_bus(parent, flags);
-   else
-   return rt_mutex_trylock(>bus_lock);
+   return rt_mutex_trylock(>bus_lock);
 }
 
 /**
@@ -991,12 +981,7 @@ static int i2c_adapter_trylock_bus(struct i2c_adapter 
*adapter, int flags)
  */
 static void i2c_adapter_unlock_bus(struct i2c_adapter *adapter, int flags)
 {
-   struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
-
-   if (parent)
-   i2c_unlock_adapter(parent);
-   else
-   rt_mutex_unlock(>bus_lock);
+   rt_mutex_unlock(>bus_lock);
 }
 
 static void i2c_dev_set_name(struct i2c_adapter *adap,
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 5c1088079231..dd8a790cb4cc 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -98,6 +98,30 @@ static unsigned int i2c_mux_parent_classes(struct 
i2c_adapter *parent)
return class;
 }
 
+static void i2c_parent_lock_bus(struct i2c_adapter *adapter, int flags)
+{
+   struct i2c_mux_priv *priv = adapter->algo_data;
+   struct i2c_adapter *parent = priv->muxc->parent;
+
+   parent->lock_bus(parent, flags);
+}
+
+static int i2c_parent_trylock_bus(struct i2c_adapter *adapter, int flags)
+{
+   struct i2c_mux_priv *priv = adapter->algo_data;
+   struct i2c_adapter *parent = priv->muxc->parent;
+
+   return parent->trylock_bus(parent, flags);
+}
+
+static void i2c_parent_unlock_bus(struct i2c_adapter *adapter, int flags)
+{
+   struct i2c_mux_priv *priv = adapter->algo_data;
+   struct i2c_adapter *parent = priv->muxc->parent;
+
+   parent->unlock_bus(parent, flags);
+}
+
 int i2c_mux_reserve_adapters(struct i2c_mux_core *muxc, int adapters)
 {
struct i2c_adapter **adapter;
@@ -181,6 +205,9 @@ int i2c_add_mux_adapter(struct i2c_mux_core *muxc,
priv->adap.retries = parent->retries;
priv->adap.timeout = parent->timeout;
priv->adap.quirks = parent->quirks;
+   priv->adap.lock_bus = i2c_parent_lock_bus;
+   priv->adap.trylock_bus = i2c_parent_trylock_bus;
+   priv->adap.unlock_bus = i2c_parent_unlock_bus;
 
/* Sanity check on class */
if (i2c_mux_parent_classes(parent) & class)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/8] i2c-mux: pinctrl: get rid of the driver private struct device pointer

[Peter Rosin]

From: Peter Rosin 

There is a copy of the device pointer in the mux core.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/muxes/i2c-mux-pinctrl.c | 23 ---
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/i2c/muxes/i2c-mux-pinctrl.c 
b/drivers/i2c/muxes/i2c-mux-pinctrl.c
index 0dc912898813..38129850cbe4 100644
--- a/drivers/i2c/muxes/i2c-mux-pinctrl.c
+++ b/drivers/i2c/muxes/i2c-mux-pinctrl.c
@@ -26,7 +26,6 @@
 #include 
 
 struct i2c_mux_pinctrl {
-   struct device *dev;
struct i2c_mux_pinctrl_platform_data *pdata;
struct pinctrl *pinctrl;
struct pinctrl_state **states;
@@ -51,6 +50,7 @@ static int i2c_mux_pinctrl_deselect(struct i2c_mux_core 
*muxc, u32 chan)
 static int i2c_mux_pinctrl_parse_dt(struct i2c_mux_pinctrl *mux,
struct platform_device *pdev)
 {
+   struct i2c_mux_core *muxc = platform_get_drvdata(pdev);
struct device_node *np = pdev->dev.of_node;
int num_names, i, ret;
struct device_node *adapter_np;
@@ -60,15 +60,12 @@ static int i2c_mux_pinctrl_parse_dt(struct i2c_mux_pinctrl 
*mux,
return 0;
 
mux->pdata = devm_kzalloc(>dev, sizeof(*mux->pdata), GFP_KERNEL);
-   if (!mux->pdata) {
-   dev_err(mux->dev,
-   "Cannot allocate i2c_mux_pinctrl_platform_data\n");
+   if (!mux->pdata)
return -ENOMEM;
-   }
 
num_names = of_property_count_strings(np, "pinctrl-names");
if (num_names < 0) {
-   dev_err(mux->dev, "Cannot parse pinctrl-names: %d\n",
+   dev_err(muxc->dev, "Cannot parse pinctrl-names: %d\n",
num_names);
return num_names;
}
@@ -76,23 +73,21 @@ static int i2c_mux_pinctrl_parse_dt(struct i2c_mux_pinctrl 
*mux,
mux->pdata->pinctrl_states = devm_kzalloc(>dev,
sizeof(*mux->pdata->pinctrl_states) * num_names,
GFP_KERNEL);
-   if (!mux->pdata->pinctrl_states) {
-   dev_err(mux->dev, "Cannot allocate pinctrl_states\n");
+   if (!mux->pdata->pinctrl_states)
return -ENOMEM;
-   }
 
for (i = 0; i < num_names; i++) {
ret = of_property_read_string_index(np, "pinctrl-names", i,
>pdata->pinctrl_states[mux->pdata->bus_count]);
if (ret < 0) {
-   dev_err(mux->dev, "Cannot parse pinctrl-names: %d\n",
+   dev_err(muxc->dev, "Cannot parse pinctrl-names: %d\n",
ret);
return ret;
}
if (!strcmp(mux->pdata->pinctrl_states[mux->pdata->bus_count],
"idle")) {
if (i != num_names - 1) {
-   dev_err(mux->dev, "idle state must be last\n");
+   dev_err(muxc->dev, "idle state must be last\n");
return -EINVAL;
}
mux->pdata->pinctrl_state_idle = "idle";
@@ -103,13 +98,13 @@ static int i2c_mux_pinctrl_parse_dt(struct i2c_mux_pinctrl 
*mux,
 
adapter_np = of_parse_phandle(np, "i2c-parent", 0);
if (!adapter_np) {
-   dev_err(mux->dev, "Cannot parse i2c-parent\n");
+   dev_err(muxc->dev, "Cannot parse i2c-parent\n");
return -ENODEV;
}
adapter = of_find_i2c_adapter_by_node(adapter_np);
of_node_put(adapter_np);
if (!adapter) {
-   dev_err(mux->dev, "Cannot find parent bus\n");
+   dev_err(muxc->dev, "Cannot find parent bus\n");
return -EPROBE_DEFER;
}
mux->pdata->parent_bus_num = i2c_adapter_id(adapter);
@@ -139,8 +134,6 @@ static int i2c_mux_pinctrl_probe(struct platform_device 
*pdev)
mux = i2c_mux_priv(muxc);
platform_set_drvdata(pdev, muxc);
 
-   mux->dev = >dev;
-
mux->pdata = dev_get_platdata(>dev);
if (!mux->pdata) {
ret = i2c_mux_pinctrl_parse_dt(mux, pdev);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/8] i2c-mux: remove the mux dev pointer from the mux per channel data

[Peter Rosin]

From: Peter Rosin 

The dev pointer is readily available in the mux core struct, no point in
keeping multiple copies around.

The patch also fixes a bug in rtl2832, which attached its mux slave
adapter to the device owning the mux parent adapter instead of
attaching it to its own device.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/i2c-mux.c  | 24 
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c |  2 +-
 drivers/i2c/muxes/i2c-mux-gpio.c   |  3 +--
 drivers/i2c/muxes/i2c-mux-pca9541.c|  2 +-
 drivers/i2c/muxes/i2c-mux-pca954x.c|  3 +--
 drivers/i2c/muxes/i2c-mux-pinctrl.c|  3 +--
 drivers/i2c/muxes/i2c-mux-reg.c|  3 +--
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c |  2 +-
 drivers/media/dvb-frontends/m88ds3103.c|  2 +-
 drivers/media/dvb-frontends/rtl2830.c  |  2 +-
 drivers/media/dvb-frontends/rtl2832.c  |  2 +-
 drivers/media/dvb-frontends/si2168.c   |  2 +-
 drivers/media/usb/cx231xx/cx231xx-i2c.c|  3 ---
 drivers/of/unittest.c  |  2 +-
 include/linux/i2c-mux.h|  1 -
 15 files changed, 24 insertions(+), 32 deletions(-)

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 7ba0308537a8..5c1088079231 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -32,7 +32,6 @@ struct i2c_mux_priv {
struct i2c_adapter adap;
struct i2c_algorithm algo;
struct i2c_mux_core *muxc;
-   struct device *mux_dev;
u32 chan_id;
 };
 
@@ -137,7 +136,6 @@ struct i2c_mux_core *i2c_mux_alloc(struct device *dev, int 
sizeof_priv)
 EXPORT_SYMBOL_GPL(i2c_mux_alloc);
 
 int i2c_add_mux_adapter(struct i2c_mux_core *muxc,
-   struct device *mux_dev,
u32 force_nr, u32 chan_id,
unsigned int class)
 {
@@ -162,7 +160,6 @@ int i2c_add_mux_adapter(struct i2c_mux_core *muxc,
 
/* Set up private adapter data */
priv->muxc = muxc;
-   priv->mux_dev = mux_dev;
priv->chan_id = chan_id;
 
/* Need to do algo dynamically because we don't know ahead
@@ -197,11 +194,11 @@ int i2c_add_mux_adapter(struct i2c_mux_core *muxc,
 * Try to populate the mux adapter's of_node, expands to
 * nothing if !CONFIG_OF.
 */
-   if (mux_dev->of_node) {
+   if (muxc->dev->of_node) {
struct device_node *child;
u32 reg;
 
-   for_each_child_of_node(mux_dev->of_node, child) {
+   for_each_child_of_node(muxc->dev->of_node, child) {
ret = of_property_read_u32(child, "reg", );
if (ret)
continue;
@@ -215,8 +212,9 @@ int i2c_add_mux_adapter(struct i2c_mux_core *muxc,
/*
 * Associate the mux channel with an ACPI node.
 */
-   if (has_acpi_companion(mux_dev))
-   acpi_preset_companion(>adap.dev, ACPI_COMPANION(mux_dev),
+   if (has_acpi_companion(muxc->dev))
+   acpi_preset_companion(>adap.dev,
+ ACPI_COMPANION(muxc->dev),
  chan_id);
 
if (force_nr) {
@@ -233,12 +231,14 @@ int i2c_add_mux_adapter(struct i2c_mux_core *muxc,
return ret;
}
 
-   WARN(sysfs_create_link(>adap.dev.kobj, _dev->kobj, 
"mux_device"),
-  "can't create symlink to mux device\n");
+   WARN(sysfs_create_link(>adap.dev.kobj, >dev->kobj,
+  "mux_device"),
+"can't create symlink to mux device\n");
 
snprintf(symlink_name, sizeof(symlink_name), "channel-%u", chan_id);
-   WARN(sysfs_create_link(_dev->kobj, >adap.dev.kobj, 
symlink_name),
-  "can't create symlink for channel %u\n", 
chan_id);
+   WARN(sysfs_create_link(>dev->kobj, >adap.dev.kobj,
+  symlink_name),
+"can't create symlink for channel %u\n", chan_id);
dev_info(>dev, "Added multiplexed i2c bus %d\n",
 i2c_adapter_id(>adap));
 
@@ -259,7 +259,7 @@ void i2c_del_mux_adapters(struct i2c_mux_core *muxc)
 
snprintf(symlink_name, sizeof(symlink_name),
 "channel-%u", priv->chan_id);
-   sysfs_remove_link(>mux_dev->kobj, symlink_name);
+   sysfs_remove_link(>dev->kobj, symlink_name);
 
sysfs_remove_link(>adap.dev.kobj, "mux_device");
i2c_del_adapter(adap);
diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c 
b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
index e0558e8a0e74..c2bc18c7921f 100644
--- a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
+++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
@@ -204,7 +204,7 @@ static int i2c_arbitrator_probe(struct platform_device 
*pdev)
}
 
/* Actually add the mux adapter */
- 

Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver

[Alan Stern]

On Tue, 5 Jan 2016, Rob Herring wrote:

> >>> > It's not clear (to me, anyway) how this is meant to work.  USB is a
> >>> > completely discoverable bus: There is no way to represent devices
> >>> > statically; they have to be discovered.  But a device can't be
> >>> > discovered unless it is functional, so if an onboard hub (or any other
> >>> > sort of USB device) requires power, clocks, or something similar in
> >>> > order to function, it won't be discovered.  There won't be any device
> >>> > structure to probe, and "forcing driver probe" won't accomplish
> >>> > anything.
> >>> >
> >>> > It seems to me that the only way something like this could be made to
> >>> > work is if the necessary actions are keyed off the host controller (and
> >>> > in particular, _not_ the hub driver), presumably at the time the
> >>> > controller is probed.
> 
> The problem with putting this in the the host controller driver is it
> assumes the initialization sequence is generic enough to be described
> in DT and that initialization is the only time we need DT data. The
> MFD example is a perfect example of another case. Suspend/resume also
> comes to mind. Even if we could put the control in both places, that
> is poor design IMO. I'd rather just make it a requirement that the
> bootloader do enough setup that devices can be discovered.

That would be okay with me.  It would make things a lot simpler (but it 
would also waste energy in situations where the devices weren't being 
used).

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] dt-bindings: add document for rk3229-vop

[Rob Herring]

On Mon, Jan 4, 2016 at 10:00 PM, Yakir Yang  wrote:
> Signed-off-by: Yakir Yang 
> Acked-by: Rob Herring 
> ---
> Changes in v2:
> - acked by Rob

It doesn't hurt, but there is no point to send a new version just to
add acks. The maintainer should add any for the current version. If
you do send a new version with changes, then it is your responsibility
to add acks. Maintainers are not going to look at older versions.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

[kbuild test robot]

Hi Peter,

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.4-rc8 next-20160105]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Peter-Rosin/i2c-mux-cleanup-and-locking-update/20160106-000205
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux i2c/for-next
config: i386-randconfig-s1-201601 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c: In function 
'inv_mpu_acpi_create_mux_client':
>> drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c:185:37: error: 'struct 
>> inv_mpu6050_state' has no member named 'mux_adapter'
  st->mux_client = i2c_new_device(st->mux_adapter, );
^

vim +185 drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c

a35c5d1a Srinivas Pandruvada 2015-01-30  179
*name = '\0';
a35c5d1a Srinivas Pandruvada 2015-01-30  180
strlcat(info.type, "-client",
a35c5d1a Srinivas Pandruvada 2015-01-30  181
sizeof(info.type));
a35c5d1a Srinivas Pandruvada 2015-01-30  182} else
a35c5d1a Srinivas Pandruvada 2015-01-30  183return 
0; /* no secondary addr, which is OK */
a35c5d1a Srinivas Pandruvada 2015-01-30  184}
a35c5d1a Srinivas Pandruvada 2015-01-30 @185st->mux_client = 
i2c_new_device(st->mux_adapter, );
a35c5d1a Srinivas Pandruvada 2015-01-30  186if (!st->mux_client)
a35c5d1a Srinivas Pandruvada 2015-01-30  187return -ENODEV;
a35c5d1a Srinivas Pandruvada 2015-01-30  188  

:: The code at line 185 was first introduced by commit
:: a35c5d1aa96aa6cc70e91786cbe9be4db23f8f4a iio: imu: inv_mpu6050: Create 
mux clients for ACPI

:: TO: Srinivas Pandruvada <srinivas.pandruv...@linux.intel.com>
:: CC: Jonathan Cameron <ji...@kernel.org>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 3/4] mfd: arizona: Switch to using clock driver for 32k clock

[kbuild test robot]

Hi Charles,

[auto build test WARNING on clk/clk-next]
[also build test WARNING on v4.4-rc8 next-20160105]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Charles-Keepax/extcon-arizona-Remove-enable-disable-of-32k-clock/20160105-234658
base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: x86_64-randconfig-x013-01041832 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

warning: (MFD_ARIZONA) selects COMMON_CLK_ARIZONA which has unmet direct 
dependencies (COMMON_CLK && MFD_ARIZONA)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v2 6/8] i2c: allow adapter drivers to override the adapter locking

[Peter Rosin]

From: Peter Rosin 

Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and
unlock_bus ops in the adapter. These funcs/ops take an additional flags
argument that indicates for what purpose the adapter is locked.

There are two flags, I2C_LOCK_ADAPTER and I2C_LOCK_SEGMENT, but they are
both implemented the same. For now. Locking the adapter means that the
whole bus is locked, locking the segment means that only the current bus
segment is locked (i.e. i2c traffic on the parent side of mux is still
allowed even if the child side of the mux is locked.

Also support a trylock_bus op (but no function to call it, as it is not
expected to be needed outside of the i2c core).

Implement i2c_lock_adapter/i2c_unlock_adapter in terms of the new locking
scheme (i.e. lock with the I2C_LOCK_ADAPTER flag).

Annotate some of the locking with explicit I2C_LOCK_SEGMENT flags.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/i2c-core.c | 40 ++--
 include/linux/i2c.h| 28 ++--
 2 files changed, 48 insertions(+), 20 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index ba8eb087f224..34a7748b4652 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -958,10 +958,10 @@ static int i2c_check_addr_busy(struct i2c_adapter 
*adapter, int addr)
 }
 
 /**
- * i2c_lock_adapter - Get exclusive access to an I2C bus segment
+ * i2c_adapter_lock_bus - Get exclusive access to an I2C bus segment
  * @adapter: Target I2C bus segment
  */
-void i2c_lock_adapter(struct i2c_adapter *adapter)
+static void i2c_adapter_lock_bus(struct i2c_adapter *adapter, int flags)
 {
struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
 
@@ -970,27 +970,26 @@ void i2c_lock_adapter(struct i2c_adapter *adapter)
else
rt_mutex_lock(>bus_lock);
 }
-EXPORT_SYMBOL_GPL(i2c_lock_adapter);
 
 /**
- * i2c_trylock_adapter - Try to get exclusive access to an I2C bus segment
+ * i2c_adapter_trylock_bus - Try to get exclusive access to an I2C bus segment
  * @adapter: Target I2C bus segment
  */
-static int i2c_trylock_adapter(struct i2c_adapter *adapter)
+static int i2c_adapter_trylock_bus(struct i2c_adapter *adapter, int flags)
 {
struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
 
if (parent)
-   return i2c_trylock_adapter(parent);
+   return parent->trylock_bus(parent, flags);
else
return rt_mutex_trylock(>bus_lock);
 }
 
 /**
- * i2c_unlock_adapter - Release exclusive access to an I2C bus segment
+ * i2c_adapter_unlock_bus - Release exclusive access to an I2C bus segment
  * @adapter: Target I2C bus segment
  */
-void i2c_unlock_adapter(struct i2c_adapter *adapter)
+static void i2c_adapter_unlock_bus(struct i2c_adapter *adapter, int flags)
 {
struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
 
@@ -999,7 +998,6 @@ void i2c_unlock_adapter(struct i2c_adapter *adapter)
else
rt_mutex_unlock(>bus_lock);
 }
-EXPORT_SYMBOL_GPL(i2c_unlock_adapter);
 
 static void i2c_dev_set_name(struct i2c_adapter *adap,
 struct i2c_client *client)
@@ -1545,6 +1543,12 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
return -EINVAL;
}
 
+   if (!adap->lock_bus) {
+   adap->lock_bus = i2c_adapter_lock_bus;
+   adap->trylock_bus = i2c_adapter_trylock_bus;
+   adap->unlock_bus = i2c_adapter_unlock_bus;
+   }
+
rt_mutex_init(>bus_lock);
mutex_init(>userspace_clients_lock);
INIT_LIST_HEAD(>userspace_clients);
@@ -2254,16 +2258,16 @@ int i2c_transfer(struct i2c_adapter *adap, struct 
i2c_msg *msgs, int num)
 #endif
 
if (in_atomic() || irqs_disabled()) {
-   ret = i2c_trylock_adapter(adap);
+   ret = adap->trylock_bus(adap, I2C_LOCK_SEGMENT);
if (!ret)
/* I2C activity is ongoing. */
return -EAGAIN;
} else {
-   i2c_lock_adapter(adap);
+   i2c_lock_bus(adap, I2C_LOCK_SEGMENT);
}
 
ret = __i2c_transfer(adap, msgs, num);
-   i2c_unlock_adapter(adap);
+   i2c_unlock_bus(adap, I2C_LOCK_SEGMENT);
 
return ret;
} else {
@@ -3038,7 +3042,7 @@ s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr, 
unsigned short flags,
flags &= I2C_M_TEN | I2C_CLIENT_PEC | I2C_CLIENT_SCCB;
 
if (adapter->algo->smbus_xfer) {
-   i2c_lock_adapter(adapter);
+   i2c_lock_bus(adapter, I2C_LOCK_SEGMENT);
 
/* Retry automatically on arbitration loss */
orig_jiffies = jiffies;
@@ -3052,7 +3056,7 @@ s32 i2c_smbus_xfer(struct i2c_adapter 

[PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

[Peter Rosin]

From: Peter Rosin 

All muxes have slave side adapters, many have some arbitrary number of
them. Handle this in the mux core, so that drivers are simplified.

Add i2c_mux_reserve_adapter that can be used when it is known in advance
how many child adapters that is to be added. This avoids reallocating
memory.

Drop i2c_del_mux_adapter and replace it with i2c_del_mux_adapters, since
no mux driver is dynamically deleting individual child adapters anyway.

Signed-off-by: Peter Rosin 
---
 drivers/i2c/i2c-mux.c| 71 ++--
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c   | 10 ++--
 drivers/i2c/muxes/i2c-mux-gpio.c | 23 +++--
 drivers/i2c/muxes/i2c-mux-pca9541.c  | 13 ++---
 drivers/i2c/muxes/i2c-mux-pca954x.c  | 26 --
 drivers/i2c/muxes/i2c-mux-pinctrl.c  | 27 +++
 drivers/i2c/muxes/i2c-mux-reg.c  | 28 ---
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c   | 12 ++---
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h|  1 -
 drivers/media/dvb-frontends/m88ds3103.c  | 11 ++---
 drivers/media/dvb-frontends/m88ds3103_priv.h |  1 -
 drivers/media/dvb-frontends/rtl2830.c| 10 ++--
 drivers/media/dvb-frontends/rtl2830_priv.h   |  1 -
 drivers/media/dvb-frontends/rtl2832.c| 11 ++---
 drivers/media/dvb-frontends/rtl2832_priv.h   |  1 -
 drivers/media/dvb-frontends/si2168.c | 10 ++--
 drivers/media/dvb-frontends/si2168_priv.h|  1 -
 drivers/media/usb/cx231xx/cx231xx-core.c |  3 +-
 drivers/media/usb/cx231xx/cx231xx-i2c.c  | 26 +-
 drivers/media/usb/cx231xx/cx231xx.h  |  2 +-
 drivers/of/unittest.c| 28 ---
 include/linux/i2c-mux.h  | 15 --
 22 files changed, 149 insertions(+), 182 deletions(-)

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 6c5cb9f7649b..7ba0308537a8 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -99,6 +99,29 @@ static unsigned int i2c_mux_parent_classes(struct 
i2c_adapter *parent)
return class;
 }
 
+int i2c_mux_reserve_adapters(struct i2c_mux_core *muxc, int adapters)
+{
+   struct i2c_adapter **adapter;
+
+   if (adapters <= muxc->max_adapters)
+   return 0;
+
+   adapter = devm_kmalloc_array(muxc->dev,
+adapters, sizeof(*adapter),
+GFP_KERNEL);
+   if (!adapter)
+   return -ENOMEM;
+
+   memcpy(adapter, muxc->adapter,
+  muxc->max_adapters * sizeof(*adapter));
+
+   devm_kfree(muxc->dev, muxc->adapter);
+   muxc->adapter = adapter;
+   muxc->max_adapters = adapters;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(i2c_mux_reserve_adapters);
+
 struct i2c_mux_core *i2c_mux_alloc(struct device *dev, int sizeof_priv)
 {
struct i2c_mux_core *muxc;
@@ -113,19 +136,29 @@ struct i2c_mux_core *i2c_mux_alloc(struct device *dev, 
int sizeof_priv)
 }
 EXPORT_SYMBOL_GPL(i2c_mux_alloc);
 
-struct i2c_adapter *i2c_add_mux_adapter(struct i2c_mux_core *muxc,
-   struct device *mux_dev,
-   u32 force_nr, u32 chan_id,
-   unsigned int class)
+int i2c_add_mux_adapter(struct i2c_mux_core *muxc,
+   struct device *mux_dev,
+   u32 force_nr, u32 chan_id,
+   unsigned int class)
 {
struct i2c_adapter *parent = muxc->parent;
struct i2c_mux_priv *priv;
char symlink_name[20];
int ret;
 
+   if (muxc->adapters >= muxc->max_adapters) {
+   int new_max = 2 * muxc->max_adapters;
+
+   if (!new_max)
+   new_max = 1;
+   ret = i2c_mux_reserve_adapters(muxc, new_max);
+   if (ret)
+   return ret;
+   }
+
priv = kzalloc(sizeof(struct i2c_mux_priv), GFP_KERNEL);
if (!priv)
-   return NULL;
+   return -ENOMEM;
 
/* Set up private adapter data */
priv->muxc = muxc;
@@ -197,7 +230,7 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_mux_core 
*muxc,
"failed to add mux-adapter (error=%d)\n",
ret);
kfree(priv);
-   return NULL;
+   return ret;
}
 
WARN(sysfs_create_link(>adap.dev.kobj, _dev->kobj, 
"mux_device"),
@@ -209,23 +242,31 @@ struct i2c_adapter *i2c_add_mux_adapter(struct 
i2c_mux_core *muxc,
dev_info(>dev, "Added multiplexed i2c bus %d\n",
 i2c_adapter_id(>adap));
 
-   return >adap;
+   muxc->adapter[muxc->adapters++] = >adap;
+   return 0;
 }
 EXPORT_SYMBOL_GPL(i2c_add_mux_adapter);
 
-void i2c_del_mux_adapter(struct i2c_adapter *adap)
+void i2c_del_mux_adapters(struct i2c_mux_core *muxc)
 {
-   struct 

Re: [PATCH 3/4] mfd: arizona: Switch to using clock driver for 32k clock

[kbuild test robot]

Hi Charles,

[auto build test ERROR on clk/clk-next]
[also build test ERROR on v4.4-rc8 next-20160105]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Charles-Keepax/extcon-arizona-Remove-enable-disable-of-32k-clock/20160105-234658
base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: i386-randconfig-s1-201601 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

>> drivers/clk/clk-arizona.c:31:16: error: field 'clk32k_hw' has incomplete type
 struct clk_hw clk32k_hw;
   ^
   In file included from include/asm-generic/bug.h:13:0,
from arch/x86/include/asm/bug.h:35,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/gfp.h:4,
from include/linux/slab.h:14,
from include/asm-generic/clkdev.h:16,
from arch/x86/include/generated/asm/clkdev.h:1,
from include/linux/clkdev.h:15,
from drivers/clk/clk-arizona.c:14:
   drivers/clk/clk-arizona.c: In function 'clk32k_to_arizona_clk':
   include/linux/kernel.h:813:48: warning: initialization from incompatible 
pointer type [-Wincompatible-pointer-types]
 const typeof( ((type *)0)->member ) *__mptr = (ptr); \
   ^
>> drivers/clk/clk-arizona.c:37:9: note: in expansion of macro 'container_of'
 return container_of(hw, struct arizona_clk, clk32k_hw);
^
   drivers/clk/clk-arizona.c: At top level:
>> drivers/clk/clk-arizona.c:77:21: error: variable 'arizona_32k_ops' has 
>> initializer but incomplete type
static const struct clk_ops arizona_32k_ops = {
^
>> drivers/clk/clk-arizona.c:78:2: error: unknown field 'prepare' specified in 
>> initializer
 .prepare = arizona_32k_enable,
 ^
>> drivers/clk/clk-arizona.c:78:13: warning: excess elements in struct 
>> initializer
 .prepare = arizona_32k_enable,
^
   drivers/clk/clk-arizona.c:78:13: note: (near initialization for 
'arizona_32k_ops')
>> drivers/clk/clk-arizona.c:79:2: error: unknown field 'unprepare' specified 
>> in initializer
 .unprepare = arizona_32k_disable,
 ^
   drivers/clk/clk-arizona.c:79:15: warning: excess elements in struct 
initializer
 .unprepare = arizona_32k_disable,
  ^
   drivers/clk/clk-arizona.c:79:15: note: (near initialization for 
'arizona_32k_ops')
   drivers/clk/clk-arizona.c: In function 'arizona_clk_of_get_pdata':
>> drivers/clk/clk-arizona.c:98:35: error: implicit declaration of function 
>> '__clk_get_name' [-Werror=implicit-function-declaration]
   arizona->pdata.clk32k_parent = __clk_get_name(mclk);
  ^
>> drivers/clk/clk-arizona.c:98:33: warning: assignment makes pointer from 
>> integer without a cast [-Wint-conversion]
   arizona->pdata.clk32k_parent = __clk_get_name(mclk);
^
   drivers/clk/clk-arizona.c: In function 'arizona_clk_probe':
>> drivers/clk/clk-arizona.c:113:9: error: variable 'clk32k_init' has 
>> initializer but incomplete type
 struct clk_init_data clk32k_init = {
^
>> drivers/clk/clk-arizona.c:114:3: error: unknown field 'name' specified in 
>> initializer
  .name = "arizona-32k",
  ^
   drivers/clk/clk-arizona.c:114:11: warning: excess elements in struct 
initializer
  .name = "arizona-32k",
  ^
   drivers/clk/clk-arizona.c:114:11: note: (near initialization for 
'clk32k_init')
>> drivers/clk/clk-arizona.c:115:3: error: unknown field 'ops' specified in 
>> initializer
  .ops = _32k_ops,
  ^
   drivers/clk/clk-arizona.c:115:10: warning: excess elements in struct 
initializer
  .ops = _32k_ops,
 ^
   drivers/clk/clk-arizona.c:115:10: note: (near initialization for 
'clk32k_init')
>> drivers/clk/clk-arizona.c:113:23: error: storage size of 'clk32k_init' isn't 
>> known
 struct clk_init_data clk32k_init = {
  ^
>> drivers/clk/clk-arizona.c:154:24: error: 'CLK_IS_ROOT' undeclared (first use 
>> in this function)
  clk32k_init.flags |= CLK_IS_ROOT;
   ^
   drivers/clk/clk-arizona.c:154:24: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/clk/clk-arizona.c:158:20: error: implicit declaration of function 
>> 'devm_clk_register' [-Werror=implicit-function-declaration]
 clkdata->clk32k = devm_clk_register(>dev, >clk32k_hw);
 

[PATCH v2 2/4] ARM: imx: select HAVE_ARM_ARCH_TIMER if selected i.MX7D

[Frank Li]

From: Frank Li 

i.MX7D Supported ARCH Timer.

Signed-off-by: Frank Li 
---
Change from v1 to v2:
 Sort config

 arch/arm/mach-imx/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 0ac180f..43ff3cd 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -561,6 +561,7 @@ config SOC_IMX7D
bool "i.MX7 Dual support"
select PINCTRL_IMX7D
select ARM_GIC
+   select HAVE_ARM_ARCH_TIMER
select HAVE_IMX_ANATOP
select HAVE_IMX_MMDC
help
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM

[Marcel Ziswiler]

From: Petr Štetiar 

Signed-off-by: Petr Štetiar 
Signed-off-by: Marcel Ziswiler 
---

Changes in v2:
- clarify exact Apalis iMX6Q/D SoM type in cover letter
- clarify exact Apalis iMX6Q/D module type and Ixora carrier board in model
  node
- got rid of obsolete mmc aliases
- working SGTL5000 audio/sound integration
- working STMPE811 touch screen controller integration
- integrated review feedback from Lucas
- left and even added some more comments as I don't see why putting any
  explanatory comments in dts' should be such a bad thing to do
- completely got rid of the memory node as that is something typically filled
  in by the boot loader e.g. U-Boot
- without the regulators simple-bus it no longer boots
- even though we supposedly shipped a few hundred V1.0a modules drop DCE UART
  support for now and simplify file layout
- replaced obsolete no-1-8-v by mainline supported voltage-ranges = <3300 3300>
  usdhc property and yes card detects are indeed active low (;-p)
- integrated review feedback from Stefan
- fixed Ethernet PHY reset & interrupt (requires Micrel PHY driver to be
  enabled)
- fixed HDMI DDC (requires GPIO-based bitbanging I2C to be enabled)
- fixed SPDIF

 arch/arm/boot/dts/imx6qdl-apalis.dtsi | 1040 +
 1 file changed, 1040 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6qdl-apalis.dtsi

diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi 
b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
new file mode 100644
index 000..6104e2e
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -0,0 +1,1040 @@
+/*
+ * Copyright 2014-2016 Toradex AG
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+
+/ {
+   model = "Toradex Apalis iMX6Q/D Module";
+   compatible = "toradex,apalis_imx6q", "fsl,imx6q";
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 500>;
+   status = "disabled";
+   };
+
+   /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
+   i2cddc: i2c@0 {
+   compatible = "i2c-gpio";
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c_ddc>;
+   gpios = < 16 GPIO_ACTIVE_HIGH /* sda */
+ 30 GPIO_ACTIVE_HIGH /* scl */
+   >;
+   i2c-gpio,delay-us = <2>;/* ~100 kHz */
+   status = "okay";
+   };
+
+   regulators {
+   compatible = "simple-bus";
+
+   reg_1p8v: 1p8v {
+   compatible = "regulator-fixed";
+   regulator-name = "1P8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   reg_2p5v: 2p5v {
+   compatible = "regulator-fixed";
+   regulator-name = "2P5V";
+   regulator-min-microvolt = <250>;
+ 

[PATCH v2 2/2] ARM: dts: imx6: Add support for Toradex Ixora carrier board

[Marcel Ziswiler]

From: Petr Štetiar 

Signed-off-by: Petr Štetiar 
Signed-off-by: Marcel Ziswiler 
---

Changes in v2: None

 arch/arm/boot/dts/Makefile   |   1 +
 arch/arm/boot/dts/imx6q-apalis-ixora.dts | 256 +++
 2 files changed, 257 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-apalis-ixora.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 44508dc..29b1aae 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -315,6 +315,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-udoo.dtb \
imx6dl-wandboard.dtb \
imx6dl-wandboard-revb1.dtb \
+   imx6q-apalis-ixora.dtb \
imx6q-apf6dev.dtb \
imx6q-arm2.dtb \
imx6q-cm-fx6.dtb \
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts 
b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
new file mode 100644
index 000..5494a13
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
@@ -0,0 +1,256 @@
+/*
+ * Copyright 2014-2016 Toradex AG
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include "imx6q.dtsi"
+#include "imx6qdl-apalis.dtsi"
+
+/ {
+   model = "Toradex Apalis iMX6Q/D Module on Ixora Carrier Board";
+   compatible = "toradex,apalis_imx6q-ixora", "toradex,apalis_imx6q",
+"fsl,imx6q";
+
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   };
+
+   aliases {
+   rtc0 = _i2c;
+   rtc1 = "/soc/aips-bus@0200/snvs@020cc000/snvs-rtc-lp@34";
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_keys>;
+
+   wakeup {
+   label = "Wake-Up";
+   gpios = < 4 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   debounce-interval = <10>;
+   gpio-key,wakeup;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_leds_ixora>;
+
+   led4-green {
+   label = "LED_4_GREEN";
+   gpios = < 17 GPIO_ACTIVE_HIGH>;
+   };
+
+   led4-red {
+   label = "LED_4_RED";
+   gpios = < 21 GPIO_ACTIVE_HIGH>;
+   };
+
+   led5-green {
+   label = "LED_5_GREEN";
+   gpios = < 1 GPIO_ACTIVE_HIGH>;
+   };
+
+   led5-red {
+   label = "LED_5_RED";
+   gpios = < 2 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   pwmleds {
+   compatible = "pwm-leds";
+   ledpwm1 {
+   label = "PWM1";
+   pwms = < 0 5>;
+   

[PATCH v2 0/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM/Ixora carrier board

[Marcel Ziswiler]

This patch series adds support for Toradex Apalis iMX6Q/D SoM module [1] and
Ixora carrier board [2].

Petr Štetiar has simply taken content of DTSes from Toradex's Git tree [3],
removed not mainlined stuff and fixed all errors returned by checkpatch script.

Please note that RESET_MOCI# used as mini-PCIe PERST# is not directly
GPIO1_IO28 but rather inverted (e.g. active-high and ored with RESETBMCU coming
off the PMIC but that is not relevant in this context). As changing the
reset-gpio polarity wasn't previously supported Petr Štetiar's
"PCI: imx6: Fix reset-gpio to work with active low GPIO" fix [4] is needed.

1. https://www.toradex.com/computer-on-modules/apalis-arm-family/freescale-imx-6
2. https://www.toradex.com/products/carrier-boards/ixora-carrier-board
3. 
https://git.toradex.com/cgit/linux-toradex.git/log/?h=toradex_imx_3.14.28_1.0.0_ga
4. https://patchwork.ozlabs.org/patch/552886/

Changes in v2:
- clarify exact Apalis iMX6Q/D SoM type in cover letter
- clarify exact Apalis iMX6Q/D module type and Ixora carrier board in model
  node
- got rid of obsolete mmc aliases
- working SGTL5000 audio/sound integration
- working STMPE811 touch screen controller integration
- integrated review feedback from Lucas
- left and even added some more comments as I don't see why putting any
  explanatory comments in dts' should be such a bad thing to do
- completely got rid of the memory node as that is something typically filled
  in by the boot loader e.g. U-Boot
- without the regulators simple-bus it no longer boots
- even though we supposedly shipped a few hundred V1.0a modules drop DCE UART
  support for now and simplify file layout
- replaced obsolete no-1-8-v by mainline supported voltage-ranges = <3300 3300>
  usdhc property and yes card detects are indeed active low (;-p)
- integrated review feedback from Stefan
- fixed Ethernet PHY reset & interrupt (requires Micrel PHY driver to be
  enabled)
- fixed HDMI DDC (requires GPIO-based bitbanging I2C to be enabled)
- fixed SPDIF

Petr Štetiar (2):
  ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM
  ARM: dts: imx6: Add support for Toradex Ixora carrier board

 arch/arm/boot/dts/Makefile   |1 +
 arch/arm/boot/dts/imx6q-apalis-ixora.dts |  256 
 arch/arm/boot/dts/imx6qdl-apalis.dtsi| 1040 ++
 3 files changed, 1297 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-apalis-ixora.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-apalis.dtsi

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance

[Guenter Roeck]

On 01/05/2016 07:57 AM, Peter Rosin wrote:

From: Peter Rosin 

The initial core mux structure starts off small with only the parent
adapter pointer, which all muxes have, and a priv pointer for mux
driver private data.

Add i2c_mux_alloc function to unify the creation of a mux.

Where appropriate, pass around the mux core structure instead of the
parent adapter or the driver private data.

Remove the parent adapter pointer from the driver private data for all
mux drivers.

Signed-off-by: Peter Rosin 
---
  drivers/i2c/i2c-mux.c| 28 +-
  drivers/i2c/muxes/i2c-arb-gpio-challenge.c   | 24 +--
  drivers/i2c/muxes/i2c-mux-gpio.c | 20 
  drivers/i2c/muxes/i2c-mux-pca9541.c  | 35 ++--
  drivers/i2c/muxes/i2c-mux-pca954x.c  | 19 ++-
  drivers/i2c/muxes/i2c-mux-pinctrl.c  | 23 +-
  drivers/i2c/muxes/i2c-mux-reg.c  | 23 ++
  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c   | 10 +++-
  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h|  1 +
  drivers/media/dvb-frontends/m88ds3103.c  | 10 +++-
  drivers/media/dvb-frontends/m88ds3103_priv.h |  1 +
  drivers/media/dvb-frontends/rtl2830.c| 10 +++-
  drivers/media/dvb-frontends/rtl2830_priv.h   |  1 +
  drivers/media/dvb-frontends/rtl2832.c| 10 +++-
  drivers/media/dvb-frontends/rtl2832_priv.h   |  1 +
  drivers/media/dvb-frontends/si2168.c | 10 +++-
  drivers/media/dvb-frontends/si2168_priv.h|  1 +
  drivers/media/usb/cx231xx/cx231xx-core.c |  3 +++
  drivers/media/usb/cx231xx/cx231xx-i2c.c  | 13 +--
  drivers/media/usb/cx231xx/cx231xx.h  |  2 ++
  drivers/of/unittest.c| 16 +++--
  include/linux/i2c-mux.h  | 14 ++-
  22 files changed, 187 insertions(+), 88 deletions(-)

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 00fc5b1c7b66..c2163f6b51d5 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -31,8 +31,8 @@
  struct i2c_mux_priv {
struct i2c_adapter adap;
struct i2c_algorithm algo;
+   struct i2c_mux_core *muxc;

-   struct i2c_adapter *parent;
struct device *mux_dev;
void *mux_priv;
u32 chan_id;
@@ -45,7 +45,8 @@ static int i2c_mux_master_xfer(struct i2c_adapter *adap,
   struct i2c_msg msgs[], int num)
  {
struct i2c_mux_priv *priv = adap->algo_data;
-   struct i2c_adapter *parent = priv->parent;
+   struct i2c_mux_core *muxc = priv->muxc;
+   struct i2c_adapter *parent = muxc->parent;
int ret;

/* Switch to the right mux port and perform the transfer. */
@@ -65,7 +66,8 @@ static int i2c_mux_smbus_xfer(struct i2c_adapter *adap,
  int size, union i2c_smbus_data *data)
  {
struct i2c_mux_priv *priv = adap->algo_data;
-   struct i2c_adapter *parent = priv->parent;
+   struct i2c_mux_core *muxc = priv->muxc;
+   struct i2c_adapter *parent = muxc->parent;
int ret;

/* Select the right mux port and perform the transfer. */
@@ -84,7 +86,7 @@ static int i2c_mux_smbus_xfer(struct i2c_adapter *adap,
  static u32 i2c_mux_functionality(struct i2c_adapter *adap)
  {
struct i2c_mux_priv *priv = adap->algo_data;
-   struct i2c_adapter *parent = priv->parent;
+   struct i2c_adapter *parent = priv->muxc->parent;

return parent->algo->functionality(parent);
  }
@@ -102,7 +104,20 @@ static unsigned int i2c_mux_parent_classes(struct 
i2c_adapter *parent)
return class;
  }

-struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter *parent,
+struct i2c_mux_core *i2c_mux_alloc(struct device *dev, int sizeof_priv)
+{
+   struct i2c_mux_core *muxc;
+
+   muxc = devm_kzalloc(dev, sizeof(*muxc) + sizeof_priv, GFP_KERNEL);
+   if (!muxc)
+   return NULL;
+   if (sizeof_priv)
+   muxc->priv = muxc + 1;
+   return muxc;
+}
+EXPORT_SYMBOL_GPL(i2c_mux_alloc);
+
+struct i2c_adapter *i2c_add_mux_adapter(struct i2c_mux_core *muxc,
struct device *mux_dev,
void *mux_priv, u32 force_nr, u32 chan_id,
unsigned int class,
@@ -111,6 +126,7 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter 
*parent,
int (*deselect) (struct i2c_adapter *,
 void *, u32))
  {
+   struct i2c_adapter *parent = muxc->parent;
struct i2c_mux_priv *priv;
char symlink_name[20];
int ret;
@@ -120,7 +136,7 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter 
*parent,
return NULL;

/* Set up private adapter data */
-   priv->parent = parent;
+   priv->muxc 

[PATCH v5 net-next 0/3] Add new capability and macb DT variant

[Neil Armstrong]

The first patch introduces a new capability bit to disable usage of the
USRIO register on platform not implementing it thus avoiding some external
imprecise aborts on ARM based platforms.
The two last patchs adds a new macb variant compatible name using the
capability, the NP4 SoC uses this particular hardware configuration.

v1: 
http://lkml.kernel.org/r/1449485914-12883-1-git-send-email-narmstr...@baylibre.com
v2: 
http://lkml.kernel.org/r/1449582726-6148-1-git-send-email-narmstr...@baylibre.com
v3: 
http://lkml.kernel.org/r/1451898103-21868-1-git-send-email-narmstr...@baylibre.com
v4: 
http://lkml.kernel.org/r/1451900573-22657-1-git-send-email-narmstr...@baylibre.com
v5: switch SoC name to non-generic NP4 name

Neil Armstrong (3):
  net: ethernet: cadence-macb: Add disabled usrio caps
  net: macb: Add NP4 macb config using USRIO_DISABLED
  dt-bindings: net: macb: Add NP4 macb variant

 Documentation/devicetree/bindings/net/macb.txt |  1 +
 drivers/net/ethernet/cadence/macb.c| 33 --
 drivers/net/ethernet/cadence/macb.h|  1 +
 3 files changed, 23 insertions(+), 12 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 net-next 2/3] net: macb: Add NP4 macb config using USRIO_DISABLED

[Neil Armstrong]

Declare a new NP4 SoC variant having USRIO_DISABLED as capability bit.

Signed-off-by: Neil Armstrong 
---
 drivers/net/ethernet/cadence/macb.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/cadence/macb.c 
b/drivers/net/ethernet/cadence/macb.c
index fa53bc3..d12ee07 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2781,6 +2781,11 @@ static const struct macb_config emac_config = {
.init = at91ether_init,
 };
 
+static const struct macb_config np4_config = {
+   .caps = MACB_CAPS_USRIO_DISABLED,
+   .clk_init = macb_clk_init,
+   .init = macb_init,
+};
 
 static const struct macb_config zynqmp_config = {
.caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO,
@@ -2801,6 +2806,7 @@ static const struct of_device_id macb_dt_ids[] = {
{ .compatible = "cdns,at32ap7000-macb" },
{ .compatible = "cdns,at91sam9260-macb", .data = _config },
{ .compatible = "cdns,macb" },
+   { .compatible = "cdns,np4-macb", .data = _config },
{ .compatible = "cdns,pc302-gem", .data = _config },
{ .compatible = "cdns,gem", .data = _config },
{ .compatible = "atmel,sama5d2-gem", .data = _config },
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 8/8] i2c-mux: relax locking of the top i2c adapter during i2c controlled muxing

[Peter Rosin]

From: Peter Rosin 

With a i2c topology like the following

   GPIO ---|  -- BAT1
|  v /
   I2C  -+--+ MUX
 |   \
   EEPROM -- BAT2

there is a locking problem with the GPIO controller since it is a client
on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1)
will lock the whole i2c bus prior to attempting to switch the mux to the
correct i2c segment. In the above case, the GPIO device is an I/O expander
with an i2c interface, and since the GPIO subsystem knows nothing (and
rightfully so) about the lockless needs of the i2c mux code, this results
in a deadlock when the GPIO driver issues i2c transfers to modify the
mux.

So, observing that while it is needed to have the i2c bus locked during the
actual MUX update in order to avoid random garbage on the slave side, it
is not strictly a must to have it locked over the whole sequence of a full
select-transfer-deselect mux client operation. The mux itself needs to be
locked, so transfers to clients behind the mux are serialized, and the mux
needs to be stable during all i2c traffic (otherwise individual mux slave
segments might see garbage, or worse).

Add devive tree properties (bool named i2c-controlled) to i2c-mux-gpio and
i2c-mux-pinctrl that asserts that the the gpio/pinctrl is controlled via
the same i2c bus that it muxes.

Modify the i2c mux locking so that muxes that are "i2c-controlled" locks
the mux instead of the whole i2c bus when there is a transfer to the slave
side of the mux. This lock serializes transfers to the slave side of the
mux.

Modify the select-transfer-deselect code for "i2c-controlled" muxes so
that each of the select-transfer-deselect ops locks the mux parent
adapter individually.

Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/i2c/i2c-mux-gpio.txt   |   2 +
 .../devicetree/bindings/i2c/i2c-mux-pinctrl.txt|   4 +
 drivers/i2c/i2c-mux.c  | 109 +++--
 drivers/i2c/muxes/i2c-mux-gpio.c   |   3 +
 drivers/i2c/muxes/i2c-mux-pinctrl.c|   3 +
 include/linux/i2c-mux-gpio.h   |   2 +
 include/linux/i2c-mux-pinctrl.h|   2 +
 include/linux/i2c-mux.h|   2 +
 8 files changed, 120 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
index 66709a825541..17670b997d81 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
@@ -28,6 +28,8 @@ Required properties:
 Optional properties:
 - idle-state: value to set the muxer to when idle. When no value is
   given, it defaults to the last value used.
+- i2c-controlled: The muxed I2C bus is also used to control all the gpios
+  used for muxing.
 
 For each i2c child node, an I2C child bus will be created. They will
 be numbered based on their order in the device tree.
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt
index ae8af1694e95..8374a1f7a709 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt
@@ -23,6 +23,10 @@ Required properties:
 - i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
   port is connected to.
 
+Optional properties:
+- i2c-controlled: The muxed I2C bus is also used to control all the pinctrl
+  pins used for muxing.
+
 Also required are:
 
 * Standard pinctrl properties that specify the pin mux state for each child
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index dd8a790cb4cc..c4d4b14a5399 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -54,6 +54,25 @@ static int i2c_mux_master_xfer(struct i2c_adapter *adap,
return ret;
 }
 
+static int __i2c_mux_master_xfer(struct i2c_adapter *adap,
+struct i2c_msg msgs[], int num)
+{
+   struct i2c_mux_priv *priv = adap->algo_data;
+   struct i2c_mux_core *muxc = priv->muxc;
+   struct i2c_adapter *parent = muxc->parent;
+   int ret;
+
+   /* Switch to the right mux port and perform the transfer. */
+
+   ret = muxc->select(muxc, priv->chan_id);
+   if (ret >= 0)
+   ret = i2c_transfer(parent, msgs, num);
+   if (muxc->deselect)
+   muxc->deselect(muxc, priv->chan_id);
+
+   return ret;
+}
+
 static int i2c_mux_smbus_xfer(struct i2c_adapter *adap,
  u16 addr, unsigned short flags,
  char read_write, u8 command,
@@ -76,6 +95,28 @@ static int i2c_mux_smbus_xfer(struct i2c_adapter *adap,
return ret;
 }
 
+static int __i2c_mux_smbus_xfer(struct i2c_adapter 

Re: [PATCH v5 net-next 2/3] net: macb: Add NP4 macb config using USRIO_DISABLED

[Nicolas Ferre]

Le 05/01/2016 14:39, Neil Armstrong a écrit :
> Declare a new NP4 SoC variant having USRIO_DISABLED as capability bit.
> 
> Signed-off-by: Neil Armstrong 

Acked-by: Nicolas Ferre 


> ---
>  drivers/net/ethernet/cadence/macb.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/ethernet/cadence/macb.c 
> b/drivers/net/ethernet/cadence/macb.c
> index fa53bc3..d12ee07 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -2781,6 +2781,11 @@ static const struct macb_config emac_config = {
>   .init = at91ether_init,
>  };
>  
> +static const struct macb_config np4_config = {
> + .caps = MACB_CAPS_USRIO_DISABLED,
> + .clk_init = macb_clk_init,
> + .init = macb_init,
> +};
>  
>  static const struct macb_config zynqmp_config = {
>   .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO,
> @@ -2801,6 +2806,7 @@ static const struct of_device_id macb_dt_ids[] = {
>   { .compatible = "cdns,at32ap7000-macb" },
>   { .compatible = "cdns,at91sam9260-macb", .data = _config },
>   { .compatible = "cdns,macb" },
> + { .compatible = "cdns,np4-macb", .data = _config },
>   { .compatible = "cdns,pc302-gem", .data = _config },
>   { .compatible = "cdns,gem", .data = _config },
>   { .compatible = "atmel,sama5d2-gem", .data = _config },
> 


-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 net-next 3/3] dt-bindings: net: macb: Add NP4 macb variant

[Nicolas Ferre]

Le 05/01/2016 14:39, Neil Armstrong a écrit :
> Add NP4 macb SoC variant.
> 
> Signed-off-by: Neil Armstrong 

Acked-by: Nicolas Ferre 

Neil, thanks for your understanding and reactivity concerning this patch
series.

Bye,

> ---
>  Documentation/devicetree/bindings/net/macb.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/macb.txt 
> b/Documentation/devicetree/bindings/net/macb.txt
> index 38c8e84..5c397ca 100644
> --- a/Documentation/devicetree/bindings/net/macb.txt
> +++ b/Documentation/devicetree/bindings/net/macb.txt
> @@ -4,6 +4,7 @@ Required properties:
>  - compatible: Should be "cdns,[-]{macb|gem}"
>Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs or the 10/100Mbit IP
>available on sama5d3 SoCs.
> +  Use "cdns,np4-macb" for NP4 SoC devices.
>Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: 
> "cdns,macb".
>Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based 
> on
>the Cadence GEM, or the generic form: "cdns,gem".
> 


-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver

[Rob Herring]

On Mon, Dec 21, 2015 at 2:33 AM, Peter Chen  wrote:
> On Fri, Dec 18, 2015 at 11:38 PM, Alan Stern  
> wrote:
>> On Fri, 18 Dec 2015, Peter Chen wrote:
>>
>>> On Fri, Dec 18, 2015 at 12:13 AM, Alan Stern  
>>> wrote:
>>
>>> > It's not clear (to me, anyway) how this is meant to work.  USB is a
>>> > completely discoverable bus: There is no way to represent devices
>>> > statically; they have to be discovered.  But a device can't be
>>> > discovered unless it is functional, so if an onboard hub (or any other
>>> > sort of USB device) requires power, clocks, or something similar in
>>> > order to function, it won't be discovered.  There won't be any device
>>> > structure to probe, and "forcing driver probe" won't accomplish
>>> > anything.
>>> >
>>> > It seems to me that the only way something like this could be made to
>>> > work is if the necessary actions are keyed off the host controller (and
>>> > in particular, _not_ the hub driver), presumably at the time the
>>> > controller is probed.

The problem with putting this in the the host controller driver is it
assumes the initialization sequence is generic enough to be described
in DT and that initialization is the only time we need DT data. The
MFD example is a perfect example of another case. Suspend/resume also
comes to mind. Even if we could put the control in both places, that
is poor design IMO. I'd rather just make it a requirement that the
bootloader do enough setup that devices can be discovered.

[...]

>>> +static int hub_of_children_register(struct usb_device *hdev)
>>> +{
>>> + struct device *dev;
>>> +
>>> + if (hdev->parent)
>>> + dev = >dev;
>>> + else
>>> + dev = bus_to_hcd(hdev->bus)->self.controller;
>>> +
>>> + if (!dev->of_node)
>>> + return 0;
>>
>> Suppose hdev->parent is not NULL (hdev isn't the root hub -- maybe it's
>> a 2nd-level hub).  Then how did hdev->dev->of_node get set?
>>
>
> Yes, the USB device doesn't know device node.

That should be a solvable problem...


> There are two problems which needs device tree to support, I have
> below solutions for them, please help to see if it is reasonable.
>
> 1. The USB device can't work without external clock, power, reset operation.
> At device tree, we have a node to describe external signals like clocks, gpios
> for all onboard devices under this controller. And this node is as phandle for
> host controller, see below:
>
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -108,6 +108,21 @@
> default-brightness-level = <7>;
> status = "okay";
> };
> +
> +   usbh1_pre_operation: usbh1_pre_operation {
> +   clocks = < IMX6QDL_CLK_1>,
> +< IMX6QDL_CLK_2>,
> +< IMX6QDL_CLK_3>,
> +< IMX6QDL_CLK_4>,
> +< IMX6QDL_CLK_5>,
> +< IMX6QDL_CLK_6>;
> +   reset-gpios = < 5 GPIO_ACTIVE_LOW>,
> + < 7 GPIO_ACTIVE_LOW>,
> + < 25 GPIO_ACTIVE_LOW>,
> + < 27 GPIO_ACTIVE_LOW>,
> + < 4 GPIO_ACTIVE_LOW>,
> + < 6 GPIO_ACTIVE_LOW>;
> +   };
>  };
>
>   {
> @@ -590,6 +605,8 @@
>   {
> vbus-supply = <_usb_h1_vbus>;
> status = "okay";
> +
> +   devices-pre-operation = <_pre_operation>
>  };

No. The binding should reflect the hardware connections. The hub is a
child of the USB controller/root hub. so the hub node had better be a
child of the controller in the DT. The clocks and reset are
connections to the hub, so they had better be in the hub's DT node.
There is really nothing more to discuss on the binding. Anything else
you are coming up with is working around kernel issues.


> At code, we add one API of_usb_pre_operation to get clocks and gpios through
> host controller's device node, and this API is called at usb_add_hcd,
> and opposite
> operation is called at usb_remove_hcd.
>
> This solution is almost the same with MMC power sequence solution.
> (see drivers/mmc/core/pwrseq.c)
>
> 2. There are MFD USB devices, which includes several interfaces under
> USB device,
> like i2c, gpios, etc. Due to lack of device tree support, USB
> class/device driver doesn't know
> which kinds of interfaces are needed for this board.

Are you talking about a device hard wired on the same board or
something like GPIOs on FTDI chip which could be hot-plugged in any
host (including non-DT based)?

For the hotplug case, we will need a way to associate a DT overlay
with the USB device and there may not even be a base DT to map the
overlay into. In this case, the USB device's driver will need to load
the overlay and trigger enumerating the child devices. Anyway, this is
a separate issue from your 

Re: [PATCH 0/2] power: Add support for TI BQ24261 charger

[Andreas Dannenberg]

On Mon, Dec 07, 2015 at 07:03:41AM +, Pallala, Ramakrishna wrote:
> Hi Sebastian,
> 
> > On Thu, Oct 29, 2015 at 10:07:03PM +0530, Ramakrishna Pallala wrote:
> > > This patch series adds the support for TI BQ24261 charger driver.
> > >
> > > TI BQ24261 charger driver relies on extcon notifications to get the
> > > charger cable type and based on that it will set the charging parameters.
> > 
> > I wonder if there is any new version of this patchset, that I missed with 
> > the
> > comments from Krzysztof and Andreas being taken care of?
> 
> I was bit busy lately. I will address both Krzysztof and Andreas comments and 
> submit the new patchset in the coming few days.

Hi Ram,
hope all is well. I was just wondering regarding the status of this...
Are you still planning on updating your driver with the feedback?

Regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] mfd: arizona: Add device tree binding documentation for new clock driver

[Charles Keepax]

Specify the device tree binding for the input clocks to Arizona devices.

Signed-off-by: Charles Keepax 
---
 Documentation/devicetree/bindings/mfd/arizona.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
b/Documentation/devicetree/bindings/mfd/arizona.txt
index 18be0cb..39f76f8 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -45,6 +45,13 @@ Optional properties:
 
   - wlf,reset : GPIO specifier for the GPIO controlling /RESET
 
+  - clocks: Should reference the clocks supplied on MCLK1 and MCLK2
+  - clock-names: Should contains two strings:
+  "mclk1" for the clock supplied on MCLK1, recommended to be a high
+  quality audio reference clock
+  "mclk2" for the clock supplied on MCLK2, recommended to be an always on
+  32k clock
+
   - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
 for the appropriate values can found in . If
 absent, no configuration of these registers is performed. If any entry has
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] clk: arizona: Add clock driver for the Arizona devices

[Charles Keepax]

Add an initial clock driver for the Arizona series audio CODECs.
Currently this driver only provides support for parsing the two input
clocks (mclk1, mclk2) and providing the internally consumed 32k clock.

Signed-off-by: Charles Keepax 
---
 MAINTAINERS   |   1 +
 drivers/clk/Kconfig   |   6 ++
 drivers/clk/Makefile  |   1 +
 drivers/clk/clk-arizona.c | 192 ++
 include/linux/mfd/arizona/pdata.h |   3 +
 5 files changed, 203 insertions(+)
 create mode 100644 drivers/clk/clk-arizona.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 233f834..29e161a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11681,6 +11681,7 @@ F:  
Documentation/devicetree/bindings/regulator/arizona-regulator.txt
 F: Documentation/devicetree/bindings/mfd/arizona.txt
 F: arch/arm/mach-s3c64xx/mach-crag6410*
 F: drivers/clk/clk-wm83*.c
+F: drivers/clk/clk-arizona.c
 F: drivers/extcon/extcon-arizona.c
 F: drivers/leds/leds-wm83*.c
 F: drivers/gpio/gpio-*wm*.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c3e3a02..becd743 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -25,6 +25,12 @@ config COMMON_CLK
 menu "Common Clock Framework"
depends on COMMON_CLK
 
+config COMMON_CLK_ARIZONA
+   tristate "Clock driver for Arizona devices"
+   depends on MFD_ARIZONA
+   ---help---
+ This driver supports the clocking on the Arizona devices.
+
 config COMMON_CLK_WM831X
tristate "Clock driver for WM831x/2x PMICs"
depends on MFD_WM831X
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 820714c..11e3aaa 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -17,6 +17,7 @@ endif
 
 # hardware specific clock types
 # please keep this section sorted lexicographically by file/directory path name
+obj-$(CONFIG_COMMON_CLK_ARIZONA)   += clk-arizona.o
 obj-$(CONFIG_MACH_ASM9260) += clk-asm9260.o
 obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)+= clk-axi-clkgen.o
 obj-$(CONFIG_ARCH_AXXIA)   += clk-axm5516.o
diff --git a/drivers/clk/clk-arizona.c b/drivers/clk/clk-arizona.c
new file mode 100644
index 000..1ab69ee
--- /dev/null
+++ b/drivers/clk/clk-arizona.c
@@ -0,0 +1,192 @@
+/*
+ * Arizona clock control
+ *
+ * Copyright 2016 Cirrus Logic, Inc.
+ *
+ * Author: Charles Keepax 
+ *
+ *  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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define CLK32K_RATE 32768
+
+struct arizona_clk {
+   struct arizona *arizona;
+
+   struct clk_hw clk32k_hw;
+   struct clk *clk32k;
+};
+
+static inline struct arizona_clk *clk32k_to_arizona_clk(struct clk_hw *hw)
+{
+   return container_of(hw, struct arizona_clk, clk32k_hw);
+}
+
+static int arizona_32k_enable(struct clk_hw *hw)
+{
+   struct arizona_clk *clkdata = clk32k_to_arizona_clk(hw);
+   struct arizona *arizona = clkdata->arizona;
+   int ret;
+
+   switch (arizona->pdata.clk32k_src) {
+   case ARIZONA_32KZ_MCLK1:
+   ret = pm_runtime_get_sync(arizona->dev);
+   if (ret != 0)
+   goto out;
+   break;
+   }
+
+   ret = regmap_update_bits_async(arizona->regmap, ARIZONA_CLOCK_32K_1,
+  ARIZONA_CLK_32K_ENA,
+  ARIZONA_CLK_32K_ENA);
+
+out:
+   return ret;
+}
+
+static void arizona_32k_disable(struct clk_hw *hw)
+{
+   struct arizona_clk *clkdata = clk32k_to_arizona_clk(hw);
+   struct arizona *arizona = clkdata->arizona;
+
+   regmap_update_bits_async(arizona->regmap, ARIZONA_CLOCK_32K_1,
+ARIZONA_CLK_32K_ENA, 0);
+
+   switch (arizona->pdata.clk32k_src) {
+   case ARIZONA_32KZ_MCLK1:
+   pm_runtime_put_sync(arizona->dev);
+   break;
+   }
+}
+
+static const struct clk_ops arizona_32k_ops = {
+   .prepare = arizona_32k_enable,
+   .unprepare = arizona_32k_disable,
+};
+
+static int arizona_clk_of_get_pdata(struct arizona *arizona)
+{
+   const char * const pins[] = { "mclk1", "mclk2" };
+   struct clk *mclk;
+   int i;
+
+   if (!of_property_read_bool(arizona->dev->of_node, "clocks"))
+   return 0;
+
+   for (i = 0; i < ARRAY_SIZE(pins); ++i) {
+   mclk = of_clk_get_by_name(arizona->dev->of_node, pins[i]);
+   if (IS_ERR(mclk))
+   return PTR_ERR(mclk);
+
+   if (clk_get_rate(mclk) == CLK32K_RATE) {
+   arizona->pdata.clk32k_src = 

[PATCH 3/4] mfd: arizona: Switch to using clock driver for 32k clock

[Charles Keepax]

Now we have a clock driver that can control the 32k clock use this
rather than directly controlling the 32k clock from the MFD device.

Signed-off-by: Charles Keepax 
---
 drivers/mfd/Kconfig  |   1 +
 drivers/mfd/arizona-core.c   | 104 +--
 include/linux/mfd/arizona/core.h |   7 +--
 3 files changed, 26 insertions(+), 86 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4d92df6..85aa33e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1367,6 +1367,7 @@ config MFD_ARIZONA
select REGMAP
select REGMAP_IRQ
select MFD_CORE
+   select COMMON_CLK_ARIZONA
bool
 
 config MFD_ARIZONA_I2C
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index d474732..5a55dd6 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -36,63 +36,6 @@ static const char * const wm5102_core_supplies[] = {
"DBVDD1",
 };
 
-int arizona_clk32k_enable(struct arizona *arizona)
-{
-   int ret = 0;
-
-   mutex_lock(>clk_lock);
-
-   arizona->clk32k_ref++;
-
-   if (arizona->clk32k_ref == 1) {
-   switch (arizona->pdata.clk32k_src) {
-   case ARIZONA_32KZ_MCLK1:
-   ret = pm_runtime_get_sync(arizona->dev);
-   if (ret != 0)
-   goto out;
-   break;
-   }
-
-   ret = regmap_update_bits(arizona->regmap, ARIZONA_CLOCK_32K_1,
-ARIZONA_CLK_32K_ENA,
-ARIZONA_CLK_32K_ENA);
-   }
-
-out:
-   if (ret != 0)
-   arizona->clk32k_ref--;
-
-   mutex_unlock(>clk_lock);
-
-   return ret;
-}
-EXPORT_SYMBOL_GPL(arizona_clk32k_enable);
-
-int arizona_clk32k_disable(struct arizona *arizona)
-{
-   mutex_lock(>clk_lock);
-
-   BUG_ON(arizona->clk32k_ref <= 0);
-
-   arizona->clk32k_ref--;
-
-   if (arizona->clk32k_ref == 0) {
-   regmap_update_bits(arizona->regmap, ARIZONA_CLOCK_32K_1,
-  ARIZONA_CLK_32K_ENA, 0);
-
-   switch (arizona->pdata.clk32k_src) {
-   case ARIZONA_32KZ_MCLK1:
-   pm_runtime_put_sync(arizona->dev);
-   break;
-   }
-   }
-
-   mutex_unlock(>clk_lock);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(arizona_clk32k_disable);
-
 static irqreturn_t arizona_clkgen_err(int irq, void *data)
 {
struct arizona *arizona = data;
@@ -874,6 +817,7 @@ static inline int arizona_of_get_core_pdata(struct arizona 
*arizona)
 
 static const struct mfd_cell early_devs[] = {
{ .name = "arizona-ldo1" },
+   { .name = "arizona-clk" },
 };
 
 static const char * const wm5102_supplies[] = {
@@ -970,7 +914,6 @@ int arizona_dev_init(struct arizona *arizona)
int n_subdevs, ret, i;
 
dev_set_drvdata(arizona->dev, arizona);
-   mutex_init(>clk_lock);
 
if (dev_get_platdata(arizona->dev))
memcpy(>pdata, dev_get_platdata(arizona->dev),
@@ -1261,28 +1204,6 @@ int arizona_dev_init(struct arizona *arizona)
}
 
/* Chip default */
-   if (!arizona->pdata.clk32k_src)
-   arizona->pdata.clk32k_src = ARIZONA_32KZ_MCLK2;
-
-   switch (arizona->pdata.clk32k_src) {
-   case ARIZONA_32KZ_MCLK1:
-   case ARIZONA_32KZ_MCLK2:
-   regmap_update_bits(arizona->regmap, ARIZONA_CLOCK_32K_1,
-  ARIZONA_CLK_32K_SRC_MASK,
-  arizona->pdata.clk32k_src - 1);
-   arizona_clk32k_enable(arizona);
-   break;
-   case ARIZONA_32KZ_NONE:
-   regmap_update_bits(arizona->regmap, ARIZONA_CLOCK_32K_1,
-  ARIZONA_CLK_32K_SRC_MASK, 2);
-   break;
-   default:
-   dev_err(arizona->dev, "Invalid 32kHz clock source: %d\n",
-   arizona->pdata.clk32k_src);
-   ret = -EINVAL;
-   goto err_reset;
-   }
-
for (i = 0; i < ARIZONA_MAX_MICBIAS; i++) {
if (!arizona->pdata.micbias[i].mV &&
!arizona->pdata.micbias[i].bypass)
@@ -1387,10 +1308,25 @@ int arizona_dev_init(struct arizona *arizona)
pm_runtime_set_active(arizona->dev);
pm_runtime_enable(arizona->dev);
 
+   arizona->clk32k = devm_clk_get(arizona->dev, "arizona-32k");
+   if (IS_ERR(arizona->clk32k)) {
+   ret = PTR_ERR(arizona->clk32k);
+   if (ret == -ENOENT)
+   ret = -EPROBE_DEFER;
+   dev_err(arizona->dev, "Failed to get 32k clock: %d\n", ret);
+   goto err_pm;
+   }
+
+   ret = clk_prepare_enable(arizona->clk32k);
+   if (ret < 0) {
+   dev_err(arizona->dev, "Failed to enable 

[PATCH v2 0/8] i2c mux cleanup and locking update

[Peter Rosin]

From: Peter Rosin 

Hi!

I have a pair of boards with this i2c topology:

   GPIO ---|  -- BAT1
|  v /
   I2C  -+--B---+ MUX
 |   \
   EEPROM -- BAT2

(B denotes the boundary between the boards)

The problem with this is that the GPIO controller sits on the same i2c bus
that it MUXes. For pca954x devices this is worked around by using unlocked
transfers when updating the MUX. I have no such luck as the GPIO is a general
purpose IO expander and the MUX is just a random bidirectional MUX, unaware
of the fact that it is muxing an i2c bus, and extending unlocked transfers
into the GPIO subsystem is too ugly to even think about. But the general hw
approach is sane in my opinion, with the number of connections between the
two boards minimized. To put is plainly, I need support for it.

So, I observe that while it is needed to have the i2c bus locked during the
actual MUX update in order to avoid random garbage on the slave side, it
is not strictly a must to have it locked over the whole sequence of a full
select-transfer-deselect operation. The MUX itself needs to be locked, so
transfers to clients behind the mux are serialized, and the MUX needs to be
stable during all i2c traffic (otherwise individual mux slave segments
might see garbage).

This series accomplishes this by adding a dt property to i2c-mux-gpio and
i2c-mux-pinctrl that can be used to state that the mux is updated by means
of the muxed master bus, and that the select-transfer-deselect operations
should be locked individually. When this holds, the i2c bus *is* locked
during muxing, since the muxing happens as part of i2c transfers. This
is true even if the MUX is updated with several transfers to the GPIO (at
least as long as *all* MUX changes are using the i2s master bus). A lock
is added to the mux so that transfers through the mux are serialized.

Concerns:
- The locking is perhaps too complex?
- I worry about the priority inheritance aspect of the adapter lock. When
  the transfers behind the mux are divided into select-transfer-deselect all
  locked individually, low priority transfers get more chances to interfere
  with high priority transfers.
- When doing an i2c_transfer() in_atomic() context of with irqs_disabled(),
  there is a higher possibility that the mux is not returned to its idle
  state after a failed (-EAGAIN) transfer due to trylock.

To summarize the series, there's some i2c-mux infrastructure cleanup work
first (I think that part stands by itself as desireable regardless), the
locking changes are in the last three patches of the series, with the real
meat in 8/8.

PS. needs a bunch of testing, I do not have access to all the involved hw

Changes since v1:
- Allocate mux core and (optional) priv in a combined allocation.
- Killed dev_err messages triggered by memory allocation failure.
- Fix the device specific i2c muxes that I had overlooked.
- Rebased on top of v4.4-rc8 (was based on v4.4-rc6 previously).

Cheers,
Peter

Peter Rosin (8):
  i2c-mux: add common core data for every mux instance
  i2c-mux: move select and deselect ops to i2c_mux_core
  i2c-mux: move the slave side adapter management to i2c_mux_core
  i2c-mux: remove the mux dev pointer from the mux per channel data
  i2c-mux: pinctrl: get rid of the driver private struct device pointer
  i2c: allow adapter drivers to override the adapter locking
  i2c: muxes always lock the parent adapter
  i2c-mux: relax locking of the top i2c adapter during i2c controlled
muxing

 .../devicetree/bindings/i2c/i2c-mux-gpio.txt   |   2 +
 .../devicetree/bindings/i2c/i2c-mux-pinctrl.txt|   4 +
 drivers/i2c/i2c-core.c |  59 ++---
 drivers/i2c/i2c-mux.c  | 272 +
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c |  46 ++--
 drivers/i2c/muxes/i2c-mux-gpio.c   |  58 ++---
 drivers/i2c/muxes/i2c-mux-pca9541.c|  58 +++--
 drivers/i2c/muxes/i2c-mux-pca954x.c|  66 ++---
 drivers/i2c/muxes/i2c-mux-pinctrl.c|  89 +++
 drivers/i2c/muxes/i2c-mux-reg.c|  63 ++---
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c |  33 +--
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h  |   2 +-
 drivers/media/dvb-frontends/m88ds3103.c|  23 +-
 drivers/media/dvb-frontends/m88ds3103_priv.h   |   2 +-
 drivers/media/dvb-frontends/rtl2830.c  |  24 +-
 drivers/media/dvb-frontends/rtl2830_priv.h |   2 +-
 drivers/media/dvb-frontends/rtl2832.c  |  30 ++-
 drivers/media/dvb-frontends/rtl2832_priv.h |   2 +-
 drivers/media/dvb-frontends/si2168.c   |  29 ++-
 drivers/media/dvb-frontends/si2168_priv.h  |   2 +-
 drivers/media/usb/cx231xx/cx231xx-core.c   |   6 +-
 drivers/media/usb/cx231xx/cx231xx-i2c.c

Re: [PATCH v5 net-next 1/3] net: ethernet: cadence-macb: Add disabled usrio caps

[Nicolas Ferre]

Le 05/01/2016 14:39, Neil Armstrong a écrit :
> On some platforms, the macb integration does not use the USRIO
> register to configure the (R)MII port and clocks.
> When the register is not implemented and the MACB error signal
> is connected to the bus error, reading or writing to the USRIO
> register can trigger some Imprecise External Aborts on ARM platforms.
> 
> Signed-off-by: Neil Armstrong 

Acked-by: Nicolas Ferre 

Thanks!

> ---
>  drivers/net/ethernet/cadence/macb.c | 27 +++
>  drivers/net/ethernet/cadence/macb.h |  1 +
>  2 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/ethernet/cadence/macb.c 
> b/drivers/net/ethernet/cadence/macb.c
> index 8b45bc9..fa53bc3 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -2124,7 +2124,8 @@ static void macb_get_regs(struct net_device *dev, 
> struct ethtool_regs *regs,
>   regs_buff[10] = macb_tx_dma(>queues[0], tail);
>   regs_buff[11] = macb_tx_dma(>queues[0], head);
>  
> - regs_buff[12] = macb_or_gem_readl(bp, USRIO);
> + if (!(bp->caps & MACB_CAPS_USRIO_DISABLED))
> + regs_buff[12] = macb_or_gem_readl(bp, USRIO);
>   if (macb_is_gem(bp)) {
>   regs_buff[13] = gem_readl(bp, DMACFG);
>   }
> @@ -2403,19 +2404,21 @@ static int macb_init(struct platform_device *pdev)
>   dev->hw_features &= ~NETIF_F_SG;
>   dev->features = dev->hw_features;
>  
> - val = 0;
> - if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
> - val = GEM_BIT(RGMII);
> - else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
> -  (bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
> - val = MACB_BIT(RMII);
> - else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
> - val = MACB_BIT(MII);
> + if (!(bp->caps & MACB_CAPS_USRIO_DISABLED)) {
> + val = 0;
> + if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
> + val = GEM_BIT(RGMII);
> + else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
> +  (bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
> + val = MACB_BIT(RMII);
> + else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
> + val = MACB_BIT(MII);
>  
> - if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
> - val |= MACB_BIT(CLKEN);
> + if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
> + val |= MACB_BIT(CLKEN);
>  
> - macb_or_gem_writel(bp, USRIO, val);
> + macb_or_gem_writel(bp, USRIO, val);
> + }
>  
>   /* Set MII management clock divider */
>   val = macb_mdc_clk_div(bp);
> diff --git a/drivers/net/ethernet/cadence/macb.h 
> b/drivers/net/ethernet/cadence/macb.h
> index 5c03e81..0d4ecfc 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -400,6 +400,7 @@
>  #define MACB_CAPS_USRIO_HAS_CLKEN0x0002
>  #define MACB_CAPS_USRIO_DEFAULT_IS_MII   0x0004
>  #define MACB_CAPS_NO_GIGABIT_HALF0x0008
> +#define MACB_CAPS_USRIO_DISABLED 0x0010
>  #define MACB_CAPS_FIFO_MODE  0x1000
>  #define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x2000
>  #define MACB_CAPS_SG_DISABLED0x4000
> 


-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: export of_default_bus_match_table

[Rob Herring]

On Tue, Jan 5, 2016 at 5:48 AM, Arnd Bergmann  wrote:
> On Tuesday 05 January 2016 19:50:31 Masahiro Yamada wrote:
>> 2016-01-05 19:13 GMT+09:00 Arnd Bergmann :
>> > On Tuesday 05 January 2016 11:17:53 Masahiro Yamada wrote:
>>
>> This bus is used to connect external (on-board) devices with the SoC.
>>
>> So, no possibility for AMBA, but
>> I want "simple-bus" for grouping some device nodes.
>> Also, "simple-mfd" would be useful because an external device could be an 
>> MFD.
>>
>>
>> Please see arch/arm/boot/dts/uniphier-support-card.dtsi
>>
>> It describes an add-on card (expansion board)
>> which has ETHER, UART, etc. on it.
>>
>> I implemented it as "simple-bus".
>>
>> This card is connected to the chip select 1
>> of the UniPhier System Bus.
>>
>
> Ok, got it. So you could alternatively define your own match table
> in the driver with just "simple-bus" and  "simple-mfd". I think either
> way is fine, let's see what the DT maintainers prefer.

I'd like a wrapper function here and try to eliminate non-default
matches (as well as auxdata). All but a few callers pass either
of_default_bus_match_table or NULL (populate only the immediate
children). So no, I don't want to see more match tables. It shouldn't
hurt to have extra entries in the match table (BTW, we should also
kill off "amba-bus" which is an ambiguous term).

If the wrapper was done as a static inline, we'd still need this
export, so I'm fine with this change and will apply it.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/irq: Export of_irq_count()

[Rob Herring]

On Mon, Jan 4, 2016 at 6:04 PM, Stephen Boyd  wrote:
> On 12/22, Rob Herring wrote:
>> On Tue, Dec 22, 2015 at 6:22 AM, Mark Brown  wrote:
>> > Some of the Qualcomm pinctrl drivers have started trying to use
>> > of_irq_count() in modular code but this fails to build as the symbol is
>> > not exported.  Since there doesn't seem to be any reason not to export
>> > the symbol make it available to modules.
>>
>> The reason it has not been exported is because we want to stick with
>> the platform_* APIs for IRQs. There's not really an equivalent
>> function though. Perhaps we should make one? Usually it is just used
>> for allocating some driver data. If that is the case, is it really
>> enough data to not just allocate the max?
>>
>
> It's mostly used for allocation but we also do some pin type
> discovery by reading registers and that would fail if we went
> past the actual number of pins there are.
>
> So how about implementing platform_irq_count()? I'd like to keep
> these drivers as tristate if possible.

Ack.

> 8<
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index d77ed0c946dd..421c67f8fdef 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -118,6 +118,25 @@ int platform_get_irq(struct platform_device *dev, 
> unsigned int num)
>  EXPORT_SYMBOL_GPL(platform_get_irq);
>
>  /**
> + * platform_irq_count - Count the number of IRQs a platform device uses
> + * @dev: platform device
> + *
> + * Return: Number of IRQs a platform device uses or EPROBE_DEFER
> + */
> +int platform_irq_count(struct platform_device *dev)
> +{
> +   int ret, nr = 0;
> +
> +   while ((ret = platform_get_irq(dev, nr)) == 0)
> +   nr++;
> +
> +   if (ret == -EPROBE_DEFER)
> +   return ret;
> +
> +   return nr;
> +}

Don't forget the export here. :)

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 net-next 3/3] dt-bindings: net: macb: Add NP4 macb variant

[Neil Armstrong]

Add NP4 macb SoC variant.

Signed-off-by: Neil Armstrong 
---
 Documentation/devicetree/bindings/net/macb.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/macb.txt 
b/Documentation/devicetree/bindings/net/macb.txt
index 38c8e84..5c397ca 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -4,6 +4,7 @@ Required properties:
 - compatible: Should be "cdns,[-]{macb|gem}"
   Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs or the 10/100Mbit IP
   available on sama5d3 SoCs.
+  Use "cdns,np4-macb" for NP4 SoC devices.
   Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: 
"cdns,macb".
   Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
   the Cadence GEM, or the generic form: "cdns,gem".
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 net-next 1/3] net: ethernet: cadence-macb: Add disabled usrio caps

[Neil Armstrong]

On some platforms, the macb integration does not use the USRIO
register to configure the (R)MII port and clocks.
When the register is not implemented and the MACB error signal
is connected to the bus error, reading or writing to the USRIO
register can trigger some Imprecise External Aborts on ARM platforms.

Signed-off-by: Neil Armstrong 
---
 drivers/net/ethernet/cadence/macb.c | 27 +++
 drivers/net/ethernet/cadence/macb.h |  1 +
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.c 
b/drivers/net/ethernet/cadence/macb.c
index 8b45bc9..fa53bc3 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2124,7 +2124,8 @@ static void macb_get_regs(struct net_device *dev, struct 
ethtool_regs *regs,
regs_buff[10] = macb_tx_dma(>queues[0], tail);
regs_buff[11] = macb_tx_dma(>queues[0], head);
 
-   regs_buff[12] = macb_or_gem_readl(bp, USRIO);
+   if (!(bp->caps & MACB_CAPS_USRIO_DISABLED))
+   regs_buff[12] = macb_or_gem_readl(bp, USRIO);
if (macb_is_gem(bp)) {
regs_buff[13] = gem_readl(bp, DMACFG);
}
@@ -2403,19 +2404,21 @@ static int macb_init(struct platform_device *pdev)
dev->hw_features &= ~NETIF_F_SG;
dev->features = dev->hw_features;
 
-   val = 0;
-   if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
-   val = GEM_BIT(RGMII);
-   else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
-(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
-   val = MACB_BIT(RMII);
-   else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
-   val = MACB_BIT(MII);
+   if (!(bp->caps & MACB_CAPS_USRIO_DISABLED)) {
+   val = 0;
+   if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
+   val = GEM_BIT(RGMII);
+   else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
+(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+   val = MACB_BIT(RMII);
+   else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+   val = MACB_BIT(MII);
 
-   if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
-   val |= MACB_BIT(CLKEN);
+   if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
+   val |= MACB_BIT(CLKEN);
 
-   macb_or_gem_writel(bp, USRIO, val);
+   macb_or_gem_writel(bp, USRIO, val);
+   }
 
/* Set MII management clock divider */
val = macb_mdc_clk_div(bp);
diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index 5c03e81..0d4ecfc 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -400,6 +400,7 @@
 #define MACB_CAPS_USRIO_HAS_CLKEN  0x0002
 #define MACB_CAPS_USRIO_DEFAULT_IS_MII 0x0004
 #define MACB_CAPS_NO_GIGABIT_HALF  0x0008
+#define MACB_CAPS_USRIO_DISABLED   0x0010
 #define MACB_CAPS_FIFO_MODE0x1000
 #define MACB_CAPS_GIGABIT_MODE_AVAILABLE   0x2000
 #define MACB_CAPS_SG_DISABLED  0x4000
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] extcon: arizona: Remove enable/disable of 32k clock

[Charles Keepax]

The 32k clock is unconditionally enabled by the MFD core so there is no
need to control it from the extcon device, so this patch removes the
control of the 32k clock.

Signed-off-by: Charles Keepax 
---
 drivers/extcon/extcon-arizona.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index e4890dd..52d041f 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1571,7 +1571,6 @@ static int arizona_extcon_probe(struct platform_device 
*pdev)
goto err_micdet;
}
 
-   arizona_clk32k_enable(arizona);
regmap_update_bits(arizona->regmap, ARIZONA_JACK_DETECT_DEBOUNCE,
   ARIZONA_JD1_DB, ARIZONA_JD1_DB);
regmap_update_bits(arizona->regmap, ARIZONA_JACK_DETECT_ANALOGUE,
@@ -1642,7 +1641,6 @@ static int arizona_extcon_remove(struct platform_device 
*pdev)
cancel_delayed_work_sync(>hpdet_work);
regmap_update_bits(arizona->regmap, ARIZONA_JACK_DETECT_ANALOGUE,
   ARIZONA_JD1_ENA, 0);
-   arizona_clk32k_disable(arizona);
 
return 0;
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance

[Peter Rosin]

Hi Guenter,

[BTW, if anyone feels spammed by this series, please drop me a note]

On 2016-01-05 17:42, Guenter Roeck wrote:
> On 01/05/2016 07:57 AM, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> The initial core mux structure starts off small with only the parent
>> adapter pointer, which all muxes have, and a priv pointer for mux
>> driver private data.
>>
>> Add i2c_mux_alloc function to unify the creation of a mux.
>>
>> Where appropriate, pass around the mux core structure instead of the
>> parent adapter or the driver private data.
>>
>> Remove the parent adapter pointer from the driver private data for all
>> mux drivers.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>   drivers/i2c/i2c-mux.c| 28 +-
>>   drivers/i2c/muxes/i2c-arb-gpio-challenge.c   | 24 +--
>>   drivers/i2c/muxes/i2c-mux-gpio.c | 20 
>>   drivers/i2c/muxes/i2c-mux-pca9541.c  | 35 
>> ++--
>>   drivers/i2c/muxes/i2c-mux-pca954x.c  | 19 ++-
>>   drivers/i2c/muxes/i2c-mux-pinctrl.c  | 23 +-
>>   drivers/i2c/muxes/i2c-mux-reg.c  | 23 ++
>>   drivers/iio/imu/inv_mpu6050/inv_mpu_core.c   | 10 +++-
>>   drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h|  1 +
>>   drivers/media/dvb-frontends/m88ds3103.c  | 10 +++-
>>   drivers/media/dvb-frontends/m88ds3103_priv.h |  1 +
>>   drivers/media/dvb-frontends/rtl2830.c| 10 +++-
>>   drivers/media/dvb-frontends/rtl2830_priv.h   |  1 +
>>   drivers/media/dvb-frontends/rtl2832.c| 10 +++-
>>   drivers/media/dvb-frontends/rtl2832_priv.h   |  1 +
>>   drivers/media/dvb-frontends/si2168.c | 10 +++-
>>   drivers/media/dvb-frontends/si2168_priv.h|  1 +
>>   drivers/media/usb/cx231xx/cx231xx-core.c |  3 +++
>>   drivers/media/usb/cx231xx/cx231xx-i2c.c  | 13 +--
>>   drivers/media/usb/cx231xx/cx231xx.h  |  2 ++
>>   drivers/of/unittest.c| 16 +++--
>>   include/linux/i2c-mux.h  | 14 ++-
>>   22 files changed, 187 insertions(+), 88 deletions(-)
>>
>> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
>> index 00fc5b1c7b66..c2163f6b51d5 100644
>> --- a/drivers/i2c/i2c-mux.c
>> +++ b/drivers/i2c/i2c-mux.c
>> @@ -31,8 +31,8 @@
>>   struct i2c_mux_priv {
>>   struct i2c_adapter adap;
>>   struct i2c_algorithm algo;
>> +struct i2c_mux_core *muxc;
>>
>> -struct i2c_adapter *parent;
>>   struct device *mux_dev;
>>   void *mux_priv;
>>   u32 chan_id;
>> @@ -45,7 +45,8 @@ static int i2c_mux_master_xfer(struct i2c_adapter *adap,
>>  struct i2c_msg msgs[], int num)
>>   {
>>   struct i2c_mux_priv *priv = adap->algo_data;
>> -struct i2c_adapter *parent = priv->parent;
>> +struct i2c_mux_core *muxc = priv->muxc;
>> +struct i2c_adapter *parent = muxc->parent;
>>   int ret;
>>
>>   /* Switch to the right mux port and perform the transfer. */
>> @@ -65,7 +66,8 @@ static int i2c_mux_smbus_xfer(struct i2c_adapter *adap,
>> int size, union i2c_smbus_data *data)
>>   {
>>   struct i2c_mux_priv *priv = adap->algo_data;
>> -struct i2c_adapter *parent = priv->parent;
>> +struct i2c_mux_core *muxc = priv->muxc;
>> +struct i2c_adapter *parent = muxc->parent;
>>   int ret;
>>
>>   /* Select the right mux port and perform the transfer. */
>> @@ -84,7 +86,7 @@ static int i2c_mux_smbus_xfer(struct i2c_adapter *adap,
>>   static u32 i2c_mux_functionality(struct i2c_adapter *adap)
>>   {
>>   struct i2c_mux_priv *priv = adap->algo_data;
>> -struct i2c_adapter *parent = priv->parent;
>> +struct i2c_adapter *parent = priv->muxc->parent;
>>
>>   return parent->algo->functionality(parent);
>>   }
>> @@ -102,7 +104,20 @@ static unsigned int i2c_mux_parent_classes(struct 
>> i2c_adapter *parent)
>>   return class;
>>   }
>>
>> -struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter *parent,
>> +struct i2c_mux_core *i2c_mux_alloc(struct device *dev, int sizeof_priv)
>> +{
>> +struct i2c_mux_core *muxc;
>> +
>> +muxc = devm_kzalloc(dev, sizeof(*muxc) + sizeof_priv, GFP_KERNEL);
>> +if (!muxc)
>> +return NULL;
>> +if (sizeof_priv)
>> +muxc->priv = muxc + 1;
>> +return muxc;
>> +}
>> +EXPORT_SYMBOL_GPL(i2c_mux_alloc);
>> +
>> +struct i2c_adapter *i2c_add_mux_adapter(struct i2c_mux_core *muxc,
>>   struct device *mux_dev,
>>   void *mux_priv, u32 force_nr, u32 chan_id,
>>   unsigned int class,
>> @@ -111,6 +126,7 @@ struct i2c_adapter *i2c_add_mux_adapter(struct 
>> i2c_adapter *parent,
>>   int (*deselect) (struct i2c_adapter *,
>>void *, u32))
>>   {
>> +struct i2c_adapter *parent = muxc->parent;
>>   struct i2c_mux_priv 

[PATCH v2 3/4] ARM: imx: config: enable psci default

[Frank Li]

From: Frank Li 

i.MX7D uboot support psci firmware.
Enabled psci default.

Signed-off-by: Frank Li 
---
Change from v1 to v2:
 arm to "ARM"

 arch/arm/configs/imx_v6_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index 2d5253d..1e792ef 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -47,6 +47,7 @@ CONFIG_PCI=y
 CONFIG_PCI_MSI=y
 CONFIG_PCI_IMX6=y
 CONFIG_SMP=y
+CONFIG_ARM_PSCI=y
 CONFIG_PREEMPT_VOLUNTARY=y
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/4] ARM: imx7d: correct chip version information

[Frank Li]

From: Frank Li 

The commond 'cat /sys/devices/soc0/revision' can
show correct soc version information.

"unknow revision" message in imx_print_silicon_rev()
will never work for digprog.

Signed-off-by: Frank Li 
---
Change from v1 to v2:
 fix grammer issues in comments.

 arch/arm/mach-imx/anatop.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
index 231bb25..bd3555e 100644
--- a/arch/arm/mach-imx/anatop.c
+++ b/arch/arm/mach-imx/anatop.c
@@ -151,7 +151,14 @@ void __init imx_init_revision_from_anatop(void)
revision = IMX_CHIP_REVISION_1_5;
break;
default:
-   revision = IMX_CHIP_REVISION_UNKNOWN;
+   /*
+* Fail back to return raw register value instead of 0xff.
+* It will be easy to know version information in SOC if it
+* can't be recognized by known version. And some chip's 
(i.MX7D)
+* digprog value match linux version format, so it needn't map
+* again and we can use register value directly.
+*/
+   revision = digprog & 0xff;
}
 
mxc_set_cpu_type(digprog >> 16 & 0xff);
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/5] Add memory mapped read support for ti-qspi

[Mark Brown]

On Tue, Jan 05, 2016 at 10:50:42AM +0530, Vignesh R wrote:
> Hi Brian,
> 
> On 12/11/2015 09:39 AM, Vignesh R wrote:
> > Changes since v4:
> > Use syscon to access system control module register in ti-qspi driver.
> > 
> 
> Gentle ping...
> Are you ok with MTD side changes of this patch series?

Please don't send content free pings and please allow a reasonable time
for review (we've just had the Christmas vacation...).


signature.asc
Description: PGP signature

Re: [PATCH v2 0/8] i2c mux cleanup and locking update

[Peter Rosin]

Hi Wolfram,

On 2016-01-05 19:48, Wolfram Sang wrote:
> Peter,
> 
>> PS. needs a bunch of testing, I do not have access to all the involved hw
> 
> First of all, thanks for diving into this topic and the huge effort you
> apparently have put into it.

Yeah, I started with dipping just the toes, but now it rather feels like
I'm fully submerged at the deep end...

> It is obviously a quite intrusive series, so it needs careful review.
> TBH, I can't really tell when I have the bandwidth to do that, so I hope
> other people will step up. And yes, it needs serious testing.
> 
> To all: Although I appreciate any review support, I'd think the first
> thing to be done should be a very high level review - is this series
> worth the huge update? Is the path chosen proper? Stuff like this. I'd
> appreciate Acks or Revs for that. Stuff like fixing checkpatch warnings
> and other minor stuff should come later.

Right, I'll hold back on sending updates for trivial stuff until the
big picture stuff has been cleared.

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

[Peter Rosin]

Hi,

This should fix it (I'm not sending a v3 right away).

Cheers,
Peter

diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c 
b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
index 1c982a56acd5..5de993deca7e 100644
--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
+++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "inv_mpu_iio.h"
@@ -182,7 +183,7 @@ int inv_mpu_acpi_create_mux_client(struct inv_mpu6050_state 
*st)
} else
return 0; /* no secondary addr, which is OK */
}
-   st->mux_client = i2c_new_device(st->mux_adapter, );
+   st->mux_client = i2c_new_device(st->muxc->adapter[0], );
if (!st->mux_client)
return -ENODEV;
 
-- 


On 2016-01-05 17:49, kbuild test robot wrote:
> Hi Peter,
> 
> [auto build test ERROR on wsa/i2c/for-next]
> [also build test ERROR on v4.4-rc8 next-20160105]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Peter-Rosin/i2c-mux-cleanup-and-locking-update/20160106-000205
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux i2c/for-next
> config: i386-randconfig-s1-201601 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c: In function 
> 'inv_mpu_acpi_create_mux_client':
>>> drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c:185:37: error: 'struct 
>>> inv_mpu6050_state' has no member named 'mux_adapter'
>   st->mux_client = i2c_new_device(st->mux_adapter, );
> ^
> 
> vim +185 drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
> 
> a35c5d1a Srinivas Pandruvada 2015-01-30  179  
> *name = '\0';
> a35c5d1a Srinivas Pandruvada 2015-01-30  180  
> strlcat(info.type, "-client",
> a35c5d1a Srinivas Pandruvada 2015-01-30  181  
> sizeof(info.type));
> a35c5d1a Srinivas Pandruvada 2015-01-30  182  } else
> a35c5d1a Srinivas Pandruvada 2015-01-30  183  
> return 0; /* no secondary addr, which is OK */
> a35c5d1a Srinivas Pandruvada 2015-01-30  184  }
> a35c5d1a Srinivas Pandruvada 2015-01-30 @185  st->mux_client 
> = i2c_new_device(st->mux_adapter, );
> a35c5d1a Srinivas Pandruvada 2015-01-30  186  if 
> (!st->mux_client)
> a35c5d1a Srinivas Pandruvada 2015-01-30  187  return 
> -ENODEV;
> a35c5d1a Srinivas Pandruvada 2015-01-30  188  
> 
> :: The code at line 185 was first introduced by commit
> :: a35c5d1aa96aa6cc70e91786cbe9be4db23f8f4a iio: imu: inv_mpu6050: Create 
> mux clients for ACPI
> 
> :: TO: Srinivas Pandruvada <srinivas.pandruv...@linux.intel.com>
> :: CC: Jonathan Cameron <ji...@kernel.org>
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/8] i2c mux cleanup and locking update

[Wolfram Sang]

Peter,

> PS. needs a bunch of testing, I do not have access to all the involved hw

First of all, thanks for diving into this topic and the huge effort you
apparently have put into it.

It is obviously a quite intrusive series, so it needs careful review.
TBH, I can't really tell when I have the bandwidth to do that, so I hope
other people will step up. And yes, it needs serious testing.

To all: Although I appreciate any review support, I'd think the first
thing to be done should be a very high level review - is this series
worth the huge update? Is the path chosen proper? Stuff like this. I'd
appreciate Acks or Revs for that. Stuff like fixing checkpatch warnings
and other minor stuff should come later.

Thanks,

   Wolfram



signature.asc
Description: Digital signature

[PATCH v2 1/4] ARM: dts: imx7d: add arch timer

[Frank Li]

From: Frank Li 

Since uboot v2016.01-rc2, which supported basic psci for i.mx7d.
So imx7d's second core can be enabled by psci.

Without arch timer, every timer event will be boardcasted to each core.
arch timer has local timer irq for each core.

Signed-off-by: Frank Li 
---

Change from v1 to v2:
 * refine commit message show the relationship between smp and arch timer

 arch/arm/boot/dts/imx7d.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 489604a..a621af6 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -119,6 +119,15 @@
clock-output-names = "osc";
};
 
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+,
+,
+;
+   interrupt-parent = <>;
+   };
+
etr@30086000 {
compatible = "arm,coresight-tmc", "arm,primecell";
reg = <0x30086000 0x1000>;
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/5] misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device.

[Cory Tusar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/21/2015 07:19 PM, Vladimir Zapolskiy wrote:
> 
> 
> With best wishes,
> Vladimir
> 
> On 10.12.2015 06:00, Cory Tusar wrote:
>> Atmel devices in this family have some quirks not found in other similar
>> chips - they do not support a sequential read of the entire EEPROM
>> contents, and the control word sent at the start of each operation
>> varies in bit length.
>>
>> This commit adds quirk support to the driver and modifies the read
>> implementation to support non-sequential reads for consistency with
>> other misc/eeprom drivers.
>>
>> Tested on a custom Freescale VF610-based platform, with an AT93C46D
>> device attached via dspi2.  The spi-gpio driver was used to allow the
>> necessary non-byte-sized transfers.
>>
>> Signed-off-by: Cory Tusar 
>> Tested-by: Chris Healy 
>> ---
>>  drivers/misc/eeprom/eeprom_93xx46.c | 126 
>> ++--
>>  include/linux/eeprom_93xx46.h   |   6 ++
>>  2 files changed, 97 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
>> b/drivers/misc/eeprom/eeprom_93xx46.c
>> index cc27e11..d50bc17 100644
>> --- a/drivers/misc/eeprom/eeprom_93xx46.c
>> +++ b/drivers/misc/eeprom/eeprom_93xx46.c
>> @@ -27,6 +27,15 @@
>>  #define ADDR_ERAL   0x20
>>  #define ADDR_EWEN   0x30
>>  
>> +struct eeprom_93xx46_devtype_data {
>> +unsigned int quirks;
>> +};
>> +
>> +static const struct eeprom_93xx46_devtype_data atmel_at93c46d_data = {
>> +.quirks = EEPROM_93XX46_QUIRK_SINGLE_WORD_READ |
>> +  EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH,
>> +};
>> +
>>  struct eeprom_93xx46_dev {
>>  struct spi_device *spi;
>>  struct eeprom_93xx46_platform_data *pdata;
>> @@ -35,6 +44,16 @@ struct eeprom_93xx46_dev {
>>  int addrlen;
>>  };
>>  
>> +static inline bool has_quirk_single_word_read(struct eeprom_93xx46_dev 
>> *edev)
>> +{
>> +return edev->pdata->quirks & EEPROM_93XX46_QUIRK_SINGLE_WORD_READ;
>> +}
>> +
>> +static inline bool has_quirk_instruction_length(struct eeprom_93xx46_dev 
>> *edev)
>> +{
>> +return edev->pdata->quirks & EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH;
>> +}
>> +
>>  static ssize_t
>>  eeprom_93xx46_bin_read(struct file *filp, struct kobject *kobj,
>> struct bin_attribute *bin_attr,
>> @@ -42,58 +61,73 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject 
>> *kobj,
>>  {
>>  struct eeprom_93xx46_dev *edev;
>>  struct device *dev;
>> -struct spi_message m;
>> -struct spi_transfer t[2];
>> -int bits, ret;
>> -u16 cmd_addr;
>> +ssize_t ret = 0;
>>  
>>  dev = container_of(kobj, struct device, kobj);
>>  edev = dev_get_drvdata(dev);
>>  
>> -cmd_addr = OP_READ << edev->addrlen;
>> +mutex_lock(>lock);
>>  
>> -if (edev->addrlen == 7) {
>> -cmd_addr |= off & 0x7f;
>> -bits = 10;
>> -} else {
>> -cmd_addr |= (off >> 1) & 0x3f;
>> -bits = 9;
>> -}
>> +if (edev->pdata->prepare)
>> +edev->pdata->prepare(edev);
>>  
>> -dev_dbg(>spi->dev, "read cmd 0x%x, %d Hz\n",
>> -cmd_addr, edev->spi->max_speed_hz);
>> +while (count) {
>> +struct spi_message m;
>> +struct spi_transfer t[2] = { { 0 } };
>> +u16 cmd_addr = OP_READ << edev->addrlen;
>> +size_t nbytes = count;
>> +int bits;
>> +int err;
>> +
>> +if (edev->addrlen == 7) {
>> +cmd_addr |= off & 0x7f;
>> +bits = 10;
>> +if (has_quirk_single_word_read(edev))
>> +nbytes = 1;
>> +} else {
>> +cmd_addr |= (off >> 1) & 0x3f;
>> +bits = 9;
>> +if (has_quirk_single_word_read(edev))
>> +nbytes = 2;
>> +}
>>  
>> -spi_message_init();
>> -memset(t, 0, sizeof(t));
>> +dev_dbg(>spi->dev, "read cmd 0x%x, %d Hz\n",
>> +cmd_addr, edev->spi->max_speed_hz);
>>  
>> -t[0].tx_buf = (char *)_addr;
>> -t[0].len = 2;
>> -t[0].bits_per_word = bits;
>> -spi_message_add_tail([0], );
>> +spi_message_init();
>>  
>> -t[1].rx_buf = buf;
>> -t[1].len = count;
>> -t[1].bits_per_word = 8;
>> -spi_message_add_tail([1], );
>> +t[0].tx_buf = (char *)_addr;
>> +t[0].len = 2;
>> +t[0].bits_per_word = bits;
>> +spi_message_add_tail([0], );
>>  
>> -mutex_lock(>lock);
>> +t[1].rx_buf = buf;
>> +t[1].len = count;
>> +t[1].bits_per_word = 8;
>> +spi_message_add_tail([1], );
>>  
>> -if (edev->pdata->prepare)
>> -edev->pdata->prepare(edev);
>> +err = spi_sync(edev->spi, );
>> +/* have to wait at least Tcsl ns */
>> + 

Re: [PATCH v4 3/5] misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings.

[Cory Tusar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/21/2015 07:12 PM, Vladimir Zapolskiy wrote:
> Hi Cory,
> 
> On 10.12.2015 06:00, Cory Tusar wrote:
>> This commit implements bindings in the eeprom_93xx46 driver allowing
>> device word size and read-only attributes to be specified via
>> devicetree.
>>
>> Signed-off-by: Cory Tusar 
>> Tested-by: Chris Healy 
>> ---
>>  drivers/misc/eeprom/eeprom_93xx46.c | 49 
>> +
>>  1 file changed, 49 insertions(+)
>>
>> diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
>> b/drivers/misc/eeprom/eeprom_93xx46.c
>> index e1bf0a5..cc27e11 100644
>> --- a/drivers/misc/eeprom/eeprom_93xx46.c
>> +++ b/drivers/misc/eeprom/eeprom_93xx46.c
>> @@ -13,6 +13,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -294,12 +296,58 @@ static ssize_t eeprom_93xx46_store_erase(struct device 
>> *dev,
>>  }
>>  static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
>>  
>> +static const struct of_device_id eeprom_93xx46_of_table[] = {
>> +{ .compatible = "eeprom-93xx46", },
> 
> immediately do you want to add the second (and much, much more preferred IMO)
> mentioned compatible value "atmel,at93c46d" to the list? Also see a note
> below.

Hi Vladimir,

That compatible value is included as part of the next patch; the Atmel
part required additional quirk support which was (IMO) separate from
exposing just existing platform device parameters.

> 
>> +{}
>> +};
>> +MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
>> +
>> +static int eeprom_93xx46_probe_dt(struct spi_device *spi)
>> +{
>> +struct device_node *np = spi->dev.of_node;
>> +struct eeprom_93xx46_platform_data *pd;
>> +u32 tmp;
>> +int ret;
>> +
>> +pd = devm_kzalloc(>dev, sizeof(*pd), GFP_KERNEL);
>> +if (!pd)
>> +return -ENOMEM;
>> +
>> +ret = of_property_read_u32(np, "data-size", );
>> +if (ret < 0) {
>> +dev_err(>dev, "data-size property not found\n");
>> +return ret;
>> +}
>> +
>> +if (tmp == 8) {
>> +pd->flags |= EE_ADDR8;
>> +} else if (tmp == 16) {
>> +pd->flags |= EE_ADDR16;
>> +} else {
>> +dev_err(>dev, "invalid data-size (%d)\n", tmp);
>> +return -EINVAL;
>> +}
> 
> If you insist on mandatory "data-size" property, could you please check
> arch/x86/platform/ce4100/falconfalls.dts , does it require updates?

Unknown.  I see no other documented reference to that particular
compatible string...looks like it was a placeholder back when the
CE4100 platform was first added.

> In that DTS you may find "atmel,at93c46" compatible value, is that kind
> of devices covered by this driver? If yes, does it make sense to
> add "atmel,at93c46" to the list of compatible values replacing
> "atmel,at93c46d" ?

Yes, that device _should_ generally work, but a quick look at both
datasheets leads me to believe that quirks differ enough to probably
warrant its own compatible value.

For example, EWEN for an x8 strapped AT93C46 is b'10011x and
b'10011xxx for the AT93C46D.  That difference is handled by
EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH.

> 
>> +
>> +if (of_property_read_bool(np, "read-only"))
>> +pd->flags |= EE_READONLY;
>> +
>> +spi->dev.platform_data = pd;
>> +
>> +return 0;
>> +}
>> +
>>  static int eeprom_93xx46_probe(struct spi_device *spi)
>>  {
>>  struct eeprom_93xx46_platform_data *pd;
>>  struct eeprom_93xx46_dev *edev;
>>  int err;
>>  
>> +if (spi->dev.of_node) {
>> +err = eeprom_93xx46_probe_dt(spi);
>> +if (err < 0)
>> +return err;
>> +}
>> +
>>  pd = spi->dev.platform_data;
>>  if (!pd) {
>>  dev_err(>dev, "missing platform data\n");
>> @@ -370,6 +418,7 @@ static int eeprom_93xx46_remove(struct spi_device *spi)
>>  static struct spi_driver eeprom_93xx46_driver = {
>>  .driver = {
>>  .name   = "93xx46",
>> +.of_match_table = of_match_ptr(eeprom_93xx46_of_table),
>>  },
>>  .probe  = eeprom_93xx46_probe,
>>  .remove = eeprom_93xx46_remove,
>>
> 
> Reviewed-by: Vladimir Zapolskiy 

Thanks and best regards,
- -Cory


- -- 
Cory Tusar
Principal
PID 1 Solutions, Inc.


"There are two ways of constructing a software design.  One way is to
 make it so simple that there are obviously no deficiencies, and the
 other way is to make it so complicated that there are no obvious
 deficiencies."  --Sir Charles Anthony Richard Hoare

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlaMh4kACgkQHT1tsfGwHJ/cpgCgmedYRGYlq+tTNzl2akHZk2C7
3s8AoJ0qI14wafGJypOfbQii3kX+6Kdd
=z4WO
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More 

[PATCH 1/1] regulator: max8973: add support for junction thermal warning

[Laxman Dewangan]

The driver MAX8973 supports the driver for Maxim PMIC MAX77621.
MAX77621 supports the  junction temp warning at 120 degC and
140 degC which is configurable. It generates alert signal when
junction temperature crosses these threshold.

MAX77621 does not support the continuous temp monitoring of
junction temperature. It just report whether junction temperature
crossed the threshold or not.

Add support to
- Configure junction temp warning threshold via DT property
  to generate alert when it crosses the threshold.
- Add support to interrupt the host from this device when alert
  occurred.
- read the junction temp via thermal framework.

Signed-off-by: Laxman Dewangan 
---
 .../bindings/regulator/max8973-regulator.txt   |   6 +
 drivers/regulator/max8973-regulator.c  | 144 -
 include/linux/regulator/max8973-regulator.h|   6 +
 3 files changed, 154 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt 
b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt
index f80ea2f..88bf9b1 100644
--- a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt
@@ -31,6 +31,12 @@ Optional properties:
property is available then etr will be enable default.
 
 Enhanced transient response (ETR) will affect the configuration of CKADV.
+-maxim,junction-temp-warning: Junction temp warning on which device generates
+   warning interrupts.
+-interrupt-flags: Interrupt flags for registering interrupt which can not be
+   passed via interrupt properties.
+
+Please note that thermal functionality is only supported on MAX77621.
 
 Example:
 
diff --git a/drivers/regulator/max8973-regulator.c 
b/drivers/regulator/max8973-regulator.c
index 5b75b7c..6ffb3ac 100644
--- a/drivers/regulator/max8973-regulator.c
+++ b/drivers/regulator/max8973-regulator.c
@@ -38,6 +38,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 /* Register definitions */
 #define MAX8973_VOUT   0x0
@@ -74,6 +77,7 @@
 #define MAX8973_WDTMR_ENABLE   BIT(6)
 #define MAX8973_DISCH_ENBABLE  BIT(5)
 #define MAX8973_FT_ENABLE  BIT(4)
+#define MAX77621_T_JUNCTION_120BIT(7)
 
 #define MAX8973_CKKADV_TRIP_MASK   0xC
 #define MAX8973_CKKADV_TRIP_DISABLE0xC
@@ -93,6 +97,13 @@
 #define MAX8973_VOLATGE_STEP   6250
 #define MAX8973_BUCK_N_VOLTAGE 0x80
 
+#define MAX77621_CHIPID_TJINT_SBIT(0)
+
+#define MAX77621_NORMAL_OPERATING_TEMP 10
+#define MAX77621_TJINT_WARNING_TEMP_12012
+#define MAX77621_TJINT_WARNING_TEMP_14014
+
+
 enum device_id {
MAX8973,
MAX77621
@@ -112,6 +123,10 @@ struct max8973_chip {
int curr_gpio_val;
struct regulator_ops ops;
enum device_id id;
+   int junction_temp_warning;
+   int irq;
+   unsigned long irq_flags;
+   struct thermal_zone_device *tz_device;
 };
 
 /*
@@ -391,6 +406,10 @@ static int max8973_init_dcdc(struct max8973_chip *max,
if (pdata->control_flags & MAX8973_CONTROL_FREQ_SHIFT_9PER_ENABLE)
control1 |= MAX8973_FREQSHIFT_9PER;
 
+   if ((max->id == MAX77621) && (pdata->junction_temp_warning ==
+   MAX77621_TJINT_WARNING_TEMP_120))
+   control2 |=  MAX77621_T_JUNCTION_120;
+
if (!(pdata->control_flags & MAX8973_CONTROL_PULL_DOWN_ENABLE))
control2 |= MAX8973_DISCH_ENBABLE;
 
@@ -457,6 +476,94 @@ static int max8973_init_dcdc(struct max8973_chip *max,
return ret;
 }
 
+#ifdef CONFIG_THERMAL_OF
+static int max8973_thermal_read_temp(void *data, int *temp)
+{
+   struct max8973_chip *mchip = data;
+   unsigned int val;
+   int ret;
+
+   ret = regmap_read(mchip->regmap, MAX8973_CHIPID1, );
+   if (ret < 0) {
+   dev_err(mchip->dev, "register CHIPID1 read failed, %d", ret);
+   return ret;
+   }
+
+   /* +1 degC to trigger cool devive */
+   if (val & MAX77621_CHIPID_TJINT_S)
+   *temp = mchip->junction_temp_warning + 1000;
+   else
+   *temp = MAX77621_NORMAL_OPERATING_TEMP;
+
+   return 0;
+}
+
+static irqreturn_t max8973_thermal_irq(int irq, void *data)
+{
+   struct max8973_chip *mchip = data;
+
+   dev_info(mchip->dev, "Junction Temp warning occurred\n");
+   thermal_zone_device_update(mchip->tz_device);
+   return IRQ_HANDLED;
+}
+
+static const struct thermal_zone_of_device_ops max77621_tz_ops = {
+   .get_temp = max8973_thermal_read_temp,
+};
+
+static int 

Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver

[Peter Chen]

On Tue, Jan 05, 2016 at 08:36:31AM -0600, Rob Herring wrote:
> > 2. There are MFD USB devices, which includes several interfaces under
> > USB device,
> > like i2c, gpios, etc. Due to lack of device tree support, USB
> > class/device driver doesn't know
> > which kinds of interfaces are needed for this board.
> 
> Are you talking about a device hard wired on the same board or
> something like GPIOs on FTDI chip which could be hot-plugged in any
> host (including non-DT based)?

I talked about the case that the device hard wired on the board.
Hot-plug device's bus topology is unknown, we can't describe it
statically at dts.

> 
> For the hotplug case, we will need a way to associate a DT overlay
> with the USB device and there may not even be a base DT to map the
> overlay into. In this case, the USB device's driver will need to load
> the overlay and trigger enumerating the child devices. Anyway, this is
> a separate issue from your problem.
> 

Since both you and Alan agree with my problem should be fixed at
bootloader, I give the kernel solution up. 

The another thing I open to discuss is how to let USB devices know its
device node, the user reported issue that they can't handle interfaces
below in USB device since that.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 5/5] misc: eeprom_93xx46: Add support for a GPIO 'select' line.

[Cory Tusar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/21/2015 07:30 PM, Vladimir Zapolskiy wrote:
> Hi Cory,
> 
> On 10.12.2015 06:00, Cory Tusar wrote:
>> This commit adds support to the eeprom_93x46 driver allowing a GPIO line
>> to function as a 'select' or 'enable' signal prior to accessing the
>> EEPROM.
>>
>> Signed-off-by: Cory Tusar 
>> Tested-by: Chris Healy 
>> ---
>>  drivers/misc/eeprom/eeprom_93xx46.c | 35 +++
>>  include/linux/eeprom_93xx46.h   |  3 +++
>>  2 files changed, 38 insertions(+)
>>
>> diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
>> b/drivers/misc/eeprom/eeprom_93xx46.c
>> index d50bc17..d28fac2 100644
>> --- a/drivers/misc/eeprom/eeprom_93xx46.c
>> +++ b/drivers/misc/eeprom/eeprom_93xx46.c
>> @@ -10,11 +10,13 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -343,6 +345,20 @@ static ssize_t eeprom_93xx46_store_erase(struct device 
>> *dev,
>>  }
>>  static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
>>  
>> +static void select_assert(void *context)
>> +{
>> +struct eeprom_93xx46_dev *edev = context;
>> +
>> +gpiod_set_value_cansleep(edev->pdata->select, 1);
>> +}
>> +
>> +static void select_deassert(void *context)
>> +{
>> +struct eeprom_93xx46_dev *edev = context;
>> +
>> +gpiod_set_value_cansleep(edev->pdata->select, 0);
>> +}
>> +
>>  static const struct of_device_id eeprom_93xx46_of_table[] = {
>>  { .compatible = "eeprom-93xx46", },
>>  { .compatible = "atmel,at93c46d", .data = _at93c46d_data, },
>> @@ -357,6 +373,8 @@ static int eeprom_93xx46_probe_dt(struct spi_device *spi)
>>  struct device_node *np = spi->dev.of_node;
>>  struct eeprom_93xx46_platform_data *pd;
>>  u32 tmp;
>> +int gpio;
>> +enum of_gpio_flags of_flags;
>>  int ret;
>>  
>>  pd = devm_kzalloc(>dev, sizeof(*pd), GFP_KERNEL);
>> @@ -381,6 +399,23 @@ static int eeprom_93xx46_probe_dt(struct spi_device 
>> *spi)
>>  if (of_property_read_bool(np, "read-only"))
>>  pd->flags |= EE_READONLY;
>>  
>> +gpio = of_get_named_gpio_flags(np, "select-gpios", 0, _flags);
>> +if (gpio_is_valid(gpio)) {
>> +unsigned long flags =
>> +of_flags == OF_GPIO_ACTIVE_LOW ? GPIOF_ACTIVE_LOW : 0;
>> +
>> +ret = devm_gpio_request_one(>dev, gpio, flags,
>> +"eeprom_93xx46_select");
>> +if (ret)
>> +return ret;
>> +
>> +pd->select = gpio_to_desc(gpio);
>> +pd->prepare = select_assert;
>> +pd->finish = select_deassert;
>> +
>> +gpiod_direction_output(pd->select, 0);
>> +}
>> +
>>  if (of_id->data) {
>>  const struct eeprom_93xx46_devtype_data *data = of_id->data;
>>  
>> diff --git a/include/linux/eeprom_93xx46.h b/include/linux/eeprom_93xx46.h
>> index 92fa4c3..03f3435 100644
>> --- a/include/linux/eeprom_93xx46.h
>> +++ b/include/linux/eeprom_93xx46.h
>> @@ -3,6 +3,8 @@
>>   * platform description for 93xx46 EEPROMs.
>>   */
>>  
>> +#include 
>> +
> 
> You need just "struct gpio_desc;" instead of the include here, please fix.

Hi Vladimir,

I'll fix for v5.

> 
>>  struct eeprom_93xx46_platform_data {
>>  unsigned char   flags;
>>  #define EE_ADDR80x01/*  8 bit addr. cfg */
>> @@ -21,4 +23,5 @@ struct eeprom_93xx46_platform_data {
>>   */
>>  void (*prepare)(void *);
>>  void (*finish)(void *);
>> +struct gpio_desc *select;
>>  };
>>
> 
> Reviewed-by: Vladimir Zapolskiy 

Thanks and best regards,
- -Cory


- -- 
Cory Tusar
Principal
PID 1 Solutions, Inc.


"There are two ways of constructing a software design.  One way is to
 make it so simple that there are obviously no deficiencies, and the
 other way is to make it so complicated that there are no obvious
 deficiencies."  --Sir Charles Anthony Richard Hoare

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlaMiFUACgkQHT1tsfGwHJ8PvwCgmCxWi9TiL+ZXCI6IYZgaGZbT
vHsAn3FOyuJ5tAqb6JywtDY6piiQGywv
=2mcd
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] drm/rockchip: vop: add rk3229 vop support

[Yakir Yang]

Hi Mark,

On 01/06/2016 08:56 AM, Mark yao wrote:

On 2016年01月05日 11:58, Yakir Yang wrote:

RK3229 registers layout is simalar to RK3288 layout, only the
interruput registers is different to RK3288.

RK3229 support two overlay plane and one hwc plane, max output
resolution is 4K. it support IOMMU, and its IOMMU same as rk3288's.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- Separate the write-mask changes out, and remove the DUMMY_INTR 
marcos (Heiko)


  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 110 

  drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  90 
+++

  2 files changed, 200 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c

index 7fbaf76..f1358f9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -191,6 +191,114 @@ static const struct vop_data rk3288_vop = {
  .win_size = ARRAY_SIZE(rk3288_vop_win_data),
  };
  +static const struct vop_scl_extension rk3229_win_full_scl_ext = {
+.cbcr_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 31),
+.cbcr_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 30),
+.cbcr_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 28),
+.cbcr_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 26),
+.cbcr_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 24),
+.yrgb_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 23),
+.yrgb_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 22),
+.yrgb_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 20),
+.yrgb_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 18),
+.yrgb_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 16),
+.line_load_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 15),
+.cbcr_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0x7, 12),
+.yrgb_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0xf, 8),
+.vsd_cbcr_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 7),
+.vsd_cbcr_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 6),
+.vsd_yrgb_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 5),
+.vsd_yrgb_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 4),
+.bic_coe_sel = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 2),
+.cbcr_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 1),
+.yrgb_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 0),
+.lb_mode = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 5),
+};
+
+static const struct vop_scl_regs rk3229_win_full_scl = {
+.ext = _win_full_scl_ext,
+.scale_yrgb_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
+.scale_yrgb_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 16),
+.scale_cbcr_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
+.scale_cbcr_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 16),
+};
+
+static const struct vop_win_phy rk3229_win01_data = {
+.scl = _win_full_scl,
+.data_formats = formats_win_full,
+.nformats = ARRAY_SIZE(formats_win_full),
+.enable = VOP_REG(RK3229_WIN0_CTRL0, 0x1, 0),
+.format = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 1),
+.rb_swap = VOP_REG(RK3229_WIN0_CTRL0, 0x1, 12),
+.act_info = VOP_REG(RK3229_WIN0_ACT_INFO, 0x1fff1fff, 0),
+.dsp_info = VOP_REG(RK3229_WIN0_DSP_INFO, 0x0fff0fff, 0),
+.dsp_st = VOP_REG(RK3229_WIN0_DSP_ST, 0x1fff1fff, 0),
+.yrgb_mst = VOP_REG(RK3229_WIN0_YRGB_MST, 0x, 0),
+.uv_mst = VOP_REG(RK3229_WIN0_CBR_MST, 0x, 0),
+.yrgb_vir = VOP_REG(RK3229_WIN0_VIR, 0x3fff, 0),
+.uv_vir = VOP_REG(RK3229_WIN0_VIR, 0x3fff, 16),
+.src_alpha_ctl = VOP_REG(RK3229_WIN0_SRC_ALPHA_CTRL, 0xff, 0),
+.dst_alpha_ctl = VOP_REG(RK3229_WIN0_DST_ALPHA_CTRL, 0xff, 0),
+};
+
+static const struct vop_win_data rk3229_vop_win_data[] = {
+{ .base = 0x00, .phy = _win01_data,
+  .type = DRM_PLANE_TYPE_PRIMARY },
+{ .base = 0x40, .phy = _win01_data,
+  .type = DRM_PLANE_TYPE_CURSOR },
+};
+
+static const struct vop_ctrl rk3229_ctrl_data = {
+.cfg_done = VOP_REG(RK3229_REG_CFG_DONE, 0x1, 0),
+.standby = VOP_REG(RK3229_SYS_CTRL, 0x1, 22),
+.gate_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 23),
+.mmu_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 20),
+.rgb_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 12),
+.hdmi_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 13),
+.edp_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 14),
+.mipi_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 15),
+.data_blank = VOP_REG(RK3229_DSP_CTRL0, 0x1, 19),
+.out_mode = VOP_REG(RK3229_DSP_CTRL0, 0xf, 0),
+.pin_pol = VOP_REG(RK3229_DSP_CTRL1, 0xf, 20),
+.dither_up = VOP_REG(RK3229_DSP_CTRL1, 0x1, 6),
+.htotal_pw = VOP_REG(RK3229_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
+.hact_st_end = VOP_REG(RK3229_DSP_HACT_ST_END, 0x1fff1fff, 0),
+.vtotal_pw = VOP_REG(RK3229_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
+.vact_st_end = VOP_REG(RK3229_DSP_VACT_ST_END, 0x1fff1fff, 0),
+.hpost_st_end = VOP_REG(RK3229_POST_DSP_HACT_INFO, 0x1fff1fff, 0),
+.vpost_st_end = VOP_REG(RK3229_POST_DSP_VACT_INFO, 0x1fff1fff, 0),
+};


Hi Yakir

RK3229 registers layout is simalar 

[PATCH] arm64: dts: qcom: apq8016-sbc: leds: bt and wlan

[Vinay Simha BN]

BT LED   - PMIC - MPP_03
WLAN LED - PMIC - MPP_02

Signed-off-by: Vinay Simha BN 
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 7bb0ab8..37ca0c8 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -94,14 +94,14 @@
led@5 {
label = "apq8016-sbc:yellow:wifi";
gpios = <_mpps 2 GPIO_ACTIVE_HIGH>;
-   linux,default-trigger = "wlan";
+   linux,default-trigger = "rfkill0";
default-state = "off";
};
 
led@6 {
label = "apq8016-sbc:blue:bt";
gpios = <_mpps 3 GPIO_ACTIVE_HIGH>;
-   linux,default-trigger = "bt";
+   linux,default-trigger = "rfkill1";
default-state = "off";
};
};
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 2/5] Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver

[Chris Zhong]

add device tree bindings for rk3288 specific Synopsys DW MIPI DSI driver

Signed-off-by: Chris Zhong 
Acked-by: Rob Herring 

---

Changes in v7: None
Changes in v6:
- update the document, since the bridge device has been deleted.

Changes in v5: None
Changes in v4: None
Changes in v3:
- move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/

 .../display/rockchip/dw_mipi_dsi_rockchip.txt  | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
new file mode 100644
index 000..1753f0c
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -0,0 +1,60 @@
+Rockchip specific extensions to the Synopsys Designware MIPI DSI
+
+
+Required properties:
+- #address-cells: Should be <1>.
+- #size-cells: Should be <0>.
+- compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi".
+- reg: Represent the physical address range of the controller.
+- interrupts: Represent the controller's interrupt to the CPU(s).
+- clocks, clock-names: Phandles to the controller's pll reference
+  clock(ref) and APB clock(pclk), as described in [1].
+- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
+- ports: contain a port node with endpoint definitions as defined in [2].
+  For vopb,set the reg = <0> and set the reg = <1> for vopl.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   mipi_dsi: mipi@ff96 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0xff96 0x4000>;
+   interrupts = ;
+   clocks = < SCLK_MIPI_24M>, < PCLK_MIPI_DSI0>;
+   clock-names = "ref", "pclk";
+   rockchip,grf = <>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mipi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mipi_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_mipi>;
+   };
+   mipi_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_mipi>;
+   };
+   };
+   };
+
+   panel {
+   compatible ="boe,tv080wum-nl0";
+   reg = <0>;
+
+   enable-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_en>;
+   backlight = <>;
+   status = "okay";
+   };
+   };
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 0/5] Add mipi dsi support for rk3288

[Chris Zhong]

The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
IP. This series adds support for a Synopsys DesignWare MIPI DSI host
controller DRM driver.

The MIPI DSI feature is tested on rk3288 evb board, backport them to
chrome os kernel chrome_v3.14, and it can display normally.

This patchset is base on the patchset from ying@freescale.com.


According to the suggestion from Thierry, I have get rid of the bridge,
and register the encoder & connecter in drm/rockchip/dw-mipi-dsi.c.

After backport below patches from linux-next, I can merge this serial into
Dave's drm-next branch.

94d5d6a0fbf3 clk: rockchip: add an id for rk3288 crypto clk
c6d49fbcfcc4 clk: rockchip: add id for mipidsi sclk on rk3288
a2f4c560f18e clk: rockchip: add mipidsi clock on rk3288
69c923743640 ARM: dts: rockchip: correct the name of REG8 for rk3288-evb-act8846
662513a14c9d ARM: dts: rockchip: add 2 regulators for rk3288-evb-act8846
b04061e6599b ARM: dts: rockchip: move the public part to rk3288-evb common


Changes in v7:
- modify the config to tristate for modules build (Mark Yao)
- Pass NULL 'name' to drm_encoder_init() to fix compile err (Mark Yao)
- Move the lcd_en control to act8846 dts

Changes in v6:
- update the document, since the bridge device has been deleted.
- move the mipi_en gate to ockchip_drm_crtc_mode_config
- Remove the atomic feature check (Mark Yao)
- Add atomic API support (Heiko Stübne)
- Do not use bridge driver (Thierry Reding)
- Optimization the phy init sequence

Changes in v5:
- modify the clk name to SCLK_MIPIDSI_24M
- add a blank line befor lcd_en

Changes in v4:
- use clk_round_rate to check the clock rate in vop_crtc_mode_fixup

Changes in v3:
- move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/

Chris Zhong (5):
  drm/rockchip: return a true clock rate to adjusted_mode
  Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
  drm: rockchip: Support Synopsys DW MIPI DSI
  ARM: dts: rockchip: add rk3288 mipi_dsi nodes
  ARM: dts: rockchip: add support mipi panel tv080wum-nl0

 .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   60 +
 arch/arm/boot/dts/rk3288-evb-act8846.dts   |2 +
 arch/arm/boot/dts/rk3288-evb.dtsi  |   12 +-
 arch/arm/boot/dts/rk3288.dtsi  |   39 +
 drivers/gpu/drm/rockchip/Kconfig   |   10 +
 drivers/gpu/drm/rockchip/Makefile  |1 +
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1196 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|8 +
 8 files changed, 1327 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
 create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c

-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 5/5] ARM: dts: rockchip: add support mipi panel tv080wum-nl0

[Chris Zhong]

This tv080wum-nl0 panel is a mipi panel, it can use in MIPI_TX socket
of rk3288 evb board.

Signed-off-by: Chris Zhong 

---

Changes in v7:
- Move the lcd_en control to act8846 dts

Changes in v6: None
Changes in v5:
- add a blank line befor lcd_en

Changes in v4: None
Changes in v3: None

 arch/arm/boot/dts/rk3288-evb-act8846.dts |  2 ++
 arch/arm/boot/dts/rk3288-evb.dtsi| 12 +++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts 
b/arch/arm/boot/dts/rk3288-evb-act8846.dts
index e662147..7d5475b 100644
--- a/arch/arm/boot/dts/rk3288-evb-act8846.dts
+++ b/arch/arm/boot/dts/rk3288-evb-act8846.dts
@@ -50,6 +50,8 @@
gpio = < 3 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_en>;
+   regulator-always-on;
+   regulator-boot-on;
regulator-name = "vcc_lcd";
vin-supply = <_io>;
};
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index 4faabdb..0c91858 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -47,7 +47,7 @@
reg = <0x0 0x8000>;
};
 
-   backlight {
+   backlight: backlight {
compatible = "pwm-backlight";
brightness-levels = <
  0   1   2   3   4   5   6   7
@@ -183,6 +183,16 @@
status = "okay";
 };
 
+_dsi {
+   status = "okay";
+   panel {
+   compatible ="boe,tv080wum-nl0";
+   reg = <0>;
+   backlight = <>;
+   status = "okay";
+   };
+};
+
  {
bus-width = <4>;
cap-mmc-highspeed;
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 4/5] ARM: dts: rockchip: add rk3288 mipi_dsi nodes

[Chris Zhong]

Add a mipi_dsi node, and also add mipi_dsi endpoints to vopb and vopl
output port nodes.

Signed-off-by: Chris Zhong 

---

Changes in v7: None
Changes in v6: None
Changes in v5:
- modify the clk name to SCLK_MIPIDSI_24M

Changes in v4: None
Changes in v3: None

 arch/arm/boot/dts/rk3288.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 04ea209..6b21a87 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -800,6 +800,10 @@
reg = <0>;
remote-endpoint = <_in_vopb>;
};
+   vopb_out_mipi: endpoint@2 {
+   reg = <2>;
+   remote-endpoint = <_in_vopb>;
+   };
};
};
 
@@ -833,6 +837,10 @@
reg = <0>;
remote-endpoint = <_in_vopl>;
};
+   vopl_out_mipi: endpoint@2 {
+   reg = <2>;
+   remote-endpoint = <_in_vopl>;
+   };
};
};
 
@@ -873,6 +881,37 @@
};
};
 
+   mipi_dsi: mipi@ff96 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0xff96 0x4000>;
+   interrupts = ;
+   clocks = < SCLK_MIPIDSI_24M>, < PCLK_MIPI_DSI0>;
+   clock-names = "ref", "pclk";
+   rockchip,grf = <>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mipi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mipi_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_mipi>;
+   };
+   mipi_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_mipi>;
+   };
+   };
+   };
+   };
+
gic: interrupt-controller@ffc01000 {
compatible = "arm,gic-400";
interrupt-controller;
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi,

Am 06.01.2016 um 00:40 schrieb Nishanth Menon :

> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>> tested on OMP5432 EVM
>> 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> arch/arm/boot/dts/omap5-board-common.dtsi | 8 
>> 1 file changed, 8 insertions(+)
>> 
>> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
>> b/arch/arm/boot/dts/omap5-board-common.dtsi
>> index 5cf76a1..30c0d3b 100644
>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>> @@ -358,6 +358,14 @@
>>  #clock-cells = <0>;
>>  };
>> 
>> +rtc {
>> +compatible = "ti,palmas-rtc";
>> +interrupt-parent = <>;
>> +interrupts = <8 IRQ_TYPE_NONE>;
> 
> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
> it had none, there'd be no interrupt, right?

Well, it just translates IRQ_TYPE_NONE through

Linux/include/dt-bindings/interrupt-controller/irq.h

to 

interrupts = <8 0>;

which is given as an example in

Documentation//devicetree/bindings/rtc/rtc-palmas.txt

Since I don't know anything about the rtc driver beyond the bindings 
documentation I assume it is correct...
I have added Laxman Dewangan because he introduced this interrupts = <8 0>;

> 
>> +ti,backup-battery-chargeable;
>> +ti,backup-battery-charge-high-current;
>> +};
>> +
>>  palmas_pmic {
>>  compatible = "ti,palmas-pmic";
>>  interrupt-parent = <>;
>> 
> 
> 
> -- 
> Regards,
> Nishanth Menon


BR,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/5] Documentation: devicetree: Add DT bindings to eeprom_93xx46 driver.

[Cory Tusar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/21/2015 07:01 PM, Vladimir Zapolskiy wrote:
> Hi Cory,
> 
> On 10.12.2015 06:00, Cory Tusar wrote:
>> This commit documents bindings to be added to the eeprom_93xx46 driver
>> which will allow:
>>
>>   - Device word size and read-only attributes to be specified.
>>   - A device-specific compatible string for use with Atmel AT93C46D
>> EEPROMs.
>>   - Specifying a GPIO line to function as a 'select' or 'enable' signal
>> prior to accessing the EEPROM.
>>
>> Signed-off-by: Cory Tusar 
>> Acked-by: Rob Herring 
>> Tested-by: Chris Healy 
>> ---
>>  .../devicetree/bindings/misc/eeprom-93xx46.txt | 25 
>> ++
>>  1 file changed, 25 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt 
>> b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
>> new file mode 100644
>> index 000..a8ebb46
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
>> @@ -0,0 +1,25 @@
>> +EEPROMs (SPI) compatible with Microchip Technology 93xx46 family.
>> +
>> +Required properties:
>> +- compatible : shall be one of:
>> +"atmel,at93c46d"
>> +"eeprom-93xx46"
> 
> the second compatible property value is not recommended by ePAPR, I would
> suggest to remove it from here and from the example below.

Hi Vladimir,

Yes, I know.  It's a "generic" binding, intended to allow any existing
users of this driver to move easily to DT with the exact same
configuration parameters exposed as the current platform device
implementation.

I took the at24 bindings (i.e. "at24c00") as an example.  I suppose I
could have stuck with just "93xx46" for the model, but instead used
"eeprom-93xx46" to match the name of the driver.

> But I see that Rob acked this change though...

Rob, does this still have your ACK as-is, given the above?

Thanks and best regards,
- -Cory


>> +- data-size : number of data bits per word (either 8 or 16)
>> +
>> +Optional properties:
>> +- read-only : parameter-less property which disables writes to the EEPROM
>> +- select-gpios : if present, specifies the GPIO that will be asserted prior 
>> to
>> +  each access to the EEPROM (e.g. for SPI bus multiplexing)
>> +
>> +Property rules described in 
>> Documentation/devicetree/bindings/spi/spi-bus.txt
>> +apply.  In particular, "reg" and "spi-max-frequency" properties must be 
>> given.
>> +
>> +Example:
>> +eeprom@0 {
>> +compatible = "eeprom-93xx46";
>> +reg = <0>;
>> +spi-max-frequency = <100>;
>> +spi-cs-high;
>> +data-size = <8>;
>> +select-gpios = < 4 GPIO_ACTIVE_HIGH>;
>> +};
>>
> 
> --
> With best wishes,
> Vladimir
> 


- -- 
Cory Tusar
Principal
PID 1 Solutions, Inc.


"There are two ways of constructing a software design.  One way is to
 make it so simple that there are obviously no deficiencies, and the
 other way is to make it so complicated that there are no obvious
 deficiencies."  --Sir Charles Anthony Richard Hoare

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlaMfhgACgkQHT1tsfGwHJ+QRwCffOZe1SiQnQPScyC2k8xU9px/
dt8An2X0c2K9TVaKo8euOIBNP/+8Y+z8
=4vbd
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/9] Support TI LMU devices

[Milo Kim]

Hi Lee,

On 11/26/2015 03:56 PM, Milo Kim wrote:

TI Lighting Management Unit drivers support lighting devices below.

  Enable pin  Backlight  HW fault monitoring  LEDs   Regulators
  --  -  ---    
LM3532   o   o   xx x
LM3631   o   o   xx5 regulators
LM3632   o   o   xx3 regulators
LM3633   o   o   oo x
LM3695   o   o   xx x
LM3697   o   o   ox x

This patch-set consists of several parts below.

   DT bindings: Binding information for each module
   LMU MFD: Device registration and HW enable pin control
   LMU fault monitor  : HW fault monitoring for open and short circuit
   LMU backlight  : Consolidated LMU backlight driver
   LM3633 LED : LED subsystem and dimming pattern generation
supported
   LM363X regulator   : LM3631 and LM3632 regulator driver for the
display bias

Updates from v1
---
   * DT bindings
 mfd   : Describe complete DT properties.
 backlight : Move backlight properties into leds/backlight/.
 Use common LED properties like 'led-sources' and 'label'.
 hwmon : LMU fault monitoring driver is not HWMON any more.
 So related properties are moved into 'ti-lmu' binding.
 leds  : Use LED common properties like 'led-sources' and 'label'.

   * MFD
 Remove LMU helpers for I2C register access. Each driver uses regmap
 helpers instead.

   * LMU fault monitoring driver
 In v1, it was HWMON driver but HWMON subsystem maintainer suggested
 moving it into MFD because it has no sensor data like temperature or
 voltage. Device attributes were replaced with debugfs files because
 monitoring should be processed for debug purpose only.

   * Backlight
 Six separate driver code was consolidated.
 Driver control code is implemented in 'ti-lmu-backlight-core.c'.
 Device specific data is defined in 'ti-lmu-backlight-data.c'.
 194 lines are saved in v2. The text segment is decreased by removing
 duplicate instructions.

 Lines of code:
   v1: 1420 (8 files)
   v2: 1226 (3 files)

 Size:
   v1:
   text  data  bss  filename
  12202   720   40  drivers/video/backlight/built-in.o
   v2:
   text  data  bss  filename
   6883   712   41  drivers/video/backlight/built-in.o

   * LED
 Use single device attribute for LED dimming operation.
 Max brightness is determined by DT property, 'led-max-microamp'.
 Remove brightness workqueue.

   * Regulator
 Use 'of_match' in regulator_desc instead of calling of_regulator_match.
 Remove unnecessary OF device ID because MFD core registers a platform
 device based on the compatible string.

Milo Kim (9):
   Documentation: dt-bindings: mfd: add TI LMU device binding information
   Documentation: dt-bindings: leds: backlight: add TI LMU backlight
 binding information
   Documentation: dt-bindings: leds: add LM3633 LED binding information
   Documentation: dt-bindings: regulator: add LM363x regulator binding
 information
   mfd: add TI LMU driver
   mfd: add TI LMU hardware fault monitoring driver
   backlight: add TI LMU backlight driver


For patch 5,6 and 7,
I'd like to get some feedback. Thanks!


   leds: add LM3633 driver
   regulator: add LM363X driver

  .../ABI/testing/debugfs-ti-lmu-fault-monitor   |  32 +
  Documentation/ABI/testing/sysfs-class-led-lm3633   |  97 +++
  .../bindings/leds/backlight/ti-lmu-backlight.txt   |  65 ++
  .../devicetree/bindings/leds/leds-lm3633.txt   |  24 +
  Documentation/devicetree/bindings/mfd/ti-lmu.txt   | 243 ++
  .../bindings/regulator/lm363x-regulator.txt|  34 +
  drivers/leds/Kconfig   |  10 +
  drivers/leds/Makefile  |   1 +
  drivers/leds/leds-lm3633.c | 840 +
  drivers/mfd/Kconfig|  22 +
  drivers/mfd/Makefile   |   3 +
  drivers/mfd/ti-lmu-fault-monitor.c | 405 ++
  drivers/mfd/ti-lmu.c   | 259 +++
  drivers/regulator/Kconfig  |   9 +
  drivers/regulator/Makefile |   1 +
  drivers/regulator/lm363x-regulator.c   | 309 
  drivers/video/backlight/Kconfig|   7 +
  drivers/video/backlight/Makefile   |   3 +
  drivers/video/backlight/ti-lmu-backlight-core.c| 649 
  drivers/video/backlight/ti-lmu-backlight-data.c| 287 +++
  include/linux/mfd/ti-lmu-backlight.h   | 290 +++
  

Re: [PATCH v11 0/8] Goodix touchscreen enhancements

[Dmitry Torokhov]

Hi Karsten,

On Tue, Jan 5, 2016 at 12:03 PM, Karsten Merker  wrote:
> On Thu, Dec 17, 2015 at 05:13:18PM -0800, Dmitry Torokhov wrote:
>> On Thu, Nov 19, 2015 at 02:26:33PM +0200, Irina Tirdea wrote:
>> > This patchset depends on Dmitry's patch that fixes the
>> > GPIO ACPI API[1], so devm_gpiod_get_optional can be properly
>> > used in the code.
>> >
>> > [1] https://lkml.org/lkml/2015/11/11/465
>>
>> Applied 1 through 5 (see my goodix branch), looking at the rest.
>
> Hello,
>
> as we are getting near to the next merge window, I wanted to
> kindly ask whether there is any news on this.  It would be really
> nice if the complete stack of goodix patches could go into kernel
> 4.5.

There is goodix branch at
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git that we
should be able to merge in 4.5. It has your patches and half of
Irina's (with config dump and ESD support missing at the moment). If
you could give ti a quick spin I'd appreciate it.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

[Peter Rosin]

Ouch, this got lost in the shuffle, don't bother testing without it.
It will be included in v3.

[the reason is that my test hw relies on vendor patches, and I have to
rebase before sending. I.e., I can only compile-test the stuff I'm
actually sending out. Inconvenient.]

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index c4d4b14a5399..c5a5886d8be1 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -215,10 +215,12 @@ int i2c_mux_reserve_adapters(struct i2c_mux_core *muxc, 
int adapters)
if (!adapter)
return -ENOMEM;
 
-   memcpy(adapter, muxc->adapter,
-  muxc->max_adapters * sizeof(*adapter));
+   if (muxc->adapter) {
+   memcpy(adapter, muxc->adapter,
+  muxc->max_adapters * sizeof(*adapter));
+   devm_kfree(muxc->dev, muxc->adapter);
+   }
 
-   devm_kfree(muxc->dev, muxc->adapter);
muxc->adapter = adapter;
muxc->max_adapters = adapters;
return 0;
-- 


On 2016-01-05 16:57, Peter Rosin wrote:
> From: Peter Rosin 
> 
> All muxes have slave side adapters, many have some arbitrary number of
> them. Handle this in the mux core, so that drivers are simplified.
> 
> Add i2c_mux_reserve_adapter that can be used when it is known in advance
> how many child adapters that is to be added. This avoids reallocating
> memory.
> 
> Drop i2c_del_mux_adapter and replace it with i2c_del_mux_adapters, since
> no mux driver is dynamically deleting individual child adapters anyway.
> 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/i2c/i2c-mux.c| 71 
> ++--
>  drivers/i2c/muxes/i2c-arb-gpio-challenge.c   | 10 ++--
>  drivers/i2c/muxes/i2c-mux-gpio.c | 23 +++--
>  drivers/i2c/muxes/i2c-mux-pca9541.c  | 13 ++---
>  drivers/i2c/muxes/i2c-mux-pca954x.c  | 26 --
>  drivers/i2c/muxes/i2c-mux-pinctrl.c  | 27 +++
>  drivers/i2c/muxes/i2c-mux-reg.c  | 28 ---
>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c   | 12 ++---
>  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h|  1 -
>  drivers/media/dvb-frontends/m88ds3103.c  | 11 ++---
>  drivers/media/dvb-frontends/m88ds3103_priv.h |  1 -
>  drivers/media/dvb-frontends/rtl2830.c| 10 ++--
>  drivers/media/dvb-frontends/rtl2830_priv.h   |  1 -
>  drivers/media/dvb-frontends/rtl2832.c| 11 ++---
>  drivers/media/dvb-frontends/rtl2832_priv.h   |  1 -
>  drivers/media/dvb-frontends/si2168.c | 10 ++--
>  drivers/media/dvb-frontends/si2168_priv.h|  1 -
>  drivers/media/usb/cx231xx/cx231xx-core.c |  3 +-
>  drivers/media/usb/cx231xx/cx231xx-i2c.c  | 26 +-
>  drivers/media/usb/cx231xx/cx231xx.h  |  2 +-
>  drivers/of/unittest.c| 28 ---
>  include/linux/i2c-mux.h  | 15 --
>  22 files changed, 149 insertions(+), 182 deletions(-)
> 
> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
> index 6c5cb9f7649b..7ba0308537a8 100644
> --- a/drivers/i2c/i2c-mux.c
> +++ b/drivers/i2c/i2c-mux.c
> @@ -99,6 +99,29 @@ static unsigned int i2c_mux_parent_classes(struct 
> i2c_adapter *parent)
>   return class;
>  }
>  
> +int i2c_mux_reserve_adapters(struct i2c_mux_core *muxc, int adapters)
> +{
> + struct i2c_adapter **adapter;
> +
> + if (adapters <= muxc->max_adapters)
> + return 0;
> +
> + adapter = devm_kmalloc_array(muxc->dev,
> +  adapters, sizeof(*adapter),
> +  GFP_KERNEL);
> + if (!adapter)
> + return -ENOMEM;
> +
> + memcpy(adapter, muxc->adapter,
> +muxc->max_adapters * sizeof(*adapter));
> +
> + devm_kfree(muxc->dev, muxc->adapter);
> + muxc->adapter = adapter;
> + muxc->max_adapters = adapters;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(i2c_mux_reserve_adapters);
> +
>  struct i2c_mux_core *i2c_mux_alloc(struct device *dev, int sizeof_priv)
>  {
>   struct i2c_mux_core *muxc;
> @@ -113,19 +136,29 @@ struct i2c_mux_core *i2c_mux_alloc(struct device *dev, 
> int sizeof_priv)
>  }
>  EXPORT_SYMBOL_GPL(i2c_mux_alloc);
>  
> -struct i2c_adapter *i2c_add_mux_adapter(struct i2c_mux_core *muxc,
> - struct device *mux_dev,
> - u32 force_nr, u32 chan_id,
> - unsigned int class)
> +int i2c_add_mux_adapter(struct i2c_mux_core *muxc,
> + struct device *mux_dev,
> + u32 force_nr, u32 chan_id,
> + unsigned int class)
>  {
>   struct i2c_adapter *parent = muxc->parent;
>   struct i2c_mux_priv *priv;
>   char symlink_name[20];
>   int ret;
>  
> + if (muxc->adapters >= muxc->max_adapters) {
> + int new_max = 2 * muxc->max_adapters;
> +
> + if (!new_max)
> +   

Re: [PATCH 3/3] arm: dts: bcm5301x: Add syscon based reboot in DT

[Jon Mason]

On Fri, Dec 18, 2015 at 10:44:28PM +0100, Arnd Bergmann wrote:
> On Friday 18 December 2015 16:37:56 Jon Mason wrote:
> > +   cru: cru@1800c184 {
> > +   compatible = "syscon";
> > +   reg = <0x1800c184 0xc>;
> > +   };
> 
> It's unusual for a device to start at such an odd address. Are you sure
> it's not a larger device starting at 0x1800c000 or 0x1800?

The CRU (Clock and Reset Unit) starts at 0x1800c100, with the
following layout:

CRU Clock Management at 0x1800c100-0x1800c180
CRU Reset at 0x1800c184
CRU Period Sample Clock at 0x1800c188
CRU Interrupt register at 0x1800c18c
CRU MDIO Control at 0x1800c190
CRU GPIO at 0x1800c1c0-0x1800c1e0
CRU SDIO 0x1800c200-0x1800c214
CRU RoboSW Interrupt at 0x1800c280
CRU Straps Control at 0x1800c2a0

The clock driver is already referencing the registers between
0x1800c100-0x1800c180, and the GPIO driver is referencing registers
between 0x1800c1c0-0x1800c1e0.

The reset part of the syscon seems to be the only useful thing in this
block.  Am I approaching this incorrectly?


> Also, please provide a more specific compatible string based on the
> name of the device in the data sheet. The node name in contrast should
> be more generic, e.g.
> 
>   cru: system-controller@1800c000 {
>   compatible = "brcm,bcm53010-cru", "syscon";

This is very similar between the NS and NSP (and NS2) platforms.  I'll
verify the layout and see if this can't be "brcm,iproc-cru" or
something similar.

Thanks,
Jon

>   reg = <0x1800c000 0x400>; /* whatever the data sheet says */
>   };
> 
> 
>   Arnd
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: export of_default_bus_match_table

[Masahiro Yamada]

Hi Arnd,

2016-01-05 19:13 GMT+09:00 Arnd Bergmann :
> On Tuesday 05 January 2016 11:17:53 Masahiro Yamada wrote:
>> Currently, drivers/bus/uniphier-system-bus.c is kept from being a
>> module due to the unresolved reference to of_default_bus_match_table.
>>
>> Refer to commit 326ea45aa827 ("bus: uniphier: allow only built-in
>> driver").
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  drivers/of/platform.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index af98343..8d103e4 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -31,6 +31,7 @@ const struct of_device_id of_default_bus_match_table[] = {
>>  #endif /* CONFIG_ARM_AMBA */
>> {} /* Empty terminated list */
>>  };
>> +EXPORT_SYMBOL(of_default_bus_match_table);
>
> I wonder if the uniphier bus should actually use the default
> match table at all. Sorry for not having thought of that when
> I did my patch.
>
> What kinds of devices do you see below this bus? Do you have multiple
> levels of devices? Are they all platform devices or could they
> be AMBA?


This bus is used to connect external (on-board) devices with the SoC.

So, no possibility for AMBA, but
I want "simple-bus" for grouping some device nodes.
Also, "simple-mfd" would be useful because an external device could be an MFD.


Please see arch/arm/boot/dts/uniphier-support-card.dtsi

It describes an add-on card (expansion board)
which has ETHER, UART, etc. on it.

I implemented it as "simple-bus".

This card is connected to the chip select 1
of the UniPhier System Bus.


-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: fuzzing dtc with AFL

[Anton Blanchard]

> I've now commited fixes (and test cases) for all of these to the
> master tree.

Thanks David! It's looking much better, but the fuzzer did trip on
another divide by zero, this time a modulo:

/dts-v1/;

/ {
x = <(0%0)>
};

Anton
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" 
in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: export of_default_bus_match_table

[Arnd Bergmann]

On Tuesday 05 January 2016 19:50:31 Masahiro Yamada wrote:
> 2016-01-05 19:13 GMT+09:00 Arnd Bergmann :
> > On Tuesday 05 January 2016 11:17:53 Masahiro Yamada wrote:
> 
> This bus is used to connect external (on-board) devices with the SoC.
> 
> So, no possibility for AMBA, but
> I want "simple-bus" for grouping some device nodes.
> Also, "simple-mfd" would be useful because an external device could be an MFD.
> 
> 
> Please see arch/arm/boot/dts/uniphier-support-card.dtsi
> 
> It describes an add-on card (expansion board)
> which has ETHER, UART, etc. on it.
> 
> I implemented it as "simple-bus".
> 
> This card is connected to the chip select 1
> of the UniPhier System Bus.
> 

Ok, got it. So you could alternatively define your own match table
in the driver with just "simple-bus" and  "simple-mfd". I think either
way is fine, let's see what the DT maintainers prefer.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/5 0:34, Arnd Bergmann 写道:

On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:

在 2016/1/4 19:13, Arnd Bergmann 写道:

On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:

在 2015/12/31 23:00, Rongrong Zou 写道:
*/
  compatible = "low-pin-count";
  device_type = "isa";
  #address-cells = <2>;
  #size-cells = <1>;
  reg = <0x0 0xa01b 0x0 0x1>;
  ranges = <0x1 0x0 0x0 0x0 0x1000>;
/*
*  ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 
0x00e4, 4>".
*
*/
  ipmi_0:ipmi@00e4{
  device_type = "ipmi";
  compatible = "ipmi-bt";
  reg = <0x1 0x00e4 0x4>;
};



This looks wrong: the property above says that the I/O port range is
translated to MMIO address 0x to 0x0001, which is not
true on your hardware. I think this needs to be changed in the code
so the ranges property is not required for I/O ports.


Ranges property can set empty, but this means 1:1 translation. the I/O
port range is translated to MMIO address 0x0001  to
0x0001 0004, it looks wrong else. I wonder if anyone get legacy
I/O port resource from dts.


As I said, nothing should really require the ranges property here, unless
you have a valid IORESOURCE_MEM translation. The code that requires
the ranges to be present is wrong.



I think the openfirmware(DT) do not support for those unmapped I/O ports, 
because I
must get resource by calling of_address_to_resource(), which have to call
pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
better idea for this now. Maybe liviu can give me some opinions.

/**
 * of_address_to_resource - Translate device tree address and return as resource
 *
 * Note that if your address is a PIO address, the conversion will fail if
 * the physical address can't be internally converted to an IO token with
 * pci_address_to_pio(), that is because it's either called to early or it
 * can't be matched to any host bridge IO space
 */
int of_address_to_resource(struct device_node *dev, int index,
   struct resource *r)


For ipmi driver, I can get I/O port resource by DMI rather than dts.


No, the ipmi driver uses the resource that belongs to the platform
device already, you can't rely on DMI data to be present there.


Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
openfirmware and a few other), I think we just use one of them, not all of them.
It depend on vendor's hardware solution actually.




Arnd

.



Thanks,

Rongrong

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] arm64: dts: qcom: apq8016-sbc: leds: bt and wlan

[Vinay Simha BN]

BT LED   - PMIC - MPP_03
WLAN LED - PMIC - MPP_02

Signed-off-by: Vinay Simha BN 
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 7bb0ab8..37ca0c8 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -94,14 +94,14 @@
led@5 {
label = "apq8016-sbc:yellow:wifi";
gpios = <_mpps 2 GPIO_ACTIVE_HIGH>;
-   linux,default-trigger = "wlan";
+   linux,default-trigger = "rfkill0";
default-state = "off";
};
 
led@6 {
label = "apq8016-sbc:blue:bt";
gpios = <_mpps 3 GPIO_ACTIVE_HIGH>;
-   linux,default-trigger = "bt";
+   linux,default-trigger = "rfkill1";
default-state = "off";
};
};
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap3: Include missing bandgap data for ti-soc-thermal driver

[Pali Rohár]

On Thursday 31 December 2015 09:38:45 Eduardo Valentin wrote:
> > +
> > +   bandgap {
> > +   reg = <0x48002524 0x4>;
> > +   compatible = "ti,omap36xx-bandgap";
> 
> Can you please already add on both cases
> 
> #thermal-sensor-cells = <0>;
> ?
> 
> This way we can already use them to define thermal zones. Of course,
> that alone won't add the thermal zones. A separated patch would be
> needed to add the thermal zone for OMAP3.

Are you going to add thermal zone defines? If yes, then it would make
sense to add that #thermal line together with thermal zone defines...

-- 
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] arm: devtree: Set system_rev from DT "/revision"

[Arnd Bergmann]

On Tuesday 05 January 2016 12:37:50 Pali Rohár wrote:
> On Monday 28 December 2015 23:27:17 Arnd Bergmann wrote:
> > On Monday 28 December 2015 13:01:22 Frank Rowand wrote:
> > > 
> > > Patch 2/5 copies the value from ATAG_REVISION into the fdt "/revision"
> > > property.
> > > 
> > > If the use of /revision is limited to being a location to hold an ATAG
> > > value to pass to the global variable system_rev, then it would make
> > > sense to just copy directly from the ATAG value into system_rev in the
> > > same board file where you are copying the ATAGs.
> > 
> > Agreed. That would be simpler, and avoid a situation where someone relies
> > on the /revision property in DT to be set from the atags compat code
> > (preventing an upgrade to a newer bootloader), or on the system_rev variable
> > to be the same across multiple boot loaders, in the absence of other
> > kernel code setting it.
> 
> So, set system_rev only for Nokia N900? At same place where is called
> save_atags()?
> 
> 

Yes.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] ARM: dts: twl6030: add gpadc

[H. Nikolaus Schaller]

tested on Pandaboard ES.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 55eb35f..98e444d 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -99,4 +99,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+   adc {
+   compatible = "ti,twl6030-gpadc";
+   interrupts = <3>;
+   #io-channel-cells = <1>;
+   };
 };
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] Enable twl603x-GPADC for some OMAP4/OMAP5 boards and Palmas-RTC for OMAP5

[H. Nikolaus Schaller]

This patch series adds DT nodes for:

twl6030-gpadc for omap4 based boards (Pandaboard ES)
twl6037-gpadc for omap5 based boards (OMAP5 EVM)
twl6037-rtc for omap5 based boards (OMAP5 EVM)


H. Nikolaus Schaller (3):
  ARM: dts: omap5-board-common: enable rtc and charging of backup
battery
  ARM: dts: omap5-board-common: enable iio gpadc for Palmas
  ARM: dts: twl6030: add gpadc

 arch/arm/boot/dts/omap5-board-common.dtsi | 18 ++
 arch/arm/boot/dts/twl6030.dtsi|  6 ++
 2 files changed, 24 insertions(+)

-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: socfpga: add cap-sd-highspeed for SD/MMC node

[dinguyen]

From: Dinh Nguyen 

Enable SD highspeed support for the SoCFPGA Arria10 devkit.

Signed-off-by: Dinh Nguyen 
---
 arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts 
b/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts
index dbbb751..8a7dfa4 100644
--- a/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts
+++ b/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts
@@ -21,6 +21,7 @@
  {
status = "okay";
num-slots = <1>;
+   cap-sd-highspeed;
broken-cd;
bus-width = <4>;
 };
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: socfpga: add the clk-phase property for sd/mmc clock

[dinguyen]

From: Dinh Nguyen 

The CIU clock for the SD/MMC should be the sdmmc_clk and not the
sdmmc_free_clk. Also, add the correct phase shift the sdmmc_clk.

Signed-off-by: Dinh Nguyen 
---
 arch/arm/boot/dts/socfpga_arria10.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi 
b/arch/arm/boot/dts/socfpga_arria10.dtsi
index cce9e50..89a3558 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -362,6 +362,7 @@
compatible = 
"altr,socfpga-a10-gate-clk";
clocks = <_free_clk>;
clk-gate = <0xC8 5>;
+   clk-phase = <0 135>;
};
 
qspi_clk: qspi_clk {
@@ -589,7 +590,7 @@
reg = <0xff808000 0x1000>;
interrupts = <0 98 IRQ_TYPE_LEVEL_HIGH>;
fifo-depth = <0x400>;
-   clocks = <_mp_clk>, <_free_clk>;
+   clocks = <_mp_clk>, <_clk>;
clock-names = "biu", "ciu";
status = "disabled";
};
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/5] Qualcomm PCIe driver and designware fixes

[Bjorn Helgaas]

On Fri, Dec 18, 2015 at 02:38:54PM +0200, Stanimir Varbanov wrote:
> Hi,
> 
> I'm sending v5 with following changes:
> - in 1/5 - replace wmb() call with PCIE_ATU_CR2 register read.
> - in 3/5 - addressed comments from Born Helgaas about usage of a
> standard PCI capabilities register names and rename link training
> function to the way that other Designware based drivers use.
> - in 5/5 - addressed a comment from Bjorn Andersson about regulator
> label duplication.
> 
> Comments are welcome!
> 
> The previous v4 of the patch set can be found at [1].
> 
> regards,
> Stan
> 
> [1] https://lkml.org/lkml/2015/12/3/370
> 
> Stanimir Varbanov (5):
>   PCI: designware: ensure ATU is enabled before IO/conf space accesses
>   DT: PCI: qcom: Document PCIe devicetree bindings
>   PCI: qcom: Add Qualcomm PCIe controller driver
>   ARM: dts: apq8064: add pcie devicetree node
>   ARM: dts: ifc6410: enable pcie dt node for this board
> 
>  .../devicetree/bindings/pci/qcom,pcie.txt  |  233 
>  MAINTAINERS|7 +
>  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   26 +
>  arch/arm/boot/dts/qcom-apq8064.dtsi|   36 ++
>  drivers/pci/host/Kconfig   |   10 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-designware.c |7 +
>  drivers/pci/host/pcie-qcom.c   |  617 
> 
>  8 files changed, 937 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt
>  create mode 100644 drivers/pci/host/pcie-qcom.c

Applied to pci/host-qcom for v4.5, with Pratyush's ack on the first patch.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] spi: atmel: add support for the internal chip-select of the spi controller

[Måns Rullgård]

Cyrille Pitchen  writes:

> This patch relies on the CSAAT (Chip Select Active After Transfer) feature
> introduced by the version 2 of the spi controller. This new mode allows to
> use properly the internal chip-select output pin of the spi controller
> instead of using external gpios. Consequently, the "cs-gpios" device-tree
> property becomes optional.
>
> When the new CSAAT bit is set into the Chip Select Register, the internal
> chip-select output pin remains asserted till both the following conditions
> become true:
> - the LASTXFER bit is set into the Control Register (or the Transmit Data
>   Register)
> - the Transmit Data Register and its shift register are empty.
>
> WARNING: if the LASTXFER bit is set into the Control Register then new
> data are written into the Transmit Data Register fast enough to keep its
> shifter not empty, the chip-select output pin remains asserted. Only when
> the shifter becomes empty, the chip-select output pin is unasserted.
>
> When the CSAAT bit is clear in the Chip Select Register, the LASTXFER bit
> is ignored in both the Control Register and the Transmit Data Register.
> The internal chip-select output pin remains active as long as the Transmit
> Data Register or its shift register are not empty.
>
> Signed-off-by: Cyrille Pitchen 
> ---
>  drivers/spi/spi-atmel.c | 37 -
>  1 file changed, 28 insertions(+), 9 deletions(-)

[...]

> @@ -1338,6 +1350,13 @@ static int atmel_spi_probe(struct platform_device 
> *pdev)
>
>   atmel_get_caps(as);
>
> + as->use_cs_gpios = true;
> + if (atmel_spi_is_v2(as) &&
> + !of_get_property(pdev->dev.of_node, "cs-gpios", NULL)) {
> + as->use_cs_gpios = false;
> + master->num_chipselect = 4;
> + }

This part breaks the AVR32 boards and probably anything else that
doesn't use devicetree but does use GPIOs for chip select.

-- 
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] Input: cyttsp - add default init function

[Oreste Salerno]

When using device trees, it's not possible to assign an init()
function in the platform data.
In case the init function has not been assigned, attempt to
perform a hard reset of the chip, using reset gpio defined in the
platform data / device tree.

Signed-off-by: Oreste Salerno 
---
 drivers/input/touchscreen/cyttsp_core.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/input/touchscreen/cyttsp_core.c 
b/drivers/input/touchscreen/cyttsp_core.c
index 8390236..9872333 100644
--- a/drivers/input/touchscreen/cyttsp_core.c
+++ b/drivers/input/touchscreen/cyttsp_core.c
@@ -238,6 +238,16 @@ static int cyttsp_set_sysinfo_regs(struct cyttsp *ts)
return retval;
 }
 
+static void cyttsp_hard_reset(struct cyttsp *ts)
+{
+   if (ts->pdata->reset_gpio) {
+   gpiod_set_value_cansleep(ts->pdata->reset_gpio, 1);
+   msleep(CY_DELAY_DFLT);
+   gpiod_set_value_cansleep(ts->pdata->reset_gpio, 0);
+   msleep(CY_DELAY_DFLT);
+   }
+}
+
 static int cyttsp_soft_reset(struct cyttsp *ts)
 {
unsigned long timeout;
@@ -659,6 +669,8 @@ struct cyttsp *cyttsp_probe(const struct cyttsp_bus_ops 
*bus_ops,
error);
goto err_free_mem;
}
+   } else {
+   cyttsp_hard_reset(ts);
}
 
input_dev->name = pdata->name;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/3] Add device tree support to the cyttsp driver

[Oreste Salerno]

This set of patches adds support to the cyttsp touchscreen driver
to retrieve platform data details from the device tree.
Additionally, they define a default init function that performs a hard
reset of the chip on boot.

---
Changes in v2:
  - Fix err_cast.cocci warning in patch 2/3

Oreste Salerno (3):
  Input: cyttsp - remove unused irq_gpio from platform_data
  Input: cyttsp - add device tree support
  Input: cyttsp - add default init function

 .../bindings/input/touchscreen/cyttsp.txt  |  73 +
 drivers/input/touchscreen/cyttsp_core.c| 120 +++--
 include/linux/input/cyttsp.h   |   4 +-
 3 files changed, 189 insertions(+), 8 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] Input: cyttsp - add device tree support

[Oreste Salerno]

Add support for retrieving the platform data from the device
tree.

Signed-off-by: Oreste Salerno 
---
 .../bindings/input/touchscreen/cyttsp.txt  |  73 ++
 drivers/input/touchscreen/cyttsp_core.c| 108 +++--
 include/linux/input/cyttsp.h   |   3 +
 3 files changed, 177 insertions(+), 7 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt

diff --git a/Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt 
b/Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt
new file mode 100644
index 000..8e0bcc73
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt
@@ -0,0 +1,73 @@
+* Cypress cyttsp touchscreen controller
+
+Required properties:
+- compatible   : must be "cypress,cyttsp-i2c" or "cypress,cyttsp-spi"
+- reg  : Device address
+- spi-max-frequency: Maximum SPI clocking speed of the device (for 
cyttsp-spi)
+- interrupt-parent : the phandle for the gpio controller
+ (see interrupt binding[0]).
+- interrupts   : (gpio) interrupt to which the chip is connected
+ (see interrupt binding[0]).
+- reset-gpios  : the reset gpio the chip is connected to
+ (see GPIO binding[1] for more details).
+- maxx : horizontal resolution of touchscreen (in pixels)
+- maxy : vertical resolution of touchscreen (in pixels)
+- bootloader-key   : the bootloader key used to exit bootloader mode
+
+Optional properties:
+- use_hndshk   : enable handshake bit
+- act_dist : active distance
+- act_intrvl   : active refresh interval in ms
+- tch_tmout: active touch timeout in ms
+- lp_intrvl: low power refresh interval in ms
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[1]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+{
+   /* ... */
+   cyttsp@a {
+   compatible = "cypress,cyttsp-i2c";
+   reg = <0xa>;
+   interrupt-parent = <_gpio>;
+   interrupts = <13 0x2008>;
+   reset-gpios = <_gpio 12 0x00>;
+
+   maxx = <800>;
+   maxy = <480>;
+   bootloader-key = /bits/ 8 <0x01 0x02 0x03 0x04 0x05 
0x06 0x07 0x08>;
+
+   use_hndshk;
+   act_dist = /bits/ 8 <0xF8>;
+   act_intrvl = /bits/ 8 <0x00>;
+   tch_tmout = /bits/ 8 <0xFF>;
+   lp_intrvl = /bits/ 8 <0x0A>;
+   };
+
+   /* ... */
+   };
+
+{
+   /* ... */
+   cyttsp@0 {
+   compatible = "cypress,cyttsp-spi";
+   spi-max-frequency = <600>;
+   reg = <0>;
+   interrupt-parent = <_gpio>;
+   interrupts = <13 0x2008>;
+   reset-gpios = <_gpio 12 0x00>;
+
+   maxx = <800>;
+   maxy = <480>;
+   bootloader-key = /bits/ 8 <0x01 0x02 0x03 0x04 0x05 
0x06 0x07 0x08>;
+
+   use_hndshk;
+   act_dist = /bits/ 8 <0xF8>;
+   act_intrvl = /bits/ 8 <0x00>;
+   tch_tmout = /bits/ 8 <0xFF>;
+   lp_intrvl = /bits/ 8 <0x0A>;
+   };
+
+   /* ... */
+   };
diff --git a/drivers/input/touchscreen/cyttsp_core.c 
b/drivers/input/touchscreen/cyttsp_core.c
index 5b74e8b..8390236 100644
--- a/drivers/input/touchscreen/cyttsp_core.c
+++ b/drivers/input/touchscreen/cyttsp_core.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "cyttsp_core.h"
 
@@ -528,18 +530,111 @@ static void cyttsp_close(struct input_dev *dev)
cyttsp_disable(ts);
 }
 
+#ifdef CONFIG_OF
+static const struct cyttsp_platform_data *cyttsp_parse_dt(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct cyttsp_platform_data *pdata;
+   u8 dt_value;
+   int ret;
+   static const char err_msg[] =
+   "property not provided in the device tree";
+
+   if (!np)
+   return ERR_PTR(-ENOENT);
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return ERR_PTR(-ENOMEM);
+
+   pdata->bl_keys = devm_kzalloc(dev, CY_NUM_BL_KEYS, GFP_KERNEL);
+   if (!pdata->bl_keys)
+   return ERR_PTR(-ENOMEM);
+
+   /* Set some default values */
+   pdata->act_dist = CY_ACT_DIST_DFLT;
+   pdata->act_intrvl = CY_ACT_INTRVL_DFLT;
+   pdata->tch_tmout = CY_TCH_TMOUT_DFLT;
+   

[PATCH v2 1/3] Input: cyttsp - remove unused irq_gpio from platform_data

[Oreste Salerno]

This field is not being used and the irq is anyway passed
via the 'irq' parameter to cyttsp_probe.

Signed-off-by: Oreste Salerno 
---
 include/linux/input/cyttsp.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/input/cyttsp.h b/include/linux/input/cyttsp.h
index 5af7c66..d7c2520 100644
--- a/include/linux/input/cyttsp.h
+++ b/include/linux/input/cyttsp.h
@@ -51,7 +51,6 @@ struct cyttsp_platform_data {
int (*init)(void);
void (*exit)(void);
char *name;
-   s16 irq_gpio;
u8 *bl_keys;
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] iio:adc:at91_adc8xx: introduce new atmel adc driver

[Ludovic Desroches]

On Wed, Dec 23, 2015 at 05:21:25PM +, Jonathan Cameron wrote:
> 
> 
> On 23 December 2015 10:48:33 GMT+00:00, Ludovic Desroches 
>  wrote:
> >On Wed, Dec 23, 2015 at 11:27:00AM +0100, Ludovic Desroches wrote:
> >> On Tue, Dec 22, 2015 at 06:34:00PM +, Jonathan Cameron wrote:
> >> > On 21/12/15 09:24, Ludovic Desroches wrote:
> >> > > This driver supports the new version of the Atmel ADC device
> >introduced
> >> > > with the SAMA5D2 SoC family.
> >> > > 
> >
> >[...]
> >
> >> > > +static irqreturn_t at91_adc_interrupt(int irq, void *private)
> >> > > +{
> >> > > +  struct iio_dev *indio = private;
> >> > > +  struct at91_adc_state *st = iio_priv(indio);
> >> > > +  u32 status = at91_adc_readl(st, ADC_ISR);
> >> > > +
> >> > > +  status &= at91_adc_readl(st, ADC_IMR);
> >> > > +  if (status & 0xFFF) {
> >> > > +  st->last_value = at91_adc_readl(st, st->chan->address);
> >> > If this is a polled read - is there any reason to read this value
> >here
> >> > rather than outside the interrupt?
> >> 
> >> No it can be done outside the interrupt. I have taken some parts from
> >the
> >> previous driver but it was reading a register used by all the
> >channels
> >> when it has been designed. So yes there is probably no more reason to
> >> read it into the interrupt.
> >> 
> >
> >Thinking about it. Is it really useful to move reading outside the
> >interrupt?
> It avoids needing to know the channel in here, hence simplifying the code a 
> bit.

I am not sure it will simplify the code since the interrupt is cleared
when reading the conversion not the interrupt status register.

> >
> >By the way this is not a polled read.
> I meant that it is an individually requested conversion rather than a free 
> running
>  sampling system where the value read might change before it is read out.
> >
> >> > > +  st->done = true;
> >> > > +  wake_up_interruptible(>wq_data_available);
> >> > > +  }
> >> > > +
> >> > > +  return IRQ_HANDLED;
> >> > > +}
> >
> >Ludovic
> >--
> >To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> >the body of a message to majord...@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 net-next 2/3] net: macb: Add NPx macb config using USRIO_DISABLED cap

[Nicolas Ferre]

Le 05/01/2016 13:20, Neil Armstrong a écrit :
> On 01/04/2016 11:38 AM, Nicolas Ferre wrote:
>> Le 04/01/2016 10:42, Neil Armstrong a écrit :
>>>  static const struct macb_config zynqmp_config = {
>>> .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO,
>>> @@ -2801,6 +2806,7 @@ static const struct of_device_id macb_dt_ids[] = {
>>> { .compatible = "cdns,at32ap7000-macb" },
>>> { .compatible = "cdns,at91sam9260-macb", .data = _config },
>>> { .compatible = "cdns,macb" },
>>> +   { .compatible = "cdns,npx-macb", .data = _config },
>>
>> I can accept that, but I think that you'd better make your device tree
>> compatibility string *not* generic. Name it by the first NPx SoC or
>> perfectly compatible SoC family that has this configuration and you'll
>> be able to make the NP(x+1) compatible with it.
> Well, the first Soc having this configuration is Np4, would cdns,np4-macb be 
> ok ?

Yes, absolutely.

Thanks

>> It has proven to be much more future proof and even if in the early days
>> of DT on ARM we accepted some binding with generic strings like this one
>> below, It has proven to be a mistake.
>>
>>> { .compatible = "cdns,gem", .data = _config },
>>> { .compatible = "atmel,sama5d2-gem", .data = _config },
>>>
>>
>>
> 
> Neil
> 


-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] drm/rockchip: vop: add rk3229 vop support

[Mark yao]

On 2016年01月05日 11:58, Yakir Yang wrote:

RK3229 registers layout is simalar to RK3288 layout, only the
interruput registers is different to RK3288.

RK3229 support two overlay plane and one hwc plane, max output
resolution is 4K. it support IOMMU, and its IOMMU same as rk3288's.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- Separate the write-mask changes out, and remove the DUMMY_INTR marcos (Heiko)

  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 110 
  drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  90 +++
  2 files changed, 200 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 7fbaf76..f1358f9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -191,6 +191,114 @@ static const struct vop_data rk3288_vop = {
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
  };
  
+static const struct vop_scl_extension rk3229_win_full_scl_ext = {

+   .cbcr_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 31),
+   .cbcr_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 30),
+   .cbcr_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 28),
+   .cbcr_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 26),
+   .cbcr_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 24),
+   .yrgb_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 23),
+   .yrgb_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 22),
+   .yrgb_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 20),
+   .yrgb_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 18),
+   .yrgb_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 16),
+   .line_load_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 15),
+   .cbcr_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0x7, 12),
+   .yrgb_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0xf, 8),
+   .vsd_cbcr_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 7),
+   .vsd_cbcr_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 6),
+   .vsd_yrgb_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 5),
+   .vsd_yrgb_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 4),
+   .bic_coe_sel = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 2),
+   .cbcr_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 1),
+   .yrgb_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 0),
+   .lb_mode = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 5),
+};
+
+static const struct vop_scl_regs rk3229_win_full_scl = {
+   .ext = _win_full_scl_ext,
+   .scale_yrgb_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
+   .scale_yrgb_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 16),
+   .scale_cbcr_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
+   .scale_cbcr_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 16),
+};
+
+static const struct vop_win_phy rk3229_win01_data = {
+   .scl = _win_full_scl,
+   .data_formats = formats_win_full,
+   .nformats = ARRAY_SIZE(formats_win_full),
+   .enable = VOP_REG(RK3229_WIN0_CTRL0, 0x1, 0),
+   .format = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 1),
+   .rb_swap = VOP_REG(RK3229_WIN0_CTRL0, 0x1, 12),
+   .act_info = VOP_REG(RK3229_WIN0_ACT_INFO, 0x1fff1fff, 0),
+   .dsp_info = VOP_REG(RK3229_WIN0_DSP_INFO, 0x0fff0fff, 0),
+   .dsp_st = VOP_REG(RK3229_WIN0_DSP_ST, 0x1fff1fff, 0),
+   .yrgb_mst = VOP_REG(RK3229_WIN0_YRGB_MST, 0x, 0),
+   .uv_mst = VOP_REG(RK3229_WIN0_CBR_MST, 0x, 0),
+   .yrgb_vir = VOP_REG(RK3229_WIN0_VIR, 0x3fff, 0),
+   .uv_vir = VOP_REG(RK3229_WIN0_VIR, 0x3fff, 16),
+   .src_alpha_ctl = VOP_REG(RK3229_WIN0_SRC_ALPHA_CTRL, 0xff, 0),
+   .dst_alpha_ctl = VOP_REG(RK3229_WIN0_DST_ALPHA_CTRL, 0xff, 0),
+};
+
+static const struct vop_win_data rk3229_vop_win_data[] = {
+   { .base = 0x00, .phy = _win01_data,
+ .type = DRM_PLANE_TYPE_PRIMARY },
+   { .base = 0x40, .phy = _win01_data,
+ .type = DRM_PLANE_TYPE_CURSOR },
+};
+
+static const struct vop_ctrl rk3229_ctrl_data = {
+   .cfg_done = VOP_REG(RK3229_REG_CFG_DONE, 0x1, 0),
+   .standby = VOP_REG(RK3229_SYS_CTRL, 0x1, 22),
+   .gate_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 23),
+   .mmu_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 20),
+   .rgb_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 12),
+   .hdmi_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 13),
+   .edp_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 14),
+   .mipi_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 15),
+   .data_blank = VOP_REG(RK3229_DSP_CTRL0, 0x1, 19),
+   .out_mode = VOP_REG(RK3229_DSP_CTRL0, 0xf, 0),
+   .pin_pol = VOP_REG(RK3229_DSP_CTRL1, 0xf, 20),
+   .dither_up = VOP_REG(RK3229_DSP_CTRL1, 0x1, 6),
+   .htotal_pw = VOP_REG(RK3229_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
+   .hact_st_end = VOP_REG(RK3229_DSP_HACT_ST_END, 0x1fff1fff, 0),
+   .vtotal_pw = VOP_REG(RK3229_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
+   .vact_st_end = VOP_REG(RK3229_DSP_VACT_ST_END, 0x1fff1fff, 0),
+   .hpost_st_end = VOP_REG(RK3229_POST_DSP_HACT_INFO, 

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* Nishanth Menon  [160105 15:40]:
> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
> > tested on OMP5432 EVM
> > 
> > Signed-off-by: H. Nikolaus Schaller 
> > ---
> >  arch/arm/boot/dts/omap5-board-common.dtsi | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
> > b/arch/arm/boot/dts/omap5-board-common.dtsi
> > index 5cf76a1..30c0d3b 100644
> > --- a/arch/arm/boot/dts/omap5-board-common.dtsi
> > +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
> > @@ -358,6 +358,14 @@
> > #clock-cells = <0>;
> > };
> >  
> > +   rtc {
> > +   compatible = "ti,palmas-rtc";
> > +   interrupt-parent = <>;
> > +   interrupts = <8 IRQ_TYPE_NONE>;
> 
> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
> it had none, there'd be no interrupt, right?

Also I'm not seeing just zeroes coming from RTC after typing hwclock
on omap5-uevm. It's working on x15 though.

Nikolaus, is hwclock command working for you on omap5-uevm?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6] pstore/ram: Add ramoops support for the Flattened Device Tree.

[Kees Cook]

[fixing devicetree mailing list]

On Tue, Jan 5, 2016 at 5:04 PM, Kees Cook  wrote:
> [thread necromancy, if you don't have the thread locally, it's here:
> https://patchwork.kernel.org/patch/1426261/]
>
> We still need to solve this, and John pinged me about it today. Where
> does this stand?
>
> -Kees
>
>
> On Sun, Apr 14, 2013 at 7:24 AM, Anton Vorontsov  wrote:
>> On Mon, Apr 08, 2013 at 12:54:01PM -0700, Bryan Freed wrote:
>> [...]
>>> And as a more general question, why should we try not to put
>>> configuration in the device tree?  It seems like a great (and
>>> portable) place to put this stuff.
>>> It certainly seems better to have it there than hardwired in the
>>> kernel or tacked onto the kernel command line.
>>
>> But then we have two in-kernel APIs to pass kernel parameters? So we'll
>> have to maintain two ways of passing the options for each driver. That is
>> hardly a good solution.
>>
>> If you would like to see a convenient way to pass kernel/module options
>> via the device tree, I would suggest implementing something like this:
>>
>> chosen {
>> kernel-options {
>> linux,pstore.record-size = 123;
>> linux,foo = "bar";
>> };
>> };
>>
>> And then let the kernel translate all these to module_param_*().
>>
>> I am still not sure about placing the options along with devices layout,
>> but if we go this route, then that is also viable:
>>
>> pstore-node {
>> linux,pstore.record-size = 123;
>> };
>>
>> And translate "linux,*" this to module_param_*().
>>
>> How does that sound?
>>
>> Thanks,
>> Anton
>
>
>
> --
> Kees Cook
> Chrome OS & Brillo Security



-- 
Kees Cook
Chrome OS & Brillo Security
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6] pstore/ram: Add ramoops support for the Flattened Device Tree.

[Rob Herring]

+Greg H

On Tue, Jan 5, 2016 at 7:06 PM, Kees Cook  wrote:
> [fixing devicetree mailing list]
>
> On Tue, Jan 5, 2016 at 5:04 PM, Kees Cook  wrote:
>> [thread necromancy, if you don't have the thread locally, it's here:
>> https://patchwork.kernel.org/patch/1426261/]
>>
>> We still need to solve this, and John pinged me about it today. Where
>> does this stand?

Wrong thread here as the latest version is "[PATCH v2] pstore-ram: add
Device Tree bindings" recently posted by Greg H (and reviewed by you).
I am mostly happy with it and only had a minor comment remaining. I
was expecting to see a v3.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] clk: arizona: Add clock driver for the Arizona devices

[Stephen Boyd]

On 01/05, Charles Keepax wrote:
> Add an initial clock driver for the Arizona series audio CODECs.
> Currently this driver only provides support for parsing the two input
> clocks (mclk1, mclk2) and providing the internally consumed 32k clock.
> 
> Signed-off-by: Charles Keepax 

Can this go through clk-tree without the other three patches and
nothing breaks?

> diff --git a/drivers/clk/clk-arizona.c b/drivers/clk/clk-arizona.c
> new file mode 100644
> index 000..1ab69ee
> --- /dev/null
> +++ b/drivers/clk/clk-arizona.c
> @@ -0,0 +1,192 @@
> +
> +static int arizona_32k_enable(struct clk_hw *hw)
> +{
> + struct arizona_clk *clkdata = clk32k_to_arizona_clk(hw);
> + struct arizona *arizona = clkdata->arizona;
> + int ret;
> +
> + switch (arizona->pdata.clk32k_src) {
> + case ARIZONA_32KZ_MCLK1:
> + ret = pm_runtime_get_sync(arizona->dev);
> + if (ret != 0)

typically we write this as

if (ret)


> + goto out;
> + break;
> + }
> +
> + ret = regmap_update_bits_async(arizona->regmap, ARIZONA_CLOCK_32K_1,
> +ARIZONA_CLK_32K_ENA,
> +ARIZONA_CLK_32K_ENA);
> +
> +out:
> + return ret;
> +}
> +
> +static int arizona_clk_of_get_pdata(struct arizona *arizona)
> +{
> + const char * const pins[] = { "mclk1", "mclk2" };
> + struct clk *mclk;
> + int i;
> +
> + if (!of_property_read_bool(arizona->dev->of_node, "clocks"))
> + return 0;
> +
> + for (i = 0; i < ARRAY_SIZE(pins); ++i) {
> + mclk = of_clk_get_by_name(arizona->dev->of_node, pins[i]);
> + if (IS_ERR(mclk))
> + return PTR_ERR(mclk);
> +
> + if (clk_get_rate(mclk) == CLK32K_RATE) {
> + arizona->pdata.clk32k_src = ARIZONA_32KZ_MCLK1 + i;
> + arizona->pdata.clk32k_parent = __clk_get_name(mclk);
> + }
> +
> + clk_put(mclk);

Is this configuring some mux for the 32kHz source? Perhaps this
can be done with assigned clock parents and a set_parent clk_op
instead of with of_clk_get_by_name() in a loop over the possible
parents?

> + }
> +
> + return 0;
> +}
> +
> +static int arizona_clk_probe(struct platform_device *pdev)
> +{
[..]
> +
> + if (arizona->pdata.clk32k_parent) {
> + clk32k_init.num_parents = 1;
> + clk32k_init.parent_names = >pdata.clk32k_parent;
> + } else {
> + clk32k_init.flags |= CLK_IS_ROOT;
> + }
> +
> + clkdata->clk32k_hw.init = _init;
> + clkdata->clk32k = devm_clk_register(>dev, >clk32k_hw);
> + if (IS_ERR(clkdata->clk32k)) {
> + ret = PTR_ERR(clkdata->clk32k);
> + dev_err(arizona->dev, "Failed to register 32k clock: %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = clk_register_clkdev(clkdata->clk32k, "arizona-32k",
> +   dev_name(arizona->dev));

Any reason we register with clkdev but don't register an of clk
provider?

> + if (ret) {
> + dev_err(arizona->dev, "Failed to register 32k clock dev: %d\n",
> + ret);
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, clkdata);
> +
> + return 0;
> +}

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver

[Timur Tabi]

Gilad Avidov wrote:


diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c 
b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
new file mode 100644
index 000..36a7746
--- /dev/null
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -0,0 +1,1808 @@
+/* Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/* Qualcomm Technologies, Inc. EMAC Ethernet Controller MAC layer support
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "emac.h"
+#include "emac-sgmii.h"


You also need

#include 

otherwise you get this:

  CC  drivers/net/ethernet/qualcomm/emac/emac-mac.o
drivers/net/ethernet/qualcomm/emac/emac-mac.c: In function 'emac_tso_csum':
drivers/net/ethernet/qualcomm/emac/emac-mac.c:2045:4: error: implicit 
declaration of function 'csum_ipv6_magic' 
[-Werror=implicit-function-declaration]

tcp_hdr(skb)->check = ~csum_ipv6_magic(
^
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] dt-bindings: add document for rk3229-vop

[Yakir Yang]

On 01/06/2016 12:06 AM, Rob Herring wrote:

On Mon, Jan 4, 2016 at 10:00 PM, Yakir Yang  wrote:

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
Changes in v2:
- acked by Rob

It doesn't hurt, but there is no point to send a new version just to
add acks. The maintainer should add any for the current version. If
you do send a new version with changes, then it is your responsibility
to add acks. Maintainers are not going to look at older versions.


Got it  :)

- Yakir


Rob






--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
> tested on OMP5432 EVM
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap5-board-common.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
> b/arch/arm/boot/dts/omap5-board-common.dtsi
> index 5cf76a1..30c0d3b 100644
> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
> @@ -358,6 +358,14 @@
>   #clock-cells = <0>;
>   };
>  
> + rtc {
> + compatible = "ti,palmas-rtc";
> + interrupt-parent = <>;
> + interrupts = <8 IRQ_TYPE_NONE>;

IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
it had none, there'd be no interrupt, right?

> + ti,backup-battery-chargeable;
> + ti,backup-battery-charge-high-current;
> + };
> +
>   palmas_pmic {
>   compatible = "ti,palmas-pmic";
>   interrupt-parent = <>;
> 


-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html