Re: [STLinux Kernel] [PATCH 3/3] ARM: dts: stih410: Enable USB2.0 and related PHY nodes at board level

[Patrice Chotard]

Hi Max

On 09/23/2015 09:37 PM, Maxime Coquelin wrote:

A borad might not expose the USB2.0 ports, so disable them by default in SoC


typo borad

Otherwise, for the series

Acked-by: Patrice Chotard 

Patrice



file, and enable them in b2120 board.

Signed-off-by: Maxime Coquelin 
---
  arch/arm/boot/dts/stih410-b2120.dts | 24 
  arch/arm/boot/dts/stih410.dtsi  | 12 
  2 files changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/stih410-b2120.dts 
b/arch/arm/boot/dts/stih410-b2120.dts
index 16f02c5..8af1e73 100644
--- a/arch/arm/boot/dts/stih410-b2120.dts
+++ b/arch/arm/boot/dts/stih410-b2120.dts
@@ -35,5 +35,29 @@
sd-uhs-sdr104;
sd-uhs-ddr50;
};
+
+   usb2_picophy1: phy2 {
+   status = "okay";
+   };
+
+   usb2_picophy2: phy3 {
+   status = "okay";
+   };
+
+   ohci0: usb@9a03c00 {
+   status = "okay";
+   };
+
+   ehci0: usb@9a03e00 {
+   status = "okay";
+   };
+
+   ohci1: usb@9a83c00 {
+   status = "okay";
+   };
+
+   ehci1: usb@9a83e00 {
+   status = "okay";
+   };
};
  };
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index 23f4a48..e3150e3 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -22,6 +22,8 @@
resets = <&softreset STIH407_PICOPHY_SOFTRESET>,
 <&picophyreset STIH407_PICOPHY0_RESET>;
reset-names = "global", "port";
+
+   status = "disabled";
};
  
  		usb2_picophy2: phy3 {

@@ -31,6 +33,8 @@
resets = <&softreset STIH407_PICOPHY_SOFTRESET>,
 <&picophyreset STIH407_PICOPHY1_RESET>;
reset-names = "global", "port";
+
+   status = "disabled";
};
  
  		ohci0: usb@9a03c00 {

@@ -43,6 +47,8 @@
reset-names = "power", "softreset";
phys = <&usb2_picophy1>;
phy-names = "usb";
+
+   status = "disabled";
};
  
  		ehci0: usb@9a03e00 {

@@ -57,6 +63,8 @@
reset-names = "power", "softreset";
phys = <&usb2_picophy1>;
phy-names = "usb";
+
+   status = "disabled";
};
  
  		ohci1: usb@9a83c00 {

@@ -69,6 +77,8 @@
reset-names = "power", "softreset";
phys = <&usb2_picophy2>;
phy-names = "usb";
+
+   status = "disabled";
};
  
  		ehci1: usb@9a83e00 {

@@ -83,6 +93,8 @@
reset-names = "power", "softreset";
phys = <&usb2_picophy2>;
phy-names = "usb";
+
+   status = "disabled";
};
  
  		sti-display-subsystem {


--
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 1/5] soc: sunxi: Add Allwinner Reduced Serial Bus (RSB) controller bindings

[Maxime Ripard]

On Thu, Sep 24, 2015 at 12:05:17AM +0800, Chen-Yu Tsai wrote:
> Reduced Serial Bus is a proprietary 2-line push-pull serial bus supporting
> multiple slave devices. It was developed by Allwinner, Inc. and used by
> Allwinner and X-Powers, Inc. for their line of PMICs and other peripheral
> ICs.
> 
> Recent Allwinner SoCs, starting with the A23, have an RSB controller. This
> is used to talk to the PMIC, and later with the A80 and A83 platform, the
> audio codec IC.
> 
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH v2 3/3] gpiolib: Add GPIO initialization

[Markus Pargmann]

Hi,

On Mon, Sep 21, 2015 at 04:42:09PM -0700, Linus Walleij wrote:
> On Sun, Aug 30, 2015 at 12:44 AM, Markus Pargmann  wrote:
> 
> > This functions adds a way to initialize a GPIO without hogging it.
> >
> > Signed-off-by: Markus Pargmann 
> 
> (...)
> 
> > -The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
> > -providing automatic GPIO request and configuration as part of the
> > -gpio-controller's driver probe function.
> > +The GPIO chip may contain GPIO definitions. These define properties for 
> > single
> > +GPIOs of this controller.
> 
> Insert text like this:
> 
> There are two types of GPIO definitions:
> 
> - GPIO hogs are ...
> 
> - GPIO initializers are ...
> 
> This list form is easier to understand.
> 
> > -Each GPIO hog definition is represented as a child node of the GPIO 
> > controller.
> > +GPIO hogging is a mechanism providing automatic GPIO request and 
> > configuration
> > +as part of the gpio-controller's driver probe function.
> > +
> > +GPIO initialization provides an automatic initialization to known save 
> > values.
> > +Instead of GPIO hogging the GPIO's value and direction can be modified by 
> > other
> > +users after it was initialized.
> > +
> > +Each GPIO definition is represented as a child node of the GPIO controller.
> >  Required properties:
> > -- gpio-hog:   A property specifying that this child node represent a GPIO 
> > hog.
> >  - gpios:  Store the GPIO information (id, flags, ...). Shall contain 
> > the
> >   number of cells specified in its parent node (GPIO controller
> >   node).
> > -Only one of the following properties scanned in the order shown below.
> > -This means that when multiple properties are present they will be searched
> > -in the order presented below and the first match is taken as the intended
> > -configuration.
> > +
> > +Optional properties:
> > +- line-name:  The GPIO label name. If not present the node name is used.
> > + Only one of gpio-hog and gpio-initval may be specified.
> 
> This is confusing. Instead write: "The two following options are
> mutually exclusive. One of them must be specified, but not both."
> 
> > +- gpio-hog:   A property specifying that this child node represent a GPIO 
> > hog.
> > +- gpio-initval: This GPIO should be initialized to the specified 
> > configuration.
> 
> > + Only one of input, output-low and output-high may be specified:
> 
> Insert "Of the following arguments, only one..." (etc)

Okay, thanks. Will change these.

> 
> >  - input:  A property specifying to set the GPIO direction as input.
> >  - output-low  A property specifying to set the GPIO direction as output 
> > with
> >   the value low.
> >  - output-high A property specifying to set the GPIO direction as output 
> > with
> >   the value high.
> >
> > -Optional properties:
> > -- line-name:  The GPIO label name. If not present the node name is used.
> > -
> >  Example of two SOC GPIO banks defined as gpio-controller nodes:
> 
> (...)
> > --- a/drivers/gpio/gpiolib-of.c
> > +++ b/drivers/gpio/gpiolib-of.c
> > @@ -234,6 +234,15 @@ static void of_gpiochip_scan_gpios(struct gpio_chip 
> > *chip)
> >
> > if (gpiod_hog(desc, lflags, dflags))
> > continue;
> > +   } else if (of_property_read_bool(np, "gpio-initval")) {
> > +   if (!dflags) {
> > +   dev_warn(chip->dev, "GPIO line %d (%s): no 
> > initialization state specified, bailing out\n",
> > +desc_to_gpio(desc), np->name);
> > +   continue;
> > +   }
> > +
> > +   if (gpiod_initialize(desc, lflags, dflags))
> > +   continue;
> 
> We usually do not mix implementations and bindings but it's OK with me.
> 
> > }
> 
> You need a terminating  else {} - clause to warn if neither of gpio-hog
> or gpio-initval is specified.

The idea was to have three cases:

1) Just give the gpio a name (desc->name). No hogging or initialization.
2) gpio-hog to initialize and acquire the GPIO for the whole time the
gpiochip is present.
2) gpio-initval to initialize the GPIO to a given value (as gpio-hog
does) but releasing the GPIO afterwards.

> 
> > -int gpiod_hog(struct gpio_desc *desc, unsigned long lflags,
> > - enum gpiod_flags dflags)
> > +static int _gpiod_initialize(struct gpio_desc *desc, unsigned long lflags,
> > + enum gpiod_flags dflags)
> 
> I don't like _underscore functions. Try to find a name that is descriptive
> and does not begin with underscore.
> 
> What about just gpiod_init()?

Okay, will change.

> 
> > if (status < 0) {
> > pr_err("setup of hog GPIO %s (chip %s, offset %d) failed\n",
> > -  name, gpiod_to_chip(desc)->label, 
> > gpio_chip_hwgpio(desc));
> > +

Re: [PATCH v2 2/3] gpiolib: gpiod_hog remove separate name argument

[Markus Pargmann]

Hi,

On Mon, Sep 21, 2015 at 04:28:48PM -0700, Linus Walleij wrote:
> On Sun, Aug 30, 2015 at 12:44 AM, Markus Pargmann  wrote:
> 
> > The gpio name is now stored in the gpio descriptor, so we can simply use
> > that instead of an argument to the function.
> >
> > Signed-off-by: Markus Pargmann 
> 
> Several problems with this patch:
> 
> - Does not apply to v4.3-rc1

Yes, a bit older already, will rebase it.

> - Fixed that but noted that it just alters the call to gpiod_hog()
>   in of_gpiochip_scan_hogs(), there is a local const char *name that
>   should be removed too.

The local const char *name is temporarily used in
of_gpiochip_scan_hogs() to get the name from DT and assign it to the
descriptor:
desc = of_parse_own_gpio(np, &name, &lflags, &dflags);
...
else
desc->name = name;

> - Looking at of_get_gpio_hog() it is unclear to me that .name
>   is set in the gpio_desc as desired. Please check this.
> 
>   Crucial code looks like this:
> 
> if (name && of_property_read_string(np, "line-name", name))
> *name = np->name;

of_get_gpio_hog() only parses the properties of the DT. It does not
assign any properties to the descriptor itself. So I kept it this way
and added the code for assignment to of_gpiochip_scan_gpios.

> 
>   i.e. is the line-name really propagated to gpiod->name?
>   Are you sure you have tested this with a DTS using line-name
>   and verified that it propagates properly?

Yes this is tested and works for me. I am using the two series together
without problems.

Best Regards,

Markus

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


signature.asc
Description: Digital signature

Re: [PATCH V2 1/2] clk: imx6: Add SPDIF_GCLK clock in clock tree

[Shengjiu Wang]

On Wed, Sep 23, 2015 at 08:33:41AM -0700, Shawn Guo wrote:
> On Tue, Sep 15, 2015 at 06:01:01PM +0800, Shengjiu Wang wrote:
> > As spdif driver will register SPDIF clock to regmap, regmap will do
> > clk_prepare in init function, so SPDIF clock is prepared in probe, then its
> > root clock (pll clock) is prepared also, which cause the arm can't enter
> > low power mode.
> 
> Can you help me understand why ARM cannot enter low power mode when pll
> clock is prepared?
> 
> Shawn
Hi Shawn

   In i.mx clock framework, when pll clk is prepared, it will be powerup. when
enterring low power idle mode, the powerdown bit is checked, when pll is not
powerdown state, chip will not enter low power idle mode.

best regards
wang shengjiu
> 
> > Add SPDIF_GCLK in clock tree which share same gate bits with SPDIF clock.
> > Its root clock is ipg clock, and register it to regmap, then the issue cam
> > be fixed.
> > 
> > Signed-off-by: Shengjiu Wang 
> > ---
> >  drivers/clk/imx/clk-imx6q.c   | 4 +++-
> >  drivers/clk/imx/clk-imx6sl.c  | 4 +++-
> >  drivers/clk/imx/clk-imx6sx.c  | 1 +
> >  include/dt-bindings/clock/imx6qdl-clock.h | 3 ++-
> >  include/dt-bindings/clock/imx6sl-clock.h  | 3 ++-
> >  include/dt-bindings/clock/imx6sx-clock.h  | 3 ++-
> >  6 files changed, 13 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
> > index b2c1c04..e6b5944 100644
> > --- a/drivers/clk/imx/clk-imx6q.c
> > +++ b/drivers/clk/imx/clk-imx6q.c
> > @@ -119,6 +119,7 @@ static unsigned int share_count_ssi1;
> >  static unsigned int share_count_ssi2;
> >  static unsigned int share_count_ssi3;
> >  static unsigned int share_count_mipi_core_cfg;
> > +static unsigned int share_count_spdif;
> >  
> >  static inline int clk_on_imx6q(void)
> >  {
> > @@ -456,7 +457,8 @@ static void __init imx6q_clocks_init(struct device_node 
> > *ccm_node)
> > clk[IMX6QDL_CLK_SATA] = imx_clk_gate2("sata",  "ahb",   
> > base + 0x7c, 4);
> > clk[IMX6QDL_CLK_SDMA] = imx_clk_gate2("sdma",  "ahb",   
> > base + 0x7c, 6);
> > clk[IMX6QDL_CLK_SPBA] = imx_clk_gate2("spba",  "ipg",   
> > base + 0x7c, 12);
> > -   clk[IMX6QDL_CLK_SPDIF]= imx_clk_gate2("spdif", 
> > "spdif_podf",base + 0x7c, 14);
> > +   clk[IMX6QDL_CLK_SPDIF]= imx_clk_gate2_shared("spdif", 
> > "spdif_podf", base + 0x7c, 14, &share_count_spdif);
> > +   clk[IMX6QDL_CLK_SPDIF_GCLK]   = imx_clk_gate2_shared("spdif_gclk", 
> > "ipg",   base + 0x7c, 14, &share_count_spdif);
> > clk[IMX6QDL_CLK_SSI1_IPG] = imx_clk_gate2_shared("ssi1_ipg",  
> > "ipg",base + 0x7c, 18, &share_count_ssi1);
> > clk[IMX6QDL_CLK_SSI2_IPG] = imx_clk_gate2_shared("ssi2_ipg",  
> > "ipg",base + 0x7c, 20, &share_count_ssi2);
> > clk[IMX6QDL_CLK_SSI3_IPG] = imx_clk_gate2_shared("ssi3_ipg",  
> > "ipg",base + 0x7c, 22, &share_count_ssi3);
> > diff --git a/drivers/clk/imx/clk-imx6sl.c b/drivers/clk/imx/clk-imx6sl.c
> > index a0d4cf2..a73cedd 100644
> > --- a/drivers/clk/imx/clk-imx6sl.c
> > +++ b/drivers/clk/imx/clk-imx6sl.c
> > @@ -97,6 +97,7 @@ static struct clk_div_table video_div_table[] = {
> >  static unsigned int share_count_ssi1;
> >  static unsigned int share_count_ssi2;
> >  static unsigned int share_count_ssi3;
> > +static unsigned int share_count_spdif;
> >  
> >  static struct clk *clks[IMX6SL_CLK_END];
> >  static struct clk_onecell_data clk_data;
> > @@ -391,7 +392,8 @@ static void __init imx6sl_clocks_init(struct 
> > device_node *ccm_node)
> > clks[IMX6SL_CLK_PWM4] = imx_clk_gate2("pwm4", "perclk", 
> >base + 0x78, 22);
> > clks[IMX6SL_CLK_SDMA] = imx_clk_gate2("sdma", "ipg",
> >base + 0x7c, 6);
> > clks[IMX6SL_CLK_SPBA] = imx_clk_gate2("spba", "ipg",
> >base + 0x7c, 12);
> > -   clks[IMX6SL_CLK_SPDIF]= imx_clk_gate2("spdif",
> > "spdif0_podf",   base + 0x7c, 14);
> > +   clks[IMX6SL_CLK_SPDIF]= imx_clk_gate2_shared("spdif", 
> > "spdif0_podf",   base + 0x7c, 14, &share_count_spdif);
> > +   clks[IMX6SL_CLK_SPDIF_GCLK]   = imx_clk_gate2_shared("spdif_gclk",  
> > "ipg", base + 0x7c, 14, &share_count_spdif);
> > clks[IMX6SL_CLK_SSI1_IPG] = imx_clk_gate2_shared("ssi1_ipg", 
> > "ipg",base + 0x7c, 18, &share_count_ssi1);
> > clks[IMX6SL_CLK_SSI2_IPG] = imx_clk_gate2_shared("ssi2_ipg", 
> > "ipg",base + 0x7c, 20, &share_count_ssi2);
> > clks[IMX6SL_CLK_SSI3_IPG] = imx_clk_gate2_shared("ssi3_ipg", 
> > "ipg",base + 0x7c, 22, &share_count_ssi3);
> > diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
> > index 5b95c2c..f2bc511 100644
> > --- a/drivers/clk/imx/clk-imx6sx.c
> > +++ b/drivers/clk/imx/clk-imx6sx.c
> > 

Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

[Ray Jui]

On 9/23/2015 2:55 PM, Ray Jui wrote:
> 
> 
> On 9/23/2015 2:29 PM, Arnd Bergmann wrote:
>> On Friday 18 September 2015 15:11:27 Ray Jui wrote:
>>> On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
 On Friday 18 September 2015 14:24:10 Ray Jui wrote:
> +   soc {
> +   compatible = "simple-bus";
> +   ranges;
> +   #address-cells = <1>;
> +   #size-cells = <1>;

> +   pinctrl: pinctrl@0301d0c8 {
>

 Similarly to the core bus, this seems to have address ranges 0x03xx and
 0x18xx on it, so put those into the ranges.

>>>
>>> Okay we have an issue here. For whatever reason, the Cygnus ASIC team
>>> decided to put registers for the same block in random locations. We see
>>> similar issues in all of our other iProc based SoCs. We have
>>> communicated this to our ASIC team, and hopefully they can revert the
>>> trend for the next SoC.
>>>
>>> For example, the gpio_ccm has registers in the following regions:
>>>
>>> gpio_ccm: gpio@1800a000 {
>>> compatible = "brcm,cygnus-ccm-gpio";
>>> reg = <0x1800a000 0x50>,
>>>   <0x0301d164 0x20>;
>>>
>>> NAND is worse, it has registers in 3 different separate regions:
>>>
>>> nand: nand@18046000 {
>>> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
>>>  "brcm,brcmnand";
>>> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
>>>   <0x18046f00 0x20>;
>>>
>>> As you can see, this makes it impossible to define a proper address
>>> range for the bus; therefore, I'll have to keep the ranges undefined and
>>> a simple 1:1 mapping under this bus.
>>
>> Hmm, you could still try to list them as non-overlapping with other
>> buses on the root node like
>>
>>  ranges = <0x0300 0x0300 0x0100>,
>>   <0x1800 0x1800 0x0100>,
>>   <0xf800 0xf800 0x0100>;
>>
>> which clarifies how the bus is wired up in hardware.
>>
>> Alternatively, you could make a more elaborate mapping, if there
>> are in fact multiple hardware ranges, like
>>
>>  #address-cells = <2>; # space:offset
>>  ranges = <1 0  0x0300 0x0100>,
>>   <2 0  0x1800 0x0100>,
>>   <3 0  0xf800 0x0100>;
>>
>> It really depends on what the hardware designers were thinking. If
>> the AXI bus actually decodes the entire 32-bit address range and devices
>> are just located at random addresses in there, your current scheme is
>> probably closest to reality.
>>
> 
> I see. Let me talk to our ASIC team to get this clarified. If in the end
> the AXI bus decodes the entire 32-bit address space, no change will be
> made. Otherwise, I'll submit another patch to list the actual address
> space that the AXI bus decodes.
> 
> Thanks for the review. It's very helpful!
> 
> Ray
> 

I just got feedback from our ASIC team. The NIC-301 is the main AXI
fabric that decodes the entire 32-bit address space on Cygnus.

I'll keep this as it is for now.

Thanks,

Ray
--
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/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver

[Songjun Wu]

DT binding documentation for this new ASoC driver.

Signed-off-by: Songjun Wu 
---

Changes in v2:
- Delete the device node "Sound".

 .../devicetree/bindings/sound/atmel-classd.txt |   52 
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-classd.txt

diff --git a/Documentation/devicetree/bindings/sound/atmel-classd.txt 
b/Documentation/devicetree/bindings/sound/atmel-classd.txt
new file mode 100644
index 000..0018451
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel-classd.txt
@@ -0,0 +1,52 @@
+* Atmel ClassD driver under ALSA SoC architecture
+
+Required properties:
+- compatible
+   Should be "atmel,sama5d2-classd".
+- reg
+   Should contain ClassD registers location and length.
+- interrupts
+   Should contain the IRQ line for the ClassD.
+- dmas
+   One DMA specifiers as described in atmel-dma.txt and dma.txt files.
+- dma-names
+   Must be "tx".
+- clock-names
+   Tuple listing input clock names.
+   Required elements: "pclk", "gclk" and "aclk".
+- clocks
+   Please refer to clock-bindings.txt.
+
+Optional properties:
+- pinctrl-names, pinctrl-0
+   Please refer to pinctrl-bindings.txt.
+- atmel,model
+   The user-visible name of this sound complex.
+   The default value is "CLASSD".
+- atmel,pwm-type
+   PWM modulation type, "single" or "diff".
+   The default value is "single".
+- atmel,non-overlap-time
+   Set non-overlapping time, the unit is nanosecond(ns).
+   There are four values,
+   <5>, <10>, <15>, <20>, the default value is <10>.
+   Non-overlapping will be disabled if not specified.
+
+Example:
+classd: classd@fc048000 {
+   compatible = "atmel,sama5d2-classd";
+   reg = <0xfc048000 0x100>;
+   interrupts = <59 IRQ_TYPE_LEVEL_HIGH 7>;
+   dmas = <&dma0
+   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
+   | AT91_XDMAC_DT_PERID(47))>;
+   dma-names = "tx";
+   clocks = <&classd_clk>, <&classd_gclk>, <&audio_pll_pmc>;
+   clock-names = "pclk", "gclk", "aclk";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_classd_default>;
+   atmel,model = "classd @ SAMA5D2-Xplained";
+   atmel,pwm-type = "diff";
+   atmel,non-overlap-time = <10>;
+};
-- 
1.7.9.5

--
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/2] ASoC: atmel-classd: add driver for Atmel CLASSD

[Songjun Wu]

The Audio Class D Amplifier driver includes two parts.
1) Driver code to implement the Audio Class D Amplifier function.
2) Device tree binding document, it describes how to add the Audio
   Class D Amplifier in device tree.

Changes in v2:
- Change the "Mono", "Swap" and "Deemphasis" controls to
  "Mono Switch", "Swap Switch" and "Deemphasis Switch".
- Merge "EQ Bass", "EQ Medium" and "EQ Treble" controls
  into one "EQ" control.
- Change the "single-ended" and "differential" to
  "Single ended", "Differential".
- Merge separate left and right controls into one single
  stereo control.
- Add a warning if the user trys to specify an invalid
  value in function "atmel_classd_codec_probe".
- Use the "dev_get_regmap()" in function
  "atmel_classd_codec_get_remap".
- Check for errors when invoking the "clk_prepare_enable".
- Remove the "dev_info" in function "atmel_classd_probe".
- Add some code to create a sound card in function
  "atmel_classd_probe".
- Remove the DT node "Sound" and the related code.
- Delete the device node "Sound".

Songjun Wu (2):
  ASoC: atmel-classd: add the Audio Class D Amplifier
  ASoC: atmel-classd: DT binding for Class D audio amplifier driver

 .../devicetree/bindings/sound/atmel-classd.txt |   52 ++
 sound/soc/atmel/Kconfig|9 +
 sound/soc/atmel/Makefile   |2 +
 sound/soc/atmel/atmel-classd.c |  680 
 sound/soc/atmel/atmel-classd.h |  120 
 5 files changed, 863 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-classd.txt
 create mode 100644 sound/soc/atmel/atmel-classd.c
 create mode 100644 sound/soc/atmel/atmel-classd.h

-- 
1.7.9.5

--
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/9] dt-bindings: add documentation of rk3036 clock controller

[Xing Zheng]

On 2015年09月17日 23:09, Heiko Stübner wrote:

Am Donnerstag, 17. September 2015, 18:32:49 schrieb Xing Zheng:

Add the devicetree binding for the cru on the rk3036 which quite similar
structured as previous clock controllers.

Signed-off-by: Xing Zheng
---

Changes in v2: None

  .../bindings/clock/rockchip,rk3036-cru.txt |   60
 1 file changed, 60 insertions(+)
  create mode 100644
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt new file
mode 100644
index 000..ac3037a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
@@ -0,0 +1,60 @@
+* Rockchip RK3036 Clock and Reset Unit
+
+The RK3036 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: should be "rockchip,rk3036-cru"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing pll rates are not changable, due to the missing pll lock
status. +
+Each clock is assigned an identifier and client nodes can use this
identifier +to specify the clock which they consume. All available clocks
are defined as +preprocessor macros in the dt-bindings/clock/rk3036-cru.h
headers and can be +used in device tree sources. Similar macros exist for
the reset sources in +these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,

The rk3036 does not seem to use a rtc clock, so this should probably go away

Done.

+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_hsadc" - external HSADC clock - optional,
+ - "ext_vip" - external VIP clock - optional,
+ - "ext_isp" - external ISP clock - optional,
+ - "ext_jtag" - external JTAG clock - optional

There do not seem to exist external clock sources for hsadc, vip, isp and jtag
in your clock tree?

missing here:
- ext_gmac

Yes, done.

+
+Example: Clock controller node:
+
+   cru: cru@2000 {
+   compatible = "rockchip,rk3036-cru";
+   reg =<0x2000 0x1000>;
+   rockchip,grf =<&grf>;
+
+   #clock-cells =<1>;
+   #reset-cells =<1>;
+   };
+
+Example: UART controller node that consumes the clock generated by the
clock +  controller:
+
+   uart0: serial@2006 {
+   compatible = "snps,dw-apb-uart";
+   reg =<0x2006 0x100>;
+   interrupts =;
+   reg-shift =<2>;
+   reg-io-width =<4>;
+   clocks =<&cru SCLK_UART0>;
+   };

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

[PATCHv4] arm64: dts: Add base stratix 10 dtsi

[dinguyen]

From: Dinh Nguyen 

Add the base DTS for Altera's SoCFPGA Stratix 10 platform.

Signed-off-by: Dinh Nguyen 
---
v4: Add a non-zero ranges property for /soc node
v3: change #address-cells and #size-cells to <2>
change the GIC address to 0xfffc1000
update the GIC virtual CPU reg length to 0x2000
v2: use interrupt-affinity for pmu node
---
 arch/arm64/Kconfig.platforms   |   5 +
 arch/arm64/boot/dts/Makefile   |   1 +
 arch/arm64/boot/dts/altera/Makefile|   5 +
 arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi  | 358 +
 .../boot/dts/altera/socfpga_stratix10_socdk.dts|  39 +++
 arch/arm64/configs/defconfig   |   1 +
 6 files changed, 409 insertions(+)
 create mode 100644 arch/arm64/boot/dts/altera/Makefile
 create mode 100644 arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
 create mode 100644 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 23800a1..36303c8 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -66,6 +66,11 @@ config ARCH_SEATTLE
help
  This enables support for AMD Seattle SOC Family
 
+config ARCH_STRATIX10
+   bool "Altera's Stratix 10 SoCFPGA Family"
+   help
+ This enables support for Altera's Stratix 10 SoCFPGA Family.
+
 config ARCH_TEGRA
bool "NVIDIA Tegra SoC Family"
select ARCH_HAS_RESET_CONTROLLER
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index d9f8833..f585606 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dts-dirs += altera
 dts-dirs += amd
 dts-dirs += apm
 dts-dirs += arm
diff --git a/arch/arm64/boot/dts/altera/Makefile 
b/arch/arm64/boot/dts/altera/Makefile
new file mode 100644
index 000..d7a6416
--- /dev/null
+++ b/arch/arm64/boot/dts/altera/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_STRATIX10) += socfpga_stratix10_socdk.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi 
b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
new file mode 100644
index 000..445aa67
--- /dev/null
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -0,0 +1,358 @@
+/*
+ * Copyright Altera Corporation (C) 2015. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+/dts-v1/;
+
+/ {
+   compatible = "altr,socfpga-stratix10";
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x0>;
+   };
+
+   cpu1: cpu@1 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x1>;
+   };
+
+   cpu2: cpu@2 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x2>;
+   };
+
+   cpu3: cpu@3 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x3>;
+   };
+   };
+
+   pmu {
+   compatible = "arm,armv8-pmuv3";
+   interrupts = <0 120 8>,
+<0 121 8>,
+<0 122 8>,
+<0 123 8>;
+   interrupt-affinity = <&cpu0>,
+<&cpu1>,
+<&cpu2>,
+<&cpu3>;
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   intc: intc@fffc1000 {
+   compatible = "arm,gic-400", "arm,cortex-a15-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x0 0

Re: [PATCH 2/5] thermal: rockchip: Support the RK3368 SoCs in thermal driver

[Caesar Wang]

Hi Dmitry,

在 2015年09月22日 01:08, Dmitry Torokhov 写道:

Hi Caesar,

On Mon, Sep 21, 2015 at 12:16:08PM +0800, Caesar Wang wrote:

The RK3368 SoCs support to 2 channel TS-ADC, the temperature criteria
of each channel can be configurable.

The system has two Temperature Sensors, channel 0 is for CPU,
and channel 1 is for GPU.

Signed-off-by: Caesar Wang 
---

  drivers/thermal/rockchip_thermal.c | 201 -
  1 file changed, 176 insertions(+), 25 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index 4d5b7d4..16d2476 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -1,6 +1,9 @@
  /*
   * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
   *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ * Caesar Wang 
+ *
   * This program is free software; you can redistribute it and/or modify it
   * under the terms and conditions of the GNU General Public License,
   * version 2, as published by the Free Software Foundation.
@@ -43,16 +46,11 @@ enum tshut_polarity {
TSHUT_HIGH_ACTIVE,
  };
  
-/**

- * The system has three Temperature Sensors.  channel 0 is reserved,
- * channel 1 is for CPU, and channel 2 is for GPU.
- */
-enum sensor_id {
-   SENSOR_CPU = 1,
-   SENSOR_GPU,
-};
-
  struct rockchip_tsadc_chip {
+   /* The sensor id of chip correspond to the ADC channel */
+   int cpu_id;
+   int gpu_id;
+
/* The hardware-controlled tshut property */
long tshut_temp;
enum tshut_mode tshut_mode;
@@ -72,10 +70,11 @@ struct rockchip_tsadc_chip {
  struct rockchip_thermal_sensor {
struct rockchip_thermal_data *thermal;
struct thermal_zone_device *tzd;
-   enum sensor_id id;
+   int id;
  };
  
-#define NUM_SENSORS	2 /* Ignore unused sensor 0 */

+/* Two sensors: CPU and GPU */
+#define NUM_SENSORS2
  
  struct rockchip_thermal_data {

const struct rockchip_tsadc_chip *chip;
@@ -94,7 +93,7 @@ struct rockchip_thermal_data {
enum tshut_polarity tshut_polarity;
  };
  
-/* TSADC V2 Sensor info define: */

+/* TSADC Sensor info define: */
  #define TSADCV2_AUTO_CON  0x04
  #define TSADCV2_INT_EN0x08
  #define TSADCV2_INT_PD0x0c
@@ -116,6 +115,8 @@ struct rockchip_thermal_data {
  #define TSADCV2_INT_PD_CLEAR_MASK ~BIT(8)
  
  #define TSADCV2_DATA_MASK			0xfff

+#define TSADCV3_DATA_MASK  0x3ff
+
  #define TSADCV2_HIGHT_INT_DEBOUNCE_COUNT  4
  #define TSADCV2_HIGHT_TSHUT_DEBOUNCE_COUNT4
  #define TSADCV2_AUTO_PERIOD_TIME  250 /* msec */
@@ -164,6 +165,45 @@ static const struct tsadc_table v2_code_table[] = {
{3421, 125000},
  };
  
+static const struct tsadc_table v3_code_table[] = {

+   {0, -4},
+   {106, -4},
+   {108, -35000},
+   {110, -3},
+   {112, -25000},
+   {114, -2},
+   {116, -15000},
+   {118, -1},
+   {120, -5000},
+   {122, 0},
+   {124, 5000},
+   {126, 1},
+   {128, 15000},
+   {130, 2},
+   {132, 25000},
+   {134, 3},
+   {136, 35000},
+   {138, 4},
+   {140, 45000},
+   {142, 5},
+   {144, 55000},
+   {146, 6},
+   {148, 65000},
+   {150, 7},
+   {152, 75000},
+   {154, 8},
+   {156, 85000},
+   {158, 9},
+   {160, 95000},
+   {162, 10},
+   {163, 105000},
+   {165, 11},
+   {167, 115000},
+   {169, 12},
+   {171, 125000},
+   {TSADCV3_DATA_MASK, 125000},
+};
+
  static u32 rk_tsadcv2_temp_to_code(long temp)
  {
int high, low, mid;
@@ -227,16 +267,83 @@ static int rk_tsadcv2_code_to_temp(u32 code, int *temp)
return 0;
  }
  
+static u32 rk_tsadcv3_temp_to_code(long temp)

+{
+   int high, low, mid;
+
+   low = 0;
+   high = ARRAY_SIZE(v3_code_table) - 1;
+   mid = (high + low) / 2;
+
+   if (temp < v3_code_table[low].temp || temp > v3_code_table[high].temp)
+   return 0;

How is this different from v2 conversion except for the table being
used? I think you should be able to reuse the conversion routines if you
pass the conversion table in as a parameter.


The table_v3 is same with the table_v2 but the anolog data of ADC.

Do you want to reuse the conversion routines,?  I know the conversion 
routines is same in
rk_tsadcv3_temp_to_code() if we have many socs maybe the ADC analog data 
are different.


Says:

rk_tsadcv3_temp_to_code(temp, xxx)

{
...

 =  rk_tsadcv2_temp_to_code(temp)

...
}
...


I guess you want to independent the adc value,after all the temperature 
points are same.


Says: maybe i will better likely on this.

//3066/3188
.

//3288

static const struct tsadc_table v2_code_table[] = {
{0,3800,3792,3783, 3774,3765, 3756,3747,..
},


//

Re: [PATCH v2 2/9] clk: rockchip: add dt-binding header for rk3036

[Xing Zheng]

On 2015年09月17日 17:25, Heiko Stübner wrote:

Am Donnerstag, 17. September 2015, 16:28:53 schrieb Xing Zheng:

Add the dt-bindings header for the rk3036, that gets shared between
the clock controller and the clock references in the dts.

Signed-off-by: Xing Zheng
---

Changes in v2: None

  include/dt-bindings/clock/rk3036-cru.h |  198
 1 file changed, 198 insertions(+)
  create mode 100644 include/dt-bindings/clock/rk3036-cru.h

diff --git a/include/dt-bindings/clock/rk3036-cru.h
b/include/dt-bindings/clock/rk3036-cru.h new file mode 100644
index 000..b0033ef
--- /dev/null
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -0,0 +1,198 @@
+/*
+ * Copyright (c) 2014 MundoReader S.L.
+ * Author: Heiko Stuebner

you can probably drop that copyright line ... I didn't do anything here ;-)

OK, done. :)



+ *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
+
+/* core clocks */
+#define PLL_APLL   1
+#define PLL_DPLL   2
+#define PLL_GPLL   3
+#define ARMCLK 4
+
+/* sclk gates (special clocks) */

you have a lot of gaps in the numbering ... intentional?
Oh, I think I referenced to "rk3288-cru.h" and cut some useless 
numbering from it for rk3036


otherwise
Reviewed-by: Heiko Stuebner

Done.

+#define SCLK_GPU   64
+#define SCLK_SPI   65
+#define SCLK_SDMMC 68
+#define SCLK_SDIO  69
+#define SCLK_EMMC  71
+#define SCLK_NANDC 76
+#define SCLK_UART0 77
+#define SCLK_UART1 78
+#define SCLK_UART2 79
+#define SCLK_I2S   82
+#define SCLK_SPDIF 83
+#define SCLK_TIMER085
+#define SCLK_TIMER186
+#define SCLK_TIMER287
+#define SCLK_TIMER388
+#define SCLK_OTGPHY0   93
+#define SCLK_OTGPHY1   94
+#define SCLK_LCDC  100
+#define SCLK_HDMI  109
+#define SCLK_HEVC  111
+#define SCLK_I2S_OUT   113
+#define SCLK_SDMMC_DRV 114
+#define SCLK_SDIO_DRV  115
+#define SCLK_EMMC_DRV  117
+#define SCLK_SDMMC_SAMPLE  118
+#define SCLK_SDIO_SAMPLE   119
+#define SCLK_EMMC_SAMPLE   121
+#define SCLK_PVTM_CORE  123
+#define SCLK_PVTM_GPU   124
+#define SCLK_PVTM_VIDEO 125
+#define SCLK_MAC   151
+#define SCLK_MACREF152
+#define SCLK_SFC   160
+
+#define DCLK_LCDC  190
+
+/* aclk gates */
+#define ACLK_DMAC2 194
+#define ACLK_LCDC  197
+#define ACLK_VIO   203
+#define ACLK_VCODEC208
+#define ACLK_CPU   209
+#define ACLK_PERI  210
+
+/* pclk gates */
+#define PCLK_GPIO0 320
+#define PCLK_GPIO1 321
+#define PCLK_GPIO2 322
+#define PCLK_GRF   329
+#define PCLK_I2C0  332
+#define PCLK_I2C1  333
+#define PCLK_I2C2  334
+#define PCLK_SPI   338
+#define PCLK_UART0 341
+#define PCLK_UART1 342
+#define PCLK_UART2 343
+#define PCLK_PWM   350
+#define PCLK_TIMER 353
+#define PCLK_HDMI  360
+#define PCLK_CPU   362
+#define PCLK_PERI  363
+#define PCLK_DDRUPCTL  364
+#define PCLK_WDT   368
+
+/* hclk gates */
+#define HCLK_OTG0  449
+#define HCLK_OTG1  450
+#define HCLK_NANDC 453
+#define HCLK_SDMMC 456
+#define HCLK_SDIO  457
+#define HCLK_EMMC  459
+#define HCLK_I2S   462
+#define HCLK_LCDC  465
+#define HCLK_ROM   467
+#define HCLK_VIO_BUS   472
+#define HCLK_VCODEC476
+#define HCLK_CPU   477
+#define HCLK_PERI  478
+
+#define CLK_NR_CLKS(HCLK_PERI + 1)
+
+/* soft-reset indices */
+#define SRST_CORE0 0
+#define SRST_CORE1 1
+#define SRST_CORE0_DBG 4
+#define SRST_CORE1_DBG 5
+#define SRST_CORE0_POR 8
+#define SRST_CORE1_POR 9
+#define SRST_L2C   12
+#define SRST_TOPDBG13
+#define SRST_STRC_SYS_A14
+#define SRST_PD_CORE_NIU   15
+
+#define SRST_TIMER216
+

Re: [PATCH v2 1/9] ARM: dts: rockchip: add core rk3036 dts

[Xing Zheng]

On 2015年09月17日 17:18, Heiko Stübner wrote:

Am Donnerstag, 17. September 2015, 16:28:52 schrieb Xing Zheng:

Initial release for rk3036, node definitions rk3036 sdk board.

Signed-off-by: Xing Zheng
---

Changes in v2: None

  arch/arm/boot/dts/Makefile   |1 +
  arch/arm/boot/dts/rk3036-sdk.dts |   62 +++
  arch/arm/boot/dts/rk3036.dtsi|  381
++ 3 files changed, 444 insertions(+)
  create mode 100644 arch/arm/boot/dts/rk3036-sdk.dts
  create mode 100644 arch/arm/boot/dts/rk3036.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d39ce4b..48260c4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -502,6 +502,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
+   rk3036-sdk.dtb \

ordering ... please put the rk3036 above rk3066 boards

Done.



rk3188-radxarock.dtb \
rk3288-evb-act8846.dtb \
rk3288-evb-rk808.dtb \
diff --git a/arch/arm/boot/dts/rk3036-sdk.dts
b/arch/arm/boot/dts/rk3036-sdk.dts new file mode 100644
index 000..9187f93
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036-sdk.dts

or "rk3036-evb.dts"? What is the actual board named?

Done, use rk3036-evb.dts

@@ -0,0 +1,62 @@
+/*
+ * Copyright (c)  2015 Xing Zheng

this probably wants a Rockchip copyright notice?

Yes, remove this notice.

+ *
+ * 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 as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * 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 "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * 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 "rk3036.dtsi"
+
+/ {
+   model = "SDK-RK3036";
+   compatible = "sdk,sdk-rk3036", "rockchip,rk3036";

model = "Rockchip RK3036-SDK";
compatible = "rockchip,rk3036-sdk", "rockchip,rk3036";

or

model = "Rockchip RK3036 Evaluation board";
compatible = "rockchip,rk3036-evb", "rockchip,rk3036";

depending on what the real board is labeled

Done.

+};
+
+&i2c1 {
+   status = "okay";
+
+hym8563: hym8563@51 {
+   compatible = "haoyu,hym8563";
+   reg =<0x51>;
+   #clock-cells =<0>;
+   clock-frequency =<32768>;
+   clock-output-names = "xin32k";
+   };
+};
\ No newline at end of file

missing newline as stated above

Done.

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
new file mode 100644
index 000..b7459c0
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -0,0 +1,381 @@
+/*
+ * 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 as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+

Re: [PATCH v2 1/5] net: add Hisilicon Network Subsystem support (config and documents)

[huangdaode]

On 2015/9/21 22:52, Rob Herring wrote:

On 09/17/2015 01:51 AM, huangdaode wrote:

The Hisilicon Network Subsystem is a long term evolution IP which is
supposed to be used in Hisilicon ICT SoC. The IP, which is called hns
for short, is a TCP/IP acceleration engine, which can directly decode
TCP/IP stream and distribute them to different ring buffers.

HNS can be configured to work on different mode for different scenario.
This patch make use only some of the mode to make it as standard
ethernet NIC. The other mode will be added soon.

The whole function has 4 kernel sub-modules:

hnae: the HNS acceleration engine framework. It provides a abstract
interface between the engine and the upper layers which make use of the
engine by ring buffer.

hns_enet_drv: a standard ethernet driver that base on the ring buffer.

hns_dsaf: one of the implementation of HNS acceleration engine, which is
applied on Hililicon hip05, Hi1610 and other later-on SoCs

hns_mdio: the mdio control to the PHY, used by acceleration engine

This submit add basic config and documents

Signed-off-by: huangdaode 
Signed-off-by: Kenneth Lee 
Signed-off-by: Yisen Zhuang 
---
  .../bindings/net/hisilicon-hip04-net.txt   |   4 +-
  .../devicetree/bindings/net/hisilicon-hns-dsaf.txt |  49 ++
  .../devicetree/bindings/net/hisilicon-hns-mdio.txt |  22 +++
  .../devicetree/bindings/net/hisilicon-hns-nic.txt  |  47 +
  arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi   | 193 +
  5 files changed, 313 insertions(+), 2 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
  create mode 100644 
Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
  create mode 100644 Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
  create mode 100644 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi

diff --git a/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt 
b/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
index 988fc69..d1df8a0 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
@@ -32,13 +32,13 @@ Required properties:
  
  Required properties:
  
-- compatible: should be "hisilicon,hip04-mdio".

+- compatible: should be "hisilicon,mdio".

Why are you removing the old one? Please use more specific compatible
strings, not less specific.



we have unified the hip04_mdio.c and hip05_mdio.c  into hns_mdio.c, so 
we plan use
"hisilicon,mdio", "hisilicon,hns-mdio" "hisilicon,hns-mdio Vx", in this 
case, "hisilicon, mdio "
is more suitable for us, meanwhile, we will upstream hip04 dts file 
later, and will apply the

compatible property with "hisilicon,mdio".


  - Inherits from MDIO bus node binding [2]
  [2] Documentation/devicetree/bindings/net/phy.txt
  
  Example:

mdio {
-   compatible = "hisilicon,hip04-mdio";
+   compatible = "hisilicon,mdio";
reg = <0x28f1000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt 
b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
new file mode 100644
index 000..80411b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
@@ -0,0 +1,49 @@
+Hisilicon DSA Fabric device controller
+
+Required properties:
+- compatible: should be "hisilicon,hns-dsaf-v1" or "hisilicon,hns-dsaf-v2".
+  "hisilicon,hns-dsaf-v1" is for hip05.
+  "hisilicon,hns-dsaf-v2" is for Hi1610 and Hi1612.
+- dsa-name: dsa fabric name who provide this interface.
+  should be "dsafX", X is the dsaf id.

What is this for? Find a different way to distinguish instances other
than an index.


our driver support multi dsaf, so X in dsafX is the dsaf id.
the enet driver interface use the dsa-name to match the dsaf engine, 
then get it's handle.
when there are 2 dsafs ,we use dsaf0 and dsaf1 to distinguish them. The 
default is dsaf0.



+- mode: dsa fabric mode string. only support one of dsaf modes like these:
+   "2port-64vf",
+   "6port-16rss",
+   "6port-16vf".
+- interrupt-parent: the interrupt parent of this device.
+- interrupts: should contain the DSA Fabric and rcb interrupt.
+- reg: specifies base physical address(es) and size of the device registers.
+  The first region is external interface control register base and size.
+  The second region is SerDes base register and size.
+  The third region is the PPE register base and size.
+  The fourth region is dsa fabric base register and size.
+  The fifth region is cpld base register and size, it is not required if do 
not use cpld.
+- phy-handle: phy handle of physicl port, 0 if not any phy device. see 
ethernet.txt [1].
+- buf-size: rx buffer size, should be 16-1024.

This is a h/w property?


yes. it's.


+- desc-num: number of description in TX and RX queue, should be 512, 1024,

[PATCH v5 3/4] edac: Add SoC EDAC support to the APM X-Gene SoC EDAC driver

[Loc Ho]

Add EDAC support for the SoC component.

Signed-off-by: Loc Ho 
---
 drivers/edac/xgene_edac.c |  498 +
 1 files changed, 498 insertions(+), 0 deletions(-)

diff --git a/drivers/edac/xgene_edac.c b/drivers/edac/xgene_edac.c
index 37121e8..bfca5d2 100644
--- a/drivers/edac/xgene_edac.c
+++ b/drivers/edac/xgene_edac.c
@@ -68,6 +68,7 @@ struct xgene_edac {
struct list_headmcus;
struct list_headpmds;
struct list_headl3s;
+   struct list_headsocs;

struct mutexmc_lock;
int mc_active_mask;
@@ -1281,6 +1282,492 @@ static int xgene_edac_l3_remove(struct 
xgene_edac_dev_ctx *l3)
return 0;
 }

+/* SoC error device */
+#define IOBAXIS0TRANSERRINTSTS 0x
+#define  IOBAXIS0_M_ILLEGAL_ACCESS_MASKBIT(1)
+#define  IOBAXIS0_ILLEGAL_ACCESS_MASK  BIT(0)
+#define IOBAXIS0TRANSERRINTMSK 0x0004
+#define IOBAXIS0TRANSERRREQINFOL   0x0008
+#define IOBAXIS0TRANSERRREQINFOH   0x000c
+#define  REQTYPE_RD(src)   (((src) & BIT(0)))
+#define  ERRADDRH_RD(src)  (((src) & 0xffc0) >> 22)
+#define IOBAXIS1TRANSERRINTSTS 0x0010
+#define IOBAXIS1TRANSERRINTMSK 0x0014
+#define IOBAXIS1TRANSERRREQINFOL   0x0018
+#define IOBAXIS1TRANSERRREQINFOH   0x001c
+#define IOBPATRANSERRINTSTS0x0020
+#define  IOBPA_M_REQIDRAM_CORRUPT_MASK BIT(7)
+#define  IOBPA_REQIDRAM_CORRUPT_MASK   BIT(6)
+#define  IOBPA_M_TRANS_CORRUPT_MASKBIT(5)
+#define  IOBPA_TRANS_CORRUPT_MASK  BIT(4)
+#define  IOBPA_M_WDATA_CORRUPT_MASKBIT(3)
+#define  IOBPA_WDATA_CORRUPT_MASK  BIT(2)
+#define  IOBPA_M_RDATA_CORRUPT_MASKBIT(1)
+#define  IOBPA_RDATA_CORRUPT_MASK  BIT(0)
+#define IOBBATRANSERRINTSTS0x0030
+#define  M_ILLEGAL_ACCESS_MASK BIT(15)
+#define  ILLEGAL_ACCESS_MASK   BIT(14)
+#define  M_WIDRAM_CORRUPT_MASK BIT(13)
+#define  WIDRAM_CORRUPT_MASK   BIT(12)
+#define  M_RIDRAM_CORRUPT_MASK BIT(11)
+#define  RIDRAM_CORRUPT_MASK   BIT(10)
+#define  M_TRANS_CORRUPT_MASK  BIT(9)
+#define  TRANS_CORRUPT_MASKBIT(8)
+#define  M_WDATA_CORRUPT_MASK  BIT(7)
+#define  WDATA_CORRUPT_MASKBIT(6)
+#define  M_RBM_POISONED_REQ_MASK   BIT(5)
+#define  RBM_POISONED_REQ_MASK BIT(4)
+#define  M_XGIC_POISONED_REQ_MASK  BIT(3)
+#define  XGIC_POISONED_REQ_MASKBIT(2)
+#define  M_WRERR_RESP_MASK BIT(1)
+#define  WRERR_RESP_MASK   BIT(0)
+#define IOBBATRANSERRREQINFOL  0x0038
+#define IOBBATRANSERRREQINFOH  0x003c
+#define  REQTYPE_F2_RD(src)((src) & BIT(0))
+#define  ERRADDRH_F2_RD(src)   (((src) & 0xffc0) >> 22)
+#define IOBBATRANSERRCSWREQID  0x0040
+#define XGICTRANSERRINTSTS 0x0050
+#define  M_WR_ACCESS_ERR_MASK  BIT(3)
+#define  WR_ACCESS_ERR_MASKBIT(2)
+#define  M_RD_ACCESS_ERR_MASK  BIT(1)
+#define  RD_ACCESS_ERR_MASKBIT(0)
+#define XGICTRANSERRINTMSK 0x0054
+#define XGICTRANSERRREQINFO0x0058
+#define  REQTYPE_MASK  BIT(26)
+#define  ERRADDR_RD(src)   ((src) & 0x03ff)
+#define GLBL_ERR_STS   0x0800
+#define  MDED_ERR_MASK BIT(3)
+#define  DED_ERR_MASK  BIT(2)
+#define  MSEC_ERR_MASK BIT(1)
+#define  SEC_ERR_MASK  BIT(0)
+#define GLBL_SEC_ERRL  0x0810
+#define GLBL_SEC_ERRH  0x0818
+#define GLBL_MSEC_ERRL 0x0820
+#define GLBL_MSEC_ERRH 0x0828
+#define GLBL_DED_ERRL  0x0830
+#define GLBL_DED_ERRLMASK  0x0834
+#define GLBL_DED_ERRH  0x0838
+#define GLBL_DED_ERRHMASK  0x083c
+#define GLBL_MDED_ERRL 0x0840
+#define GLBL_MDED_ERRLMASK 0x0844
+#define GLBL_MDED_ERRH 0x0848
+#define GLBL_MDED_ERRHMASK 0x084c
+
+static const char * const soc_mem_err_v1[] = {
+   "10GbE0",
+   "10GbE1",
+   "Security",
+   "SATA45",
+   "SATA23/ETH23",
+   "SATA01/ETH01",
+   "USB1",
+   "USB0",
+   "QML",
+   "QM0",
+   "QM1 (XGbE01)",
+   "PCIE4",
+   "PCIE3",
+   "PCIE2",
+   "PCIE1",
+   "PCIE0",
+   "CTX Manager",
+   "OCM",
+   "1GbE",
+   "CLE",
+   "AHBC",
+   "PktDMA",
+   "GFC",
+   "MSLIM",
+   "10GbE2",
+   "10GbE3",
+   "QM2 (XGbE23)",
+   "IOB",
+   "unknown",
+   "unknown",
+   "unknown",
+   "unknown",
+};
+
+static void xgene_edac_iob_gic_report(struct edac_device_ctl_info *edac_dev)
+{
+   struct xgene_edac_dev_ctx *ctx = edac_dev->pvt_info;
+   u32 err_addr_lo;
+   u32 err_addr_hi;
+   u32 reg;
+   u32 info;
+
+   /* GIC

[PATCH v5 2/4] edac: Add L3 EDAC support to the APM X-Gene SoC EDAC driver

[Loc Ho]

Add EDAC support for the L3 component.

Signed-off-by: Loc Ho 
---
 drivers/edac/xgene_edac.c |  669 -
 1 files changed, 474 insertions(+), 195 deletions(-)

diff --git a/drivers/edac/xgene_edac.c b/drivers/edac/xgene_edac.c
index 5ff42d5..37121e8 100644
--- a/drivers/edac/xgene_edac.c
+++ b/drivers/edac/xgene_edac.c
@@ -63,10 +63,11 @@ struct xgene_edac {
struct regmap   *efuse_map;
void __iomem*pcp_csr;
spinlock_t  lock;
-   struct dentry   *dfs;
+   struct dentry   *dfs;

struct list_headmcus;
struct list_headpmds;
+   struct list_headl3s;

struct mutexmc_lock;
int mc_active_mask;
@@ -537,140 +538,134 @@ static void xgene_edac_pmd_l1_check(struct 
edac_device_ctl_info *edac_dev,
pg_f = ctx->pmd_csr + cpu_idx * CPU_CSR_STRIDE + CPU_MEMERR_CPU_PAGE;

val = readl(pg_f + MEMERR_CPU_ICFESR_PAGE_OFFSET);
-   if (val) {
-   dev_err(edac_dev->dev,
-   "CPU%d L1 memory error ICF 0x%08X Way 0x%02X Index 
0x%02X Info 0x%02X\n",
-   ctx->pmd * MAX_CPU_PER_PMD + cpu_idx, val,
-   MEMERR_CPU_ICFESR_ERRWAY_RD(val),
-   MEMERR_CPU_ICFESR_ERRINDEX_RD(val),
-   MEMERR_CPU_ICFESR_ERRINFO_RD(val));
-   if (val & MEMERR_CPU_ICFESR_CERR_MASK)
-   dev_err(edac_dev->dev,
-   "One or more correctable error\n");
-   if (val & MEMERR_CPU_ICFESR_MULTCERR_MASK)
-   dev_err(edac_dev->dev, "Multiple correctable error\n");
-   switch (MEMERR_CPU_ICFESR_ERRTYPE_RD(val)) {
-   case 1:
-   dev_err(edac_dev->dev, "L1 TLB multiple hit\n");
-   break;
-   case 2:
-   dev_err(edac_dev->dev, "Way select multiple hit\n");
-   break;
-   case 3:
-   dev_err(edac_dev->dev, "Physical tag parity error\n");
-   break;
-   case 4:
-   case 5:
-   dev_err(edac_dev->dev, "L1 data parity error\n");
-   break;
-   case 6:
-   dev_err(edac_dev->dev, "L1 pre-decode parity error\n");
-   break;
-   }
+   if (!val)
+   goto chk_lsu;
+   dev_err(edac_dev->dev,
+   "CPU%d L1 memory error ICF 0x%08X Way 0x%02X Index 0x%02X Info 
0x%02X\n",
+   ctx->pmd * MAX_CPU_PER_PMD + cpu_idx, val,
+   MEMERR_CPU_ICFESR_ERRWAY_RD(val),
+   MEMERR_CPU_ICFESR_ERRINDEX_RD(val),
+   MEMERR_CPU_ICFESR_ERRINFO_RD(val));
+   if (val & MEMERR_CPU_ICFESR_CERR_MASK)
+   dev_err(edac_dev->dev, "One or more correctable error\n");
+   if (val & MEMERR_CPU_ICFESR_MULTCERR_MASK)
+   dev_err(edac_dev->dev, "Multiple correctable error\n");
+   switch (MEMERR_CPU_ICFESR_ERRTYPE_RD(val)) {
+   case 1:
+   dev_err(edac_dev->dev, "L1 TLB multiple hit\n");
+   break;
+   case 2:
+   dev_err(edac_dev->dev, "Way select multiple hit\n");
+   break;
+   case 3:
+   dev_err(edac_dev->dev, "Physical tag parity error\n");
+   break;
+   case 4:
+   case 5:
+   dev_err(edac_dev->dev, "L1 data parity error\n");
+   break;
+   case 6:
+   dev_err(edac_dev->dev, "L1 pre-decode parity error\n");
+   break;
+   }

-   /* Clear any HW errors */
-   writel(val, pg_f + MEMERR_CPU_ICFESR_PAGE_OFFSET);
+   /* Clear any HW errors */
+   writel(val, pg_f + MEMERR_CPU_ICFESR_PAGE_OFFSET);

-   if (val & (MEMERR_CPU_ICFESR_CERR_MASK |
-  MEMERR_CPU_ICFESR_MULTCERR_MASK))
-   edac_device_handle_ce(edac_dev, 0, 0,
- edac_dev->ctl_name);
-   }
+   if (val & (MEMERR_CPU_ICFESR_CERR_MASK |
+  MEMERR_CPU_ICFESR_MULTCERR_MASK))
+   edac_device_handle_ce(edac_dev, 0, 0, edac_dev->ctl_name);

+chk_lsu:
val = readl(pg_f + MEMERR_CPU_LSUESR_PAGE_OFFSET);
-   if (val) {
+   if (!val)
+   goto chk_mmu;
+   dev_err(edac_dev->dev,
+   "CPU%d memory error LSU 0x%08X Way 0x%02X Index 0x%02X Info 
0x%02X\n",
+   ctx->pmd * MAX_CPU_PER_PMD + cpu_idx, val,
+   MEMERR_CPU_LSUESR_ERRWAY_RD(val),
+   MEMERR_CPU_LSUESR_ERRINDEX_RD(val),
+   MEMERR_CPU_LSUESR_ERRINFO_RD(val));
+   if (val & MEMERR_CPU_LSUESR_CERR_MASK)
+   dev_err(edac_dev->dev, "One or more correctable error\n");
+   

[PATCH v5 4/4] arm64: Add L3/SoC DT subnodes to the APM X-Gene SoC EDAC node

[Loc Ho]

Add L3/SoC DT subnodes to the APM X-Gene SoC EDAC node.

Signed-off-by: Loc Ho 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index d831bc2..fac1720 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -477,6 +477,16 @@
reg = <0x0 0x7c60 0x0 0x20>;
pmd-controller = <3>;
};
+
+   edacl3@7e60 {
+   compatible = "apm,xgene-edac-l3";
+   reg = <0x0 0x7e60 0x0 0x1000>;
+   };
+
+   edacsoc@7e93 {
+   compatible = "apm,xgene-edac-soc-v1";
+   reg = <0x0 0x7e93 0x0 0x1000>;
+   };
};

pcie0: pcie@1f2b {
--
1.7.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 1/4] Documentation: Update the APM X-Gene SoC EDAC DTS binding for L3/SoC subnodes

[Loc Ho]

Update documentation for the APM X-Gene SoC EDAC DTS binding for L3/SoC
subnodes.

Signed-off-by: Loc Ho 
---
 .../devicetree/bindings/edac/apm-xgene-edac.txt|   23 
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt 
b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
index 78edb80..78e2a31 100644
--- a/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
+++ b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
@@ -5,6 +5,8 @@ The follow error types are supported:

   memory controller- Memory controller
   PMD (L1/L2)  - Processor module unit (PMD) L1/L2 cache
+  L3   - L3 cache controller
+  SoC  - SoC IP's such as Ethernet, SATA, and etc

 The following section describes the EDAC DT node binding.

@@ -30,6 +32,17 @@ Required properties for PMD subnode:
 - reg  : First resource shall be the PMD resource.
 - pmd-controller   : Instance number of the PMD controller.

+Required properties for L3 subnode:
+- compatible   : Shall be "apm,xgene-edac-l3" or
+  "apm,xgene-edac-l3-v2".
+- reg  : First resource shall be the L3 EDAC resource.
+
+Required properties for SoC subnode:
+- compatible   : Shall be "apm,xgene-edac-soc-v1" for revision 1 or
+  "apm,xgene-edac-l3-soc" for general value reporting
+  only.
+- reg  : First resource shall be the SoC EDAC resource.
+
 Example:
csw: csw@7e20 {
compatible = "apm,xgene-csw", "syscon";
@@ -76,4 +89,14 @@ Example:
reg = <0x0 0x7c00 0x0 0x20>;
pmd-controller = <0>;
};
+
+   edacl3@7e60 {
+   compatible = "apm,xgene-edac-l3";
+   reg = <0x0 0x7e60 0x0 0x1000>;
+   };
+
+   edacsoc@7e93 {
+   compatible = "apm,xgene-edac-soc-v1";
+   reg = <0x0 0x7e93 0x0 0x1000>;
+   };
};
--
1.7.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 0/4] edac: Add L3/SoC support to the APM X-Gene SoC EDAC driver

[Loc Ho]

v5:
* Drop the EDAC debugfs export and use the wrapper from maintainer
* Clean up debugfs node function to make use of function wrapper
* Clean up function xgene_edac_l3_v1_errata_chk
* Move SoC part into another patch
* Tested with 
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git#edac-debugfs
* Make function xgene_edac_l3_create_debugfs_nodes more readable

v4:
* Remove function for EDAC debugfs node and replace with export variable
* Switch the driver to use the exported edac_debugfs variable
* Revert the if statement logic for function as necessary
* Remove un-necessary code in debugfs creation functions

v3:
* Add an function to retrieve the EDAC debugfs node
* Move all debugfs node under EDAC code debugfs node
* Update L3 to check for v1 errata
* Rename error label for L3/SoC add routines
* Re-structure SoC EDAC functions for code readability
* Inline the function xgene_edac_soc_mem_data
* Remove un-necessary { }

v2:
* Update binding documentation accordingly
* Change all single bit defines to BIT(x)
* Add support for L3 version 1 and 2 HW's
* Change to use debug file system for error injection
* In L3/SoC instance add function, allocate EDAC context after all
  initalization successed
* Support raw or detail info for SoC EDAC error reporting

v1:
* Add L3/SoC support to the APM X-Gene SoC EDAC driver
---
Loc Ho (4):
  Documentation: Update the APM X-Gene SoC EDAC DTS binding for L3/SoC
subnodes
  edac: Add L3 EDAC support to the APM X-Gene SoC EDAC driver
  edac: Add SoC EDAC support to the APM X-Gene SoC EDAC driver
  arm64: Add L3/SoC DT subnodes to the APM X-Gene SoC EDAC node

 .../devicetree/bindings/edac/apm-xgene-edac.txt|   23 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   10 +
 drivers/edac/xgene_edac.c  | 1165 
 3 files changed, 1004 insertions(+), 194 deletions(-)

--
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/2] dma: Add Freescale qDMA engine driver support

[Li Yang]

On Fri, Sep 11, 2015 at 12:53 AM, Yuan Yao  wrote:
> Add Freescale Queue Direct Memory Access(qDMA) controller support.
> This module can be found on LS-1 and LS-2 SoCs.
>
> This add the legacy mode support for qDMA.
>
> Signed-off-by: Yuan Yao 
> ---
>  Documentation/devicetree/bindings/dma/fsl-qdma.txt |  43 ++
>  MAINTAINERS|   7 +
>  drivers/dma/Kconfig|  10 +
>  drivers/dma/Makefile   |   1 +
>  drivers/dma/fsl-qdma.c | 521 
> +
>  5 files changed, 582 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/fsl-qdma.txt
>  create mode 100644 drivers/dma/fsl-qdma.c
>
> diff --git a/Documentation/devicetree/bindings/dma/fsl-qdma.txt 
> b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
> new file mode 100644
> index 000..cdae71c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
> @@ -0,0 +1,43 @@
> +* Freescale queue Direct Memory Access Controller(qDMA) Controller
> +
> +  The qDMA controller transfers blocks of data between one source and one or 
> more
> +destinations. The blocks of data transferred can be represented in memory as 
> contiguous
> +or non-contiguous using scatter/gather table(s). Channel virtualization is 
> supported
> +through enqueuing of DMA jobs to, or dequeuing DMA jobs from, different work
> +queues.
> +  Legacy mode is primarily included for software requiring the earlier
> +QorIQ DMA programming model. This mode provides a simple programming
> +model not utilizing the datapath architecture. In legacy mode, DMA
> +operations are directly configured through a set of architectural
> +registers per channel.

Is this binding only covering the legacy mode?  The binding should
describe the whole IP block no matter if we have driver for all the
features.

> +
> +* qDMA Controller
> +Required properties:
> +- compatible :
> +   - "fsl,ls-qdma" for qDMA used similar to that on LS SoC

Compatible need to be specific like "fsl,ls1021a-qdma".  See
http://www.devicetree.org/Device_Tree_Usage.

> +- reg : Specifies base physical address(s) and size of the qDMA registers.
> +   The region is qDMA control register's address and size.
> +- interrupts : A list of interrupt-specifiers, one for each entry in
> +   interrupt-names.
> +- interrupt-names : Should contain:
> +   "qdma-tx" - the  interrupt
> +   "qdma-err" - the error interrupt
> +- channels : Number of channels supported by the controller
> +
> +Optional properties:
> +- big-endian: If present registers and hardware scatter/gather descriptors
> +   of the qDMA are implemented in big endian mode, otherwise in little

Endian
> +   mode.
> +
> +
> +Examples:
> +
> +   qdma: qdma@839 {
> +   compatible = "fsl,ls-qdma";
> +   reg = <0x0 0x838 0x0 0x2>;
> +   interrupts = ,
> +   ;
> +   interrupt-names = "qdma-tx", "qdma-err";
> +   big-endian;
> +   channels = <1>;
> +   };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5772ccf..a4d1b52 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4357,6 +4357,13 @@ L:   linuxppc-...@lists.ozlabs.org
>  S: Maintained
>  F: drivers/dma/fsldma.*
>
> +FREESCALE qDMA DRIVER
> +M: Yuan Yao 
> +L: linux-arm-ker...@lists.infradead.org

Interestingly you listed arm mailing list instead of dmaengine mailing list.

> +S: Maintained
> +F: Documentation/devicetree/bindings/dma/fsl-qdma.txt
> +F: drivers/dma/fsl-qdma.c
> +
>  FREESCALE I2C CPM DRIVER
>  M: Jochen Friedrich 
>  L: linuxppc-...@lists.ozlabs.org
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index b458475..e29e985 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -193,6 +193,16 @@ config FSL_EDMA
>   multiplexing capability for DMA request sources(slot).
>   This module can be found on Freescale Vybrid and LS-1 SoCs.
>
> +config FSL_QDMA
> +   tristate "Freescale qDMA engine support"
> +   select DMA_ENGINE
> +   select DMA_VIRTUAL_CHANNELS
> +   help
> + Support the Freescale qDMA engine with command queue and legacy 
> mode.
> + Channel virtualization is supported through enqueuing of DMA jobs 
> to,
> + or dequeuing DMA jobs from, different work queues.
> + This module can be found on Freescale LS SoCs.

Better to spell out Layerscape

> +
>  config FSL_RAID
>  tristate "Freescale RAID engine Support"
>  depends on FSL_SOC && !ASYNC_TX_ENABLE_CHANNEL_SWITCH
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index 7711a71..8de7526 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_DW_DMAC_CORE) += dw/
>  obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
>  obj-$(CONFIG_FSL_DMA) += fsldma.o
>  obj-$(CONFIG_FSL

Re: [PATCH v2 0/9] Phy, mdiobus, and netdev struct device fixes

[David Miller]

From: Russell King - ARM Linux 
Date: Tue, 22 Sep 2015 17:17:10 +0100

> This is the second version of the series, with the comments David had
> on the first patch fixed up.  Original series description with updated
> diffstat below.

This needs some build fixes:

drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 
‘xgene_enet_phy_connect’:
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:694:20: error: too few arguments 
to function ‘of_phy_connect’
   pdata->phy_dev = of_phy_connect(ndev, phy_np,
^
In file included from drivers/net/ethernet/apm/xgene/xgene_enet_main.h:31:0,
 from drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:22:
include/linux/of_mdio.h:18:27: note: declared here
 extern struct phy_device *of_phy_connect(struct net_device *dev,
   ^

Re: [PATCH v11 3/4] add FPGA manager core

[Josh Cartwright]

On Wed, Sep 23, 2015 at 12:10:13PM -0500, atull wrote:
> On Tue, 22 Sep 2015, Josh Cartwright wrote:
[..]
> > > +struct fpga_manager *of_fpga_mgr_get(struct device_node *node)
> > > +{
> > > + struct fpga_manager *mgr;
> > > + struct device *dev;
> > > +
> > > + if (!node)
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + dev = class_find_device(fpga_mgr_class, NULL, node,
> > > + fpga_mgr_of_node_match);
> > > + if (!dev)
> > > + return ERR_PTR(-ENODEV);
> > > +
> > > + mgr = to_fpga_manager(dev);
> > > + put_device(dev);
> > 
> > Who's ensuring the FPGA manager device's lifetime between _get and _put?
> 
> Well... get_device and put_device are not sufficient?

Sorry if I was too opaque.

You've just put_device()'d the only reference to the device you had
here, so nothing is preventing from the device from being ripped away
while it's being used.

You should remove the put_device() call here, and add a corresponding
put_device() in fpga_mgr_put().

The module refcounting is also a bit strange, as you are
acquiring/releasing a reference to THIS_MODULE, but you also should care
about the lower-level driver's module refcount.

[..]
> > > + dt_label = of_get_property(mgr->dev.of_node, "label", NULL);
> > > + if (dt_label)
> > > + ret = dev_set_name(&mgr->dev, "%s", dt_label);
> > > + else
> > > + ret = dev_set_name(&mgr->dev, "fpga%d", id);
> > 
> > I'm wondering if an alias {} node is better for this.
> 
> I could look into that.  Is there an example of that you particularly
> like for this?

Look at i2c's usage of the of_alias_*() functions.

  Josh


signature.asc
Description: PGP signature

Re: [RESEND PATCHv3] arm64: dts: Add base stratix 10 dtsi

[Mark Rutland]

On Wed, Sep 23, 2015 at 11:43:25PM +0100, Dinh Nguyen wrote:
> On Wed, Sep 23, 2015 at 12:54 AM, Mark Rutland  wrote:
> >> +/ {
> >> + compatible = "altr,socfpga-stratix10";
> >> + #address-cells = <2>;
> >> + #size-cells = <2>;
> >
> > [...]
> >
> >> + soc {
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + compatible = "simple-bus";
> >> + device_type = "soc";
> >> + interrupt-parent = <&intc>;
> >
> > As far as I am aware, this requires a (non-empty) ranges property, given the
> > parent node has {address,size}-cells = <2>.
> >
> > Does the kernel not complain currently?
> >
> 
> I do not see any complaints without ranges here, but with ranges, I get:

I'm surprised (and a little worried) that we don't warn in the absence of
ranges when #{address,size}-cells changes. That doesn't feel right.

> DTC arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dtb
> Warning (ranges_format): /soc has empty "ranges" property but its
> #address-cells (1) differs from / (2)
> Warning (ranges_format): /soc has empty "ranges" property but its
> #size-cells (1) differs from / (2)

As I mentioned, the ranges proeprty should be non-empty.

Thanks,
Mark.
--
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: [RESEND PATCHv3] arm64: dts: Add base stratix 10 dtsi

[Dinh Nguyen]

On Wed, Sep 23, 2015 at 12:54 AM, Mark Rutland  wrote:
>> +/ {
>> + compatible = "altr,socfpga-stratix10";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>
> [...]
>
>> + soc {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "simple-bus";
>> + device_type = "soc";
>> + interrupt-parent = <&intc>;
>
> As far as I am aware, this requires a (non-empty) ranges property, given the
> parent node has {address,size}-cells = <2>.
>
> Does the kernel not complain currently?
>

I do not see any complaints without ranges here, but with ranges, I get:

DTC arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dtb
Warning (ranges_format): /soc has empty "ranges" property but its
#address-cells (1) differs from / (2)
Warning (ranges_format): /soc has empty "ranges" property but its
#size-cells (1) differs from / (2)

Dinh
--
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/2] ARM: socfpga: dts: enable USB and I2C on Arria10 SoCDK

[dinguyen]

From: Dinh Nguyen 

On the Arria10 Devkit, the I2C bus has a serial EEPROM and an RTC
hanging off it. Also, enable the USB node.

Signed-off-by: Dinh Nguyen 
---
 arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi 
b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
index 99aa9a1..567df98 100644
--- a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
@@ -70,6 +70,33 @@
status = "okay";
 };
 
+&i2c1 {
+   speed-mode = <0>;
+   status = "okay";
+
+   /*
+* adjust the falling times to decrease the i2c frequency to 50Khz
+* because the LCD module does not work at the standard 100Khz
+*/
+   i2c-sda-falling-time-ns = <6000>;
+   i2c-scl-falling-time-ns = <6000>;
+
+   eeprom@51 {
+   compatible = "atmel,24c32";
+   reg = <0x51>;
+   pagesize = <32>;
+   };
+
+   rtc@68 {
+   compatible = "dallas,ds1339";
+   reg = <0x68>;
+   };
+};
+
 &uart1 {
status = "okay";
 };
+
+&usb0 {
+   status = "okay";
+};
-- 
2.4.5

--
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/2] ARM: socfpga: dts: add clock fields for I2C, UART and USB on Arria10

[dinguyen]

From: Dinh Nguyen 

Add the required clock fields for all the I2C nodes. Also add missing clock
fields for UART0 and USB1.

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

diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi 
b/arch/arm/boot/dts/socfpga_arria10.dtsi
index 2340fcb..cce9e50 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -519,6 +519,7 @@
compatible = "snps,designware-i2c";
reg = <0xffc02200 0x100>;
interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&l4_sp_clk>;
status = "disabled";
};
 
@@ -528,6 +529,7 @@
compatible = "snps,designware-i2c";
reg = <0xffc02300 0x100>;
interrupts = <0 106 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&l4_sp_clk>;
status = "disabled";
};
 
@@ -537,6 +539,7 @@
compatible = "snps,designware-i2c";
reg = <0xffc02400 0x100>;
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&l4_sp_clk>;
status = "disabled";
};
 
@@ -546,6 +549,7 @@
compatible = "snps,designware-i2c";
reg = <0xffc02500 0x100>;
interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&l4_sp_clk>;
status = "disabled";
};
 
@@ -555,6 +559,7 @@
compatible = "snps,designware-i2c";
reg = <0xffc02600 0x100>;
interrupts = <0 109 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&l4_sp_clk>;
status = "disabled";
};
 
@@ -658,6 +663,7 @@
interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
+   clocks = <&l4_sp_clk>;
status = "disabled";
};
 
@@ -692,6 +698,8 @@
compatible = "snps,dwc2";
reg = <0xffb4 0x>;
interrupts = <0 96 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&usb_clk>;
+   clock-names = "otg";
phys = <&usbphy0>;
phy-names = "usb2-phy";
status = "disabled";
-- 
2.4.5

--
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/2] mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan

[Ulf Hansson]

On 17 September 2015 at 17:20, Shawn Lin  wrote:
> On 2015/9/17 19:44, Ulf Hansson wrote:
>>
>> On 14 September 2015 at 08:29, Shawn Lin  wrote:
>>>
>>> This patch adds Generic PHY access for sdhci-of-arasan. Driver
>>> can get PHY handler from dt-binding, and power-on/init the PHY.
>>> Also we add pm ops for PHY here if CONFIG_PM_SLEEP is enabled.
>>> Currently, it's just mandatory for arasan,sdhci-5.1.
>>
>>
>> I am trying to understand how a PHY can be used together with a
>> MMC/SD/SDIO controller. Normally the card connector doesn't hold any
>> intelligence, so I wonder if PHY is correctly used here.
>>
>> Could you try to explain, HW-wise, what role the PHY has for you?
>>
>
> Thanks for comment, Ulf.
>
> It's the first time we introduce phy into mmc subsystem,also it's my first
> time to use phy for emmc in real Soc.
> so definitely we need to discuss it deliberately.
>
> From my view, phy is an active-power, differential sampling and more
> well-designed analog *IO component* for ultra-highspeed device to guarantee
> its signal integrity, like USB, UFS, DDR-RAM,MIPI and so on.
>
> (1)Firstly it contains DLL to generate delayline and phase for sampling data
> from mmc devices. When sdhci controller executes tuning and sends out tuning
> sequence, and PHY can auto change its delayline and phase
> in order to test if this "sample timing" is okay. If not, CRC err is
> generate back to the controller. Then after SDHCI tune timing for 40 times,
> also PHY have scanned all the "sample windows" by trying different delayline
> and phase combination, and finally auto-select the best sample timing for
> the "sample windows". And sdhci HOST CONTROL
> 2 Register[6:7] is controlled by PHY in my case.
>
> (2)Then phy can programming source/sink impedance to avoid signal reflex.
> Given that JEDEC has come to HS533(highspeed 533MHz), this function is
> imperative to be implemented just like the role of ODT for DDR-RAM's PHY.
>
> (3)Phy is integrated with diff pull-up/down resistance value and open-drain
> type for HW design.
>
> (4)Phy can also have some enable-bit to decide whether all mmc
> signal(clk/data/cmd/strobe) can output to the devices or not.

Thanks for elaborating. It seems like using phy is justified in your case.

>
>
> For the card, even for host controller itself, phy can just be regarded as a
> need-to-do-something-before-used GPIO.
> So, before we start initializing card, we need to power up PHY, enable clk
> for it and configure all the stuffs. Also we need to power down it for
> power-saving when into suspend. That's all we need to do and that's all the
> generic phy framework had provided by four interface:
> phy_init/phy_exit/phy_power_on/phy_power_off.
>
>
> Sincerely welcome any comments here to make things better. :)
>
>

I will get back to your patch and review it in detail as soon as can.

Kind regards
Uffe
--
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/9] ARM: dts: Move all Cygnus peripherals into soc bus

[Ray Jui]

On 9/23/2015 2:29 PM, Arnd Bergmann wrote:
> On Friday 18 September 2015 15:11:27 Ray Jui wrote:
>> On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
>>> On Friday 18 September 2015 14:24:10 Ray Jui wrote:
 +   soc {
 +   compatible = "simple-bus";
 +   ranges;
 +   #address-cells = <1>;
 +   #size-cells = <1>;
>>>
 +   pinctrl: pinctrl@0301d0c8 {

>>>
>>> Similarly to the core bus, this seems to have address ranges 0x03xx and
>>> 0x18xx on it, so put those into the ranges.
>>>
>>
>> Okay we have an issue here. For whatever reason, the Cygnus ASIC team
>> decided to put registers for the same block in random locations. We see
>> similar issues in all of our other iProc based SoCs. We have
>> communicated this to our ASIC team, and hopefully they can revert the
>> trend for the next SoC.
>>
>> For example, the gpio_ccm has registers in the following regions:
>>
>> gpio_ccm: gpio@1800a000 {
>> compatible = "brcm,cygnus-ccm-gpio";
>> reg = <0x1800a000 0x50>,
>>   <0x0301d164 0x20>;
>>
>> NAND is worse, it has registers in 3 different separate regions:
>>
>> nand: nand@18046000 {
>> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
>>  "brcm,brcmnand";
>> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
>>   <0x18046f00 0x20>;
>>
>> As you can see, this makes it impossible to define a proper address
>> range for the bus; therefore, I'll have to keep the ranges undefined and
>> a simple 1:1 mapping under this bus.
> 
> Hmm, you could still try to list them as non-overlapping with other
> buses on the root node like
> 
>   ranges = <0x0300 0x0300 0x0100>,
><0x1800 0x1800 0x0100>,
><0xf800 0xf800 0x0100>;
> 
> which clarifies how the bus is wired up in hardware.
> 
> Alternatively, you could make a more elaborate mapping, if there
> are in fact multiple hardware ranges, like
> 
>   #address-cells = <2>; # space:offset
>   ranges = <1 0  0x0300 0x0100>,
><2 0  0x1800 0x0100>,
><3 0  0xf800 0x0100>;
> 
> It really depends on what the hardware designers were thinking. If
> the AXI bus actually decodes the entire 32-bit address range and devices
> are just located at random addresses in there, your current scheme is
> probably closest to reality.
> 

I see. Let me talk to our ASIC team to get this clarified. If in the end
the AXI bus decodes the entire 32-bit address space, no change will be
made. Otherwise, I'll submit another patch to list the actual address
space that the AXI bus decodes.

Thanks for the review. It's very helpful!

Ray
--
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/9] ARM: dts: consolidate aliases for Cygnus dt files

[Florian Fainelli]

On 23/09/15 14:46, Ray Jui wrote:
> 
> 
> On 9/23/2015 2:31 PM, Arnd Bergmann wrote:
>> On Friday 18 September 2015 14:44:54 Ray Jui wrote:
>>> On 9/18/2015 2:27 PM, Arnd Bergmann wrote:
 On Friday 18 September 2015 14:24:06 Ray Jui wrote:

 The SoC has at least four uarts according to this, so it seems unlikely 
 that
 each board really only uses only the fourth one of them and labels it '0'
 on the board. As soon as you get one board that has more than one uart 
 wired
 up, you would need to undo this.

>>>
>>> I think Scott might have explained this in the past. uart3 is going to
>>> be used on all Cygnus boards (including all future boards) because the
>>> bootrom was designed to use uart3 as console and that won't change.
>>>
>>> Let me know if you still think I need to move this back to the dts.
>>
>> I would still like to see them stay in the .dts file, if only for
>> consistency with other platforms. 
>>
>> Also, even if you can guarantee that uart3 is always used for the
>> console, that doesn't prevent board designers from adding more than
>> one uart, right?
>>
>>  Arnd
>>
> 
> Okay. Given that this patch series has been merged by Florian, I'll
> submit another patch to move it back to .dts files.

You could send me either a replacement patch series (all 9), or an
individual patch to replace a previous version (e.g; replace v2 with a
v3), or an incremental one, whatever works for you.

Thanks!
-- 
Florian
--
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/9] ARM: dts: consolidate aliases for Cygnus dt files

[Ray Jui]

On 9/23/2015 2:31 PM, Arnd Bergmann wrote:
> On Friday 18 September 2015 14:44:54 Ray Jui wrote:
>> On 9/18/2015 2:27 PM, Arnd Bergmann wrote:
>>> On Friday 18 September 2015 14:24:06 Ray Jui wrote:
>>>
>>> The SoC has at least four uarts according to this, so it seems unlikely that
>>> each board really only uses only the fourth one of them and labels it '0'
>>> on the board. As soon as you get one board that has more than one uart wired
>>> up, you would need to undo this.
>>>
>>
>> I think Scott might have explained this in the past. uart3 is going to
>> be used on all Cygnus boards (including all future boards) because the
>> bootrom was designed to use uart3 as console and that won't change.
>>
>> Let me know if you still think I need to move this back to the dts.
> 
> I would still like to see them stay in the .dts file, if only for
> consistency with other platforms. 
> 
> Also, even if you can guarantee that uart3 is always used for the
> console, that doesn't prevent board designers from adding more than
> one uart, right?
> 
>   Arnd
> 

Okay. Given that this patch series has been merged by Florian, I'll
submit another patch to move it back to .dts files.

Thanks,

Ray
--
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: [RESEND PATCHv3] arm64: dts: Add base stratix 10 dtsi

[Mark Rutland]

> +/ {
> + compatible = "altr,socfpga-stratix10";
> + #address-cells = <2>;
> + #size-cells = <2>;

[...]

> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + device_type = "soc";
> + interrupt-parent = <&intc>;

As far as I am aware, this requires a (non-empty) ranges property, given the
parent node has {address,size}-cells = <2>.

Does the kernel not complain currently?

Otherwise this looks OK to me. Please fix the rangers property and ask for this
to be taken via arm-soc. I note neither Arnd nor Olof are on Cc currently.

Thanks,
Mark.
--
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/9] ARM: dts: consolidate aliases for Cygnus dt files

[Arnd Bergmann]

On Friday 18 September 2015 14:44:54 Ray Jui wrote:
> On 9/18/2015 2:27 PM, Arnd Bergmann wrote:
> > On Friday 18 September 2015 14:24:06 Ray Jui wrote:
> > 
> > The SoC has at least four uarts according to this, so it seems unlikely that
> > each board really only uses only the fourth one of them and labels it '0'
> > on the board. As soon as you get one board that has more than one uart wired
> > up, you would need to undo this.
> > 
> 
> I think Scott might have explained this in the past. uart3 is going to
> be used on all Cygnus boards (including all future boards) because the
> bootrom was designed to use uart3 as console and that won't change.
> 
> Let me know if you still think I need to move this back to the dts.

I would still like to see them stay in the .dts file, if only for
consistency with other platforms. 

Also, even if you can guarantee that uart3 is always used for the
console, that doesn't prevent board designers from adding more than
one uart, right?

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 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

[Arnd Bergmann]

On Friday 18 September 2015 15:11:27 Ray Jui wrote:
> On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
> > On Friday 18 September 2015 14:24:10 Ray Jui wrote:
> >> +   soc {
> >> +   compatible = "simple-bus";
> >> +   ranges;
> >> +   #address-cells = <1>;
> >> +   #size-cells = <1>;
> > 
> >> +   pinctrl: pinctrl@0301d0c8 {
> >>
> > 
> > Similarly to the core bus, this seems to have address ranges 0x03xx and
> > 0x18xx on it, so put those into the ranges.
> >
> 
> Okay we have an issue here. For whatever reason, the Cygnus ASIC team
> decided to put registers for the same block in random locations. We see
> similar issues in all of our other iProc based SoCs. We have
> communicated this to our ASIC team, and hopefully they can revert the
> trend for the next SoC.
> 
> For example, the gpio_ccm has registers in the following regions:
> 
> gpio_ccm: gpio@1800a000 {
> compatible = "brcm,cygnus-ccm-gpio";
> reg = <0x1800a000 0x50>,
>   <0x0301d164 0x20>;
> 
> NAND is worse, it has registers in 3 different separate regions:
> 
> nand: nand@18046000 {
> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
>  "brcm,brcmnand";
> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
>   <0x18046f00 0x20>;
> 
> As you can see, this makes it impossible to define a proper address
> range for the bus; therefore, I'll have to keep the ranges undefined and
> a simple 1:1 mapping under this bus.

Hmm, you could still try to list them as non-overlapping with other
buses on the root node like

ranges = <0x0300 0x0300 0x0100>,
 <0x1800 0x1800 0x0100>,
 <0xf800 0xf800 0x0100>;

which clarifies how the bus is wired up in hardware.

Alternatively, you could make a more elaborate mapping, if there
are in fact multiple hardware ranges, like

#address-cells = <2>; # space:offset
ranges = <1 0  0x0300 0x0100>,
 <2 0  0x1800 0x0100>,
 <3 0  0xf800 0x0100>;

It really depends on what the hardware designers were thinking. If
the AXI bus actually decodes the entire 32-bit address range and devices
are just located at random addresses in there, your current scheme is
probably closest to reality.

> > It probably also makes sense to name the bus according to what kind of
> > bus (axi, ahb, plb, ...) is used here. If the soc has nested buses
> > (e.g. an ahb connected to an axi bus,) then model both of them in the DT.
> 
> Based on the block diagram from the ASIC team, it looks like all of them
> are connected to one major AXI fabric. I can rename the bus to AXI.

Ok.

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 4/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Arnd Bergmann]

On Wednesday 23 September 2015 21:39:27 Arnd Bergmann wrote:
> On Wednesday 23 September 2015 20:35:45 Will Deacon wrote:
> > 
> > From what Lorenzo was saying, ACPI shares the interpretation that David is
> > implementing here and, given that the DT version seems to be subjective,
> > aligning this reg property with MMCFG seems to make sense.
> 
> We should then make it very clear in the binding that the driver
> is not allowed to actually map the registers for the buses outside
> of the bus-range, as that is highly unusual.

One more point here: I think ACPI does something different here,
it lists the base address of mmconfig space of the the PCI domain
that the host bridge belongs to. In contrast, in DT the 'reg'
property is defined as the registers belonging to the host bridge
itself, and the DT does not say anything about domains at all
(aside from the linux,pci-domain property that is not mandatory
and a Linux-specific extension).

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 v5 05/11] power: bq24257: Add SW-based approach for Power Good determination

[Andreas Dannenberg]

On Wed, Sep 23, 2015 at 02:34:27PM -0500, Andreas Dannenberg wrote:
> On Tue, Sep 22, 2015 at 09:37:20PM +0200, Sebastian Reichel wrote:
> > 
> > I guess you can just handle this like an optional gpio
> > 
> > if(bq->pg)
> > state->power_good = !gpiod_get_value_cansleep(bq->pg);
> > else
> > ...
> 
> What happens when somebody wants to use GPIO number 0? According to
> gpio_is_valid() this is a valid GPIO so technically I should not use a
> check against zero to see whether the user has configured a GPIO for
> this purpose and wants to use it, no?

Ok never mind I figured it out. bq->pg is of type gpio_desc and not the
actual GPIO number. Together with your suggestion of how to use gpiod_*
in combination with platform data this will be a nice simplification!

Regards,

--
Andreas Dannenberg
Texas Instruments Inc

--
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 09/11] power: bq24257: Allow input current limit sysfs access

[Andreas Dannenberg]

On Wed, Sep 23, 2015 at 08:53:59PM +0200, Sebastian Reichel wrote:
> Hi,
> 
> On Wed, Sep 23, 2015 at 01:32:58PM -0500, Andreas Dannenberg wrote:
> > On Wed, Sep 23, 2015 at 05:02:28PM +0200, Sebastian Reichel wrote:
> > > On Wed, Sep 23, 2015 at 09:11:46AM -0500, Andreas Dannenberg wrote:
> > > > Ok. So how should we best go about extending the usage of the
> > > > 'input_current_limit' sysfs node for this charger? You mentioned
> > > > writing 'auto' into it should enable the auto-detection mode. I suppose
> > > > writing a fixed current value will disable it. But how to indicate to
> > > > the user when reading 'input_current_limit' whether auto mode is enabled
> > > > or not (I think this is something we should do).
> > > 
> > > Right, I haven't thought of this.
> > > 
> > > > Can we return a mixed number/string like this?
> > > > 
> > > > # Example: charger auto detection mode is disabled, and input current
> > > > # limit is configured as 500mA.
> > > > 
> > > > $ cat input_current_limit
> > > > 50
> > > > 
> > > > # Example: charger auto detection mode is enabled, and a charger
> > > > # supporting 1A was detected (note the mixed number/string thats
> > > > # returned)
> > > > 
> > > > $ cat input_current_limit
> > > > 100 (auto)
> > > > 
> > > > Would that work?
> > > 
> > > No. sysfs nodes should only contain one value per file.
> > > 
> > > > Or should we introduce a new sysfs property?
> > > 
> > > So maybe keep this patch as is (disallow setting the limit in auto
> > > mode) and create another file for setting (and getting) the mode.
> > 
> > Thanks for the continued feedback. Will look into this and add a new
> > property.
> >  
> > > Also it might be a good idea to return to safe defaults when the
> > > charger is disconnected (-> reset to DT specified values).
> > 
> > It already does this when the charger type auto-detection is enabled.
> > When configured for manually setting the input current limit the use
> > case is a bit more complex and I do not recommend resetting the limit to
> > 500mA. Let me explain why:
> >
> > 1) Using USB chargers is only one of the ways the bq2525x devices can be
> > used in a system. Imagine a shipping product that comes with its own
> > proprietary wall power (or built-in) supply that let's say cranks out
> > 2A.  As a vendor you want to configure your system (meaning, the bq2425x
> > via DT) to a fixed value of 2A. The user un-plugging and re-plugging the
> > power supply should not arbitrarily change that pre-configured limit
> 
> I did not write, that it should reset to 500mA, but that it should
> reset to DT specified values. So e.g. if the device is confiured to
> be in auto mode in DT, then configured to use fixed 1000mA, then it
> should return to auto mode on unplug. OTOH if DT specifies 500mA
> fixed and user sets 1000mA, then it should return to 500mA fixes.
> So re-plugging returns to pre-configured limits.

Ok yes considering the default being the DT value what you originally
wrote that makes more sense now. My mind was buried in the code :)

> > 2) Even in case of USB chargers, userspace could detect the power
> > un-plug event, and re-configure the limit to something else.  So I think
> > it's really policy that should not be implemented in the Kernel driver.
> 
> I think it should be done exactly the opposite way. Userspace should
> set the custom value again. My main motivation is, that DT values
> should be safe for all attachable power supplies, while the user
> supplied value may only be safe with the currently connected power
> supply.

I don't think there is really a right or wrong here but I do see your
point. It's a workable and safe solution. Will implement accordingly.

Regards,

--
Andreas Dannenberg
Texas Instruments Inc
--
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/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Will Deacon]

On Wed, Sep 23, 2015 at 08:39:27PM +0100, Arnd Bergmann wrote:
> On Wednesday 23 September 2015 20:35:45 Will Deacon wrote:
> > On Wed, Sep 23, 2015 at 08:27:41PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 23 September 2015 11:21:56 David Daney wrote:
> > > > >>
> > > > >>  /* Limit the bus-range to fit within reg */
> > > > >> -bus_max = pci->cfg.bus_range->start +
> > > > >> -  (resource_size(&pci->cfg.res) >> 
> > > > >> pci->cfg.ops.bus_shift) - 1;
> > > > >> +bus_max = (resource_size(&pci->cfg.res) >> 
> > > > >> pci->cfg.ops.bus_shift) - 1;
> > > > >> +if (bus_max > 255)
> > > > >> +bus_max = 255;
> > > > >
> > > > > I still don't understand the need for this part. If the cfg space is 
> > > > > bigger
> > > > > than bus_max, isn't that simply an invalid resource? Given that the 
> > > > > resource
> > > > > could be broken in other ways too, this check feels more like a 
> > > > > specific
> > > > > workaround rather than generally useful code.
> > > > 
> > > > Imagine...
> > > > 
> > > >bus-range [0x80 .. 0xff], this requires a cfg.res that will cover 
> > > > the 
> > > > entire range of 0..0xff.
> > > > 
> > > >according to the calculations above, (resource_size(&pci->cfg.res) 
> > > > >> 
> > > > pci->cfg.ops.bus_shift) - 1 will have a value of 0xff, so...
> > > 
> > > Extending the computation to 32 bit seems fine, but I'd rather warn loudly
> > > if the bus range does not fit within the registers.
> > > 
> > > Also note that the computation is already correct with my interpretation
> > > of the reg property.
> > 
> > From what Lorenzo was saying, ACPI shares the interpretation that David is
> > implementing here and, given that the DT version seems to be subjective,
> > aligning this reg property with MMCFG seems to make sense.
> 
> We should then make it very clear in the binding that the driver
> is not allowed to actually map the registers for the buses outside
> of the bus-range, as that is highly unusual.
> 
> We would also need a special exception for this if we ever get to
> implement the DT source checker that we have been talking about for
> years, as the reg property might then overlap with a property from
> another device.

Completely agreed. Having a base that isn't actually safe to map is horrible
and should be called out.

Will
--
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/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Arnd Bergmann]

On Wednesday 23 September 2015 20:35:45 Will Deacon wrote:
> On Wed, Sep 23, 2015 at 08:27:41PM +0100, Arnd Bergmann wrote:
> > On Wednesday 23 September 2015 11:21:56 David Daney wrote:
> > > >>
> > > >>  /* Limit the bus-range to fit within reg */
> > > >> -bus_max = pci->cfg.bus_range->start +
> > > >> -  (resource_size(&pci->cfg.res) >> 
> > > >> pci->cfg.ops.bus_shift) - 1;
> > > >> +bus_max = (resource_size(&pci->cfg.res) >> 
> > > >> pci->cfg.ops.bus_shift) - 1;
> > > >> +if (bus_max > 255)
> > > >> +bus_max = 255;
> > > >
> > > > I still don't understand the need for this part. If the cfg space is 
> > > > bigger
> > > > than bus_max, isn't that simply an invalid resource? Given that the 
> > > > resource
> > > > could be broken in other ways too, this check feels more like a specific
> > > > workaround rather than generally useful code.
> > > 
> > > Imagine...
> > > 
> > >bus-range [0x80 .. 0xff], this requires a cfg.res that will cover the 
> > > entire range of 0..0xff.
> > > 
> > >according to the calculations above, (resource_size(&pci->cfg.res) >> 
> > > pci->cfg.ops.bus_shift) - 1 will have a value of 0xff, so...
> > 
> > Extending the computation to 32 bit seems fine, but I'd rather warn loudly
> > if the bus range does not fit within the registers.
> > 
> > Also note that the computation is already correct with my interpretation
> > of the reg property.
> 
> From what Lorenzo was saying, ACPI shares the interpretation that David is
> implementing here and, given that the DT version seems to be subjective,
> aligning this reg property with MMCFG seems to make sense.

We should then make it very clear in the binding that the driver
is not allowed to actually map the registers for the buses outside
of the bus-range, as that is highly unusual.

We would also need a special exception for this if we ever get to
implement the DT source checker that we have been talking about for
years, as the reg property might then overlap with a property from
another device.

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

[PATCH 1/3] ARM: dts: stih407: Enable PWM nodes only board level

[Maxime Coquelin]

The PWM may not be used on some boards, so enable them only the board file.

Signed-off-by: Maxime Coquelin 
---
 arch/arm/boot/dts/stih407-family.dtsi | 6 --
 arch/arm/boot/dts/stihxxx-b2120.dtsi  | 8 
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index ae05277..9975e8f 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -585,7 +585,6 @@
/* COMMS PWM Module */
pwm0: pwm@981 {
compatible  = "st,sti-pwm";
-   status  = "okay";
#pwm-cells  = <2>;
reg = <0x981 0x68>;
pinctrl-names   = "default";
@@ -593,12 +592,13 @@
clock-names = "pwm";
clocks  = <&clk_sysin>;
st,pwm-num-chan = <1>;
+
+   status  = "disabled";
};
 
/* SBC PWM Module */
pwm1: pwm@951 {
compatible  = "st,sti-pwm";
-   status  = "okay";
#pwm-cells  = <2>;
reg = <0x951 0x68>;
pinctrl-names   = "default";
@@ -609,6 +609,8 @@
clock-names = "pwm";
clocks  = <&clk_sysin>;
st,pwm-num-chan = <4>;
+
+   status  = "disabled";
};
};
 };
diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi 
b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index f589fe4..ab029f7 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -27,6 +27,14 @@
};
};
 
+   pwm0: pwm@981 {
+   status = "okay";
+   };
+
+   pwm1: pwm@951 {
+   status = "okay";
+   };
+
i2c@9842000 {
status = "okay";
};
-- 
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 2/3] ARM: dts: stih407/410: Tidy up display nodes

[Maxime Coquelin]

The display nodes are common to both STiH407 and STiH410, move them to the
family file.

Signed-off-by: Maxime Coquelin 
---
 arch/arm/boot/dts/stih407-family.dtsi | 13 +
 arch/arm/boot/dts/stih407.dtsi| 13 -
 arch/arm/boot/dts/stih410.dtsi| 13 -
 3 files changed, 13 insertions(+), 26 deletions(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index 9975e8f..5b454d9 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -152,6 +152,19 @@
;
};
 
+   /* Display */
+   vtg_main: sti-vtg-main@8d02800 {
+   compatible = "st,vtg";
+   reg = <0x8d02800 0x200>;
+   interrupts = ;
+   };
+
+   vtg_aux: sti-vtg-aux@8d00200 {
+   compatible = "st,vtg";
+   reg = <0x8d00200 0x100>;
+   interrupts = ;
+   };
+
serial@983 {
compatible = "st,asc";
reg = <0x983 0x2c>;
diff --git a/arch/arm/boot/dts/stih407.dtsi b/arch/arm/boot/dts/stih407.dtsi
index 3efa3b2..98c3468 100644
--- a/arch/arm/boot/dts/stih407.dtsi
+++ b/arch/arm/boot/dts/stih407.dtsi
@@ -10,19 +10,6 @@
 #include "stih407-family.dtsi"
 / {
soc {
-   /* Display */
-   vtg_main: sti-vtg-main@8d02800 {
-   compatible = "st,vtg";
-   reg = <0x8d02800 0x200>;
-   interrupts = ;
-   };
-
-   vtg_aux: sti-vtg-aux@8d00200 {
-   compatible = "st,vtg";
-   reg = <0x8d00200 0x100>;
-   interrupts = ;
-   };
-
sti-display-subsystem {
compatible = "st,sti-display-subsystem";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index 6f40bc9..23f4a48 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -85,19 +85,6 @@
phy-names = "usb";
};
 
-   /* Display */
-   vtg_main: sti-vtg-main@8d02800 {
-   compatible = "st,vtg";
-   reg = <0x8d02800 0x200>;
-   interrupts = ;
-   };
-
-   vtg_aux: sti-vtg-aux@8d00200 {
-   compatible = "st,vtg";
-   reg = <0x8d00200 0x100>;
-   interrupts = ;
-   };
-
sti-display-subsystem {
compatible = "st,sti-display-subsystem";
#address-cells = <1>;
-- 
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 3/3] ARM: dts: stih410: Enable USB2.0 and related PHY nodes at board level

[Maxime Coquelin]

A borad might not expose the USB2.0 ports, so disable them by default in SoC
file, and enable them in b2120 board.

Signed-off-by: Maxime Coquelin 
---
 arch/arm/boot/dts/stih410-b2120.dts | 24 
 arch/arm/boot/dts/stih410.dtsi  | 12 
 2 files changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/stih410-b2120.dts 
b/arch/arm/boot/dts/stih410-b2120.dts
index 16f02c5..8af1e73 100644
--- a/arch/arm/boot/dts/stih410-b2120.dts
+++ b/arch/arm/boot/dts/stih410-b2120.dts
@@ -35,5 +35,29 @@
sd-uhs-sdr104;
sd-uhs-ddr50;
};
+
+   usb2_picophy1: phy2 {
+   status = "okay";
+   };
+
+   usb2_picophy2: phy3 {
+   status = "okay";
+   };
+
+   ohci0: usb@9a03c00 {
+   status = "okay";
+   };
+
+   ehci0: usb@9a03e00 {
+   status = "okay";
+   };
+
+   ohci1: usb@9a83c00 {
+   status = "okay";
+   };
+
+   ehci1: usb@9a83e00 {
+   status = "okay";
+   };
};
 };
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index 23f4a48..e3150e3 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -22,6 +22,8 @@
resets = <&softreset STIH407_PICOPHY_SOFTRESET>,
 <&picophyreset STIH407_PICOPHY0_RESET>;
reset-names = "global", "port";
+
+   status = "disabled";
};
 
usb2_picophy2: phy3 {
@@ -31,6 +33,8 @@
resets = <&softreset STIH407_PICOPHY_SOFTRESET>,
 <&picophyreset STIH407_PICOPHY1_RESET>;
reset-names = "global", "port";
+
+   status = "disabled";
};
 
ohci0: usb@9a03c00 {
@@ -43,6 +47,8 @@
reset-names = "power", "softreset";
phys = <&usb2_picophy1>;
phy-names = "usb";
+
+   status = "disabled";
};
 
ehci0: usb@9a03e00 {
@@ -57,6 +63,8 @@
reset-names = "power", "softreset";
phys = <&usb2_picophy1>;
phy-names = "usb";
+
+   status = "disabled";
};
 
ohci1: usb@9a83c00 {
@@ -69,6 +77,8 @@
reset-names = "power", "softreset";
phys = <&usb2_picophy2>;
phy-names = "usb";
+
+   status = "disabled";
};
 
ehci1: usb@9a83e00 {
@@ -83,6 +93,8 @@
reset-names = "power", "softreset";
phys = <&usb2_picophy2>;
phy-names = "usb";
+
+   status = "disabled";
};
 
sti-display-subsystem {
-- 
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 0/3] ARM: dts: Various STi DT clean-ups

[Maxime Coquelin]

This series cleans the STi407 family DTs, by factorizing common nodes between
STiH407 and STiH410, and also by only enabling PWM and USB nodes at board
level, as they could not be exposed on some boards.

Maxime Coquelin (3):
  ARM: dts: stih407: Enable PWM nodes only board level
  ARM: dts: stih407/410: Tidy up display nodes
  ARM: dts: stih410: Enable USB2.0 and related PHY nodes at board level

 arch/arm/boot/dts/stih407-family.dtsi | 19 +--
 arch/arm/boot/dts/stih407.dtsi| 13 -
 arch/arm/boot/dts/stih410-b2120.dts   | 24 
 arch/arm/boot/dts/stih410.dtsi| 23 +++
 arch/arm/boot/dts/stihxxx-b2120.dtsi  |  8 
 5 files changed, 60 insertions(+), 27 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

Re: [PATCH v3 4/6] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Arnd Bergmann]

On Wednesday 23 September 2015 08:50:45 David Daney wrote:
> On 09/23/2015 01:01 AM, Arnd Bergmann wrote:
> > On Tuesday 22 September 2015 16:49:15 David Daney wrote:
> >> From: David Daney 
> >> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt 
> >> b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> >> index cf3e205..105a968 100644
> >> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> >> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> >> @@ -34,7 +34,9 @@ Properties of the host controller node:
> >>   - #size-cells: Must be 2.
> >>
> >>   - reg: The Configuration Space base address and size, as 
> >> accessed
> >> -   from the parent bus.
> >> +   from the parent bus.  The base address corresponds to
> >> +   bus zero, even though the "bus-range" property may 
> >> specify
> >> +   a different starting bus number.
> >
> > This sounds like very unusual behavior. If you have a system with faked
> > bus numbers where the registers only physically exist for a subset of the
> > buses, this requires defining a reg property that contains MMIO space
> > which is outside of the device and potentially contains other devices.
> 
> The pci-host-generic driver only maps the ranges that correspond to the 
> "bus-range" buses, so mapping of illegal address ranges should not be a 
> problem.

There is still a problem with what the driver is allowed to map,
the current behavior is just an implementation detail that should
not mean the binding can rely on that.

We do the per-bus mapping because the vmalloc space on 32-bit systems
is very limited. A driver for a purely 64-bit OS could simplify this
by just mapping the entire 'reg' property as most drivers do, and
then use the device as an offset into that.

> > What would break if we instead defined it the expected way and only
> > list the registers for the bus numbers in the "bus-range" property?
> 
> I'm not sure if we have the luxury of being able to change the 
> definition, although the existing code only works with a starting bus 
> number of zero.  From this we might conclude that non-zero starting bus 
> numbers cannot exist in the wild, so changing the the definition of 
> "reg" so that it starts at the starting bus number might be possible.
>
> My reading of:
> 
> http://www.o3one.org/hwdocs/openfirmware/pci_supplement_2_1.pdf
> 
> Section 3.1.1, does not preclude your interpretation.  Although that is 
> for PCI-PCI bridges, and not this pci-host-generic root complex.
> 
> If we really want to go with a different definition of what the "reg" 
> property means, then actual code has to change, and we risk breaking 
> something.

My understanding is that the code has to change anyway in one place
or another. The change you did in this patch is not needed then, but
you say that something else has to change. Is this the only change
we'd need?

diff --git a/drivers/pci/host/pci-host-generic.c 
b/drivers/pci/host/pci-host-generic.c
index 265dd25169bf..d8a5c0047155 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -196,7 +196,7 @@ static int gen_pci_parse_map_cfg_windows(struct gen_pci 
*pci)
u32 sz = 1 << pci->cfg.ops->bus_shift;
 
pci->cfg.win[idx] = devm_ioremap(dev,
-pci->cfg.res.start + busn * sz,
+pci->cfg.res.start + idx * sz,
 sz);
if (!pci->cfg.win[idx])
return -ENOMEM;

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 4/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Will Deacon]

On Wed, Sep 23, 2015 at 08:27:41PM +0100, Arnd Bergmann wrote:
> On Wednesday 23 September 2015 11:21:56 David Daney wrote:
> > >>
> > >>  /* Limit the bus-range to fit within reg */
> > >> -bus_max = pci->cfg.bus_range->start +
> > >> -  (resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) 
> > >> - 1;
> > >> +bus_max = (resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) 
> > >> - 1;
> > >> +if (bus_max > 255)
> > >> +bus_max = 255;
> > >
> > > I still don't understand the need for this part. If the cfg space is 
> > > bigger
> > > than bus_max, isn't that simply an invalid resource? Given that the 
> > > resource
> > > could be broken in other ways too, this check feels more like a specific
> > > workaround rather than generally useful code.
> > 
> > Imagine...
> > 
> >bus-range [0x80 .. 0xff], this requires a cfg.res that will cover the 
> > entire range of 0..0xff.
> > 
> >according to the calculations above, (resource_size(&pci->cfg.res) >> 
> > pci->cfg.ops.bus_shift) - 1 will have a value of 0xff, so...
> 
> Extending the computation to 32 bit seems fine, but I'd rather warn loudly
> if the bus range does not fit within the registers.
> 
> Also note that the computation is already correct with my interpretation
> of the reg property.

>From what Lorenzo was saying, ACPI shares the interpretation that David is
implementing here and, given that the DT version seems to be subjective,
aligning this reg property with MMCFG seems to make sense.

Will
--
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 05/11] power: bq24257: Add SW-based approach for Power Good determination

[Andreas Dannenberg]

On Tue, Sep 22, 2015 at 09:37:20PM +0200, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Sep 18, 2015 at 04:39:53PM -0500, Andreas Dannenberg wrote:
> > -   state->power_good = !gpiod_get_value_cansleep(bq->pg);
> > +   if (bq->pg_gpio_disable)
> > +   /*
> > +* If we have a chip without a dedicated power-good GPIO or
> > +* some other explicit bit that would provide this information
> > +* assume the power is good if there is no supply related
> > +* fault - and not good otherwise. There is a possibility for
> > +* other errors to mask that power in fact is not good but this
> > +* is probably the best we can do here.
> > +*/
> > +   switch (state->fault) {
> > +   case FAULT_INPUT_OVP:
> > +   case FAULT_INPUT_UVLO:
> > +   case FAULT_INPUT_LDO_LOW:
> > +   state->power_good = false;
> > +   break;
> > +   default:
> > +   state->power_good = true;
> > +   }
> > +   else
> > +   state->power_good = !gpiod_get_value_cansleep(bq->pg);
> 
> I guess you can just handle this like an optional gpio
> 
> if(bq->pg)
> state->power_good = !gpiod_get_value_cansleep(bq->pg);
> else
> ...

What happens when somebody wants to use GPIO number 0? According to
gpio_is_valid() this is a valid GPIO so technically I should not use a
check against zero to see whether the user has configured a GPIO for
this purpose and wants to use it, no?

Regards,

--
Andreas Dannenberg
Texas Instruments Inc
--
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/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Will Deacon]

On Wed, Sep 23, 2015 at 07:21:56PM +0100, David Daney wrote:
> On 09/23/2015 11:01 AM, Will Deacon wrote:
> > On Thu, Sep 17, 2015 at 11:02:11PM +0100, David Daney wrote:
> [...]
> >
> >>   Properties of the /chosen node:
> >> diff --git a/drivers/pci/host/pci-host-generic.c 
> >> b/drivers/pci/host/pci-host-generic.c
> >> index 77cf4bd..0a9c453 100644
> >> --- a/drivers/pci/host/pci-host-generic.c
> >> +++ b/drivers/pci/host/pci-host-generic.c
> >> @@ -164,7 +164,7 @@ out_release_res:
> >>   static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
> >>   {
> >>int err;
> >> -  u8 bus_max;
> >> +  int bus_max;
> >>resource_size_t busn;
> >>struct resource *bus_range;
> >>struct device *dev = pci->host.dev.parent;
> >> @@ -177,8 +177,9 @@ static int gen_pci_parse_map_cfg_windows(struct 
> >> gen_pci *pci)
> >>}
> >>
> >>/* Limit the bus-range to fit within reg */
> >> -  bus_max = pci->cfg.bus_range->start +
> >> -(resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) - 1;
> >> +  bus_max = (resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) - 1;
> >> +  if (bus_max > 255)
> >> +  bus_max = 255;
> >
> > I still don't understand the need for this part. If the cfg space is bigger
> > than bus_max, isn't that simply an invalid resource? Given that the resource
> > could be broken in other ways too, this check feels more like a specific
> > workaround rather than generally useful code.
> 
> Imagine...
> 
>bus-range [0x80 .. 0xff], this requires a cfg.res that will cover the 
> entire range of 0..0xff.
> 
>according to the calculations above, (resource_size(&pci->cfg.res) >> 
> pci->cfg.ops.bus_shift) - 1 will have a value of 0xff, so...
> 
>bus_max = 0x80 + 0xff -> OVERFLOW of u8!
> 
> That is not useful.  bus_max should represent the largest bus number 
> that can be covered by cfg.res.  That is what my patch is attempting to 
> accomplish.  Calculate the largest bus number that can be accommodated 
> by cfg.res, and then clamp it to 0xff.

Sorry, I should've been more specific. The only part I don't like is the
'if (bus_max > 255)' check.

Will
--
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: [RESEND PATCHv3] arm64: dts: Add base stratix 10 dtsi

[Dinh Nguyen]

On Tue, Sep 15, 2015 at 4:47 PM,   wrote:
> From: Dinh Nguyen 
>
> Add the base DTS for Altera's SoCFPGA Stratix 10 platform.
>
> Signed-off-by: Dinh Nguyen 
> ---
> v3: change #address-cells and #size-cells to <2>
> change the GIC address to 0xfffc1000
> update the GIC virtual CPU reg length to 0x2000
> v2: use interrupt-affinity for pmu node
> ---
>  arch/arm64/Kconfig.platforms   |   5 +
>  arch/arm64/boot/dts/Makefile   |   1 +
>  arch/arm64/boot/dts/altera/Makefile|   5 +
>  arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi  | 357 
> +
>  .../boot/dts/altera/socfpga_stratix10_socdk.dts|  39 +++
>  arch/arm64/configs/defconfig   |   1 +
>  6 files changed, 408 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/altera/Makefile
>  create mode 100644 arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
>  create mode 100644 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
>

Gentle ping?

Thanks,
Dinh
--
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/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Arnd Bergmann]

On Wednesday 23 September 2015 11:21:56 David Daney wrote:
> >>
> >>  /* Limit the bus-range to fit within reg */
> >> -bus_max = pci->cfg.bus_range->start +
> >> -  (resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) - 
> >> 1;
> >> +bus_max = (resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) - 
> >> 1;
> >> +if (bus_max > 255)
> >> +bus_max = 255;
> >
> > I still don't understand the need for this part. If the cfg space is bigger
> > than bus_max, isn't that simply an invalid resource? Given that the resource
> > could be broken in other ways too, this check feels more like a specific
> > workaround rather than generally useful code.
> 
> Imagine...
> 
>bus-range [0x80 .. 0xff], this requires a cfg.res that will cover the 
> entire range of 0..0xff.
> 
>according to the calculations above, (resource_size(&pci->cfg.res) >> 
> pci->cfg.ops.bus_shift) - 1 will have a value of 0xff, so...

Extending the computation to 32 bit seems fine, but I'd rather warn loudly
if the bus range does not fit within the registers.

Also note that the computation is already correct with my interpretation
of the reg property.

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] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Robin Murphy]

On 23/09/15 19:18, Marc Zyngier wrote:

On Wed, 23 Sep 2015 18:52:59 +0100
Will Deacon  wrote:


On Wed, Sep 23, 2015 at 06:08:39PM +0100, David Daney wrote:

On 09/23/2015 10:01 AM, Marc Zyngier wrote:

On Tue, 22 Sep 2015 17:00:06 -0700
David Daney  wrote:


From: David Daney 

Call of_msi_map_rid() to handle mapping of the requester id.

Signed-off-by: David Daney 
---
   drivers/irqchip/irq-gic-v3-its-pci-msi.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index cf351c6..8b1c938 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -86,7 +86,8 @@ static int its_pci_msi_prepare(struct irq_domain *domain, 
struct device *dev,
pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);

/* ITS specific DeviceID, as the core ITS ignores dev. */
-   info->scratchpad[0].ul = dev_alias.dev_id;
+   info->scratchpad[0].ul = of_msi_map_rid(dev, domain->of_node,
+   dev_alias.dev_id);

return msi_info->ops->msi_prepare(domain->parent,
  dev, dev_alias.count, info);


I really wonder if that shouldn't be part of the pci_for_each_dma_alias
call. It would make a lot more sense for this functionality to be an
integral part of the core code, and would probably make the integration
of _IORT (which has the exact same requirements) a bit easier.

Thoughts?



I am a proponent of pushing things like this as far into the core code
as possible.  So, from that point of view, I think it would probably be
a good idea.

I can prepare a patch that does that, but it would also be nice hear
from other maintainers and get their thoughts on this.


Hmm, we use pci_for_each_dma_alias in the SMMU drivers to get the SID,
so I'm not sure that using the MSI mapping is necessarily the right thing
to do there. Maybe we should instead have dma_alias_to_msi_id helpers or
something?


Yes, that's probably a sensible solution.


Seconded; take a look at all the additional bus-walking 
iommu_group_get_for_pci_dev does between the call to 
pci_for_each_dma_alias and the group = iommu_group_alloc() line - I'd 
say it's only at the latter point, when there are no aliases found on 
the PCI side, that it would then need to check the external RID-SID 
mapping to see if there is any further aliasing downstream of the root 
complex (and possibly liaise with the IOMMU driver to retrieve an 
appropriate group, but let's worry about that bit later).


Robin.



M.



--
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] Documentation: dt: keystone: provide SoC specific compatible flags

[Nishanth Menon]

On 09/23/2015 01:05 PM, Murali Karicheri wrote:
> On 09/22/2015 12:08 PM, Nishanth Menon wrote:
[...]

>> diff --git
>> a/Documentation/devicetree/bindings/arm/keystone/keystone.txt
>> b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
>> index 59d7a46f85eb..800d2d02e27b 100644
>> --- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt
>> +++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
>> @@ -9,12 +9,26 @@ Required properties:
>>  the form "ti,keystone-*". Generic devices like gic, arch_timers,
>> ns16550
>>  type UART should use the specified compatible for those devices.
>>
>> +SoC families:
>> +
>> +- Keystone 2 generic SoC:
>> +   compatible = "ti,keystone"
>> +
>> +SoCs:
>> +
>> +- Keystone 2 Hawking/Kepler
>> +   compatible = ti,k2hk", "ti,keystone"
>> +- Keystone 2 Lamarr
>> +   compatible = ti,k2l", "ti,keystone"
>> +- Keystone 2 Edison
>> +   compatible = ti,k2e", "ti,keystone"
>> +
>>   Boards:
>>   -  Keystone 2 Hawking/Kepler EVM
>> -   compatible = "ti,k2hk-evm","ti,keystone"
>> +   compatible = "ti,k2hk-evm", "ti,k2hk", "ti,keystone"
>>
>>   -  Keystone 2 Lamarr EVM
>> -   compatible = "ti,k2l-evm","ti,keystone"
>> +   compatible = "ti,k2l-evm", "ti, k2l", "ti,keystone"
>>
>>   -  Keystone 2 Edison EVM
>> -   compatible = "ti,k2e-evm","ti,keystone"
>> +   compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"
>>
> DTS takes care of the difference in the hardware and If there SoC
> specific customization required outside this, then it is best to include
> this as part of that change. In the past, I believe we didn't do it due
> to the same reason as above.

Right now, they all claim to be the same keystone SoC -> which is
inaccurate at the very least, and downright wrong IMHO since k2e/hk and
l are different SoCs - even though they belong to keystone family, they
are as similar as OMAP4 is to OMAP5 is to DRA7. This is similar to how
various other SoCs distinguish between SoCs as well.

-- 
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

Re: [PATCH v5 09/11] power: bq24257: Allow input current limit sysfs access

[Sebastian Reichel]

Hi,

On Wed, Sep 23, 2015 at 01:32:58PM -0500, Andreas Dannenberg wrote:
> On Wed, Sep 23, 2015 at 05:02:28PM +0200, Sebastian Reichel wrote:
> > On Wed, Sep 23, 2015 at 09:11:46AM -0500, Andreas Dannenberg wrote:
> > > Ok. So how should we best go about extending the usage of the
> > > 'input_current_limit' sysfs node for this charger? You mentioned
> > > writing 'auto' into it should enable the auto-detection mode. I suppose
> > > writing a fixed current value will disable it. But how to indicate to
> > > the user when reading 'input_current_limit' whether auto mode is enabled
> > > or not (I think this is something we should do).
> > 
> > Right, I haven't thought of this.
> > 
> > > Can we return a mixed number/string like this?
> > > 
> > > # Example: charger auto detection mode is disabled, and input current
> > > # limit is configured as 500mA.
> > > 
> > > $ cat input_current_limit
> > > 50
> > > 
> > > # Example: charger auto detection mode is enabled, and a charger
> > > # supporting 1A was detected (note the mixed number/string thats
> > > # returned)
> > > 
> > > $ cat input_current_limit
> > > 100 (auto)
> > > 
> > > Would that work?
> > 
> > No. sysfs nodes should only contain one value per file.
> > 
> > > Or should we introduce a new sysfs property?
> > 
> > So maybe keep this patch as is (disallow setting the limit in auto
> > mode) and create another file for setting (and getting) the mode.
> 
> Thanks for the continued feedback. Will look into this and add a new
> property.
>  
> > Also it might be a good idea to return to safe defaults when the
> > charger is disconnected (-> reset to DT specified values).
> 
> It already does this when the charger type auto-detection is enabled.
> When configured for manually setting the input current limit the use
> case is a bit more complex and I do not recommend resetting the limit to
> 500mA. Let me explain why:
>
> 1) Using USB chargers is only one of the ways the bq2525x devices can be
> used in a system. Imagine a shipping product that comes with its own
> proprietary wall power (or built-in) supply that let's say cranks out
> 2A.  As a vendor you want to configure your system (meaning, the bq2425x
> via DT) to a fixed value of 2A. The user un-plugging and re-plugging the
> power supply should not arbitrarily change that pre-configured limit

I did not write, that it should reset to 500mA, but that it should
reset to DT specified values. So e.g. if the device is confiured to
be in auto mode in DT, then configured to use fixed 1000mA, then it
should return to auto mode on unplug. OTOH if DT specifies 500mA
fixed and user sets 1000mA, then it should return to 500mA fixes.
So re-plugging returns to pre-configured limits.

> 2) Even in case of USB chargers, userspace could detect the power
> un-plug event, and re-configure the limit to something else.  So I think
> it's really policy that should not be implemented in the Kernel driver.

I think it should be done exactly the opposite way. Userspace should
set the custom value again. My main motivation is, that DT values
should be safe for all attachable power supplies, while the user
supplied value may only be safe with the currently connected power
supply.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v2 3/3] mfd: tps65912: Rewrite driver adding DT support and using regmap

[Andrew F. Davis]

On 09/23/2015 12:53 PM, Mark Brown wrote:

On Wed, Sep 23, 2015 at 11:07:39AM -0500, Andrew F. Davis wrote:


  drivers/gpio/Kconfig   |   6 +
  drivers/gpio/Makefile  |   1 +
  drivers/gpio/gpio-tps65912.c   | 138 
  drivers/mfd/Kconfig|  24 ++
  drivers/mfd/Makefile   |   3 +
  drivers/mfd/tps65912-core.c| 114 ++
  drivers/mfd/tps65912-i2c.c |  86 
  drivers/mfd/tps65912-spi.c |  85 +++
  drivers/regulator/Kconfig  |   6 +
  drivers/regulator/Makefile |   1 +
  drivers/regulator/tps65912-regulator.c | 240 
  include/linux/mfd/tps65912.h   | 393 +


Please submit this like a normal driver, not as one enormous patch
covering every subsystem.



OK, I'll break-out the regulator and gpio into their own patches and
send this series again, sorry about the noise.

Andrew
--
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

[linux-sunxi][PATCH v3] ARM: sun7i: dt: Add new Olimex A20 EVB device

[codekipper]

From: Marcus Cooper 

The A20-SOM-EVB is a reference design of a 2-layer board for the
A20-SOM.
It expands the features of A20-SOM by adding VGA connector, HDMI
connector, audio In/Out, LCD connector, 2 Mpix camera, gigabit
Ethernet, SATA, USB-OTG and 2 USB hosts.

Signed-off-by: Marcus Cooper 
---
Changes since v2:
- changed dcdc2 to have max voltage of 1.4V
Changes since v1:
- renamed dts from sun7i-a20-olinuxino-evb to sun7i-a20-olimex-som-evb
- added "axp209 dtsi"
- change regulator settings
---
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 216 +
 2 files changed, 217 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 359dcb5..8419a3e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -617,6 +617,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-i12-tvbox.dtb \
sun7i-a20-m3.dtb \
sun7i-a20-mk808c.dtb \
+   sun7i-a20-olimex-som-evb.dtb \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
sun7i-a20-olinuxino-micro.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts 
b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
new file mode 100644
index 000..41b4b4a
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
@@ -0,0 +1,216 @@
+/*
+ * Copyright 2015 - Marcus Cooper 
+ *
+ * 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 as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * 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 "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * 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 "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Olimex A20-Olimex-SOM-EVB";
+   compatible = "olimex,a20-olimex-som-evb", "allwinner,sun7i-a20";
+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&led_pins_olimex_som_evb>;
+
+   green {
+   label = "a20-olimex-som-evb:green:usr";
+   gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+   };
+
+   reg_axp_ipsout: axp_ipsout {
+   compatible = "regulator-fixed";
+   regulator-name = "axp-ipsout";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+};
+
+&ahci {
+   target-supply = <®_ahci_5v>;
+   status = "okay";
+};
+
+&ehci0 {
+   status = "okay";
+};
+
+&ehci1 {
+   status = "okay";
+};
+
+&gmac {
+   pinctrl-names = "default";
+   pinctrl-0 = <&gmac_pins_rgmii_a>;
+   phy = <&phy1>;
+   phy-mode = "rgmii";
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
+&i2c0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c0_pins

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Vladimir Zapolskiy]

Hi Sascha,

On 23.09.2015 16:37, Sascha Hauer wrote:
> This adds support for the Mediatek thermal controller found on MT8173
> and likely other SoCs.
> The controller is a bit special. It does not have its own ADC, instead
> it controls the on-SoC AUXADC via AHB bus accesses. For this reason
> we need the physical address of the AUXADC. Also it controls a mux
> using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
> 
> Signed-off-by: Sascha Hauer 
> Reviewed-by: Daniel Kurtz 
> ---
>  drivers/thermal/Kconfig   |   8 +
>  drivers/thermal/Makefile  |   1 +
>  drivers/thermal/mtk_thermal.c | 537 
> ++
>  3 files changed, 546 insertions(+)
>  create mode 100644 drivers/thermal/mtk_thermal.c
> 

[snip]

> +
> + auxadc = of_parse_phandle(np, "mediatek,auxadc", 0);
> + if (!auxadc) {
> + dev_err(&pdev->dev, "missing auxadc node\n");
> + return -ENODEV;
> + }
> +
> + auxadc_phys_base = of_get_phys_base(auxadc);

in case of OF_DYNAMIC enabled of_parse_phandle() requires of_node_put(),
which is fine to place right here.

> + if (auxadc_phys_base == OF_BAD_ADDR) {
> + dev_err(&pdev->dev, "Can't get auxadc phys address\n");
> + return -EINVAL;
> + }
> +

[snip]

> +
> + /*
> +  * These calibration values should finally be provided by the
> +  * firmware or fuses. For now use default values.
> +  */
> + mt->calib_slope = -123;
> + mt->calib_offset = 465124;
> +
> + for (i = 0; i < MT8173_NUM_ZONES; i++)
> + mtk_thermal_init_bank(mt, i, apmixed_phys_base, 
> auxadc_phys_base);
> +
> + platform_set_drvdata(pdev, mt);
> +
> + for (i = 0; i < MT8173_NUM_ZONES; i++) {
> + struct mtk_thermal_bank *bank = &mt->banks[i];
> +
> + bank->tzd = thermal_zone_of_sensor_register(&pdev->dev, i, bank,
> + &mtk_thermal_ops);

I would propose to add return value checks here, otherwise there might
be an oops in mtk_thermal_remove(), if something goes wrong.

--
With best wishes,
Vladimir
--
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 09/11] power: bq24257: Allow input current limit sysfs access

[Andreas Dannenberg]

On Wed, Sep 23, 2015 at 05:02:28PM +0200, Sebastian Reichel wrote:
> Hi,
> 
> On Wed, Sep 23, 2015 at 09:11:46AM -0500, Andreas Dannenberg wrote:
> > Ok. So how should we best go about extending the usage of the
> > 'input_current_limit' sysfs node for this charger? You mentioned
> > writing 'auto' into it should enable the auto-detection mode. I suppose
> > writing a fixed current value will disable it. But how to indicate to
> > the user when reading 'input_current_limit' whether auto mode is enabled
> > or not (I think this is something we should do).
> 
> Right, I haven't thought of this.
> 
> > Can we return a mixed number/string like this?
> > 
> > # Example: charger auto detection mode is disabled, and input current
> > # limit is configured as 500mA.
> > 
> > $ cat input_current_limit
> > 50
> > 
> > # Example: charger auto detection mode is enabled, and a charger
> > # supporting 1A was detected (note the mixed number/string thats
> > # returned)
> > 
> > $ cat input_current_limit
> > 100 (auto)
> > 
> > Would that work?
> 
> No. sysfs nodes should only contain one value per file.
> 
> > Or should we introduce a new sysfs property?
> 
> So maybe keep this patch as is (disallow setting the limit in auto
> mode) and create another file for setting (and getting) the mode.

Thanks for the continued feedback. Will look into this and add a new
property.
 
> Also it might be a good idea to return to safe defaults when the
> charger is disconnected (-> reset to DT specified values).

It already does this when the charger type auto-detection is enabled.
When configured for manually setting the input current limit the use
case is a bit more complex and I do not recommend resetting the limit to
500mA. Let me explain why:

1) Using USB chargers is only one of the ways the bq2525x devices can be
used in a system. Imagine a shipping product that comes with its own
proprietary wall power (or built-in) supply that let's say cranks out
2A.  As a vendor you want to configure your system (meaning, the bq2425x
via DT) to a fixed value of 2A. The user un-plugging and re-plugging the
power supply should not arbitrarily change that pre-configured limit

2) Even in case of USB chargers, userspace could detect the power
un-plug event, and re-configure the limit to something else.  So I think
it's really policy that should not be implemented in the Kernel driver.

Regards,

--
Andreas Dannenberg
Texas Instruments Inc

--
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/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[David Daney]

On 09/23/2015 11:01 AM, Will Deacon wrote:

On Thu, Sep 17, 2015 at 11:02:11PM +0100, David Daney wrote:

[...]



  Properties of the /chosen node:
diff --git a/drivers/pci/host/pci-host-generic.c 
b/drivers/pci/host/pci-host-generic.c
index 77cf4bd..0a9c453 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -164,7 +164,7 @@ out_release_res:
  static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
  {
int err;
-   u8 bus_max;
+   int bus_max;
resource_size_t busn;
struct resource *bus_range;
struct device *dev = pci->host.dev.parent;
@@ -177,8 +177,9 @@ static int gen_pci_parse_map_cfg_windows(struct gen_pci 
*pci)
}

/* Limit the bus-range to fit within reg */
-   bus_max = pci->cfg.bus_range->start +
- (resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) - 1;
+   bus_max = (resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) - 1;
+   if (bus_max > 255)
+   bus_max = 255;


I still don't understand the need for this part. If the cfg space is bigger
than bus_max, isn't that simply an invalid resource? Given that the resource
could be broken in other ways too, this check feels more like a specific
workaround rather than generally useful code.


Imagine...

  bus-range [0x80 .. 0xff], this requires a cfg.res that will cover the 
entire range of 0..0xff.


  according to the calculations above, (resource_size(&pci->cfg.res) >> 
pci->cfg.ops.bus_shift) - 1 will have a value of 0xff, so...


  bus_max = 0x80 + 0xff -> OVERFLOW of u8!

That is not useful.  bus_max should represent the largest bus number 
that can be covered by cfg.res.  That is what my patch is attempting to 
accomplish.  Calculate the largest bus number that can be accommodated 
by cfg.res, and then clamp it to 0xff.


David Daney.

--
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] Documentation: dt: keystone: provide SoC specific compatible flags

[santosh shilimkar]

Nishant,

On 9/22/2015 9:08 AM, Nishanth Menon wrote:

Keystone2 devices are used on more platforms than just Texas
Instruments reference evaluation platforms called EVMs. Providing a
generic compatible "ti,keystone" is not sufficient to differentiate
various SoC definitions possible on various platforms. So, provide
compatible matches for each SoC family by itself.

This allows SoC specific logic to be run time handled based on
of_machine_is_compatible("ti,k2hk") or as needed for the dependent
processor instead of needing to use board dependent compatibles that
are needed now.

Signed-off-by: Nishanth Menon 
---

You need to expand that 'not sufficient' for me. Unless there is
genuine case to support this, I would want to avoid this churn.

Regards,
Santosh
--
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] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Marc Zyngier]

On Wed, 23 Sep 2015 18:52:59 +0100
Will Deacon  wrote:

> On Wed, Sep 23, 2015 at 06:08:39PM +0100, David Daney wrote:
> > On 09/23/2015 10:01 AM, Marc Zyngier wrote:
> > > On Tue, 22 Sep 2015 17:00:06 -0700
> > > David Daney  wrote:
> > >
> > >> From: David Daney 
> > >>
> > >> Call of_msi_map_rid() to handle mapping of the requester id.
> > >>
> > >> Signed-off-by: David Daney 
> > >> ---
> > >>   drivers/irqchip/irq-gic-v3-its-pci-msi.c | 3 ++-
> > >>   1 file changed, 2 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
> > >> b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> > >> index cf351c6..8b1c938 100644
> > >> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> > >> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> > >> @@ -86,7 +86,8 @@ static int its_pci_msi_prepare(struct irq_domain 
> > >> *domain, struct device *dev,
> > >>  pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);
> > >>
> > >>  /* ITS specific DeviceID, as the core ITS ignores dev. */
> > >> -info->scratchpad[0].ul = dev_alias.dev_id;
> > >> +info->scratchpad[0].ul = of_msi_map_rid(dev, domain->of_node,
> > >> +dev_alias.dev_id);
> > >>
> > >>  return msi_info->ops->msi_prepare(domain->parent,
> > >>dev, dev_alias.count, info);
> > >
> > > I really wonder if that shouldn't be part of the pci_for_each_dma_alias
> > > call. It would make a lot more sense for this functionality to be an
> > > integral part of the core code, and would probably make the integration
> > > of _IORT (which has the exact same requirements) a bit easier.
> > >
> > > Thoughts?
> > >
> > 
> > I am a proponent of pushing things like this as far into the core code 
> > as possible.  So, from that point of view, I think it would probably be 
> > a good idea.
> > 
> > I can prepare a patch that does that, but it would also be nice hear 
> > from other maintainers and get their thoughts on this.
> 
> Hmm, we use pci_for_each_dma_alias in the SMMU drivers to get the SID,
> so I'm not sure that using the MSI mapping is necessarily the right thing
> to do there. Maybe we should instead have dma_alias_to_msi_id helpers or
> something?

Yes, that's probably a sensible solution.

M.
-- 
Jazz is not dead. It just smells funny.
--
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] Documentation: dt: keystone: provide SoC specific compatible flags

[Murali Karicheri]

On 09/22/2015 12:08 PM, Nishanth Menon wrote:

Keystone2 devices are used on more platforms than just Texas
Instruments reference evaluation platforms called EVMs. Providing a
generic compatible "ti,keystone" is not sufficient to differentiate
various SoC definitions possible on various platforms. So, provide
compatible matches for each SoC family by itself.

This allows SoC specific logic to be run time handled based on
of_machine_is_compatible("ti,k2hk") or as needed for the dependent
processor instead of needing to use board dependent compatibles that
are needed now.

Signed-off-by: Nishanth Menon 
---
  .../devicetree/bindings/arm/keystone/keystone.txt| 20 +---
  1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt 
b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
index 59d7a46f85eb..800d2d02e27b 100644
--- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
@@ -9,12 +9,26 @@ Required properties:
 the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550
 type UART should use the specified compatible for those devices.

+SoC families:
+
+- Keystone 2 generic SoC:
+   compatible = "ti,keystone"
+
+SoCs:
+
+- Keystone 2 Hawking/Kepler
+   compatible = ti,k2hk", "ti,keystone"
+- Keystone 2 Lamarr
+   compatible = ti,k2l", "ti,keystone"
+- Keystone 2 Edison
+   compatible = ti,k2e", "ti,keystone"
+
  Boards:
  -  Keystone 2 Hawking/Kepler EVM
-   compatible = "ti,k2hk-evm","ti,keystone"
+   compatible = "ti,k2hk-evm", "ti,k2hk", "ti,keystone"

  -  Keystone 2 Lamarr EVM
-   compatible = "ti,k2l-evm","ti,keystone"
+   compatible = "ti,k2l-evm", "ti, k2l", "ti,keystone"

  -  Keystone 2 Edison EVM
-   compatible = "ti,k2e-evm","ti,keystone"
+   compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"

DTS takes care of the difference in the hardware and If there SoC 
specific customization required outside this, then it is best to include 
this as part of that change. In the past, I believe we didn't do it due 
to the same reason as above.


Murali

--
Murali Karicheri
Linux Kernel, Keystone
--
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/5] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[Will Deacon]

On Thu, Sep 17, 2015 at 11:02:11PM +0100, David Daney wrote:
> From: David Daney 
> 
> There are two problems with the bus_max calculation:
> 
> 1) The u8 data type can overflow for large config space windows.
> 
> 2) The calculation is incorrect for a bus range that doesn't start at
>zero.
> 
> Since the configuration space is relative to bus zero, make bus_max
> just be the size of the config window scaled by bus_shift.  Then clamp
> it to a maximum of 255, per PCI.  Use a data type of int to avoid
> overflow problems.
> 
> Update host-generic-pci.txt to clarify the semantics of the "reg"
> property with respect to non-zero starting bus numbers.
> 
> Signed-off-by: David Daney 
> ---
> Change from v1: Added text to host-generic-pci.txt
> 
>  Documentation/devicetree/bindings/pci/host-generic-pci.txt | 4 +++-
>  drivers/pci/host/pci-host-generic.c| 7 ---
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt 
> b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> index cf3e205..105a968 100644
> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> @@ -34,7 +34,9 @@ Properties of the host controller node:
>  - #size-cells: Must be 2.
>  
>  - reg: The Configuration Space base address and size, as accessed
> -   from the parent bus.
> +   from the parent bus.  The base address corresponds to
> +   bus zero, even though the "bus-range" property may specify
> +   a different starting bus number.

That's a useful clarification, thanks.

>  Properties of the /chosen node:
> diff --git a/drivers/pci/host/pci-host-generic.c 
> b/drivers/pci/host/pci-host-generic.c
> index 77cf4bd..0a9c453 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -164,7 +164,7 @@ out_release_res:
>  static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
>  {
>   int err;
> - u8 bus_max;
> + int bus_max;
>   resource_size_t busn;
>   struct resource *bus_range;
>   struct device *dev = pci->host.dev.parent;
> @@ -177,8 +177,9 @@ static int gen_pci_parse_map_cfg_windows(struct gen_pci 
> *pci)
>   }
>  
>   /* Limit the bus-range to fit within reg */
> - bus_max = pci->cfg.bus_range->start +
> -   (resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) - 1;
> + bus_max = (resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) - 1;
> + if (bus_max > 255)
> + bus_max = 255;

I still don't understand the need for this part. If the cfg space is bigger
than bus_max, isn't that simply an invalid resource? Given that the resource
could be broken in other ways too, this check feels more like a specific
workaround rather than generally useful code.

Will
--
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/5] PCI: generic: Only fixup irqs for bus we are creating.

[Will Deacon]

On Thu, Sep 17, 2015 at 11:02:09PM +0100, David Daney wrote:
> From: David Daney 
> 
> If we create multiple buses with pci-host-generic, or there are buses
> created by other drivers, we don't want to call pci_fixup_irqs() which
> operates on all devices, not just the devices on the bus being added.
> The consequence is that either the fixups are done more than once, or
> in some cases incorrect fixups could be applied.
> 
> Call pci_bus_fixup_irqs() instead of pci_fixup_irqs().
> 
> Signed-off-by: David Daney 
> ---
> Changes from v1: Moved most of the code to pci_bus_fixup_irqs(),
> making this patch very simple.

Acked-by: Will Deacon 

Will
--
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] soc: sunxi: Add driver for Allwinner Reduced Serial Bus

[Mark Brown]

On Thu, Sep 24, 2015 at 12:05:18AM +0800, Chen-Yu Tsai wrote:

> +static int sunxi_rsb_device_probe(struct device *dev)
> +{
> + const struct sunxi_rsb_driver *drv = to_sunxi_rsb_driver(dev->driver);
> + struct sunxi_rsb_device *rdev = to_sunxi_rsb_device(dev);
> + int ret;
> +
> + if (dev->bus != &sunxi_rsb_bus)
> + return 0;

That's a bit worrying...  why might this get called for something other
than a rsb device?

> +struct regmap *devm_regmap_init_sunxi_rsb(struct sunxi_rsb_device *rdev,
> +   const struct regmap_config *config);

This should work most of the time but you might want to take a look at
the changes introduced in 3cfe7a74d42b (regmap: Use different lockdep
class for each regmap init call) and follow a similar pattern for RSB to
avoid spurious lockdep warnings in some configurations - see the commit
log for that change for a full explanation.

Otherwise the regmap bit of this looks good, I'll try to have another
look through at the rest of the code later.


signature.asc
Description: Digital signature

Re: [PATCH v2 3/3] mfd: tps65912: Rewrite driver adding DT support and using regmap

[Mark Brown]

On Wed, Sep 23, 2015 at 11:07:39AM -0500, Andrew F. Davis wrote:

>  drivers/gpio/Kconfig   |   6 +
>  drivers/gpio/Makefile  |   1 +
>  drivers/gpio/gpio-tps65912.c   | 138 
>  drivers/mfd/Kconfig|  24 ++
>  drivers/mfd/Makefile   |   3 +
>  drivers/mfd/tps65912-core.c| 114 ++
>  drivers/mfd/tps65912-i2c.c |  86 
>  drivers/mfd/tps65912-spi.c |  85 +++
>  drivers/regulator/Kconfig  |   6 +
>  drivers/regulator/Makefile |   1 +
>  drivers/regulator/tps65912-regulator.c | 240 
>  include/linux/mfd/tps65912.h   | 393 
> +

Please submit this like a normal driver, not as one enormous patch
covering every subsystem.


signature.asc
Description: Digital signature

Re: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

[Tony Lindgren]

* Suman Anna  [150903 16:01]:
>  On 07/23/2015 02:24 AM, Tony Lindgren wrote:
> > OK maybe check the syss/sysc registers involved here for each hardware
> > module here and which driver tinkers with which registers? This will
> > make things a lot easier in the long run for sure.
> 
> The OMAP remoteproc driver typically deals with only the reset registers
> and another register in the Control module for programming the boot
> address for the DSPs. You can look up the OMAP4 hwmod data for
> reference. There is currently a .prcm.omap4.modulemode set for these,
> and I have a patch to remove those. I haven't yet posted it yet [1],
> because OMAP remoteprocs are still not bootable on mainline.

Thanks for checking that. Like we chatted, let's make sure we don't
end up with iommu and remoteproc "consumer device" specific data
in the iommu and remoteproc code.

Regards,

Tony

> [1]
> http://git.ti.com/gitweb/?p=rpmsg/remoteproc.git;a=commit;h=0dd2a6a2d8869ee6cec92f75d70663259a41c11f
--
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] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Will Deacon]

On Wed, Sep 23, 2015 at 06:08:39PM +0100, David Daney wrote:
> On 09/23/2015 10:01 AM, Marc Zyngier wrote:
> > On Tue, 22 Sep 2015 17:00:06 -0700
> > David Daney  wrote:
> >
> >> From: David Daney 
> >>
> >> Call of_msi_map_rid() to handle mapping of the requester id.
> >>
> >> Signed-off-by: David Daney 
> >> ---
> >>   drivers/irqchip/irq-gic-v3-its-pci-msi.c | 3 ++-
> >>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
> >> b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >> index cf351c6..8b1c938 100644
> >> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> >> @@ -86,7 +86,8 @@ static int its_pci_msi_prepare(struct irq_domain 
> >> *domain, struct device *dev,
> >>pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);
> >>
> >>/* ITS specific DeviceID, as the core ITS ignores dev. */
> >> -  info->scratchpad[0].ul = dev_alias.dev_id;
> >> +  info->scratchpad[0].ul = of_msi_map_rid(dev, domain->of_node,
> >> +  dev_alias.dev_id);
> >>
> >>return msi_info->ops->msi_prepare(domain->parent,
> >>  dev, dev_alias.count, info);
> >
> > I really wonder if that shouldn't be part of the pci_for_each_dma_alias
> > call. It would make a lot more sense for this functionality to be an
> > integral part of the core code, and would probably make the integration
> > of _IORT (which has the exact same requirements) a bit easier.
> >
> > Thoughts?
> >
> 
> I am a proponent of pushing things like this as far into the core code 
> as possible.  So, from that point of view, I think it would probably be 
> a good idea.
> 
> I can prepare a patch that does that, but it would also be nice hear 
> from other maintainers and get their thoughts on this.

Hmm, we use pci_for_each_dma_alias in the SMMU drivers to get the SID,
so I'm not sure that using the MSI mapping is necessarily the right thing
to do there. Maybe we should instead have dma_alias_to_msi_id helpers or
something?

Will
--
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] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[David Daney]

On 09/23/2015 10:01 AM, Marc Zyngier wrote:

On Tue, 22 Sep 2015 17:00:06 -0700
David Daney  wrote:


From: David Daney 

Call of_msi_map_rid() to handle mapping of the requester id.

Signed-off-by: David Daney 
---
  drivers/irqchip/irq-gic-v3-its-pci-msi.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index cf351c6..8b1c938 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -86,7 +86,8 @@ static int its_pci_msi_prepare(struct irq_domain *domain, 
struct device *dev,
pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);

/* ITS specific DeviceID, as the core ITS ignores dev. */
-   info->scratchpad[0].ul = dev_alias.dev_id;
+   info->scratchpad[0].ul = of_msi_map_rid(dev, domain->of_node,
+   dev_alias.dev_id);

return msi_info->ops->msi_prepare(domain->parent,
  dev, dev_alias.count, info);


I really wonder if that shouldn't be part of the pci_for_each_dma_alias
call. It would make a lot more sense for this functionality to be an
integral part of the core code, and would probably make the integration
of _IORT (which has the exact same requirements) a bit easier.

Thoughts?



I am a proponent of pushing things like this as far into the core code 
as possible.  So, from that point of view, I think it would probably be 
a good idea.


I can prepare a patch that does that, but it would also be nice hear 
from other maintainers and get their thoughts on this.




M.



--
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 3/4] add FPGA manager core

[atull]

Hi Josh,

Thanks for the review.  This is all at the tail end of a long
(>2 years) discussion on this.  I hope that the way this has
shaped out still meets the needs of the people who have been
in this discussion the most and have had the strongest feelings
(due to being current users of FPGAs under Linux).

On Tue, 22 Sep 2015, Josh Cartwright wrote:

> > 
> > The following sysfs files are created:
> > * /sys/class/fpga_manager//name
> >   Name of low level driver.
> 
> Don't 'struct device's already have a name?  Why do you need another name
> attribute?

It's a nicety but not a necessity.  And it's not the only kernel framework
that has human readable names like that. Look at i2c for one example.
Nobody's complained about this one before but I guess it's not
absolutely needed.

> > +
> > +static const char * const state_str[] = {
> > +   [FPGA_MGR_STATE_UNKNOWN] =  "unknown",
> > +   [FPGA_MGR_STATE_POWER_OFF] ="power off",
> > +   [FPGA_MGR_STATE_POWER_UP] = "power up",
> > +   [FPGA_MGR_STATE_RESET] ="reset",
> > +
> > +   /* requesting FPGA image from firmware */
> > +   [FPGA_MGR_STATE_FIRMWARE_REQ] = "firmware request",
> > +   [FPGA_MGR_STATE_FIRMWARE_REQ_ERR] = "firmware request error",
> > +
> > +   /* Preparing FPGA to receive image */
> > +   [FPGA_MGR_STATE_WRITE_INIT] =   "write init",
> > +   [FPGA_MGR_STATE_WRITE_INIT_ERR] =   "write init error",
> > +
> > +   /* Writing image to FPGA */
> > +   [FPGA_MGR_STATE_WRITE] ="write",
> > +   [FPGA_MGR_STATE_WRITE_ERR] ="write error",
> > +
> > +   /* Finishing configuration after image has been written */
> > +   [FPGA_MGR_STATE_WRITE_COMPLETE] =   "write complete",
> > +   [FPGA_MGR_STATE_WRITE_COMPLETE_ERR] =   "write complete error",
> > +
> > +   /* FPGA reports to be in normal operating mode */
> > +   [FPGA_MGR_STATE_OPERATING] ="operating",
> > +};
> 
> Is it really necessary to expose the whole FPGA manager state machine to
> userspace?  Is the only justification "for debugging"?
> 
> If so, that seems pretty short-sighted, as it then makes the state
> machine part of the stable usermode API.  It even makes less sense given
> this patchsets current state: configuration of the FPGA is not something
> that userspace is directly triggering.

Nope, not for debugging.

This feature was requested two years ago by folks who have userspace
bringing up a complicated system in FPGAs under Linux.

https://lkml.org/lkml/2013/9/18/490

There are likely to be interfaces that can be triggered by userspace. Please
look at my last patchset for one example: using device tree overlays.
That can be triggered from userspace.  You could have a layered system
where userspace loads one DT overlay (which triggers FPGA programming
and drivers probing), checks for success, then loads the next
DT overlay to program the next FPGA in the system.  In this case
the userspace interface is the configfs interface for DT overlays
so I would not be able to add FPGA manager status to that interface.
The only status I would have would be in the configfs, indicating
whether the overlay got applied successfully or not.

> 
> > +
> > +static ssize_t name_show(struct device *dev,
> > +struct device_attribute *attr, char *buf)
> > +{
> > +   struct fpga_manager *mgr = to_fpga_manager(dev);
> > +
> > +   return sprintf(buf, "%s\n", mgr->name);
> > +}
> > +
> > +static ssize_t state_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > +   struct fpga_manager *mgr = to_fpga_manager(dev);
> > +
> > +   return sprintf(buf, "%s\n", state_str[mgr->state]);
> > +}
> 
> Is it possible that the state of the FPGA has changed since the last
> time we've done an update?  Should the lower-level drivers' state()
> callback be invoked here?

Exposing the low level driver's state is not exactly the intent here.
Above I commented further on the intent of exposing state.
I want to expose how far the FPGA manager core's state machine gets
in the process of programming.  So if we can't get the FPGA into
a state ready for receiving data, it will be "write init error", for
instance.  If we can't load the specific firmware file we wanted,
it's "firmware request error." 

> 
> > +
> > +static DEVICE_ATTR_RO(name);
> > +static DEVICE_ATTR_RO(state);
> > +
> > +static struct attribute *fpga_mgr_attrs[] = {
> > +   &dev_attr_name.attr,
> > +   &dev_attr_state.attr,
> > +   NULL,
> > +};
> > +ATTRIBUTE_GROUPS(fpga_mgr);
> > +
> > +static int fpga_mgr_of_node_match(struct device *dev, const void *data)
> > +{
> > +   return dev->of_node == data;
> > +}
> > +
> > +/**
> > + * of_fpga_mgr_get - get an exclusive reference to a fpga mgr
> > + * @node:  device node
> > + *
> > + * Given a device node, get an exclusive reference to a fpga mgr.
> > + *
> > + * Return: fpga manager struct or IS_ERR() condition containing error cod

Re: [PATCH v2 2/3] of/irq: Add new function of_msi_map_rid()

[David Daney]

On 09/23/2015 10:07 AM, Rob Herring wrote:

On Tue, Sep 22, 2015 at 7:00 PM, David Daney  wrote:

From: David Daney 

The device tree property "msi-map" specifies how to create the PCI
requester id used in some MSI controllers.  Add a new function
of_msi_map_rid() that finds the msi-map property and applies its
translation to a given requester id.

Signed-off-by: David Daney 
---
  drivers/of/irq.c   | 86 ++
  include/linux/of_irq.h |  7 
  2 files changed, 93 insertions(+)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 55317fa..3f64d2e 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -598,3 +598,89 @@ void of_msi_configure(struct device *dev, struct 
device_node *np)
 d = irq_find_host(msi_np);
 dev_set_msi_domain(dev, d);
  }
+
+/**
+ * of_msi_map_rid - Map a MSI requester ID for a device.
+ * @dev: device for which the mapping is to be done.
+ * @msi_np: device node of the expected msi controller.
+ * @rid_in: unmapped MSI requester ID for the device.
+ *
+ * Walk up the device hierarchy looking for devices with a "msi-map"
+ * property.  If found, apply the mapping to @rid_in.
+ *
+ * Returns the mapped MSI requester ID.
+ */
+u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in)


Generally, the OF API does not use struct device except for what is in
of/device.c. I'm guessing you need it here because you have devices
without DT nodes?


Exactly right.  As you can see we walk up the hierarchy until we find a 
device with the desired of_node ("msi-map").




We may want to handle this more like NUMA node IDs where we populate
data in struct device at creation time and looking at struct device
parents is independent of DT. How would this information be retrieved
with ACPI?


ACPI has a table called _IORT that contains similar information.  It 
would have to be extracted with an analogous facility.





+{
+   struct device *parent_dev;
+   struct device_node *msi_controller_node;
+   const __be32 *msi_map;



+   u32 map_mask, masked_rid;
+   u32 rid_base, msi_base, rid_len, phandle;


One line please.

OK.

It looks like another revision of the patch is in order.




+   int msi_map_len;
+   bool matched;
+   u32 rid_out = rid_in;
+
+   /*
+* Walk up the device parent links looking for one with a
+* "msi-map" property.
+*/
+   msi_map = NULL;


init in the declaration.


OK...



+   for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
+   if (!parent_dev->of_node)
+   continue;
+
+   msi_map = of_get_property(parent_dev->of_node,
+ "msi-map", &msi_map_len);
+   if (!msi_map)
+   continue;
+
+   if (msi_map_len % (4 * sizeof(__be32))) {
+   dev_err(parent_dev, "Error: Bad msi-map length: %d\n",
+   msi_map_len);
+   goto out;


Just return here.


+   }
+   /* We have a good parent_dev and msi_map, let's use them. */
+   break;
+   }
+   if (!msi_map)
+   goto out;


Just return here.


+
+   /* The default is to select all bits. */
+   map_mask = 0x;
+
+   /*
+* Can be overridden by "msi-map-mask" property.  If
+* of_property_read_u32() fails, the default is used.
+*/
+   of_property_read_u32(parent_dev->of_node, "msi-map-mask", &map_mask);
+
+   masked_rid = map_mask & rid_in;
+   matched = false;
+   while (!matched && msi_map_len >= 4 * sizeof(__be32)) {
+   rid_base = be32_to_cpup(msi_map + 0);
+   phandle = be32_to_cpup(msi_map + 1);
+   msi_base = be32_to_cpup(msi_map + 2);
+   rid_len = be32_to_cpup(msi_map + 3);
+
+   msi_controller_node = of_find_node_by_phandle(phandle);
+
+   matched = masked_rid >= rid_base &&
+   masked_rid < rid_base + rid_len &&
+   msi_np == msi_controller_node;
+
+   of_node_put(msi_controller_node);
+   msi_map_len -= 4 * sizeof(__be32);
+   msi_map += 4;
+   }
+   if (!matched)
+   goto out;


Just return here.


+
+   rid_out = masked_rid + msi_base;
+   dev_dbg(dev,
+   "msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: %08x, 
length: %08x, rid: %08x -> %08x\n",
+   dev_name(parent_dev), map_mask, rid_base, msi_base,
+   rid_len, rid_in, rid_out);
+out:
+   return rid_out;
+}
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 4bcbd58..8cd9334 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -75,6 +75,7 @@ static inline int of_irq_to_resource_table(struct device_node 
*dev,
  extern unsigned int irq_of

Re: [PATCH v2 2/3] of/irq: Add new function of_msi_map_rid()

[Rob Herring]

On Tue, Sep 22, 2015 at 7:00 PM, David Daney  wrote:
> From: David Daney 
>
> The device tree property "msi-map" specifies how to create the PCI
> requester id used in some MSI controllers.  Add a new function
> of_msi_map_rid() that finds the msi-map property and applies its
> translation to a given requester id.
>
> Signed-off-by: David Daney 
> ---
>  drivers/of/irq.c   | 86 
> ++
>  include/linux/of_irq.h |  7 
>  2 files changed, 93 insertions(+)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 55317fa..3f64d2e 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -598,3 +598,89 @@ void of_msi_configure(struct device *dev, struct 
> device_node *np)
> d = irq_find_host(msi_np);
> dev_set_msi_domain(dev, d);
>  }
> +
> +/**
> + * of_msi_map_rid - Map a MSI requester ID for a device.
> + * @dev: device for which the mapping is to be done.
> + * @msi_np: device node of the expected msi controller.
> + * @rid_in: unmapped MSI requester ID for the device.
> + *
> + * Walk up the device hierarchy looking for devices with a "msi-map"
> + * property.  If found, apply the mapping to @rid_in.
> + *
> + * Returns the mapped MSI requester ID.
> + */
> +u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 
> rid_in)

Generally, the OF API does not use struct device except for what is in
of/device.c. I'm guessing you need it here because you have devices
without DT nodes?

We may want to handle this more like NUMA node IDs where we populate
data in struct device at creation time and looking at struct device
parents is independent of DT. How would this information be retrieved
with ACPI?

> +{
> +   struct device *parent_dev;
> +   struct device_node *msi_controller_node;
> +   const __be32 *msi_map;

> +   u32 map_mask, masked_rid;
> +   u32 rid_base, msi_base, rid_len, phandle;

One line please.

> +   int msi_map_len;
> +   bool matched;
> +   u32 rid_out = rid_in;
> +
> +   /*
> +* Walk up the device parent links looking for one with a
> +* "msi-map" property.
> +*/
> +   msi_map = NULL;

init in the declaration.

> +   for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
> +   if (!parent_dev->of_node)
> +   continue;
> +
> +   msi_map = of_get_property(parent_dev->of_node,
> + "msi-map", &msi_map_len);
> +   if (!msi_map)
> +   continue;
> +
> +   if (msi_map_len % (4 * sizeof(__be32))) {
> +   dev_err(parent_dev, "Error: Bad msi-map length: %d\n",
> +   msi_map_len);
> +   goto out;

Just return here.

> +   }
> +   /* We have a good parent_dev and msi_map, let's use them. */
> +   break;
> +   }
> +   if (!msi_map)
> +   goto out;

Just return here.

> +
> +   /* The default is to select all bits. */
> +   map_mask = 0x;
> +
> +   /*
> +* Can be overridden by "msi-map-mask" property.  If
> +* of_property_read_u32() fails, the default is used.
> +*/
> +   of_property_read_u32(parent_dev->of_node, "msi-map-mask", &map_mask);
> +
> +   masked_rid = map_mask & rid_in;
> +   matched = false;
> +   while (!matched && msi_map_len >= 4 * sizeof(__be32)) {
> +   rid_base = be32_to_cpup(msi_map + 0);
> +   phandle = be32_to_cpup(msi_map + 1);
> +   msi_base = be32_to_cpup(msi_map + 2);
> +   rid_len = be32_to_cpup(msi_map + 3);
> +
> +   msi_controller_node = of_find_node_by_phandle(phandle);
> +
> +   matched = masked_rid >= rid_base &&
> +   masked_rid < rid_base + rid_len &&
> +   msi_np == msi_controller_node;
> +
> +   of_node_put(msi_controller_node);
> +   msi_map_len -= 4 * sizeof(__be32);
> +   msi_map += 4;
> +   }
> +   if (!matched)
> +   goto out;

Just return here.

> +
> +   rid_out = masked_rid + msi_base;
> +   dev_dbg(dev,
> +   "msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: 
> %08x, length: %08x, rid: %08x -> %08x\n",
> +   dev_name(parent_dev), map_mask, rid_base, msi_base,
> +   rid_len, rid_in, rid_out);
> +out:
> +   return rid_out;
> +}
> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index 4bcbd58..8cd9334 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -75,6 +75,7 @@ static inline int of_irq_to_resource_table(struct 
> device_node *dev,
>  extern unsigned int irq_of_parse_and_map(struct device_node *node, int 
> index);
>  extern struct device_node *of_irq_find_parent(struct device_node *child);
>  extern void of_msi_conf

Re: [PATCH 3/3] ARM: dts: omap5-uevm: enable iio gpadc for Palmas

[H. Nikolaus Schaller]

Hi,

Am 23.09.2015 um 18:56 schrieb Tony Lindgren :

> * H. Nikolaus Schaller  [150923 05:53]:
> 
> Missing description?

well, description is “ARM: dts: omap5-uevm: enable iio gpadc for Palmas"

and I didn’t catch that the commit is otherwise empty. Sorry.

> BTW, this I want to queue separately
> as I have patches in works to support omap5 variants with
> omap5-board-common.dtsi to avoid duplicating things as
> we get omap5 better supported for things like regulators.

Yes, it should work for all Palmas based OMAP5 boards and a 
omap5-board-common.dtsi would be the right place (after
it comes to existence).

> 
> Regards,
> 
> Tony
> 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> arch/arm/boot/dts/omap5-uevm.dts | 22 ++
>> 1 file changed, 22 insertions(+)
>> 
>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts 
>> b/arch/arm/boot/dts/omap5-uevm.dts
>> index 3b16e8f..0d4c8ff 100644
>> --- a/arch/arm/boot/dts/omap5-uevm.dts
>> +++ b/arch/arm/boot/dts/omap5-uevm.dts
>> @@ -342,6 +342,28 @@
>> 
>>  ti,ldo6-vibrator;
>> 
>> +gpadc {
>> +compatible = "ti,palmas-gpadc";
>> +interrupts = <18 0
>> +  16 0
>> +  17 0>;
>> +ti,channel0-current-microamp = <5>;
>> +ti,channel3-current-microamp = <10>;
>> +iio_map {
>> +ch1 {
>> +ti,adc-channel-number = <1>;
>> +ti,adc-consumer-device = 
>> "generic-adc-thermal.0";
>> +ti,adc-consumer-channel 
>> ="battery-temp-channel";
>> +};
>> +
>> +ch6 {
>> +ti,adc-channel-number = <6>;
>> +ti,adc-consumer-device = 
>> "palmas-battery";
>> +ti,adc-consumer-channel 
>> ="vbat_channel";
>> +};
>> +};
>> +};
>> +
>>  regulators {
>>  smps123_reg: smps123 {
>>  /* VDD_OPP_MPU */
>> -- 
>> 2.5.1
>> 

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 v2 3/3] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

[Marc Zyngier]

On Tue, 22 Sep 2015 17:00:06 -0700
David Daney  wrote:

> From: David Daney 
> 
> Call of_msi_map_rid() to handle mapping of the requester id.
> 
> Signed-off-by: David Daney 
> ---
>  drivers/irqchip/irq-gic-v3-its-pci-msi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c 
> b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> index cf351c6..8b1c938 100644
> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> @@ -86,7 +86,8 @@ static int its_pci_msi_prepare(struct irq_domain *domain, 
> struct device *dev,
>   pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);
>  
>   /* ITS specific DeviceID, as the core ITS ignores dev. */
> - info->scratchpad[0].ul = dev_alias.dev_id;
> + info->scratchpad[0].ul = of_msi_map_rid(dev, domain->of_node,
> + dev_alias.dev_id);
>  
>   return msi_info->ops->msi_prepare(domain->parent,
> dev, dev_alias.count, info);

I really wonder if that shouldn't be part of the pci_for_each_dma_alias
call. It would make a lot more sense for this functionality to be an
integral part of the core code, and would probably make the integration
of _IORT (which has the exact same requirements) a bit easier.

Thoughts?

M.
-- 
Jazz is not dead. It just smells funny.
--
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] of/irq: Add new function of_msi_map_rid()

[David Daney]

On 09/23/2015 09:52 AM, Marc Zyngier wrote:

On Tue, 22 Sep 2015 17:00:05 -0700
David Daney  wrote:


From: David Daney 

The device tree property "msi-map" specifies how to create the PCI
requester id used in some MSI controllers.  Add a new function
of_msi_map_rid() that finds the msi-map property and applies its
translation to a given requester id.

Signed-off-by: David Daney 
---
  drivers/of/irq.c   | 86 ++
  include/linux/of_irq.h |  7 
  2 files changed, 93 insertions(+)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 55317fa..3f64d2e 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -598,3 +598,89 @@ void of_msi_configure(struct device *dev, struct 
device_node *np)

[...]

+   while (!matched && msi_map_len >= 4 * sizeof(__be32)) {
+   rid_base = be32_to_cpup(msi_map + 0);
+   phandle = be32_to_cpup(msi_map + 1);
+   msi_base = be32_to_cpup(msi_map + 2);
+   rid_len = be32_to_cpup(msi_map + 3);


Rob did suggest to use of_property_read_u32_index() instead of these
be32_to_cpup(). Not sure if that'd be a major improvement though.



I did think about that, but the micro-optimizer in me didn't feel 
comfortable with the overhead of rerunning of_find_property() for each 
value.  I decided to run of_find_property() once, and then iterate 
through the individual values within the property.


If there are strong objections to doing it this way, we can change it.

David Daney
--
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 3/3] ARM: dts: omap5-uevm: enable iio gpadc for Palmas

[Tony Lindgren]

* H. Nikolaus Schaller  [150923 05:53]:

Missing description? BTW, this I want to queue separately
as I have patches in works to support omap5 variants with
omap5-board-common.dtsi to avoid duplicating things as
we get omap5 better supported for things like regulators.

Regards,

Tony

> Signed-off-by: H. Nikolaus Schaller 
> ---
> arch/arm/boot/dts/omap5-uevm.dts | 22 ++
> 1 file changed, 22 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap5-uevm.dts 
> b/arch/arm/boot/dts/omap5-uevm.dts
> index 3b16e8f..0d4c8ff 100644
> --- a/arch/arm/boot/dts/omap5-uevm.dts
> +++ b/arch/arm/boot/dts/omap5-uevm.dts
> @@ -342,6 +342,28 @@
> 
>   ti,ldo6-vibrator;
> 
> + gpadc {
> + compatible = "ti,palmas-gpadc";
> + interrupts = <18 0
> +   16 0
> +   17 0>;
> + ti,channel0-current-microamp = <5>;
> + ti,channel3-current-microamp = <10>;
> + iio_map {
> + ch1 {
> + ti,adc-channel-number = <1>;
> + ti,adc-consumer-device = 
> "generic-adc-thermal.0";
> + ti,adc-consumer-channel 
> ="battery-temp-channel";
> + };
> +
> + ch6 {
> + ti,adc-channel-number = <6>;
> + ti,adc-consumer-device = 
> "palmas-battery";
> + ti,adc-consumer-channel 
> ="vbat_channel";
> + };
> + };
> + };
> +
>   regulators {
>   smps123_reg: smps123 {
>   /* VDD_OPP_MPU */
> -- 
> 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

Re: [PATCH v2 2/3] of/irq: Add new function of_msi_map_rid()

[Marc Zyngier]

On Tue, 22 Sep 2015 17:00:05 -0700
David Daney  wrote:

> From: David Daney 
> 
> The device tree property "msi-map" specifies how to create the PCI
> requester id used in some MSI controllers.  Add a new function
> of_msi_map_rid() that finds the msi-map property and applies its
> translation to a given requester id.
> 
> Signed-off-by: David Daney 
> ---
>  drivers/of/irq.c   | 86 
> ++
>  include/linux/of_irq.h |  7 
>  2 files changed, 93 insertions(+)
> 
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 55317fa..3f64d2e 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -598,3 +598,89 @@ void of_msi_configure(struct device *dev, struct 
> device_node *np)
>   d = irq_find_host(msi_np);
>   dev_set_msi_domain(dev, d);
>  }
> +
> +/**
> + * of_msi_map_rid - Map a MSI requester ID for a device.
> + * @dev: device for which the mapping is to be done.
> + * @msi_np: device node of the expected msi controller.
> + * @rid_in: unmapped MSI requester ID for the device.
> + *
> + * Walk up the device hierarchy looking for devices with a "msi-map"
> + * property.  If found, apply the mapping to @rid_in.
> + *
> + * Returns the mapped MSI requester ID.
> + */
> +u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 
> rid_in)
> +{
> + struct device *parent_dev;
> + struct device_node *msi_controller_node;
> + const __be32 *msi_map;
> + u32 map_mask, masked_rid;
> + u32 rid_base, msi_base, rid_len, phandle;
> + int msi_map_len;
> + bool matched;
> + u32 rid_out = rid_in;
> +
> + /*
> +  * Walk up the device parent links looking for one with a
> +  * "msi-map" property.
> +  */
> + msi_map = NULL;
> + for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
> + if (!parent_dev->of_node)
> + continue;
> +
> + msi_map = of_get_property(parent_dev->of_node,
> +   "msi-map", &msi_map_len);
> + if (!msi_map)
> + continue;
> +
> + if (msi_map_len % (4 * sizeof(__be32))) {
> + dev_err(parent_dev, "Error: Bad msi-map length: %d\n",
> + msi_map_len);
> + goto out;
> + }
> + /* We have a good parent_dev and msi_map, let's use them. */
> + break;
> + }
> + if (!msi_map)
> + goto out;
> +
> + /* The default is to select all bits. */
> + map_mask = 0x;
> +
> + /*
> +  * Can be overridden by "msi-map-mask" property.  If
> +  * of_property_read_u32() fails, the default is used.
> +  */
> + of_property_read_u32(parent_dev->of_node, "msi-map-mask", &map_mask);
> +
> + masked_rid = map_mask & rid_in;
> + matched = false;
> + while (!matched && msi_map_len >= 4 * sizeof(__be32)) {
> + rid_base = be32_to_cpup(msi_map + 0);
> + phandle = be32_to_cpup(msi_map + 1);
> + msi_base = be32_to_cpup(msi_map + 2);
> + rid_len = be32_to_cpup(msi_map + 3);

Rob did suggest to use of_property_read_u32_index() instead of these
be32_to_cpup(). Not sure if that'd be a major improvement though.

> +
> + msi_controller_node = of_find_node_by_phandle(phandle);
> +
> + matched = masked_rid >= rid_base &&
> + masked_rid < rid_base + rid_len &&
> + msi_np == msi_controller_node;
> +
> + of_node_put(msi_controller_node);
> + msi_map_len -= 4 * sizeof(__be32);
> + msi_map += 4;
> + }
> + if (!matched)
> + goto out;
> +
> + rid_out = masked_rid + msi_base;
> + dev_dbg(dev,
> + "msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: 
> %08x, length: %08x, rid: %08x -> %08x\n",
> + dev_name(parent_dev), map_mask, rid_base, msi_base,
> + rid_len, rid_in, rid_out);
> +out:
> + return rid_out;
> +}
> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index 4bcbd58..8cd9334 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -75,6 +75,7 @@ static inline int of_irq_to_resource_table(struct 
> device_node *dev,
>  extern unsigned int irq_of_parse_and_map(struct device_node *node, int 
> index);
>  extern struct device_node *of_irq_find_parent(struct device_node *child);
>  extern void of_msi_configure(struct device *dev, struct device_node *np);
> +u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 
> rid_in);
>  
>  #else /* !CONFIG_OF */
>  static inline unsigned int irq_of_parse_and_map(struct device_node *dev,
> @@ -87,6 +88,12 @@ static inline void *of_irq_find_parent(struct device_node 
> *child)
>  {
>   return NULL;
>  }
> +
> +static inline u32 of_msi_map_rid(struct device *dev,
> +  struct de

Re: [PATCH v2 1/3] Docs: dt: Add PCI MSI map bindings

[Marc Zyngier]

On Tue, 22 Sep 2015 17:00:04 -0700
David Daney  wrote:

> From: Mark Rutland 
> 
> Currently msi-parent is used by a few bindings to describe the
> relationship between a PCI root complex and a single MSI controller, but
> this property does not have a generic binding document.
> 
> Additionally, msi-parent is insufficient to describe more complex
> relationships between MSI controllers and devices under a root complex,
> where devices may be able to target multiple MSI controllers, or where
> MSI controllers use (non-probeable) sideband information to distinguish
> devices.
> 
> This patch adds a generic binding for mapping PCI devices to MSI
> controllers. This document covers msi-parent, and a new msi-map property
> (specific to PCI*) which may be used to map devices (identified by their
> Requester ID) to sideband data for each MSI controller that they may
> target.
> 
> Signed-off-by: Mark Rutland 
> Signed-off-by: David Daney 

I thought I had done it already, but nevertheless:

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny.
--
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 3/4] add FPGA manager core

[atull]

On Wed, 23 Sep 2015, Dan Carpenter wrote:

> On Wed, Sep 23, 2015 at 03:23:54PM +0200, Pavel Machek wrote:
> > > > +int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags,
> > > > +  const char *image_name)
> > > > +{
> > > > +   struct device *dev = &mgr->dev;
> > > > +   const struct firmware *fw;
> > > > +   int ret;
> > > > +
> > > > +   if (!mgr)
> > > > +   return -ENODEV;
> > > 
> > > Again; I'm of the opinion this is needlessly defensive.
> > 
> > Not only that, it can never happen. mgr is already dereferenced above.
> > 
> 
> It's not dereferenced.  We're taking the address of mgr->dev but we
> don't dereference mgr.
> 
> regards,
> dan carpenter
> 
> 

That's correct, it's not dereferenced.

Is there some community agreement on whether we want to check a pointer
that has been passed for NULL or not?  This is C code after all.  Checking
a passed pointer for NULL is a very common reason to return -ENODEV.

Alan
--
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/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs.

[David Daney]

On 09/22/2015 06:19 AM, Bjorn Helgaas wrote:

Hi David,

On Fri, Sep 18, 2015 at 06:00:28PM -0700, David Daney wrote:

On 09/18/2015 12:45 PM, Arnd Bergmann wrote:

On Friday 18 September 2015 10:00:32 David Daney wrote:

On 09/18/2015 12:19 AM, Arnd Bergmann wrote:

On Thursday 17 September 2015 15:41:33 David Daney wrote:

From: David Daney 

The on-chip devices all have fixed bars.  So, fix them up.

Signed-off-by: David Daney 



You should be able to just mark the BARs as fixed in DT


I think we can switch to PCI_PROBE_ONLY, and have all non-fixed BAR
devices configured by firmware.  This may significantly simplify any
quirks required in the kernel.


I don't like PCI_PROBE_ONLY, and I'd like to avoid it when we can.


I don't like it either, but if it were the only way the PCI maintainers 
would allow us to support the hardware, I would rewrite the firmware to 
make it possible.  However, as you say below ...




Your original patch description said the on-chip devices have "fixed
BARs."  In what sense are they "fixed"?  I assume they are writable
enough so we can learn their sizes?


Yes.  The BAR registers are writable, but ignored.  So, the size is 
correctly probed.  The BAR registers are initialized by 
hardware/firmware to the proper value.



 If we can't learn their sizes, we
have bigger problems because we can't tell what space is used.

Are there other parts of the system, e.g., run-time firmware, that
depend on the devices not being moved?


The devices cannot move, the address decoding is not programmable.  The 
BAR registers are provided as an aid in integrating the devices with OS 
PCI infrastructure.  Although, one might argue that they don't do a very 
good job of adhering to the PCI specifications...





For the record:  The PCI Enhanced Allocation (EA) capability (approved
by PCI SIG on 23 October 2014) is the proper way to handle this going
forward.  However, this is not yet implemented in the SoCs that this
patch addresses.  Our plan is to implement the EA capability in the core
PCI code, so that we do not need to keep adding devices to this fixup code.


Sean Stalley has posted some patches to add EA support to Linux, but I
haven't merged them yet.  If we had that, another option would be to
hook into your config accessors and fabricate an EA capability.


To me, this is the most interesting part of your message.  If you really 
would accept a config read accessor that presented a synthetic EA 
capability, that would be ideal.  We know exactly which roots contain 
the fixed devices, so it would be a trivial exercise to provide a custom 
config accessor.


I am going to work on this in hope of eventual acceptance of this strategy.

Thanks,
David Daney


--
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 v4 0/5] ARM: sunxi: Add Reduced Serial Bus support

[Chen-Yu Tsai]

Hi everyone,

This is my fourth attempt at adding support for Allwinner's Reduced
Serial Bus (RSB), which is used to communicate with PMICs and other
peripherals on their newer SoCs, such as the A23/A33/A80.

RSB is a simplified two wire interface using push-pull outputs,
supporting multiple slaves, address and data parity checks, and
clock speeds up to 20 MHz. The bus only supports simple register
read/writes, with possible register sizes of 8/16/32 bits. Access
sizes not matching the slave device register sizes result in NACKs
or errors. 32 bit registers in devices have yet to be seen.

Previous attempts to add support through the I2C subsystem have
been rejected, as the bus line protocol is too different to even
consider. The latest attempt to add a common bus driver was also
rejected as this is sunxi only.

This version adds a platform driver for the RSB controller under
drivers/soc/sunxi, which adds a custom driver type and bus type
for slave drivers to use. Custom regmap support is also merged
into the controller driver. Currently the driver only exports 2
symbols: sunxi_rsb_driver_register() & devm_regmap_init_sunxi_rsb().

Patch 1 adds the DT bindings for Allwinner RSB controller.

Patch 2 adds the driver itself.

Patch 3 adds the RSB nodes for A23/A33 dtsi.

Patch 5 & 5 enable the RSB controller on the boards I have.

Still to come are axp20x driver support for the RSB based AXP223.
The complete series can be found at:

https://github.com/wens/linux/tree/sunxi-rsb-v4

This is now sunxi specific, so if everything works out, it should
all go through Maxime's tree?


Regards,
ChenYu

Chen-Yu Tsai (5):
  soc: sunxi: Add Allwinner Reduced Serial Bus (RSB) controller bindings
  soc: sunxi: Add driver for Allwinner Reduced Serial Bus
  ARM: dts: sun8i: Add Reduced Serial Bus controller device node to
A23/A33 dtsi
  ARM: dts: sun8i: ippo-q8h-v5: Enable Reduced Serial Bus controller
  ARM: dts: sun8i: sinlinx-sina33: Enable Reduced Serial Bus controller

 .../devicetree/bindings/soc/sunxi/rsb.txt  |  47 ++
 arch/arm/boot/dts/sun8i-a23-a33.dtsi   |  21 +
 arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts|   4 +
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts |   4 +
 drivers/soc/sunxi/Kconfig  |  10 +
 drivers/soc/sunxi/Makefile |   1 +
 drivers/soc/sunxi/sunxi_rsb.c  | 786 +
 include/linux/soc/sunxi/sunxi_rsb.h|  89 +++
 8 files changed, 962 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/sunxi/rsb.txt
 create mode 100644 drivers/soc/sunxi/sunxi_rsb.c
 create mode 100644 include/linux/soc/sunxi/sunxi_rsb.h

-- 
2.5.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 v4 1/5] soc: sunxi: Add Allwinner Reduced Serial Bus (RSB) controller bindings

[Chen-Yu Tsai]

Reduced Serial Bus is a proprietary 2-line push-pull serial bus supporting
multiple slave devices. It was developed by Allwinner, Inc. and used by
Allwinner and X-Powers, Inc. for their line of PMICs and other peripheral
ICs.

Recent Allwinner SoCs, starting with the A23, have an RSB controller. This
is used to talk to the PMIC, and later with the A80 and A83 platform, the
audio codec IC.

Signed-off-by: Chen-Yu Tsai 
---

Changes since v3:

  - Merged common RSB bindings and Allwinner RSB controller bindings
  - Moved to soc/sunxi/rsb.txt
  - Removed runtime address from bindings
  - #address-cells changed to 1
  - Default to 3 MHz if bus clock speed is not specified

---
 .../devicetree/bindings/soc/sunxi/rsb.txt  | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/sunxi/rsb.txt

diff --git a/Documentation/devicetree/bindings/soc/sunxi/rsb.txt 
b/Documentation/devicetree/bindings/soc/sunxi/rsb.txt
new file mode 100644
index ..3dd28343b6ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/sunxi/rsb.txt
@@ -0,0 +1,47 @@
+Allwinner Reduced Serial Bus (RSB) controller
+
+The RSB controller found on later Allwinner SoCs is an SMBus like 2 wire
+serial bus with 1 master and up to 15 slaves. It is represented by a node
+for the controller itself, and child nodes representing the slave devices.
+
+Required properties :
+
+ - reg : Offset and length of the register set for the controller.
+ - compatible  : Shall be "allwinner,sun8i-a23-rsb".
+ - interrupts  : The interrupt line associated to the RSB controller.
+ - clocks  : The gate clk associated to the RSB controller.
+ - resets  : The reset line associated to the RSB controller.
+ - #address-cells  : shall be 1
+ - #size-cells : shall be 0
+
+Optional properties :
+
+ - clock-frequency : Desired RSB bus clock frequency in Hz. Maximum is 20MHz.
+If not set this defaults to 3MHz.
+
+Child nodes:
+
+An RSB controller node can contain zero or more child nodes representing
+slave devices on the bus.  Child 'reg' properties should contain the slave
+device's hardware address. The hardware address is hardwired in the device,
+which can normally be found in the datasheet.
+
+Example:
+
+   rsb@01f03400 {
+   compatible = "allwinner,sun8i-a23-rsb";
+   reg = <0x01f03400 0x400>;
+   interrupts = <0 39 4>;
+   clocks = <&apb0_gates 3>;
+   clock-frequency = <300>;
+   resets = <&apb0_rst 3>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pmic@3e3 {
+   compatible = "...";
+   reg = <0x3e3>;
+
+   /* ... */
+   };
+   };
-- 
2.5.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 2/4] doc: dt-binding: ci-hdrc-usb2: add i.mx specific binding "need-three-clocks"

[Rob Herring]

On Thu, Sep 17, 2015 at 9:35 PM, Peter Chen  wrote:
> On Wed, Sep 16, 2015 at 08:54:25AM -0500, Rob Herring wrote:
>> On 09/15/2015 08:49 PM, Peter Chen wrote:
>> > Some SoCs needs three clock to let controller work, but others only
>> > need one, add one property to differentiate this.

[...]

>> > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
>> > b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>> > index f15a317..4900092 100644
>> > --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>> > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>> > @@ -54,6 +54,9 @@ i.mx specific properties
>> >argument that indicate usb controller index
>> >  - disable-over-current: disable over current detect
>> >  - external-vbus-divider: enables off-chip resistor divider for Vbus
>> > +- need-three-clocks: the SoC before imx6 series (except for imx23/imx28)
>> > +  needs three clcoks for controller, others only need one. Without this
>> > +  property, the driver will consider this controller only need one clock.
>>
>> That's pretty ugly and unnecessary. Either use the compatible string to
>> determine
>
> Since there are too many SoCs to use it, I just didn't want to add
> judgement for platforms, and thought using feature property is simpler.
> If you doesn't agree, I will use other ways.
>
>> if you have 3 clocks or just always try to retrieve the 3
>> clocks in the driver and fall back to 1.
>>
>
> It is not easy to use this way, one-clock platforms have no dev_id for
> clock, but three-clock platforms have.

You just need to try to retrieve the 3rd clock by name. If that
succeeds, retrieve clocks 1 and 2. If you can't retrieve the 3rd
clock, the just get the 1st clock with no name.

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 v4 4/5] ARM: dts: sun8i: ippo-q8h-v5: Enable Reduced Serial Bus controller

[Chen-Yu Tsai]

The Reduced Serial Bus controller is used to talk to the onboard PMIC.

Signed-off-by: Chen-Yu Tsai 
---

Changes since v3:

None

---
 arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts 
b/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
index 4f47fd654eea..af87e4922e44 100644
--- a/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
+++ b/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
@@ -58,6 +58,10 @@
status = "failed";
 };
 
+&r_rsb {
+   status = "okay";
+};
+
 /*
  * FIXME for now we only support host mode and rely on u-boot to have
  * turned on Vbus which is controlled by the axp223 pmic on the board.
-- 
2.5.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 v2 0/3] mfd: tps65912: Driver rewrite with DT support

[Andrew F. Davis]

In an effort to cleanup this driver and add Device Tree support
the driver has been rewritten based on new driver styles and
modern kernel driver helpers. This has nearly halved the lines
of code while keeping all previous functionality.

Platform file based initialization has been dropped as there is
no examples of this use in the kernel.

v1 can be found here: [1]

Changes from v1:
 - Split the rewrite into delete/create patches
 - several small fixes as discussed in v1 thread

[1] http://www.spinics.net/lists/devicetree/msg93863.html

Andrew F. Davis (3):
  Documentation: tps65912: Add DT bindings for the TPS65912 PMIC
  mfd: tps65912: Remove old driver in preparation for new driver
  mfd: tps65912: Rewrite driver adding DT support and using regmap

 .../devicetree/bindings/gpio/gpio-tps65912.txt |  16 +
 Documentation/devicetree/bindings/mfd/tps65912.txt |  42 ++
 .../bindings/regulator/tps65912-regulator.txt  |  32 +
 drivers/gpio/Kconfig   |   2 +-
 drivers/gpio/gpio-tps65912.c   | 291 
 drivers/mfd/Kconfig|  20 +-
 drivers/mfd/Makefile   |   3 +-
 drivers/mfd/tps65912-core.c| 289 +++-
 drivers/mfd/tps65912-i2c.c | 225 +++---
 drivers/mfd/tps65912-irq.c | 217 --
 drivers/mfd/tps65912-spi.c | 226 +++---
 drivers/regulator/Kconfig  |   2 +-
 drivers/regulator/tps65912-regulator.c | 781 +++--
 include/linux/mfd/tps65912.h   | 255 ---
 14 files changed, 925 insertions(+), 1476 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
 rewrite drivers/gpio/gpio-tps65912.c (68%)
 rewrite drivers/mfd/tps65912-core.c (96%)
 rewrite drivers/mfd/tps65912-i2c.c (93%)
 delete mode 100644 drivers/mfd/tps65912-irq.c
 rewrite drivers/mfd/tps65912-spi.c (92%)
 rewrite drivers/regulator/tps65912-regulator.c (94%)

-- 
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 v4 3/5] ARM: dts: sun8i: Add Reduced Serial Bus controller device node to A23/A33 dtsi

[Chen-Yu Tsai]

This patch adds a device node for the Reduced Serial Bus (RSB)
controller and the defacto pinmux setting to the A23/A33 dtsi.

Since there is only one possible pinmux setting for RSB, just
set it in the dtsi.

Signed-off-by: Chen-Yu Tsai 
---

Changes since v3:

  - Changed #address-cells to 1

---
 arch/arm/boot/dts/sun8i-a23-a33.dtsi | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 04bccad977ee..828aaf52c342 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -651,6 +651,13 @@
#size-cells = <0>;
#gpio-cells = <3>;
 
+   r_rsb_pins: r_rsb {
+   allwinner,pins = "PL0", "PL1";
+   allwinner,function = "s_rsb";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
r_uart_pins_a: r_uart@0 {
allwinner,pins = "PL2", "PL3";
allwinner,function = "s_uart";
@@ -658,5 +665,19 @@
allwinner,pull = ;
};
};
+
+   r_rsb: rsb@01f03400 {
+   compatible = "allwinner,sun8i-a23-rsb";
+   reg = <0x01f03400 0x400>;
+   interrupts = ;
+   clocks = <&apb0_gates 3>;
+   clock-frequency = <300>;
+   resets = <&apb0_rst 3>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&r_rsb_pins>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
};
 };
-- 
2.5.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 v2 3/3] mfd: tps65912: Rewrite driver adding DT support and using regmap

[Andrew F. Davis]

The old driver does not support DT. Rewrite the driver adding DT support
and use modern kernel features such as regmap and related helpers.

Signed-off-by: Andrew F. Davis 
---
 drivers/gpio/Kconfig   |   6 +
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-tps65912.c   | 138 
 drivers/mfd/Kconfig|  24 ++
 drivers/mfd/Makefile   |   3 +
 drivers/mfd/tps65912-core.c| 114 ++
 drivers/mfd/tps65912-i2c.c |  86 
 drivers/mfd/tps65912-spi.c |  85 +++
 drivers/regulator/Kconfig  |   6 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/tps65912-regulator.c | 240 
 include/linux/mfd/tps65912.h   | 393 +
 12 files changed, 1097 insertions(+)
 create mode 100644 drivers/gpio/gpio-tps65912.c
 create mode 100644 drivers/mfd/tps65912-core.c
 create mode 100644 drivers/mfd/tps65912-i2c.c
 create mode 100644 drivers/mfd/tps65912-spi.c
 create mode 100644 drivers/regulator/tps65912-regulator.c
 create mode 100644 include/linux/mfd/tps65912.h

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index fb28483..82218fa 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -838,6 +838,12 @@ config GPIO_TPS65910
  Select this option to enable GPIO driver for the TPS65910
  chip family.
 
+config GPIO_TPS65912
+   tristate "TI TPS65912 GPIO"
+   depends on MFD_TPS65912
+   help
+ This driver supports TPS65912 gpio chip
+
 config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 605bf89..f79a7c4 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -96,6 +96,7 @@ obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
 obj-$(CONFIG_GPIO_PALMAS)  += gpio-palmas.o
 obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
 obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
+obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
 obj-$(CONFIG_GPIO_TS5500)  += gpio-ts5500.o
 obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
 obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
new file mode 100644
index 000..4707e62
--- /dev/null
+++ b/drivers/gpio/gpio-tps65912.c
@@ -0,0 +1,138 @@
+/*
+ * TI TPS65912x GPIO Driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis 
+ *
+ * This program 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 program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the Arizona GPIO driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+struct tps65912_gpio {
+   struct tps65912 *tps;
+   struct gpio_chip gpio_chip;
+};
+
+#define to_gpio(gc) container_of(gc, struct tps65912_gpio, gpio_chip)
+
+static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
+{
+   struct tps65912_gpio *gpio = to_gpio(gc);
+   int ret, val;
+
+   ret = regmap_read(gpio->tps->regmap, TPS65912_GPIO1 + offset, &val);
+   if (ret < 0)
+   return ret;
+
+   return val & GPIO_STS_MASK;
+}
+
+static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
+ int value)
+{
+   struct tps65912_gpio *gpio = to_gpio(gc);
+
+   regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+  GPIO_SET_MASK, value ? GPIO_SET_MASK : 0);
+}
+
+static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
+   int value)
+{
+   struct tps65912_gpio *gpio = to_gpio(gc);
+
+   /* Set the initial value */
+   tps65912_gpio_set(gc, offset, value);
+
+   return regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_CFG_MASK, GPIO_CFG_MASK);
+}
+
+static int tps65912_gpio_input(struct gpio_chip *gc, unsigned offset)
+{
+   struct tps65912_gpio *gpio = to_gpio(gc);
+
+   return regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_CFG_MASK, 0);
+}
+
+static const struct of_device_id tps65912_gpio_of_match_table[] = {
+   { .compatible = "ti,tps65912-gpio", },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, tps65912_gpio_of_match_table);
+
+static struct gpio_chip template_chip = {
+   .label  = "tps65912-gpio",

[PATCH v2 1/3] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC

[Andrew F. Davis]

The TPS65912 PMIC contains several regulators and a GPIO controller.
Add bindings for the TPS65912 PMIC.

Signed-off-by: Andrew F. Davis 
---
 .../devicetree/bindings/gpio/gpio-tps65912.txt | 16 +
 Documentation/devicetree/bindings/mfd/tps65912.txt | 42 ++
 .../bindings/regulator/tps65912-regulator.txt  | 32 +
 3 files changed, 90 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/tps65912-regulator.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt 
b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
new file mode 100644
index 000..0c5c05c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
@@ -0,0 +1,16 @@
+* TPS65912 GPIO Controller bindings
+
+Required properties:
+ - compatible : Should be "ti,tps65912-gpio".
+ - gpio-controller : Marks the device node as a GPIO Controller.
+ - #gpio-cells : Should be two.  The first cell is the pin number and
+ the second cell is used to specify flags.
+ See include/dt-bindings/gpio/gpio.h for possible values.
+
+Example:
+
+   gpio4: tps65912_gpio {
+   compatible = "ti,tps65912-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
diff --git a/Documentation/devicetree/bindings/mfd/tps65912.txt 
b/Documentation/devicetree/bindings/mfd/tps65912.txt
new file mode 100644
index 000..a2c94b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65912.txt
@@ -0,0 +1,42 @@
+* TPS65912 Power Management Integrated Circuit bindings
+
+Required properties:
+ - compatible : Should be "ti,tps65912".
+ - reg : Slave address or chip select number (I2C / SPI).
+ - interrupt-parent : The parent interrupt controller.
+ - interrupts : The interrupt line the device is connected to.
+ - interrupt-controller : Marks the device node as an interrupt controller.
+ - #interrupt-cells: The number of cells to describe an IRQ, this should be 2.
+ The first cell is the IRQ number.
+ The second cell is the flags, encoded as the trigger masks from
+ ../interrupt-controller/interrupts.txt
+
+Additional nodes defined in:
+ - Regulators: ../regulator/tps65912-regulator.txt
+ - GPIO: ../gpio/gpio-tps65912.txt.
+
+Example:
+
+   pmic: tps65912@2d {
+   compatible = "ti,tps65912";
+   reg = <0x2d>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   dcdc1: regulator-dcdc1 {
+   compatible = "ti,tps65912-dcdc1";
+   regulator-name = "vdd_core";
+   regulator-min-microvolt = <912000>;
+   regulator-max-microvolt = <1144000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   gpio4: tps65912_gpio {
+   compatible = "ti,tps65912-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+   };
diff --git a/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt 
b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
new file mode 100644
index 000..e8c21f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
@@ -0,0 +1,32 @@
+* TPS65912 regulator bindings
+
+Required properties:
+ - compatible: Should be:
+   - "ti,tps65912-dcdc1" for DCDC1
+   - "ti,tps65912-dcdc2" for DCDC2
+   - "ti,tps65912-dcdc3" for DCDC3
+   - "ti,tps65912-dcdc4" for DCDC4
+   - "ti,tps65912-ldo1" for LDO1
+   - "ti,tps65912-ldo2" for LDO2
+   - "ti,tps65912-ldo3" for LDO3
+   - "ti,tps65912-ldo4" for LDO4
+   - "ti,tps65912-ldo5" for LDO5
+   - "ti,tps65912-ldo6" for LDO6
+   - "ti,tps65912-ldo7" for LDO7
+   - "ti,tps65912-ldo8" for LDO8
+   - "ti,tps65912-ldo9" for LDO9
+   - "ti,tps65912-ldo10" for LDO10
+
+Optional properties:
+ - Any optional property defined in ../regulator/regulator.txt
+
+Example:
+
+   xyz: regulator@0 {
+   compatible = "ti,tps65912-dcdc1";
+   regulator-name = "vdd_core";
+   regulator-min-microvolt = <912000>;
+   regulator-max-microvolt = <1144000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
-- 
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 v4 2/5] soc: sunxi: Add driver for Allwinner Reduced Serial Bus

[Chen-Yu Tsai]

Reduced Serial Bus (RSB) is an Allwinner proprietery interface
used to communicate with PMICs and other peripheral ICs.

RSB is a two-wire push-pull serial bus that supports 1 master
device and up to 15 active slave devices.

Signed-off-by: Chen-Yu Tsai 
---

Changes since v3:

  - Merged common bus regmap and controller functions into a single driver
  - Moved to drivers/soc/sunxi/
  - Allocate and map runtime address statically.

---
 drivers/soc/sunxi/Kconfig   |  10 +
 drivers/soc/sunxi/Makefile  |   1 +
 drivers/soc/sunxi/sunxi_rsb.c   | 786 
 include/linux/soc/sunxi/sunxi_rsb.h |  89 
 4 files changed, 886 insertions(+)
 create mode 100644 drivers/soc/sunxi/sunxi_rsb.c
 create mode 100644 include/linux/soc/sunxi/sunxi_rsb.h

diff --git a/drivers/soc/sunxi/Kconfig b/drivers/soc/sunxi/Kconfig
index 353b07e40176..84f437f2ea0a 100644
--- a/drivers/soc/sunxi/Kconfig
+++ b/drivers/soc/sunxi/Kconfig
@@ -1,6 +1,16 @@
 #
 # Allwinner sunXi SoC drivers
 #
+config SUNXI_RSB
+   bool
+   default MACH_SUN8I || MACH_SUN9I
+   select REGMAP
+   help
+ Say y here to enable Reduced Serial Bus (RSB) support. This
+ controller is responsible for communicating with various RSB
+ based devices, such as AXP223, AXP8XX PMICs, and AC100/AC200
+ ICs.
+
 config SUNXI_SRAM
bool
default ARCH_SUNXI
diff --git a/drivers/soc/sunxi/Makefile b/drivers/soc/sunxi/Makefile
index 4cf9dbdf346e..1a4c16016931 100644
--- a/drivers/soc/sunxi/Makefile
+++ b/drivers/soc/sunxi/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_SUNXI_RSB) += sunxi_rsb.o
 obj-$(CONFIG_SUNXI_SRAM) +=sunxi_sram.o
diff --git a/drivers/soc/sunxi/sunxi_rsb.c b/drivers/soc/sunxi/sunxi_rsb.c
new file mode 100644
index ..d142a796961a
--- /dev/null
+++ b/drivers/soc/sunxi/sunxi_rsb.c
@@ -0,0 +1,786 @@
+/*
+ * RSB (Reduced Serial Bus) driver.
+ *
+ * Author: Chen-Yu Tsai 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ * The RSB controller looks like an SMBus controller which only supports
+ * byte and word data transfers. But, it differs from standard SMBus
+ * protocol on several aspects:
+ * - it uses addresses set at runtime to address slaves. Runtime addresses
+ *   are sent to slaves using their 12bit hardware addresses. Up to 15
+ *   runtime addresses are available.
+ * - it adds a parity bit every 8bits of data and address for read and
+ *   write accesses; this replaces the ack bit
+ * - only one read access is required to read a byte (instead of a write
+ *   followed by a read access in standard SMBus protocol)
+ * - there's no Ack bit after each read access
+ *
+ * This means this bus cannot be used to interface with standard SMBus
+ * devices. Devices known to support this interface include the AXP223,
+ * AXP809, and AXP806 PMICs, and the AC100 audio codec, all from X-Powers.
+ *
+ * A description of the operation and wire protocol can be found in the
+ * RSB section of Allwinner's A80 user manual, which can be found at
+ *
+ * https://github.com/allwinner-zh/documents/tree/master/A80
+ *
+ * This document is officially released by Allwinner.
+ *
+ * This driver is based on i2c-sun6i-p2wi.c, the P2WI bus driver.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* RSB registers */
+#define RSB_CTRL   0x0 /* Global control */
+#define RSB_CCR0x4 /* Clock control */
+#define RSB_INTE   0x8 /* Interrupt controls */
+#define RSB_INTS   0xc /* Interrupt status */
+#define RSB_ADDR   0x10/* Address to send with read/write command */
+#define RSB_DATA   0x1c/* Data to read/write */
+#define RSB_LCR0x24/* Line control */
+#define RSB_DMCR   0x28/* Device mode (init) control */
+#define RSB_CMD0x2c/* RSB Command */
+#define RSB_DAR0x30/* Device address / runtime address */
+
+/* CTRL fields */
+#define RSB_CTRL_START_TRANS   BIT(7)
+#define RSB_CTRL_ABORT_TRANS   BIT(6)
+#define RSB_CTRL_GLOBAL_INT_ENBBIT(1)
+#define RSB_CTRL_SOFT_RST  BIT(0)
+
+/* CLK CTRL fields */
+#define RSB_CCR_SDA_OUT_DELAY(v)   (((v) & 0x7) << 8)
+#define RSB_CCR_MAX_CLK_DIV0xff
+#define RSB_CCR_CLK_DIV(v) ((v) & RSB_CCR_MAX_CLK_DIV)
+
+/* STATUS fields */
+#define RSB_INTS_TRANS_ERR_ACK BIT(16)
+#define RSB_INTS_TRANS_ERR_DATA_BIT(v) (((v) >> 8) & 0xf)
+#define RSB_INTS_TRANS_ERR_DATAGENMASK(11, 8)
+#define RSB_INTS_LOAD_BSY  BIT(2)
+#define RSB_INTS_TRANS_ERR BIT(1)
+#define RSB_INTS_TRANS_OVERBIT(0)
+
+/* LI

[PATCH v2 2/3] mfd: tps65912: Remove old driver in preparation for new driver

[Andrew F. Davis]

The old tps65912 driver is being replaced, delete old driver.

Signed-off-by: Andrew F. Davis 
---
 drivers/gpio/Kconfig   |   6 -
 drivers/gpio/Makefile  |   1 -
 drivers/gpio/gpio-tps65912.c   | 153 --
 drivers/mfd/Kconfig|  26 --
 drivers/mfd/Makefile   |   4 -
 drivers/mfd/tps65912-core.c| 175 ---
 drivers/mfd/tps65912-i2c.c | 139 -
 drivers/mfd/tps65912-irq.c | 217 -
 drivers/mfd/tps65912-spi.c | 141 -
 drivers/regulator/Kconfig  |   6 -
 drivers/regulator/Makefile |   1 -
 drivers/regulator/tps65912-regulator.c | 541 -
 include/linux/mfd/tps65912.h   | 328 
 13 files changed, 1738 deletions(-)
 delete mode 100644 drivers/gpio/gpio-tps65912.c
 delete mode 100644 drivers/mfd/tps65912-core.c
 delete mode 100644 drivers/mfd/tps65912-i2c.c
 delete mode 100644 drivers/mfd/tps65912-irq.c
 delete mode 100644 drivers/mfd/tps65912-spi.c
 delete mode 100644 drivers/regulator/tps65912-regulator.c
 delete mode 100644 include/linux/mfd/tps65912.h

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b4fc9e4..fb28483 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -838,12 +838,6 @@ config GPIO_TPS65910
  Select this option to enable GPIO driver for the TPS65910
  chip family.
 
-config GPIO_TPS65912
-   tristate "TI TPS65912 GPIO"
-   depends on (MFD_TPS65912_I2C || MFD_TPS65912_SPI)
-   help
- This driver supports TPS65912 gpio chip
-
 config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f79a7c4..605bf89 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -96,7 +96,6 @@ obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
 obj-$(CONFIG_GPIO_PALMAS)  += gpio-palmas.o
 obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
 obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
-obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
 obj-$(CONFIG_GPIO_TS5500)  += gpio-ts5500.o
 obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
 obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
deleted file mode 100644
index 9cdbc0c..000
--- a/drivers/gpio/gpio-tps65912.c
+++ /dev/null
@@ -1,153 +0,0 @@
-/*
- * Copyright 2011 Texas Instruments Inc.
- *
- * Author: Margarita Olaya 
- *
- *  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 driver is based on wm8350 implementation.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-struct tps65912_gpio_data {
-   struct tps65912 *tps65912;
-   struct gpio_chip gpio_chip;
-};
-
-#define to_tgd(gc) container_of(gc, struct tps65912_gpio_data, gpio_chip)
-
-static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-   int val;
-
-   val = tps65912_reg_read(tps65912, TPS65912_GPIO1 + offset);
-
-   if (val & GPIO_STS_MASK)
-   return 1;
-
-   return 0;
-}
-
-static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
- int value)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
-   if (value)
-   tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
-   GPIO_SET_MASK);
-   else
-   tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
-   GPIO_SET_MASK);
-}
-
-static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
-   int value)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
-   /* Set the initial value */
-   tps65912_gpio_set(gc, offset, value);
-
-   return tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
-   GPIO_CFG_MASK);
-}
-
-static int tps65912_gpio_input(struct gpio_chip *gc, unsigned offset)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
-   return tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
-   GPIO_CFG_MASK);
-}
-
-static 

[PATCH v4 5/5] ARM: dts: sun8i: sinlinx-sina33: Enable Reduced Serial Bus controller

[Chen-Yu Tsai]

The Reduced Serial Bus controller is used to talk to the onboard PMIC.

Signed-off-by: Chen-Yu Tsai 
---

Changes since v3:

None

---
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts 
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 1d5390d4e03a..13ce68f06dd6 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -130,6 +130,10 @@
};
 };
 
+&r_rsb {
+   status = "okay";
+};
+
 &uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_b>;
-- 
2.5.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 v3 3/6] PCI: generic: Quit clobbering our pci_ops.

[David Daney]

On 09/23/2015 01:21 AM, Arnd Bergmann wrote:

On Tuesday 22 September 2015 16:49:14 David Daney wrote:

From: David Daney 

The pci-host-generic driver keeps a global struct pci_ops which it
then patches with the .map_bus method appropriate for the bus device.
A problem arises when the driver is used for two different types of
bus devices, the .map_bus method for the last device probed clobbers
the method for all previous devices.  The result, only the last bus
device probed has the proper .map_bus, and the others fail.

Move the struct pci_ops into the bus specific structure, and
initialize it when the bus device is probed.  Keep a copy of the
gen_pci_cfg_bus_ops structure, instead of a pointer to a global copy,


This is a very useful change.


to future proof against the addition of bus specific elements to
struct pci_ops.


but I don't like this part. We should just not have bus specific
elements in pci_ops. We don't really have that here either, except
that the gen_pci driver had a hack for reusing the same operations
for things that are actually different.

It's an established practice that anything named '*_operations' is
meant to be constant and ideally defined as 'static const ... *_ops;'
in the driver. We could try to enforce this better by marking
bus->ops as 'const' and changing all the instances of this structure
accordingly.


@@ -65,7 +65,11 @@ static void __iomem *gen_pci_map_cfg_bus_cam(struct pci_bus 
*bus,

  static struct gen_pci_cfg_bus_ops gen_pci_cfg_cam_bus_ops = {
.bus_shift  = 16,
-   .map_bus= gen_pci_map_cfg_bus_cam,
+   .ops= {
+   .map_bus= gen_pci_map_cfg_bus_cam,
+   .read   = pci_generic_config_read,
+   .write  = pci_generic_config_write,
+   }
  };


So this is good. We could in theory unify the map_bus functions
like this now:

static void __iomem *gen_pci_map_cfg_bus(struct pci_bus *bus,
  unsigned int devfn,
  int where)
{
 struct gen_pci *pci = bus->sysdata;
struct gen_pci_cfg_bus_ops *ops;
 resource_size_t idx;

ops = container_of(bus->ops, struct gen_pci_cfg_bus_ops, ops);
idx = bus->number - pci->cfg.bus_range->start;

 return pci->cfg.win[idx] + ((devfn << ops->dev_shift) | where);
}

Not sure if that improves clarity or not, up to Will.


@@ -234,8 +237,7 @@ static int gen_pci_probe(struct platform_device *pdev)
}

of_id = of_match_node(gen_pci_of_match, np);
-   pci->cfg.ops = of_id->data;
+   pci->cfg.ops = *(struct gen_pci_cfg_bus_ops *)of_id->data;


This is the part that grabbed my attention, we should not do it like this.



I will consider changing this so that a structure copy is not used, 
perhaps as you suggest above.


David Daney.



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 v3 4/6] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

[David Daney]

On 09/23/2015 01:01 AM, Arnd Bergmann wrote:

On Tuesday 22 September 2015 16:49:15 David Daney wrote:

From: David Daney 

There are two problems with the bus_max calculation:

1) The u8 data type can overflow for large config space windows.

2) The calculation is incorrect for a bus range that doesn't start at
zero.

Since the configuration space is relative to bus zero, make bus_max
just be the size of the config window scaled by bus_shift.  Then clamp
it to a maximum of 255, per PCI.  Use a data type of int to avoid
overflow problems.

Update host-generic-pci.txt to clarify the semantics of the "reg"
property with respect to non-zero starting bus numbers.

Signed-off-by: David Daney 


Not sure about this one


diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt 
b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
index cf3e205..105a968 100644
--- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
+++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
@@ -34,7 +34,9 @@ Properties of the host controller node:
  - #size-cells: Must be 2.

  - reg: The Configuration Space base address and size, as accessed
-   from the parent bus.
+   from the parent bus.  The base address corresponds to
+   bus zero, even though the "bus-range" property may specify
+   a different starting bus number.


This sounds like very unusual behavior. If you have a system with faked
bus numbers where the registers only physically exist for a subset of the
buses, this requires defining a reg property that contains MMIO space
which is outside of the device and potentially contains other devices.


The pci-host-generic driver only maps the ranges that correspond to the 
"bus-range" buses, so mapping of illegal address ranges should not be a 
problem.




What would break if we instead defined it the expected way and only
list the registers for the bus numbers in the "bus-range" property?


I'm not sure if we have the luxury of being able to change the 
definition, although the existing code only works with a starting bus 
number of zero.  From this we might conclude that non-zero starting bus 
numbers cannot exist in the wild, so changing the the definition of 
"reg" so that it starts at the starting bus number might be possible.


My reading of:

http://www.o3one.org/hwdocs/openfirmware/pci_supplement_2_1.pdf

Section 3.1.1, does not preclude your interpretation.  Although that is 
for PCI-PCI bridges, and not this pci-host-generic root complex.


If we really want to go with a different definition of what the "reg" 
property means, then actual code has to change, and we risk breaking 
something.


David Daney


--
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] dmaengine: vdma: Add 64 bit addressing support to the driver

[Anurag Kumar Vulisha]

Hi Vinod,

Thanks for reviewing the patch

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Monday, September 21, 2015 9:27 PM
> To: Anurag Kumar Vulisha
> Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Michal
> Simek; Soren Brinkmann; Dan Williams; afaer...@suse.de; Maxime Ripard;
> Laurent Pinchart; Appana Durga Kedareswara Rao; Anirudha Sarangi; Srikanth
> Vemula; devicetree@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; dmaeng...@vger.kernel.org; Anurag Kumar
> Vulisha
> Subject: Re: [PATCH v2] dmaengine: vdma: Add 64 bit addressing support to
> the driver
>
> On Thu, Aug 27, 2015 at 09:19:18PM +0530, Anurag Kumar Vulisha wrote:
> > This VDMA  is a soft ip, which can be programmed to support
> > 32 bit addressing or greater than 32 bit addressing.
> >
> > When the VDMA ip is configured for 32 bit address space the transfer
> > start address is specified by a single register.
>
> would be good to specfiy which one
>

Will change  this in v3

> > When the  VDMA core is configured for an address space greater than 32
> > then each start address is specified by a combination of two
> > registers. The first register specifies the LSB 32 bits of address,
> > while the next register specifies the MSB 32 bits of address.For
> > example,5Ch will specify the LSB 32 bits while 60h will specify the
> > MSB 32 bits of the first start address.So we need to program two
> > registers at a time.
>
> can we have spaces after full stops and commas!
>

Will take care of this in v3 patch.

> > +/* Since vdma driver is trying to write to a register offset which is
> > +not a
> > + * multiple of 64 bits(ex : 0x5c), we are writing as two separate 32
> > +bits
> > + * instead of a single 64 bit register write.
> > + */
>
> This is not kernel style for multi-lines, pls refer to
> Documentation/CodingStyle
>

Will address this in v3 patch

> > +
> > +static inline void vdma_desc_write_64(struct xilinx_vdma_chan *chan,
> u32 reg,
> > +u32 value_lsb, u32 value_msb)
> > +{
> > +   /* Write the lsb 32 bits*/
> > +   writel(value_lsb, chan->xdev->regs + chan->desc_offset + reg);
> > +
> > +   /* Write the msb 32 bits */
> > +   writel(value_msb, chan->xdev->regs + chan->desc_offset + reg + 4);
>
> why not writeq

We are trying to write at a register address(ex:0x5c) which is not aligned on 8 
bytes  boundary.So if I try to use 64 bit write on it,unalignment  fault is 
getting  generated.To avoid that we are using two separate 32  bit writes.
We had this discussion in previous versions of this patch with Laurent Pinchart 
.I have also added this exaplanation in the comments above this function.

>
> > +   err = of_property_read_u32(node, "xlnx,addrwidth", &addr_width);
> > +
> > +   if (err < 0) {
> > +   /* Setting addr_width property to default 32 bits */
> > +   addr_width = 32;
> > +   }
>
> braces for a single line statement! Also space is redandant before if 
> condition
>

Will take care of this in v3 patch

Thanks,
Anurag Kumar V

> --
> ~Vinod


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

--
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: [RFC 0/5] console/acpi: add DBG2 and SPCR console configuration

[G Gregory]

On Wed, Sep 23, 2015 at 03:38:20PM +0800, Ming Lei wrote:
> Hi Leif,
> 
> 
> On Tue, Sep 8, 2015 at 8:43 PM, Leif Lindholm  
> wrote:
> > Support for configuring bootconsole and console via the ACPI tables
> > DBG2 (Debug Port Table 2) [1] and SPCR (Serial Port Console Redirection
> > Table) [2], defined by Microsoft, has been discussed on and off over the
> > years.
> >
> > [1] 
> > https://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
> > [2] 
> > https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx
> >
> > Licensing concerns have prevented this happening in the past, but as of
> > 10 August 2015, these tables have both been released also under OWF 1.0
> > (http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0)
> > which is think is noncontroversially GPL-compatible?
> >
> > This set is a first attempt at implementing this.
> 
> From distribution view, the patchset looks very useful.
> 
> I have one simple question, are there other candidates for conveying this kind
> of information like what DBG2/SPCR does? Or are DBG2 and SPCR the
> offical speficiations to do such things in ARM server industry?
> 

They are mandated in the SBBR spec

Graeme


--
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: fix usb pin control for imx-rex dts

[Felipe Tonello]

On Mon, Sep 21, 2015 at 9:17 AM, Felipe Tonello  wrote:
> On Wed, Sep 16, 2015 at 6:40 PM,   wrote:
>> From: "Felipe F. Tonello" 
>>
>> This fixes a duplicated pin control causing this error:
>>
>> imx6q-pinctrl 20e.iomuxc: pin MX6Q_PAD_GPIO_1 already
>> requested by regulators:regulator@2; cannot claim for 2184000.usb
>> imx6q-pinctrl 20e.iomuxc: pin-137 (2184000.usb) status -22
>> imx6q-pinctrl 20e.iomuxc: could not request pin 137
>> (MX6Q_PAD_GPIO_1) from group usbotggrp  on device 20e.iomuxc
>> imx_usb 2184000.usb: Error applying setting, reverse things
>> back
>> imx6q-pinctrl 20e.iomuxc: pin MX6Q_PAD_EIM_D31 already
>> requested by regulators:regulator@1; cannot claim for 2184200.usb
>> imx6q-pinctrl 20e.iomuxc: pin-52 (2184200.usb) status -22
>> imx6q-pinctrl 20e.iomuxc: could not request pin 52 (MX6Q_PAD_EIM_D31)
>> from group usbh1grp  on device 20e.iomuxc
>> imx_usb 2184200.usb: Error applying setting, reverse things
>> back
>>
>> Signed-off-by: Felipe F. Tonello 
>

Ping?
--
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/2] clk: imx6: Add SPDIF_GCLK clock in clock tree

[Shawn Guo]

On Tue, Sep 15, 2015 at 06:01:01PM +0800, Shengjiu Wang wrote:
> As spdif driver will register SPDIF clock to regmap, regmap will do
> clk_prepare in init function, so SPDIF clock is prepared in probe, then its
> root clock (pll clock) is prepared also, which cause the arm can't enter
> low power mode.

Can you help me understand why ARM cannot enter low power mode when pll
clock is prepared?

Shawn

> Add SPDIF_GCLK in clock tree which share same gate bits with SPDIF clock.
> Its root clock is ipg clock, and register it to regmap, then the issue cam
> be fixed.
> 
> Signed-off-by: Shengjiu Wang 
> ---
>  drivers/clk/imx/clk-imx6q.c   | 4 +++-
>  drivers/clk/imx/clk-imx6sl.c  | 4 +++-
>  drivers/clk/imx/clk-imx6sx.c  | 1 +
>  include/dt-bindings/clock/imx6qdl-clock.h | 3 ++-
>  include/dt-bindings/clock/imx6sl-clock.h  | 3 ++-
>  include/dt-bindings/clock/imx6sx-clock.h  | 3 ++-
>  6 files changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
> index b2c1c04..e6b5944 100644
> --- a/drivers/clk/imx/clk-imx6q.c
> +++ b/drivers/clk/imx/clk-imx6q.c
> @@ -119,6 +119,7 @@ static unsigned int share_count_ssi1;
>  static unsigned int share_count_ssi2;
>  static unsigned int share_count_ssi3;
>  static unsigned int share_count_mipi_core_cfg;
> +static unsigned int share_count_spdif;
>  
>  static inline int clk_on_imx6q(void)
>  {
> @@ -456,7 +457,8 @@ static void __init imx6q_clocks_init(struct device_node 
> *ccm_node)
>   clk[IMX6QDL_CLK_SATA] = imx_clk_gate2("sata",  "ahb",   
> base + 0x7c, 4);
>   clk[IMX6QDL_CLK_SDMA] = imx_clk_gate2("sdma",  "ahb",   
> base + 0x7c, 6);
>   clk[IMX6QDL_CLK_SPBA] = imx_clk_gate2("spba",  "ipg",   
> base + 0x7c, 12);
> - clk[IMX6QDL_CLK_SPDIF]= imx_clk_gate2("spdif", 
> "spdif_podf",base + 0x7c, 14);
> + clk[IMX6QDL_CLK_SPDIF]= imx_clk_gate2_shared("spdif", 
> "spdif_podf", base + 0x7c, 14, &share_count_spdif);
> + clk[IMX6QDL_CLK_SPDIF_GCLK]   = imx_clk_gate2_shared("spdif_gclk", 
> "ipg",   base + 0x7c, 14, &share_count_spdif);
>   clk[IMX6QDL_CLK_SSI1_IPG] = imx_clk_gate2_shared("ssi1_ipg",  
> "ipg",base + 0x7c, 18, &share_count_ssi1);
>   clk[IMX6QDL_CLK_SSI2_IPG] = imx_clk_gate2_shared("ssi2_ipg",  
> "ipg",base + 0x7c, 20, &share_count_ssi2);
>   clk[IMX6QDL_CLK_SSI3_IPG] = imx_clk_gate2_shared("ssi3_ipg",  
> "ipg",base + 0x7c, 22, &share_count_ssi3);
> diff --git a/drivers/clk/imx/clk-imx6sl.c b/drivers/clk/imx/clk-imx6sl.c
> index a0d4cf2..a73cedd 100644
> --- a/drivers/clk/imx/clk-imx6sl.c
> +++ b/drivers/clk/imx/clk-imx6sl.c
> @@ -97,6 +97,7 @@ static struct clk_div_table video_div_table[] = {
>  static unsigned int share_count_ssi1;
>  static unsigned int share_count_ssi2;
>  static unsigned int share_count_ssi3;
> +static unsigned int share_count_spdif;
>  
>  static struct clk *clks[IMX6SL_CLK_END];
>  static struct clk_onecell_data clk_data;
> @@ -391,7 +392,8 @@ static void __init imx6sl_clocks_init(struct device_node 
> *ccm_node)
>   clks[IMX6SL_CLK_PWM4] = imx_clk_gate2("pwm4", "perclk", 
>base + 0x78, 22);
>   clks[IMX6SL_CLK_SDMA] = imx_clk_gate2("sdma", "ipg",
>base + 0x7c, 6);
>   clks[IMX6SL_CLK_SPBA] = imx_clk_gate2("spba", "ipg",
>base + 0x7c, 12);
> - clks[IMX6SL_CLK_SPDIF]= imx_clk_gate2("spdif",
> "spdif0_podf",   base + 0x7c, 14);
> + clks[IMX6SL_CLK_SPDIF]= imx_clk_gate2_shared("spdif", 
> "spdif0_podf",   base + 0x7c, 14, &share_count_spdif);
> + clks[IMX6SL_CLK_SPDIF_GCLK]   = imx_clk_gate2_shared("spdif_gclk",  
> "ipg", base + 0x7c, 14, &share_count_spdif);
>   clks[IMX6SL_CLK_SSI1_IPG] = imx_clk_gate2_shared("ssi1_ipg", 
> "ipg",base + 0x7c, 18, &share_count_ssi1);
>   clks[IMX6SL_CLK_SSI2_IPG] = imx_clk_gate2_shared("ssi2_ipg", 
> "ipg",base + 0x7c, 20, &share_count_ssi2);
>   clks[IMX6SL_CLK_SSI3_IPG] = imx_clk_gate2_shared("ssi3_ipg", 
> "ipg",base + 0x7c, 22, &share_count_ssi3);
> diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
> index 5b95c2c..f2bc511 100644
> --- a/drivers/clk/imx/clk-imx6sx.c
> +++ b/drivers/clk/imx/clk-imx6sx.c
> @@ -454,6 +454,7 @@ static void __init imx6sx_clocks_init(struct device_node 
> *ccm_node)
>   clks[IMX6SX_CLK_SPBA] = imx_clk_gate2("spba",  "ipg",   
> base + 0x7c, 12);
>   clks[IMX6SX_CLK_AUDIO]= imx_clk_gate2_shared("audio",  
> "audio_podf",base + 0x7c, 14, &share_count_audio);
>   clks[IMX6SX_CLK_SPDIF]= imx_clk_gate2_shared("spdif",  
> "spdif_podf",base + 0x7c, 14, &share_count_a

Re: [PATCH 3/4] serial: bcm2835: add auxiliary uart1 to device tree of bcm2835

[Stephen Warren]

On 09/23/2015 04:01 AM, Martin Sperl wrote:

On 22.09.2015 04:42, Stephen Warren wrote:

On 09/11/2015 05:20 AM, ker...@martin.sperl.org wrote:

From: Martin Sperl 

Add the auxiliary uart1 device to the device tree of the bcm2835 SOC.



diff --git a/arch/arm/boot/dts/bcm2835.dtsi
b/arch/arm/boot/dts/bcm2835.dtsi



+uart1: uart@7e215040 {
+compatible = "ns16550";


compatible should always include a precise HW-specific value; something
like brcm,bcm2835-aux-uart. That way, if we find some other issue that
needs working around on this HW in the future, all DTs will already
contain the compatible value that SW needs in order to trigger that
workaround. That's a generally true statement; i.e. irrespective of
anything else in this series.

I don't believe "ns16550" should be in the compatible value for this
device, since the device cannot be successfully driven by SW that only
knows about a standard 16650 UART. SW must know about the different
divider, and there is no possibility of SW knowing about that before
this series.



OK - I will look into creating a separate driver then that uses the 8250
implementation as a basis...


I expect all you need to do is add a new PORT_* value to the existing 
driver (which then drives some new quirk setting re: the clock rate), 
and add new entry for the compatible value in of_platform_serial_table[] 
in drivers/tty/serial/of_serial.c to select the correct TYPE_*.

--
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 v7 3/6] pci:host: Add Altera PCIe host controller driver

[Marc Zyngier]

On Wed, 23 Sep 2015 17:33:09 +0800
Ley Foon Tan  wrote:

> On Wed, Sep 23, 2015 at 2:33 AM, Marc Zyngier  wrote:
> > On Mon, 21 Sep 2015 10:13:04 +0800
> > Ley Foon Tan  wrote:
> >
> >> This patch adds the Altera PCIe host controller driver.
> >>
> >> Signed-off-by: Ley Foon Tan 
> >> ---
> >>  drivers/pci/host/Kconfig   |   8 +
> >>  drivers/pci/host/Makefile  |   1 +
> >>  drivers/pci/host/pcie-altera.c | 591 
> >> +
> >>  3 files changed, 600 insertions(+)
> >>  create mode 100644 drivers/pci/host/pcie-altera.c
> >>
> >> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> >> index d5e58ba..df9ed4f 100644
> >> --- a/drivers/pci/host/Kconfig
> >> +++ b/drivers/pci/host/Kconfig
> >> @@ -145,4 +145,12 @@ config PCIE_IPROC_BCMA
> >> Say Y here if you want to use the Broadcom iProc PCIe controller
> >> through the BCMA bus interface
> >>
> >> +config PCIE_ALTERA
> >> + tristate "Altera PCIe controller"
> >> + depends on ARCH_SOCFPGA || NIOS2
> >> + select PCI_DOMAINS
> >> + help
> >> +   Say Y here if you want to enable PCIe controller support for Altera
> >> +   SoCFPGA family of SoCs.
> >> +
> >
> > Is there anything in this driver that is actually specific to any of
> > these two platforms/architectures? I'd don't think we should restrict
> > if we can avoid it (hint: the companion MSI driver is not restricted to
> > any architecture).
> No specific dependency on these 2 architectures. Then I will remove this.

OK. If you fix this, you can put my

Reviewed-by: Marc Zyngier 

on this patch.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
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 09/11] power: bq24257: Allow input current limit sysfs access

[Sebastian Reichel]

Hi,

On Wed, Sep 23, 2015 at 09:11:46AM -0500, Andreas Dannenberg wrote:
> On Wed, Sep 23, 2015 at 02:29:06AM +0200, Sebastian Reichel wrote:
> > On Tue, Sep 22, 2015 at 05:10:45PM -0500, Andreas Dannenberg wrote:
> > > On Tue, Sep 22, 2015 at 09:16:49PM +0200, Sebastian Reichel wrote:
> > > > On Fri, Sep 18, 2015 at 04:39:57PM -0500, Andreas Dannenberg wrote:
> > > > > This patch allows reading (and writing, if the D+/D- USB signal-based
> > > > > charger type detection is disabled) of the input current limit through
> > > > > the power supply's input_current_limit sysfs property. This allows
> > > > > userspace to see what charger was detected and to re-configure the
> > > > > maximum current drawn from the external supply at runtime based on
> > > > > system-level knowledge or user input.
> > > > 
> > > > Maybe also support writing into input_current_limit in auto mode.
> > > > Just disable auto detection until "auto" is written into sysfs node.
> > > 
> > > Auto-detection was enabled by default in the original driver so I think
> > > that should be left intact. I added the ability to manually override
> > > this via DT with a fixed value, and then configure said fixed value
> > > through sysfs at runtime.
> > > 
> > > I'm not 100% clear on the usecase of runtime enabling/disabling auto so
> > > I'd rather leave the implementation as-is. Either auto mode is enabled
> > > or not -- and this is directly tied to the DT setting. But if someone
> > > has a strong usecase for this I can certainly add it.
> > 
> > For some usb power supplies auto-detection doesn't work very well,
> > resulting in a 100mA default fallback. Users knowing their hardware
> > could force charging with the correct input current limitation.
> 
> Ok. So how should we best go about extending the usage of the
> 'input_current_limit' sysfs node for this charger? You mentioned
> writing 'auto' into it should enable the auto-detection mode. I suppose
> writing a fixed current value will disable it. But how to indicate to
> the user when reading 'input_current_limit' whether auto mode is enabled
> or not (I think this is something we should do).

Right, I haven't thought of this.

> Can we return a mixed number/string like this?
> 
> # Example: charger auto detection mode is disabled, and input current
> # limit is configured as 500mA.
> 
> $ cat input_current_limit
> 50
> 
> # Example: charger auto detection mode is enabled, and a charger
> # supporting 1A was detected (note the mixed number/string thats
> # returned)
> 
> $ cat input_current_limit
> 100 (auto)
> 
> Would that work?

No. sysfs nodes should only contain one value per file.

> Or should we introduce a new sysfs property?

So maybe keep this patch as is (disallow setting the limit in auto
mode) and create another file for setting (and getting) the mode.

Also it might be a good idea to return to safe defaults when the
charger is disconnected (-> reset to DT specified values).

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v2 5/7] ARM: at91/defconfig: sama5: add PIO4 controller support

[Nicolas Ferre]

Le 21/09/2015 20:25, Linus Walleij a écrit :
> On Wed, Sep 16, 2015 at 8:37 AM, Ludovic Desroches
>  wrote:
> 
>> SAMA5D2 chip family has a new PIO controller.
>>
>> Signed-off-by: Ludovic Desroches 
> 
> Acked-by: Linus Walleij 
> 
> Please merge this through Nicolas' AT91 tree.

Added in the at91-4.4-defconfig branch.

Thanks.

Paul,

This symbol will appear in Linus W.'s tree and is selected in mine. So
you may find that the symbol appear unused before the two trees are
merged in Linux-next or mainline.

Bye,
-- 
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/7] New Atmel PIO4 pinctrl/gpio driver

[Nicolas Ferre]

Le 21/09/2015 20:50, Linus Walleij a écrit :
> On Wed, Sep 16, 2015 at 8:36 AM, Ludovic Desroches
>  wrote:
> 
>> The Atmel PIO4 controller has been introduced with SAMA5D2 chip family. This
>> drivers manages both pinmux/pinconf and gpio stuff. It is inspired by 
>> Mediatek
>> pinctrl driver.
>>
>> Changes from v1:
>> - remove some unneeded gpio specific ops (gpio_request, gpio_free,
>>   gpio_request_enable, gpio_disable_free and gpio_set_direction).
>> - code styling fixes.
>> - add sama5d2 pin description and device pin muxing.
> 
> Looks Good To Me, and has Sascha's ACKs, so merged patches
> 1, 2, 3, 4 to the pinctrl tree. Please merge the AT91 DT things into
> the AT91 tree.

Great!

So patch 5 is included in at91-4.4-defconfig branch.
patches 6 and 7 queued in at91-4.4-dt branch.
They are included in at91-next that is merged in linux-next and will
both take the arm-soc path later in the cycle.

Thanks, bye,
-- 
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 v3 2/4] Documentation: bindings: mfd: cros ec: document vbc EC property

[Emilio López]

Hi Lee,

On 22/09/15 21:34, Lee Jones wrote:

On Mon, 21 Sep 2015, Emilio López wrote:


Some EC implementations include a small nvram space used to store
verified boot context data. This boolean property lets us indicate
whether this space is available or not on a specific EC implementation.

Signed-off-by: Emilio López 
---

Patch is new in v3, split from 3/4

  Documentation/devicetree/bindings/mfd/cros-ec.txt | 4 
  1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt 
b/Documentation/devicetree/bindings/mfd/cros-ec.txt
index 1777916..136e0c2 100644
--- a/Documentation/devicetree/bindings/mfd/cros-ec.txt
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -34,6 +34,10 @@ Required properties (LPC):
  - compatible: "google,cros-ec-lpc"
  - reg: List of (IO address, size) pairs defining the interface uses

+Optional properties (all):
+- google,has-vbc-nvram: Some implementations of the EC include a small
+  nvram space used to store verified boot context data. This boolean flag
+  is used to specify whether this nvram is present or not.


Is there no way to check for this at runtime?


You can issue a read and see if it succeeds, but the problem is that 
some EC implementations return success even when they don't implement 
the functionality.


Cheers,

Emilio
--
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