Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Kukjin Kim]

On 09/30/15 09:30, Krzysztof Kozlowski wrote:
> On 29.09.2015 20:57, Javier Martinez Canillas wrote:
>> There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
>> Rev4 and Rev5. The only difference between these 2 revisions is the codec,
>> Rev4 has a max98095 codec while Rev5 has a max98090.
>>
>> Mainline only supports Rev4 so this patch moves the common device nodes to
>> a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.
>>
>> The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>> The DTS in the vendor ChromeOS tree are called exynos5250-snow-rev{4,5}.dtb
>> but I decided to leave Rev4 as exynos5250-snow.dtb to avoid breaking u-boot
>> that has CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" in snow_defconfig.
>>
>> Also, ChromiumOS Rev4 DTS has "google,snow-rev4" in its compatible string
>> but was not added in mainline since Rev4 firmware fallbacks to "google,snow"
>> and Rev5 searches for "google,snow-rev5". That way the compatible string
>> could be consistent with the DTS naming and still be able to pack both Rev4
>> and Rev5 FDT in the same FIT image and let the firmware pick the correct FDT.
>>
>>  arch/arm/boot/dts/Makefile|   1 +
>>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
>> ++
>>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>>  arch/arm/boot/dts/exynos5250-snow.dts | 666 
>> +
>>  4 files changed, 733 insertions(+), 665 deletions(-)
>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts
> 
> Now the exynos5250-snow.dts means in fact Rev4... but there is no
> information in DTS about it. I think adding compatible
> "google,snow-rev4" makes sense:
> 1. For informational purposes (this could be also handled with a comment).
> 2. Later one could decide to switch the default meaning of "google,snow"
> to Rev5 and the real compatible (rev4) will be there already.
> 
> Could you add the new compatible and fix patch issues pointed by Doug?
> 
Documenting for the compatibles would be required even I already applied
its updated patch...

- Kukjin
--
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] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Kukjin Kim]

On 09/30/15 15:44, Javier Martinez Canillas wrote:
> There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
> Rev4 and Rev5. The only difference between these 2 revisions is the codec,
> Rev4 has a max98095 codec while Rev5 has a max98090.
> 
> Mainline only supports Rev4 so this patch moves the common device nodes to
> a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.
> 
> The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.
> 
> Signed-off-by: Javier Martinez Canillas 
> Tested-by: Mauro Carvalho Chehab 
> Reviewed-by: Douglas Anderson 
> 
> ---
> 
> Changes in v2:
> - Add Mauro Carvalho Chehab's Tested-by tag.
> - Add Doug Anderson's Reviewed-by tag.
> - Remove warning about adding a whitespace error. Suggested by Doug Anderson.
> - Make Rev{4,5} codec pinctrl properties to match. Suggested by Doug Anderson.
> - Add "google,snow-rev4" to compatible string. Suggested by Krzysztof 
> Kozlowski.
> 
>  arch/arm/boot/dts/Makefile|   1 +
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
> ++
>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>  arch/arm/boot/dts/exynos5250-snow.dts | 671 +
>  4 files changed, 736 insertions(+), 667 deletions(-)
>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts
> 
Applied, thanks.

- Kukjin
--
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 03/17] drm: bridge: analogix/dp: fix some obvious code style

[Yakir Yang]

Hi Krzysztof,

On 09/30/2015 01:22 PM, Krzysztof Kozlowski wrote:

On 22.09.2015 16:34, Yakir Yang wrote:

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
   from exynos_dp code, and rephrase reasonable commit message, and
   remove some controversial style (Krzysztof)
 -  analogix_dp_write_byte_to_dpcd(
 -  dp, DP_TEST_RESPONSE,
 +  analogix_dp_write_byte_to_dpcd(dp,
 +  DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);

Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
   uncommon style like bellow: (Joe Preches)
 -  retval = exynos_dp_read_bytes_from_i2c(...
  ...);
 +  retval =
 +  exynos_dp_read_bytes_from_i2c(..);

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
  3 files changed, 163 insertions(+), 162 deletions(-)


IMHO much better than in previous attempt. The code looks good:

Reviewed-by: Krzysztof Kozlowski 

BTW my opinion is not enough, you still need an ack from Exynos DP
maintainer (or DRM guys).


Aha, thanks.

- Yakir


Best regards,
Krzysztof







--
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] regulator: act8865: support output voltage by VSET2[] bits

[kbuild test robot]

Hi Wenyou,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: i386-randconfig-r0-201539 (attached as .config)
reproduce:
  git checkout 2470179cdcc3b8eebdb6abd5aecbbe6e2804fb33
  # save the attached .config to linux build tree
  make ARCH=i386 

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

>> drivers/regulator/act8865-regulator.c:265:48: error: macro "ACT88xx_REG" 
>> requires 5 arguments, but only 4 given
 ACT88xx_REG("DCDC_REG1", ACT8865, DCDC1, VSET2),
   ^
>> drivers/regulator/act8865-regulator.c:265:2: error: 'ACT88xx_REG' undeclared 
>> here (not in a function)
 ACT88xx_REG("DCDC_REG1", ACT8865, DCDC1, VSET2),
 ^
   drivers/regulator/act8865-regulator.c:266:48: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("DCDC_REG2", ACT8865, DCDC2, VSET2),
   ^
   drivers/regulator/act8865-regulator.c:267:48: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("DCDC_REG3", ACT8865, DCDC3, VSET2),
   ^
   drivers/regulator/act8865-regulator.c:268:45: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("LDO_REG1", ACT8865, LDO1, VSET),
^
   drivers/regulator/act8865-regulator.c:269:45: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("LDO_REG2", ACT8865, LDO2, VSET),
^
   drivers/regulator/act8865-regulator.c:270:45: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("LDO_REG3", ACT8865, LDO3, VSET),
^
   drivers/regulator/act8865-regulator.c:271:45: error: macro "ACT88xx_REG" 
requires 5 arguments, but only 4 given
 ACT88xx_REG("LDO_REG4", ACT8865, LDO4, VSET),
^

vim +/ACT88xx_REG +265 drivers/regulator/act8865-regulator.c

   259  ACT88xx_REG("LDO_REG2", ACT8865, LDO2, VSET, "inl45"),
   260  ACT88xx_REG("LDO_REG3", ACT8865, LDO3, VSET, "inl67"),
   261  ACT88xx_REG("LDO_REG4", ACT8865, LDO4, VSET, "inl67"),
   262  };
   263  
   264  static const struct regulator_desc act8865_alt_regulators[] = {
 > 265  ACT88xx_REG("DCDC_REG1", ACT8865, DCDC1, VSET2),
   266  ACT88xx_REG("DCDC_REG2", ACT8865, DCDC2, VSET2),
   267  ACT88xx_REG("DCDC_REG3", ACT8865, DCDC3, VSET2),
   268  ACT88xx_REG("LDO_REG1", ACT8865, LDO1, VSET),

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


.config.gz
Description: Binary data

Re: [PATCH v5 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Yakir Yang]

Hi Krzysztof,

On 09/30/2015 01:17 PM, Krzysztof Kozlowski wrote:

On 22.09.2015 16:29, Yakir Yang wrote:

Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.

Beside the new analogix_dp driver would export four hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_detect()" and "analogix_dp_get_modes()"

The bind/unbind symbols is used for analogix platform driver to connect
with analogix_dp core driver. And the detect/get_modes is used for analogix
platform driver to init the connector.

They reason why connector need register in helper driver is rockchip drm
haven't implement the atomic API, but Exynos drm have implement it, so
there would need two different connector helper functions, that's why we
leave the connector register in helper driver.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
   the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
   attch function. Cause once platform failed at attach, core driver should
   still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
   patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)

Thanks for fixing this, looks much better.

I don't feel comfortable enough to provide a review tag but it looks
good to me.


Thanks  ;)

- Yakir


Best regards,
Krzysztof







--
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: shmobile: porter: initial device tree

[Geert Uytterhoeven]

Hi Sergei,

On Wed, Sep 30, 2015 at 1:26 AM, Sergei Shtylyov
 wrote:
> Add the initial device tree for the R8A7791 SoC based Porter low cost board
> (which  is a  slightly modified version  of the Henninger board).

Can you please tell us more about the differences?
It will help us reviewing future DTS updates.

> Signed-off-by: Sergei Shtylyov 

If you update Documentation/devicetree/bindings/arm/shmobile.txt, you can
add my
Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 PATCH v3 0/5] usb: change clock information for chipidea

[Shawn Guo]

On Wed, Sep 30, 2015 at 02:24:28PM +0800, Peter Chen wrote:
> On Wed, Sep 30, 2015 at 01:28:36PM +0800, Shawn Guo wrote:
> > On Wed, Sep 30, 2015 at 10:25:20AM +0800, Peter Chen wrote:
> > > This patch set changes usb clock information for legacy i.mx platforms.
> > > At these platforms, they needs three clocks to let controller work.
> > > 
> > > Hi Shawn,
> > > 
> > > Fabio has tested for both imx27 and imx25 platforms.
> > > I have queued 1/5 and 5/5, would you please help to queue others,
> > > thanks.
> > > 
> > > Changes for v3:
> > > - Delete property "needs-three-clocks", and using of_device_id->data
> > >   to differentiate platforms
> > > - change  #v3.19+ to  
> > > #v4.1+
> > 
> > So the last patch will be sent as a fix with stable on copy?
> 
> Yes
> 
> > In that
> > case, will USB driver just work without corresponding DTS change?  Or
> > the driver change has a dependency on the DTS change?
> > 
> 
> At v4.1, One of USB driver changes break i.mx27's USB function.
> The driver's change at patch 5/5 is also tagged for stable tree,
> so it needs both DTS and driver's change to let i.mx27 USB work from
> v4.1.

In that case, you need to have dts and driver changes go through the
same tree.  For dts patches, you can have

Acked-by: Shawn Guo 

As a side note, the kernel change breaks the ABI with DT anyway.

Shawn
--
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] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
Rev4 and Rev5. The only difference between these 2 revisions is the codec,
Rev4 has a max98095 codec while Rev5 has a max98090.

Mainline only supports Rev4 so this patch moves the common device nodes to
a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.

The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.

Signed-off-by: Javier Martinez Canillas 
Tested-by: Mauro Carvalho Chehab 
Reviewed-by: Douglas Anderson 

---

Changes in v2:
- Add Mauro Carvalho Chehab's Tested-by tag.
- Add Doug Anderson's Reviewed-by tag.
- Remove warning about adding a whitespace error. Suggested by Doug Anderson.
- Make Rev{4,5} codec pinctrl properties to match. Suggested by Doug Anderson.
- Add "google,snow-rev4" to compatible string. Suggested by Krzysztof Kozlowski.

 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 ++
 arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
 arch/arm/boot/dts/exynos5250-snow.dts | 671 +
 4 files changed, 736 insertions(+), 667 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
 create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5436ad479b08..a2408a63b341 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -115,6 +115,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+   exynos5250-snow-rev5.dtb \
exynos5250-spring.dtb \
exynos5260-xyref5260.dtb \
exynos5410-smdk5410.dtb \
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
new file mode 100644
index ..0a7f408824d8
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -0,0 +1,684 @@
+/*
+ * Google Snow board device tree source
+ *
+ * Copyright (c) 2012 Google, Inc
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "exynos5250.dtsi"
+
+/ {
+   aliases {
+   i2c104 = &i2c_104;
+   };
+
+   memory {
+   reg = <0x4000 0x8000>;
+   };
+
+   chosen {
+   bootargs = "console=tty1";
+   stdout-path = "serial3:115200n8";
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   pinctrl-names = "default";
+   pinctrl-0 = <&power_key_irq &lid_irq>;
+
+   power {
+   label = "Power";
+   gpios = <&gpx1 3 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   gpio-key,wakeup;
+   };
+
+   lid-switch {
+   label = "Lid";
+   gpios = <&gpx3 5 GPIO_ACTIVE_LOW>;
+   linux,input-type = <5>; /* EV_SW */
+   linux,code = <0>; /* SW_LID */
+   debounce-interval = <1>;
+   gpio-key,wakeup;
+   };
+   };
+
+   vbat: vbat-fixed-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vbat-supply";
+   regulator-boot-on;
+   };
+
+   i2c-arbitrator {
+   compatible = "i2c-arb-gpio-challenge";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c-parent = <&{/i2c@12CA}>;
+
+   our-claim-gpio = <&gpf0 3 GPIO_ACTIVE_LOW>;
+   their-claim-gpios = <&gpe0 4 GPIO_ACTIVE_LOW>;
+   slew-delay-us = <10>;
+   wait-retry-us = <3000>;
+   wait-free-us = <5>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&arb_our_claim &arb_their_claim>;
+
+   /* Use ID 104 as a hint that we're on physical bus 4 */
+   i2c_104: i2c@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   battery: sbs-battery@b {
+   compatible = "sbs,sbs-battery";
+   reg = <0xb>;
+   sbs,poll-retry-count = <1>;
+   };
+
+   cros_ec: embedded-controller {
+   compatible = "google,cros-ec-i2c";
+   reg = <0x1e>;
+   interrupts = <6 IRQ_TYPE_NONE>;
+   interrupt-parent = <&gpx1>;
+   pinctrl-names = "default";
+  

[PATCH v2 3/3] ARM: dts: sun6i: hummingbird: Drop AXP221 DC1SW and DC5LDO supplies

[Chen-Yu Tsai]

"dcdc1-supply" and "dcdc5-supply" have been dropped, as they are
internally connected and should not be represented in the device
tree.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts 
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 06d9391ca30e..f93cf4c42a7a 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -178,8 +178,6 @@
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <1>;
-   dcdc1-supply = <&vcc_3v0>;
-   dcdc5-supply = <&vcc_dram>;
 
regulators {
x-powers,dcdc-freq = <3000>;
-- 
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 2/3] regulator: axp20x: set supply names for AXP22X DC1SW/DC5LDO internally

[Chen-Yu Tsai]

The DC1SW and DC5LDO regulators in the AXP22X are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property.

Since they are internally connected, the relationship should not be
represented in the device tree, but handled internally by the driver.

This patch has the driver remember the regulator names for the parent
DCDC1/DCDC5, and use them as supply names for DC1SW/DC5LDO.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/regulator/axp20x-regulator.c | 54 +---
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index a9567af7cec0..35de22fdb7a0 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -196,10 +196,10 @@ static const struct regulator_desc axp22x_regulators[] = {
AXP_DESC(AXP22X, DCDC5, "dcdc5", "vin5", 1000, 2550, 50,
 AXP22X_DCDC5_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(5)),
/* secondary switchable output of DCDC1 */
-   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", "dcdc1", 1600, 3400, 100,
+   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", NULL, 1600, 3400, 100,
AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(7)),
/* LDO regulator internally chained to DCDC5 */
-   AXP_DESC(AXP22X, DC5LDO, "dc5ldo", "dcdc5", 700, 1400, 100,
+   AXP_DESC(AXP22X, DC5LDO, "dc5ldo", NULL, 700, 1400, 100,
 AXP22X_DC5LDO_V_OUT, 0x7, AXP22X_PWR_OUT_CTRL1, BIT(0)),
AXP_DESC(AXP22X, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
 AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(6)),
@@ -350,6 +350,8 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
};
int ret, i, nregulators;
u32 workmode;
+   const char *axp22x_dc1_name = axp22x_regulators[AXP22X_DCDC1].name;
+   const char *axp22x_dc5_name = axp22x_regulators[AXP22X_DCDC5].name;
 
switch (axp20x->variant) {
case AXP202_ID:
@@ -371,8 +373,37 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
axp20x_regulator_parse_dt(pdev);
 
for (i = 0; i < nregulators; i++) {
-   rdev = devm_regulator_register(&pdev->dev, ®ulators[i],
-  &config);
+   const struct regulator_desc *desc = ®ulators[i];
+   struct regulator_desc *new_desc;
+
+   /*
+* Regulators DC1SW and DC5LDO are connected internally,
+* so we have to handle their supply names separately.
+*
+* We always register the regulators in proper sequence,
+* so the supply names are correctly read. See the last
+* part of this loop to see where we save the DT defined
+* name.
+*/
+   if (regulators == axp22x_regulators) {
+   if (i == AXP22X_DC1SW) {
+   new_desc = devm_kzalloc(&pdev->dev,
+   sizeof(*desc),
+   GFP_KERNEL);
+   *new_desc = regulators[i];
+   new_desc->supply_name = axp22x_dc1_name;
+   desc = new_desc;
+   } else if (i == AXP22X_DC5LDO) {
+   new_desc = devm_kzalloc(&pdev->dev,
+   sizeof(*desc),
+   GFP_KERNEL);
+   *new_desc = regulators[i];
+   new_desc->supply_name = axp22x_dc5_name;
+   desc = new_desc;
+   }
+   }
+
+   rdev = devm_regulator_register(&pdev->dev, desc, &config);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev, "Failed to register %s\n",
regulators[i].name);
@@ -388,6 +419,21 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
dev_err(&pdev->dev, "Failed to set workmode on 
%s\n",
rdev->desc->name);
}
+
+   /*
+* Save AXP22X DCDC1 / DCDC5 regulator names for later.
+*/
+   if (regulators == axp22x_regulators) {
+   /* Can we use rdev->constraints->name instead? */
+   if (i == AXP22X_DCDC1)
+   of_property_read_string(rdev->dev.of_node,
+   "regulator-name",
+   &axp22x_dc1_name);
+   else if (i == AXP22X_DCDC5)
+ 

[PATCH 2/2] regulator: act8865: add DT binding for property "active-semi,vsel-high"

[Wenyou Yang]

Add a DT property "active-semi,vsel-high" to indicate the VSEL pin
is high. If this property is missing, then assume the VSEL pin is
low(0).

Signed-off-by: Wenyou Yang 
---

 .../bindings/regulator/act8865-regulator.txt   |3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt 
b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
index e91485d..6067d98 100644
--- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
@@ -8,6 +8,8 @@ Required properties:
 Optional properties:
 - system-power-controller: Telling whether or not this pmic is controlling
   the system power. See 
Documentation/devicetree/bindings/power/power-controller.txt .
+- active-semi,vsel-high: Indicates the VSEL pin is high.
+  If this property is missing, assume the VSEL pin is low(0).
 
 Optional input supply properties:
 - for act8600:
@@ -49,6 +51,7 @@ Example:
pmic: act8865@5b {
compatible = "active-semi,act8865";
reg = <0x5b>;
+   active-semi,vsel-high;
status = "disabled";
 
regulators {
-- 
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 1/2] regulator: act8865: support output voltage by VSET2[] bits

[Wenyou Yang]

For the step-down DC/DC regulators, the output voltage is
selectable by setting VSEL pin that when VSEL is low, output
voltage is programmed by VSET1[] bits, and when VSEL is high,
output voltage is programmed by VSET2[] bits.

The DT property "active-semi,vsel-high" is used to specify
the VSEL pin at high on the board.

Signed-off-by: Wenyou Yang 
---

 drivers/regulator/act8865-regulator.c |   24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/act8865-regulator.c 
b/drivers/regulator/act8865-regulator.c
index 896db16..e2b50f3 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -261,6 +261,16 @@ static const struct regulator_desc act8865_regulators[] = {
ACT88xx_REG("LDO_REG4", ACT8865, LDO4, VSET, "inl67"),
 };
 
+static const struct regulator_desc act8865_alt_regulators[] = {
+   ACT88xx_REG("DCDC_REG1", ACT8865, DCDC1, VSET2),
+   ACT88xx_REG("DCDC_REG2", ACT8865, DCDC2, VSET2),
+   ACT88xx_REG("DCDC_REG3", ACT8865, DCDC3, VSET2),
+   ACT88xx_REG("LDO_REG1", ACT8865, LDO1, VSET),
+   ACT88xx_REG("LDO_REG2", ACT8865, LDO2, VSET),
+   ACT88xx_REG("LDO_REG3", ACT8865, LDO3, VSET),
+   ACT88xx_REG("LDO_REG4", ACT8865, LDO4, VSET),
+};
+
 #ifdef CONFIG_OF
 static const struct of_device_id act8865_dt_ids[] = {
{ .compatible = "active-semi,act8600", .data = (void *)ACT8600 },
@@ -413,6 +423,7 @@ static int act8865_pmic_probe(struct i2c_client *client,
struct act8865 *act8865;
unsigned long type;
int off_reg, off_mask;
+   int voltage_select;
 
pdata = dev_get_platdata(dev);
 
@@ -424,6 +435,10 @@ static int act8865_pmic_probe(struct i2c_client *client,
return -ENODEV;
 
type = (unsigned long) id->data;
+
+   voltage_select = !!of_get_property(dev->of_node,
+  "active-semi,vsel-high",
+  NULL);
} else {
type = i2c_id->driver_data;
}
@@ -442,8 +457,13 @@ static int act8865_pmic_probe(struct i2c_client *client,
off_mask = ACT8846_OFF_SYSMASK;
break;
case ACT8865:
-   regulators = act8865_regulators;
-   num_regulators = ARRAY_SIZE(act8865_regulators);
+   if (voltage_select) {
+   regulators = act8865_alt_regulators;
+   num_regulators = ARRAY_SIZE(act8865_alt_regulators);
+   } else {
+   regulators = act8865_regulators;
+   num_regulators = ARRAY_SIZE(act8865_regulators);
+   }
off_reg = ACT8865_SYS_CTRL;
off_mask = ACT8865_MSTROFF;
break;
-- 
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/3] regulator: axp20x: Drop AXP221 DC1SW/DC5LDO supplies from bindings

[Chen-Yu Tsai]

Hi everyone,

This is v2 of "regulators: axp20x: Rename AXP221 DC1SW and DC5LDO supply
names". v2 removes the regulator supply properties for AXP221 DC1SW
and DC5LDO, instead of renaming them. These 2 regulators are secondary
outputs for DCDC1 and DCDC5 buck regulators, respectively, so they are
connected to them internally. This relationship should not be represented
in the device tree.


Patch 1 drops the AXP22X DC1SW/DC5LDO supply properties from the axp20x
DT bindings.

Patch 2 updates the axp20x regulator driver.

Patch 3 updates the only dts, the Hummingbird A31, that uses these
bindings.

If everything's ok, could we merge this for 4.4?

Thanks.


Regards,
ChenYu


Chen-Yu Tsai (3):
  mfd: axp20x: Drop AXP221 DC1SW and DC5LDO regulator supplies from
bindings
  regulator: axp20x: set supply names for AXP22X DC1SW/DC5LDO internally
  ARM: dts: sun6i: hummingbird: Drop AXP221 DC1SW and DC5LDO supplies

 Documentation/devicetree/bindings/mfd/axp20x.txt |  4 +-
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts  |  2 -
 drivers/regulator/axp20x-regulator.c | 54 ++--
 3 files changed, 52 insertions(+), 8 deletions(-)

-- 
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 1/3] mfd: axp20x: Drop AXP221 DC1SW and DC5LDO regulator supplies from bindings

[Chen-Yu Tsai]

The DC1SW and DC5LDO regulators in the AXP221 are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property. This causes
some confusion when we actually use it in the dts:

axp221 {
/* self supplying? */
dcdc1-supply = <&dcdc1>;
dcdc5-supply = <&dcdc5>;

dcdc1: dcdc1 {
...
};

dcdc5: dcdc5 {
...
};
};

Since they are internally connected within the PMIC, their relationships
should not be visible in the device tree.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 41811223e5be..a474359dd206 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -60,8 +60,8 @@ DCDC2 : DC-DC buck: vin2-supply
 DCDC3  : DC-DC buck: vin3-supply
 DCDC4  : DC-DC buck: vin4-supply
 DCDC5  : DC-DC buck: vin5-supply
-DC1SW  : On/Off Switch : dcdc1-supply  : DCDC1 secondary output
-DC5LDO : LDO   : dcdc5-supply  : input from DCDC5
+DC1SW  : On/Off Switch :   : DCDC1 secondary output
+DC5LDO : LDO   :   : input from DCDC5
 ALDO1  : LDO   : aldoin-supply : shared supply
 ALDO2  : LDO   : aldoin-supply : shared supply
 ALDO3  : LDO   : aldoin-supply : shared supply
-- 
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 0/2] Add support to make output voltage determined by VSET2[] bits

[Wenyou Yang]

The patch is to add support to make the output voltage of ACT8865
DC/DC regulator determined by VSET2[] bits. The DT property
"active-semi,vsel-high" is used to specify the VSEL pin at high
on the board. When the VSEL pin is high, output voltage is programmed
by VSET2[] bits.


Wenyou Yang (2):
  regulator: act8865: support output voltage by VSET2[] bits
  regulator: act8865: add DT binding for property
"active-semi,vsel-high"

 .../bindings/regulator/act8865-regulator.txt   |3 +++
 drivers/regulator/act8865-regulator.c  |   24 ++--
 2 files changed, 25 insertions(+), 2 deletions(-)

-- 
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] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

Hello Krzysztof,

On 09/30/2015 02:30 AM, Krzysztof Kozlowski wrote:

[snip]

>>
>> The DTS in the vendor ChromeOS tree are called exynos5250-snow-rev{4,5}.dtb
>> but I decided to leave Rev4 as exynos5250-snow.dtb to avoid breaking u-boot
>> that has CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" in snow_defconfig.
>>
>> Also, ChromiumOS Rev4 DTS has "google,snow-rev4" in its compatible string
>> but was not added in mainline since Rev4 firmware fallbacks to "google,snow"
>> and Rev5 searches for "google,snow-rev5". That way the compatible string
>> could be consistent with the DTS naming and still be able to pack both Rev4
>> and Rev5 FDT in the same FIT image and let the firmware pick the correct FDT.
>>
>>  arch/arm/boot/dts/Makefile|   1 +
>>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
>> ++
>>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>>  arch/arm/boot/dts/exynos5250-snow.dts | 666 
>> +
>>  4 files changed, 733 insertions(+), 665 deletions(-)
>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
>>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts
> 
> Now the exynos5250-snow.dts means in fact Rev4... but there is no
> information in DTS about it. I think adding compatible
> "google,snow-rev4" makes sense:
> 1. For informational purposes (this could be also handled with a comment).
> 2. Later one could decide to switch the default meaning of "google,snow"
> to Rev5 and the real compatible (rev4) will be there already.
>

Ok, I explained my rationale about why I did not add a "google,snow-rev4"
but I don't have a strong opinion on this so I'll add it on v2.
 
> Could you add the new compatible and fix patch issues pointed by Doug?
>

Sure.

> Best regards,
> Krzysztof
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

[Shawn Guo]

On Tue, Sep 01, 2015 at 06:06:53PM +0530, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
> 
> Signed-off-by: Sanchayan Maity 

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

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Javier Martinez Canillas]

Hello Doug,

On 09/29/2015 07:28 PM, Doug Anderson wrote:

[snip]

> 
> 
>>  arch/arm/boot/dts/Makefile|   1 +
>>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
>> ++
>>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>>  arch/arm/boot/dts/exynos5250-snow.dts | 666 
>> +
>>  4 files changed, 733 insertions(+), 665 deletions(-)
> 
> Thanks!  Note:
> 
> $ pwclient git-am 7285451
> Applying patch #7285451 using 'git am'
> Description: ARM: dts: Add Exynos5250 Snow Rev5+ support
> Applying: ARM: dts: Add Exynos5250 Snow Rev5+ support
> .git/rebase-apply/patch:774: new blank line at EOF.
> +
> warning: 1 line adds whitespace errors.
>

sigh, sorry for missing that one.
 
> 
> One other nit is that the exynos5250-snow.dts" ends up with the
> "max98095" pinctrl properties sorted differently than the
> "exynos5250-snow-rev5.dts".  Is it worth reordering the
> "exynos5250-snow.dts" in the same patch?
>

Right, I'll change exynos5250-snow.dts to have pinctrl-names
before pinctrl-0 that will not only match max98090 properties
order but also be consistent with the rest of the dev nodes.
 
> Otherwise this looks fine to me.
> 
> Reviewed-by: Douglas Anderson 
> 

Thanks a lot for your feedback and review!

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 PATCH v3 0/5] usb: change clock information for chipidea

[Peter Chen]

On Wed, Sep 30, 2015 at 01:28:36PM +0800, Shawn Guo wrote:
> On Wed, Sep 30, 2015 at 10:25:20AM +0800, Peter Chen wrote:
> > This patch set changes usb clock information for legacy i.mx platforms.
> > At these platforms, they needs three clocks to let controller work.
> > 
> > Hi Shawn,
> > 
> > Fabio has tested for both imx27 and imx25 platforms.
> > I have queued 1/5 and 5/5, would you please help to queue others,
> > thanks.
> > 
> > Changes for v3:
> > - Delete property "needs-three-clocks", and using of_device_id->data
> >   to differentiate platforms
> > - change  #v3.19+ to  #v4.1+
> 
> So the last patch will be sent as a fix with stable on copy?

Yes

> In that
> case, will USB driver just work without corresponding DTS change?  Or
> the driver change has a dependency on the DTS change?
> 

At v4.1, One of USB driver changes break i.mx27's USB function.
The driver's change at patch 5/5 is also tagged for stable tree,
so it needs both DTS and driver's change to let i.mx27 USB work from
v4.1.

-- 

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

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

[Sascha Hauer]

Hi Vladimir,

On Wed, Sep 23, 2015 at 09:31:12PM +0300, Vladimir Zapolskiy wrote:
> Hi Sascha,
> 
> 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.

Thanks for the input. I'll fix that in the next round.

Sascha

-- 
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- |
--
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] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

Hi Eduardo,

On Tue, Sep 29, 2015 at 04:04:40PM -0700, Eduardo Valentin wrote:
> On Wed, Sep 23, 2015 at 03:37:42PM +0200, Sascha Hauer wrote:
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> You dont seam to be using this header. Can you please clean up to have
> only the headers you need?

Ok, did that.

> > +   struct mtk_thermal *mt = bank->mt;
> > +   int temp, i, max;
> > +   u32 raw;
> > +
> > +   temp = max = INT_MIN;
> > +
> > +   for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
> > +   raw = readl(mt->thermal_base + sensing_points[i].msr);
> > +
> > +   temp = raw_to_mcelsius(mt, raw);
> > +
> > +   /*
> > +* The first read of a sensor often contains very high bogus
> > +* temperature value. Filter these out so that the system does
> > +* not immediately shut down.
> > +*/
> > +   if (temp > 20)
> 
> Ok... How about after the first read?  is > 20 a valid (supported) value 
> range?

No, temperatures over 200°C are not supported for this SoC.

> > +
> > +   mt->dev = &pdev->dev;
> > +
> > +   auxadc = of_parse_phandle(np, "mediatek,auxadc", 0);
> of_put?

added

> > +   if (!auxadc) {
> > +   dev_err(&pdev->dev, "missing auxadc node\n");
> > +   return -ENODEV;
> > +   }
> > +
> > +   auxadc_phys_base = of_get_phys_base(auxadc);
> > +   if (auxadc_phys_base == OF_BAD_ADDR) {
> > +   dev_err(&pdev->dev, "Can't get auxadc phys address\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   apmixedsys = of_parse_phandle(np, "mediatek,apmixedsys", 0);
> > +   if (!apmixedsys) {
> > +   dev_err(&pdev->dev, "missing apmixedsys node\n");
> > +   return -ENODEV;
> > +   }

For this one aswell.

> > +   /*
> > +* 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;
> 
> I would still prefer that this driver would not have these hardcoded
> values. Specially considering the fact that we could map it in DT for
> instance. What is the impact of using this? Does it work across all chip
> distribution?

I think yes, but not that accurate.

> 
> Should we wait until you have the code to read the fuses before merging
> this?

I'd say we should merge this. It makes the life easier for the guys
writing the cpufreq driver. Adding a dependency on a not yet written
driver IMO only adds unnecessary delays.

> 
> > +
> > +   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);
> 
> You need to error handle this.

Errors here are pretty much expected. This is due to the behaviour of
thermal_zone_of_sensor_register which errors out when no user for a
sensor is found. Normally I would expect that I can register a sensor
regardless if it is used or not, but that's not how
thermal_zone_of_sensor_register is written.

I could catch -EPROBE_DEFER here, but currently I see no case where this
can actually be returned from thermal_zone_of_sensor_register.

What I can and should do though is to call
thermal_zone_of_sensor_unregister only for sensors that are successfully
registered.

Sascha

-- 
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- |
--
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 0/9] ARM: dts: update Boundary Devices boards support

[Shawn Guo]

On Wed, Sep 09, 2015 at 02:30:44PM +0200, Gary Bisson wrote:
> Hi all,
> 
> This series is a follow-up to the previous series that added LCD display
> support.
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/364425.html

The MAINTAINERS file has been updated for a couple of release cycles
with my new email address.  Please stop sending patches to
shawn@linaro.org, and resend any patches you want me to collect to
shawn...@kernel.org.

Shawn

> 
> This one aims at adding touchscreen and WiFi support for Nitrogen6x as well as
> adding two boards: Nitrogen6_Max and Nit6xlite.
> 
> It also takes care of updating the licenses to be GPLv2/X11.
> 
> The series has been tested against linux-next tag next-20150909.
> 
> Note that imx_v6_v7_defconfig has been used with the following additions:
> CONFIG_TOUCHSCREEN_EDT_FT5X06=y
> CONFIG_I2C_MUX_GPIO=y
> CONFIG_RTC_DRV_M41T80=y
> 
> Modifications:
> v2->v3:
> - Rename nodes to general class of device as suggested by Philipp and Russell.
> - Remove useless wakeup-gpio field for edt,ft5x06 touchscreen
> - Add missing muxing for interrupt GPIO
> - Rebased on next-20150909
> v1->v2:
> - Add Boundary Devices Inc. to vendor prefixes
> - Relicense devices trees to GPLv2/X11 as suggested by Fabio for:
>   - Nitrogen6x
>   - SabreLite
>   - Nit6xLite
>   - Nitrogen6_MAX
> - Change manufacturer to Boundary Devices as suggested by Fabio for:
>   - Nitrogen6x
>   - Nit6xLite
>   - Nitrogen6_MAX
> - Fixed missing macros for gpio/irq values as suggested by Philipp.
> - Rebased on next-20150908
> 
> Regards,
> Gary
> 
> Gary Bisson (9):
>   ARM: dts: imx6dql-nitrogen6x: add touchscreen support
>   ARM: dts: imx6qdl-nitrogen6x: add wifi wl1271 support
>   ARM: dts: imx6qdl-nitrogen6x: relicense under GPLv2/X11
>   ARM: dts: imx6qdl-sabrelite: relicense under GPLv2/X11
>   of: Add Boundary Devices Inc. vendor prefix
>   ARM: dts: imx6q-nitrogen6x: change manufacturer to Boundary Devices
>   ARM: dts: imx6dl-nitrogen6x: change manufacturer to Boundary Devices
>   ARM: dts: imx: add Boundary Devices Nitrogen6_Max board
>   ARM: dts: imx: add Boundary Devices Nitrogen6_Lite board
> 
>  .../devicetree/bindings/vendor-prefixes.txt|   1 +
>  arch/arm/boot/dts/Makefile |   2 +
>  arch/arm/boot/dts/imx6dl-nit6xlite.dts |  49 ++
>  arch/arm/boot/dts/imx6dl-nitrogen6x.dts|  44 +-
>  arch/arm/boot/dts/imx6dl-sabrelite.dts |  40 +-
>  arch/arm/boot/dts/imx6q-nitrogen6_max.dts  |  53 ++
>  arch/arm/boot/dts/imx6q-nitrogen6x.dts |  44 +-
>  arch/arm/boot/dts/imx6q-sabrelite.dts  |  40 +-
>  ...6qdl-nitrogen6x.dtsi => imx6qdl-nit6xlite.dtsi} | 396 ++
>  arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi   | 873 
> +
>  arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi  | 111 ++-
>  arch/arm/boot/dts/imx6qdl-sabrelite.dtsi   |  40 +-
>  12 files changed, 1523 insertions(+), 170 deletions(-)
>  create mode 100644 arch/arm/boot/dts/imx6dl-nit6xlite.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-nitrogen6_max.dts
>  copy arch/arm/boot/dts/{imx6qdl-nitrogen6x.dtsi => imx6qdl-nit6xlite.dtsi} 
> (50%)
>  create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> 
> -- 
> 2.5.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
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 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

[maitysanchayan]

Hello Shawn,

The driver has landed in your tree. Can you queue this DT change for the same?

Thanks.

- Sanchayan.

On 15-09-01 18:06:53, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vf500-colibri-eval-v3.dts |  5 +++
>  arch/arm/boot/dts/vf500-colibri.dtsi| 47 
> +
>  2 files changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> index 7fc782c..c3173fc 100644
> --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> @@ -15,3 +15,8 @@
>   model = "Toradex Colibri VF50 on Colibri Evaluation Board";
>   compatible = "toradex,vf500-colibri_vf50-on-eval", 
> "toradex,vf500-colibri_vf50", "fsl,vf500";
>  };
> +
> +&touchscreen {
> + vf50-ts-min-pressure = <200>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi 
> b/arch/arm/boot/dts/vf500-colibri.dtsi
> index cee34a3..84f091d 100644
> --- a/arch/arm/boot/dts/vf500-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
> @@ -17,4 +17,51 @@
>   memory {
>   reg = <0x8000 0x800>;
>   };
> +
> + touchscreen: vf50-touchscreen {
> + compatible = "toradex,vf50-touchscreen";
> + io-channels = <&adc1 0>,<&adc0 0>,
> + <&adc0 1>,<&adc1 2>;
> + xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <&pinctrl_touchctrl_idle>;
> + pinctrl-1 = <&pinctrl_touchctrl_default>;
> + pinctrl-2 = <&pinctrl_touchctrl_gpios>;
> + vf50-ts-min-pressure = <200>;
> + status = "disabled";
> + };
> +};
> +
> +&iomuxc {
> + vf610-colibri {
> + pinctrl_touchctrl_idle: touchctrl_idle {
> + fsl,pins = <
> + VF610_PAD_PTA18__GPIO_8 0x006d
> + VF610_PAD_PTA19__GPIO_9 0x006c
> + >;
> + };
> +
> + pinctrl_touchctrl_default: touchctrl_default {
> + fsl,pins = <
> + VF610_PAD_PTA18__ADC0_SE0   0x0040
> + VF610_PAD_PTA19__ADC0_SE1   0x0040
> + VF610_PAD_PTA16__ADC1_SE0   0x0040
> + VF610_PAD_PTB2__ADC1_SE20x0040
> + >;
> + };
> +
> + pinctrl_touchctrl_gpios: touchctrl_gpios {
> + fsl,pins = <
> + VF610_PAD_PTA23__GPIO_130x22e9
> + VF610_PAD_PTB23__GPIO_930x22e9
> + VF610_PAD_PTA22__GPIO_120x22e9
> + VF610_PAD_PTA11__GPIO_4 0x22e9
> + >;
> + };
> + };
>  };
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] iio:light:tsl2563: Add DT support

[Peter Meerwald]

Hello Suresh,

> * Add Device Tree support for the Dyna Image AP3223 ambient light sensor and
> * proximity driver,
> * Document the binding and
> * Add a vendor prefix for Dyna Image

the mail's subject line should read something like
iio: light: Add AP3223 DT support

tsl2563 is a different driver

> v2
> * Seperating the device tree changes from code

Separating

> 
> Signed-off-by: Suresh Rajashekara 
> ---
>  Documentation/devicetree/bindings/iio/light/ap3223.txt | 18 
> ++
>  Documentation/devicetree/bindings/vendor-prefixes.txt  |  1 +
>  2 files changed, 19 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/light/ap3223.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/light/ap3223.txt 
> b/Documentation/devicetree/bindings/iio/light/ap3223.txt
> new file mode 100644
> index 000..b255d27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/ap3223.txt
> @@ -0,0 +1,18 @@
> +* Dyna Image AP3223 ambient light sensor and proximity sensor
> +
> +http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2&dpid=8
> +
> +Required properties:
> +
> +  - compatible : should be "dynaimage,ap3223"
> +  - reg : the I2C address of the sensor
> +
> +Example:
> +
> +ap3223@1c {
> + compatible = "dynaimage,ap3223";
> + reg = <0x1c>;
> +
> + pinctrl-0 = <&ap3223_pins>;
> + pinctrl-names = "default";
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 5f20add..704da45 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -46,6 +46,7 @@ digilentDiglent, Inc.
>  dlg  Dialog Semiconductor
>  dlinkD-Link Corporation
>  dmo  Data Modul AG
> +dynaimageDyna-Image
>  ebv  EBV Elektronik
>  edt  Emerging Display Technologies
>  elan Elan Microelectronic Corp.
> 

-- 

Peter Meerwald
+43-664-218 (mobile)
--
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 v15 1/2] arm:dts:ls1021a: Add DCU dts node

[Shawn Guo]

On Thu, Aug 27, 2015 at 02:13:46PM +0800, Jianwei Wang wrote:
> Add DCU node, DCU is a display controller of Freescale
> named 2D-ACE.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 

When you resend, please use "ARM: dts: ls1021a: ..." as subject prefix.

Shawn
--
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 v15 1/2] arm:dts:ls1021a: Add DCU dts node

[Shawn Guo]

On Thu, Aug 27, 2015 at 02:13:46PM +0800, Jianwei Wang wrote:
> Add DCU node, DCU is a display controller of Freescale
> named 2D-ACE.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 

MAINTAINERS file has been updated for a couple of release cycles.
Please stop using shawn@linaro.org, and resend to
shawn...@kernel.org instead.

Shawn

> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index c70bb27..6d6e3e2 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -383,6 +383,16 @@
><&platform_clk 1>;
>   };
>  
> + dcu: dcu@2ce {
> + compatible = "fsl,ls1021a-dcu";
> + reg = <0x0 0x2ce 0x0 0x1>;
> + interrupts = ;
> + clocks = <&platform_clk 0>;
> + clock-names = "dcu";
> + big-endian;
> + status = "disabled";
> + };
> +
>   mdio0: mdio@2d24000 {
>   compatible = "gianfar";
>   device_type = "mdio";
> -- 
> 2.1.0.27.g96db324
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
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 07/17] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver

[Krzysztof Kozlowski]

On 22.09.2015 16:43, Yakir Yang wrote:
> After exynos_dp have been split the common IP code into analogix_dp driver,
> the analogix_dp driver have deprecated some Samsung platform properties which
> could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
> for Exynos DTS file for dp-controller.
> 
> Beside the backward compatibility is fully preserved, so there are no
> bisectability break that make this change in a separate patch.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v5:
> - Correct the misspell in commit message. (Krzysztof)
> 
> Changes in v4:
> - Separate all DTS changes to a separate patch. (Krzysztof)
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/boot/dts/exynos5250-arndale.dts   | 2 --
>  arch/arm/boot/dts/exynos5250-smdk5250.dts  | 2 --
>  arch/arm/boot/dts/exynos5250-snow.dts  | 4 +---
>  arch/arm/boot/dts/exynos5250-spring.dts| 4 +---
>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 +---
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  | 2 --
>  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 4 +---
>  7 files changed, 4 insertions(+), 18 deletions(-)
> 

Assuming this will be merged as part of this set (dependency on previous
patches):

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

--
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/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Krzysztof Kozlowski]

On 22.09.2015 16:37, Yakir Yang wrote:
> Both hsync/vsync polarity and interlace mode can be parsed from
> drm display mode, and dynamic_range and ycbcr_coeff can be judge
> by the video code.
> 
> But presumably Exynos still relies on the DT properties, so take
> good use of mode_fixup() in to achieve the compatibility hacks.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v5:
> - Switch video timing type to "u32", so driver could use 
> "of_property_read_u32"
>   to get the backword timing values. 

Okay

> Krzysztof suggest me that driver could use
>   the "of_property_read_bool" to get backword timing values, but that 
> interfacs
>   would modify the original drm_display_mode timing directly (whether those
>   properties exists or not).

Hmm, I don't understand. You have a:
struct video_info {
bool h_sync_polarity;
bool v_sync_polarity;
bool interlaced;
};

so what is wrong with:
dp_video_config->h_sync_polarity =
of_property_read_bool(dp_node, "hsync-active-high");

Is it exactly the same binding as previously?

Best regards,
Krzysztof

> 
> Changes in v4:
> - Provide backword compatibility with samsung. (Krzysztof)
> 
> Changes in v3:
> - Dynamic parse video timing info from struct drm_display_mode and
>   struct drm_display_info. (Thierry)
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 144 
> +
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   8 +-
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
>  3 files changed, 104 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 1e3c8d3..6be139b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
>   return;
>   }
>  
> - ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
> -  dp->video_info->link_rate);
> + ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
> +  dp->video_info.link_rate);
>   if (ret) {
>   dev_err(dp->dev, "unable to do link train\n");
>   return;
> @@ -1030,6 +1030,85 @@ static void analogix_dp_bridge_disable(struct 
> drm_bridge *bridge)
>   dp->dpms_mode = DRM_MODE_DPMS_OFF;
>  }
>  
> +static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *orig_mode,
> + struct drm_display_mode *mode)
> +{
> + struct analogix_dp_device *dp = bridge->driver_private;
> + struct drm_display_info *display_info = &dp->connector->display_info;
> + struct video_info *video = &dp->video_info;
> + struct device_node *dp_node = dp->dev->of_node;
> + int vic;
> +
> + /* Input video interlaces & hsync pol & vsync pol */
> + video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> + video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
> + video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
> +
> + /* Input video dynamic_range & colorimetry */
> + vic = drm_match_cea_mode(mode);
> + if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
> + (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
> + video->dynamic_range = CEA;
> + video->ycbcr_coeff = COLOR_YCBCR601;
> + } else if (vic) {
> + video->dynamic_range = CEA;
> + video->ycbcr_coeff = COLOR_YCBCR709;
> + } else {
> + video->dynamic_range = VESA;
> + video->ycbcr_coeff = COLOR_YCBCR709;
> + }
> +
> + /* Input vide bpc and color_formats */
> + switch (display_info->bpc) {
> + case 12:
> + video->color_depth = COLOR_12;
> + break;
> + case 10:
> + video->color_depth = COLOR_10;
> + break;
> + case 8:
> + video->color_depth = COLOR_8;
> + break;
> + case 6:
> + video->color_depth = COLOR_6;
> + break;
> + default:
> + video->color_depth = COLOR_8;
> + break;
> + }
> + if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
> + video->color_space = COLOR_YCBCR444;
> + else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
> + video->color_space = COLOR_YCBCR422;
> + else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
> + video->color_space = COLOR_RGB;
> + else
> + video->color_space = COLOR_RGB;
> +
> + /*
> +  * NOTE: those property parsing code is used for providing backward
> +  

Re: [RESEND PATCH v3 0/5] usb: change clock information for chipidea

[Shawn Guo]

On Wed, Sep 30, 2015 at 10:25:20AM +0800, Peter Chen wrote:
> This patch set changes usb clock information for legacy i.mx platforms.
> At these platforms, they needs three clocks to let controller work.
> 
> Hi Shawn,
> 
> Fabio has tested for both imx27 and imx25 platforms.
> I have queued 1/5 and 5/5, would you please help to queue others,
> thanks.
> 
> Changes for v3:
> - Delete property "needs-three-clocks", and using of_device_id->data
>   to differentiate platforms
> - change  #v3.19+ to  #v4.1+

So the last patch will be sent as a fix with stable on copy?  In that
case, will USB driver just work without corresponding DTS change?  Or
the driver change has a dependency on the DTS change?

Shawn

> 
> Changes for v2:
> - Add imx25 & imx27 dts change
> - Add Fabio's tested-by and Cc:  #v3.19+
> - Some typo and commit description
> 
> Peter Chen (5):
>   doc: dt-binding: ci-hdrc-usb2: split vendor specific properties
>   ARM: dts: imx27.dtsi: change the clock information for usb
>   ARM: dts: imx25.dtsi: change the clock information for usb
>   ARM: dts: imx35.dtsi: change the clock information for usb
>   usb: chipidea: imx: refine clock operations to adapt for all platforms
> 
>  .../devicetree/bindings/usb/ci-hdrc-usb2.txt   |  10 +-
>  arch/arm/boot/dts/imx25.dtsi   |   8 +-
>  arch/arm/boot/dts/imx27.dtsi   |  16 ++-
>  arch/arm/boot/dts/imx35.dtsi   |   8 +-
>  drivers/usb/chipidea/ci_hdrc_imx.c | 156 
> ++---
>  5 files changed, 164 insertions(+), 34 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 v5 03/17] drm: bridge: analogix/dp: fix some obvious code style

[Krzysztof Kozlowski]

On 22.09.2015 16:34, Yakir Yang wrote:
> Fix some obvious alignment problems, like alignment and line
> over 80 characters problems, make this easy to be maintained
> later.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v5:
> - Resequence this patch after analogix_dp driver have been split
>   from exynos_dp code, and rephrase reasonable commit message, and
>   remove some controversial style (Krzysztof)
> - analogix_dp_write_byte_to_dpcd(
> - dp, DP_TEST_RESPONSE,
> + analogix_dp_write_byte_to_dpcd(dp,
> + DP_TEST_RESPONSE,
>   DP_TEST_EDID_CHECKSUM_WRITE);
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Improved commit message more readable, and avoid using some
>   uncommon style like bellow: (Joe Preches)
> -  retval = exynos_dp_read_bytes_from_i2c(...
> ...);
> +  retval =
> +  exynos_dp_read_bytes_from_i2c(..);
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 
> ++---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
>  3 files changed, 163 insertions(+), 162 deletions(-)
> 

IMHO much better than in previous attempt. The code looks good:

Reviewed-by: Krzysztof Kozlowski 

BTW my opinion is not enough, you still need an ack from Exynos DP
maintainer (or DRM guys).


Best regards,
Krzysztof

--
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 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Krzysztof Kozlowski]

On 22.09.2015 16:29, Yakir Yang wrote:
> Split the dp core driver from exynos directory to bridge directory,
> and rename the core driver to analogix_dp_*, rename the platform
> code to exynos_dp.
> 
> Beside the new analogix_dp driver would export four hooks.
> "analogix_dp_bind()" and "analogix_dp_unbind()"
> "analogix_dp_detect()" and "analogix_dp_get_modes()"
> 
> The bind/unbind symbols is used for analogix platform driver to connect
> with analogix_dp core driver. And the detect/get_modes is used for analogix
> platform driver to init the connector.
> 
> They reason why connector need register in helper driver is rockchip drm
> haven't implement the atomic API, but Exynos drm have implement it, so
> there would need two different connector helper functions, that's why we
> leave the connector register in helper driver.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v5:
> - Correct the check condition of gpio_is_valid when driver try to get
>   the "hpd-gpios" DT propery. (Heiko)
> - Move the platform attach callback in the front of core driver bridge
>   attch function. Cause once platform failed at attach, core driver should
>   still failed, so no need to init connector before platform attached 
> (Krzysztof)
> - Keep code style no changes with the previous exynos_dp_code.c in this
>   patch, and update commit message about the new export symbol (Krzysztof)
> - Gather the device type patch (v4 11/16) into this one. (Krzysztof)
> - leave out the connector registration to analogix platform driver. (Thierry)

Thanks for fixing this, looks much better.

I don't feel comfortable enough to provide a review tag but it looks
good to me.

Best regards,
Krzysztof

--
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] ARM: sun7i: dt: Add new Olimex A20 EVB device

[Maxime Ripard]

On Sun, Sep 27, 2015 at 08:16:42AM +0200, codekip...@gmail.com wrote:
> 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 v3:
> - removed i2c1 as it's not used
> - removed axp_ipsout regulator
> 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 | 202 
> +
>  2 files changed, 203 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 1c5f225..0e87a54 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -618,6 +618,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..3317c22
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> @@ -0,0 +1,202 @@
> +/*
> + * 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";
> + };
> + };
> +};
> +
> +&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>;
> + };
> +};

Re: [PATCH v3 2/2] iio:light:ap3223: Add DT support

[Rob Herring]

On Tue, Sep 29, 2015 at 8:36 PM, Suresh Rajashekara
 wrote:
> * Add Device Tree support for the Dyna Image AP3223 ambient light sensor and
> * proximity driver,
> * Document the binding and
> * Add a vendor prefix for Dyna Image
>
> v3
> * Fixing typo in comment
> v2
> * Seperating the device tree changes from code
>
> Signed-off-by: Suresh Rajashekara 
> ---
>  Documentation/devicetree/bindings/iio/light/ap3223.txt | 18 
> ++
>  Documentation/devicetree/bindings/vendor-prefixes.txt  |  1 +
>  2 files changed, 19 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/light/ap3223.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/light/ap3223.txt 
> b/Documentation/devicetree/bindings/iio/light/ap3223.txt
> new file mode 100644
> index 000..b255d27
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/ap3223.txt
> @@ -0,0 +1,18 @@
> +* Dyna Image AP3223 ambient light sensor and proximity sensor
> +
> +http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2&dpid=8
> +
> +Required properties:
> +
> +  - compatible : should be "dynaimage,ap3223"
> +  - reg : the I2C address of the sensor

We have i2c/trivial-devices.txt for simple devices.

> +
> +Example:
> +
> +ap3223@1c {
> +   compatible = "dynaimage,ap3223";
> +   reg = <0x1c>;
> +
> +   pinctrl-0 = <&ap3223_pins>;
> +   pinctrl-names = "default";

This doesn't belong here.

> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 5f20add..704da45 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -46,6 +46,7 @@ digilent  Diglent, Inc.
>  dlgDialog Semiconductor
>  dlink  D-Link Corporation
>  dmoData Modul AG
> +dynaimage  Dyna-Image
>  ebvEBV Elektronik
>  edtEmerging Display Technologies
>  elan   Elan Microelectronic Corp.
> --
> 2.6.0.rc2.230.g3dd15c0
>
--
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

[RESEND PATCH v3 2/5] ARM: dts: imx27.dtsi: change the clock information for usb

[Peter Chen]

For imx27, it needs three clocks to let the controller work,
the old code is wrong, and usbmisc has not included clock handling
code any more. Without this patch, it will cause below data
abort when accessing usbmisc registers.

usbcore: registered new interface driver usb-storage
Unhandled fault: external abort on non-linefetch (0x008) at 0xf4424600
pgd = c0004000
[f4424600] *pgd=1452(bad)
Internal error: : 8 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.0-next-20150701-dirty #3089
Hardware name: Freescale i.MX27 (Device Tree Support)
task: c7832b60 ti: c783e000 task.ti: c783e000
PC is at usbmisc_imx27_init+0x4c/0xbc
LR is at usbmisc_imx27_init+0x40/0xbc
pc : []lr : []psr: 6093
sp : c783fe08  ip :   fp : 
r10: c0576434  r9 : 009c  r8 : c7a773a0
r7 : 0100  r6 : 6013  r5 : c7a776f0  r4 : c7a773f0
r3 : f4424600  r2 :   r1 : 0001  r0 : 0001
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 0005317f  Table: a0004000  DAC: 0017
Process swapper (pid: 1, stack limit = 0xc783e190)
Stack: (0xc783fe08 to 0xc784)

Signed-off-by: Peter Chen 
Reported-by: Fabio Estevam 
Tested-by: Fabio Estevam 
Cc:  #v4.1+
---
 arch/arm/boot/dts/imx27.dtsi | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index feb9d34..f818ea4 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -486,7 +486,10 @@
compatible = "fsl,imx27-usb";
reg = <0x10024000 0x200>;
interrupts = <56>;
-   clocks = <&clks IMX27_CLK_USB_IPG_GATE>;
+   clocks = <&clks IMX27_CLK_USB_IPG_GATE>,
+   <&clks IMX27_CLK_USB_AHB_GATE>,
+   <&clks IMX27_CLK_USB_DIV>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = <&usbmisc 0>;
status = "disabled";
};
@@ -495,7 +498,10 @@
compatible = "fsl,imx27-usb";
reg = <0x10024200 0x200>;
interrupts = <54>;
-   clocks = <&clks IMX27_CLK_USB_IPG_GATE>;
+   clocks = <&clks IMX27_CLK_USB_IPG_GATE>,
+   <&clks IMX27_CLK_USB_AHB_GATE>,
+   <&clks IMX27_CLK_USB_DIV>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = <&usbmisc 1>;
dr_mode = "host";
status = "disabled";
@@ -505,7 +511,10 @@
compatible = "fsl,imx27-usb";
reg = <0x10024400 0x200>;
interrupts = <55>;
-   clocks = <&clks IMX27_CLK_USB_IPG_GATE>;
+   clocks = <&clks IMX27_CLK_USB_IPG_GATE>,
+   <&clks IMX27_CLK_USB_AHB_GATE>,
+   <&clks IMX27_CLK_USB_DIV>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = <&usbmisc 2>;
dr_mode = "host";
status = "disabled";
@@ -515,7 +524,6 @@
#index-cells = <1>;
compatible = "fsl,imx27-usbmisc";
reg = <0x10024600 0x200>;
-   clocks = <&clks IMX27_CLK_USB_AHB_GATE>;
};
 
sahara2: sahara@10025000 {
-- 
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

[RESEND PATCH v3 1/5] doc: dt-binding: ci-hdrc-usb2: split vendor specific properties

[Peter Chen]

Each vendor may have its specific properties, they are not belonged
to common optional properties, split them from common's.

Signed-off-by: Peter Chen 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
index 77946f5..27dc705 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -27,10 +27,6 @@ Optional properties:
 - vbus-supply: reference to the VBUS regulator
 - maximum-speed: limit the maximum connection speed to "full-speed".
 - tpl-support: TPL (Targeted Peripheral List) feature for targeted hosts
-- fsl,usbmisc: (FSL only) phandler of non-core register device, with one
-  argument that indicate usb controller index
-- disable-over-current: (FSL only) disable over current detect
-- external-vbus-divider: (FSL only) enables off-chip resistor divider for Vbus
 - itc-setting: interrupt threshold control register control, the setting
   should be aligned with ITC bits at register USBCMD.
 - ahb-burst-config: it is vendor dependent, the required value should be
@@ -54,6 +50,12 @@ Optional properties:
 - phy-clkgate-delay-us: the delay time (us) between putting the PHY into
   low power mode and gating the PHY clock.
 
+i.mx specific properties
+- fsl,usbmisc: phandler of non-core register device, with one
+  argument that indicate usb controller index
+- disable-over-current: disable over current detect
+- external-vbus-divider: enables off-chip resistor divider for Vbus
+
 Example:
 
usb@f7ed {
-- 
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

[RESEND PATCH v3 0/5] usb: change clock information for chipidea

[Peter Chen]

This patch set changes usb clock information for legacy i.mx platforms.
At these platforms, they needs three clocks to let controller work.

Hi Shawn,

Fabio has tested for both imx27 and imx25 platforms.
I have queued 1/5 and 5/5, would you please help to queue others,
thanks.

Changes for v3:
- Delete property "needs-three-clocks", and using of_device_id->data
  to differentiate platforms
- change  #v3.19+ to  #v4.1+

Changes for v2:
- Add imx25 & imx27 dts change
- Add Fabio's tested-by and Cc:  #v3.19+
- Some typo and commit description

Peter Chen (5):
  doc: dt-binding: ci-hdrc-usb2: split vendor specific properties
  ARM: dts: imx27.dtsi: change the clock information for usb
  ARM: dts: imx25.dtsi: change the clock information for usb
  ARM: dts: imx35.dtsi: change the clock information for usb
  usb: chipidea: imx: refine clock operations to adapt for all platforms

 .../devicetree/bindings/usb/ci-hdrc-usb2.txt   |  10 +-
 arch/arm/boot/dts/imx25.dtsi   |   8 +-
 arch/arm/boot/dts/imx27.dtsi   |  16 ++-
 arch/arm/boot/dts/imx35.dtsi   |   8 +-
 drivers/usb/chipidea/ci_hdrc_imx.c | 156 ++---
 5 files changed, 164 insertions(+), 34 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

[RESEND PATCH v3 4/5] ARM: dts: imx35.dtsi: change the clock information for usb

[Peter Chen]

For imx35, it needs three clocks to let the controller work,
the old code is wrong, and the usbmisc does not include
clock handling code any more.

Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx35.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index e6540b5..5b887d0 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -305,7 +305,8 @@
compatible = "fsl,imx35-usb", "fsl,imx27-usb";
reg = <0x53ff4000 0x0200>;
interrupts = <37>;
-   clocks = <&clks 73>;
+   clocks = <&clks 9>, <&clks 73>, <&clks 28>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = <&usbmisc 0>;
fsl,usbphy = <&usbphy0>;
status = "disabled";
@@ -315,7 +316,8 @@
compatible = "fsl,imx35-usb", "fsl,imx27-usb";
reg = <0x53ff4400 0x0200>;
interrupts = <35>;
-   clocks = <&clks 73>;
+   clocks = <&clks 9>, <&clks 73>, <&clks 28>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = <&usbmisc 1>;
fsl,usbphy = <&usbphy1>;
dr_mode = "host";
@@ -325,8 +327,6 @@
usbmisc: usbmisc@53ff4600 {
#index-cells = <1>;
compatible = "fsl,imx35-usbmisc";
-   clocks = <&clks 9>, <&clks 73>, <&clks 28>;
-   clock-names = "ipg", "ahb", "per";
reg = <0x53ff4600 0x00f>;
};
};
-- 
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

[RESEND PATCH v3 5/5] usb: chipidea: imx: refine clock operations to adapt for all platforms

[Peter Chen]

Some i.mx platforms need three clocks to let controller work, but
others only need one, refine clock operation to adapt for all
platforms, it fixes a regression found at i.mx27.

Signed-off-by: Peter Chen 
Tested-by: Fabio Estevam 
Cc:  #v4.1+
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 156 -
 1 file changed, 138 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 6ccbf60..6ec0fbc 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -32,6 +32,10 @@ static const struct ci_hdrc_imx_platform_flag imx27_usb_data 
= {
CI_HDRC_DISABLE_STREAMING,
 };
 
+static const struct ci_hdrc_imx_platform_flag imx31_usb_data = {
+   CI_HDRC_DISABLE_STREAMING,
+};
+
 static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
.flags = CI_HDRC_IMX28_WRITE_FIX |
CI_HDRC_TURN_VBUS_EARLY_ON |
@@ -68,6 +72,13 @@ static const struct ci_hdrc_imx_platform_flag imx7d_usb_data 
= {
 static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
{ .compatible = "fsl,imx28-usb", .data = &imx28_usb_data},
{ .compatible = "fsl,imx27-usb", .data = &imx27_usb_data},
+   { .compatible = "fsl,imx25-usb", .data = &imx27_usb_data},
+   { .compatible = "fsl,imx35-usb", .data = &imx27_usb_data},
+   { .compatible = "fsl,imx23-usb", .data = &imx31_usb_data},
+   { .compatible = "fsl,imx31-usb", .data = &imx31_usb_data},
+   { .compatible = "fsl,imx50-usb", .data = &imx31_usb_data},
+   { .compatible = "fsl,imx51-usb", .data = &imx31_usb_data},
+   { .compatible = "fsl,imx53-usb", .data = &imx31_usb_data},
{ .compatible = "fsl,imx6q-usb", .data = &imx6q_usb_data},
{ .compatible = "fsl,imx6sl-usb", .data = &imx6sl_usb_data},
{ .compatible = "fsl,imx6sx-usb", .data = &imx6sx_usb_data},
@@ -77,6 +88,15 @@ static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, ci_hdrc_imx_dt_ids);
 
+static inline bool imx_needs_three_clocks
+   (const struct ci_hdrc_imx_platform_flag *imx_platform_flag)
+{
+   if (imx_platform_flag == &imx27_usb_data)
+   return true;
+
+   return false;
+}
+
 struct ci_hdrc_imx_data {
struct usb_phy *phy;
struct platform_device *ci_pdev;
@@ -84,6 +104,12 @@ struct ci_hdrc_imx_data {
struct imx_usbmisc_data *usbmisc_data;
bool supports_runtime_pm;
bool in_lpm;
+   /* SoC before i.mx6 (except imx23/imx28) needs three clks */
+   bool need_three_clks;
+   struct clk *clk_ipg;
+   struct clk *clk_ahb;
+   struct clk *clk_per;
+   /* - */
 };
 
 /* Common functions shared by usbmisc drivers */
@@ -135,6 +161,105 @@ static struct imx_usbmisc_data 
*usbmisc_get_init_data(struct device *dev)
 }
 
 /* End of common functions shared by usbmisc drivers*/
+static int imx_get_clks(struct device *dev)
+{
+   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+   int ret = 0;
+
+   if (data->need_three_clks) {
+   data->clk_ipg = devm_clk_get(dev, "ipg");
+   if (IS_ERR(data->clk_ipg)) {
+   ret = PTR_ERR(data->clk_ipg);
+   dev_err(dev,
+   "Failed to get ipg clock, err=%d\n", ret);
+   return ret;
+   }
+
+   data->clk_ahb = devm_clk_get(dev, "ahb");
+   if (IS_ERR(data->clk_ahb)) {
+   ret = PTR_ERR(data->clk_ahb);
+   dev_err(dev,
+   "Failed to get ahb clock, err=%d\n", ret);
+   return ret;
+   }
+
+   data->clk_per = devm_clk_get(dev, "per");
+   if (IS_ERR(data->clk_per)) {
+   ret = PTR_ERR(data->clk_per);
+   dev_err(dev,
+   "Failed to get per clock, err=%d\n", ret);
+   return ret;
+   }
+   } else {
+   data->clk = devm_clk_get(dev, NULL);
+   if (IS_ERR(data->clk)) {
+   ret = PTR_ERR(data->clk);
+   dev_err(dev,
+   "Failed to get clock, err=%d\n", ret);
+   return ret;
+   }
+   }
+
+   return ret;
+}
+
+static int imx_prepare_enable_clks(struct device *dev)
+{
+   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+   int ret = 0;
+
+   if (data->need_three_clks) {
+   ret = clk_prepare_enable(data->clk_ipg);
+   if (ret) {
+   dev_err(dev,
+   "Failed to prepare/enable ipg clk, err=%d\n",
+   ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(dat

[RESEND PATCH v3 3/5] ARM: dts: imx25.dtsi: change the clock information for usb

[Peter Chen]

For imx25, it needs three clocks to let the controller work,
the old code is wrong, and usbmisc has not included clock
handling code any more.

Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx25.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 677f81d..ab843bd 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -493,7 +493,8 @@
compatible = "fsl,imx25-usb", "fsl,imx27-usb";
reg = <0x53ff4000 0x0200>;
interrupts = <37>;
-   clocks = <&clks 70>;
+   clocks = <&clks 9>, <&clks 70>, <&clks 8>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = <&usbmisc 0>;
fsl,usbphy = <&usbphy0>;
status = "disabled";
@@ -503,7 +504,8 @@
compatible = "fsl,imx25-usb", "fsl,imx27-usb";
reg = <0x53ff4400 0x0200>;
interrupts = <35>;
-   clocks = <&clks 70>;
+   clocks = <&clks 9>, <&clks 70>, <&clks 8>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = <&usbmisc 1>;
fsl,usbphy = <&usbphy1>;
status = "disabled";
@@ -512,8 +514,6 @@
usbmisc: usbmisc@53ff4600 {
#index-cells = <1>;
compatible = "fsl,imx25-usbmisc";
-   clocks = <&clks 9>, <&clks 70>, <&clks 8>;
-   clock-names = "ipg", "ahb", "per";
reg = <0x53ff4600 0x00f>;
};
 
-- 
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 0/5] usb: change clock information for chipidea

[Shawn Guo]

On Tue, Sep 22, 2015 at 7:56 AM, Peter Chen  wrote:
> On Mon, Sep 21, 2015 at 09:49:11PM -0300, Fabio Estevam wrote:
>> On Sun, Sep 20, 2015 at 9:43 PM, Peter Chen  wrote:
>> > This patch set changes usb clock information for legacy i.mx platforms.
>> > At these platforms, they needs three clocks to let controller work.
>> >
>> > Hi Fabio,
>> >
>> > Would you please have a test at imx27 and imx25 boards, thanks.
>>
>> Works fine on both boards, thanks
>
> Hi Shawn,
>
> Would you please help to queue dts changes (2/5, 3/5, 4/5)?

Please send them to Shawn Guo .

Shawn
--
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 7/7] pinctrl: freescale: imx: imx7d iomuxc-lpsr devicetree bindings

[Shawn Guo]

On Mon, Sep 28, 2015 at 04:56:41PM -0500, Adrian Alonso wrote:
> Add iomuxc-lpsr devicetree bindings documentation
> Provide documentation context as well an example on
> pheriperals that could use pad from either iomuxc controller
> supported by iMX7D SoC
> 
> Signed-off-by: Adrian Alonso 
> ---
> Changes for V2: New patch on imx7d iomuxc-lpsr patch series
> Changes for V3: Add shared input select register notes
> Changes for V4: Resend
> Changes for V5:
> - Fix spell error
> - Remove references of SHARE_INPUT_SELECT_REG flag
> Changes for V6: Resend
> Changes for v7: Resend
> 
>  .../bindings/pinctrl/fsl,imx7d-pinctrl.txt | 63 
> +-
>  1 file changed, 62 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
> index 8bbf25d..aae069f 100644
> --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
> @@ -1,16 +1,42 @@
>  * Freescale i.MX7 Dual IOMUX Controller
>  
> +iMX7D supports two iomuxc controllers, fsl,imx7d-iomuxc controller is similar
> +as previous iMX SoC generation and fsl,imx7d-iomuxc-lpsr which provides low
> +power state retention capabilities on gpios that are part of iomuxc-lpsr
> +(GPIO1_IO7..GPIO1_IO0). While iomuxc-lpsr provides its own set of registers 
> for
> +mux and pad control settings, it shares the input select register from main
> +iomuxc controller for daisy chain settings, the fsl,input-sel property 
> extends
> +fsl,imx-pinctrl driver to support iomuxc-lpsr controller.
> +
> +iomuxc_lpsr: iomuxc-lpsr@302c {
> + compatible = "fsl,imx7d-iomuxc-lpsr";
> + reg = <0x302c 0x1>;
> + fsl,input-sel = <&iomuxc>;
> +};
> +
> +iomuxc: iomuxc@3033 {
> + compatible = "fsl,imx7d-iomuxc";
> + reg = <0x3033 0x1>;
> +};
> +
> +Pheriparials using pads from iomuxc-lpsr support low state retention power
> +state, under LPSR mode GPIO's state of pads are retain.
> +
>  Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
>  and usage.
>  
>  Required properties:
> -- compatible: "fsl,imx7d-iomuxc"
> +- compatible: "fsl,imx7d-iomuxc" for main IOMUXC controller, or
> +  "fsl,imx7d-iomuxc-lpsr" for Low Power State Retention IOMUXC controller.
>  - fsl,pins: each entry consists of 6 integers and represents the mux and 
> config
>setting for one pin.  The first 5 integers  mux_val
>input_val> are specified using a PIN_FUNC_ID macro, which can be found in
>imx7d-pinfunc.h under device tree source folder.  The last integer CONFIG 
> is
>the pad setting value like pull-up on this pin.  Please refer to i.MX7 Dual
>Reference Manual for detailed CONFIG settings.
> +- fsl,input-sel: required property for iomuxc-lpsr controller, this property 
> is
> +  a phandle for main iomuxc controller which shares the input select 
> register for
> +  daisy chain settings.
>  
>  CONFIG bits definition:
>  PAD_CTL_PUS_100K_DOWN   (0 << 5)
> @@ -25,3 +51,38 @@ PAD_CTL_DSE_X1  (0 << 0)
>  PAD_CTL_DSE_X2  (1 << 0)
>  PAD_CTL_DSE_X3  (2 << 0)
>  PAD_CTL_DSE_X4  (3 << 0)
> +
> +Examples:
> +While iomuxc-lpsr is intended to be used by dedicated peripherals to take
> +advantages of LPSR power mode, is also possible that an IP to use pads from
> +any of the iomux controllers. For example the I2C1 IP can use SCL pad from
> +iomuxc-lpsr controller and SDA pad from iomuxc controller as:
> +
> +i2c1: i2c@30a2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1_1 &pinctrl_i2c1_2>;
> + status = "okay";
> +};
> +
> +iomuxc-lpsr@302c {
> + compatible = "fsl,imx7d-iomuxc-lpsr";
> + reg = <0x302c 0x1>;
> + fsl,input-sel = <&iomuxc>;
> +
> + pinctrl_i2c1_1: i2c1grp-1 {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x407f
> + >;
> + };
> +};
> +
> +iomuxc@3033 {
> + compatible = "fsl,imx7d-iomuxc";
> + reg = <0x3033 0x1>;
> +
> + pinctrl_i2c1_2: i2c1grp-2 {
> + fsl,pins = <
> + MX7D_PAD_I2C1_SCL__I2C1_SCL 0x407f

I'm not sure how many times I should repeat: you should set up a
I2C1_SDA instead of two I2C1_SCL in this example.

Shawn

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

Re: [PATCH v7 1/7] ARM: dts: imx: imx7d-sbd remove fixed can2-3v3 regulator

[Shawn Guo]

On Mon, Sep 28, 2015 at 04:56:35PM -0500, Adrian Alonso wrote:
> Remove incorrect can2-3v3 fixed regulator, imx7d-sdb doesn't
> have a dedicated can2 fixed regulator instead it shares PERI_3V3
> fixed regulator (RT8070ZS) which is enabled by default (hardwired)
> from pmic pfuze3000 NVCC_3V3 power rail.

@Frank, can you please confirm it? 

> 
> Signed-off-by: Adrian Alonso 

Please stop sending patch to shawn@linaro.org, and
shawn...@kernel.org is good enough.

> ---
> Changes for V7: New patch in series

I do not understand why the patch has to be included in this series. 

Shawn

> 
>  arch/arm/boot/dts/imx7d-sdb.dts | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index 8059458..83f0053 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -78,16 +78,7 @@
>   enable-active-high;
>   };
>  
> - reg_can2_3v3: regulator@2 {
> - compatible = "regulator-fixed";
> - reg = <2>;
> - regulator-name = "can2-3v3";
> - regulator-min-microvolt = <330>;
> - regulator-max-microvolt = <330>;
> - gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
> - };
> -
> - reg_vref_1v8: regulator@3 {
> + reg_vref_1v8: regulator@2 {
>   compatible = "regulator-fixed";
>   reg = <3>;
>   regulator-name = "vref-1v8";
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] iio:light:ap3223: Add DT support

[Suresh Rajashekara]

* Add Device Tree support for the Dyna Image AP3223 ambient light sensor and
* proximity driver,
* Document the binding and
* Add a vendor prefix for Dyna Image

v3
* Fixing typo in comment
v2
* Seperating the device tree changes from code

Signed-off-by: Suresh Rajashekara 
---
 Documentation/devicetree/bindings/iio/light/ap3223.txt | 18 ++
 Documentation/devicetree/bindings/vendor-prefixes.txt  |  1 +
 2 files changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/ap3223.txt

diff --git a/Documentation/devicetree/bindings/iio/light/ap3223.txt 
b/Documentation/devicetree/bindings/iio/light/ap3223.txt
new file mode 100644
index 000..b255d27
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/ap3223.txt
@@ -0,0 +1,18 @@
+* Dyna Image AP3223 ambient light sensor and proximity sensor
+
+http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2&dpid=8
+
+Required properties:
+
+  - compatible : should be "dynaimage,ap3223"
+  - reg : the I2C address of the sensor
+
+Example:
+
+ap3223@1c {
+   compatible = "dynaimage,ap3223";
+   reg = <0x1c>;
+
+   pinctrl-0 = <&ap3223_pins>;
+   pinctrl-names = "default";
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 5f20add..704da45 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -46,6 +46,7 @@ digilent  Diglent, Inc.
 dlgDialog Semiconductor
 dlink  D-Link Corporation
 dmoData Modul AG
+dynaimage  Dyna-Image
 ebvEBV Elektronik
 edtEmerging Display Technologies
 elan   Elan Microelectronic Corp.
-- 
2.6.0.rc2.230.g3dd15c0

--
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 v3 1/2] iio:light: Add Dyna-Image AP3223 ambient light and proximity driver

[Suresh Rajashekara]

Minimal implementation with support for raw light and proximity reading.

This is based on the driver provided by the vendor
(which was an input driver). Authors of the
driver from the vendor included
* John Huang 
* Templeton Tsai 
* Vic Lee 

v3
* Resubmitting due to typo in accompanying patch

v2
* Using regmap framework
* Error handling
* Code cleanups following comments

Signed-off-by: Suresh Rajashekara 
---
 drivers/iio/light/Kconfig  |  11 +
 drivers/iio/light/Makefile |   1 +
 drivers/iio/light/ap3223.c | 706 +
 3 files changed, 718 insertions(+)
 create mode 100644 drivers/iio/light/ap3223.c

diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index ae68c64..5c93ef0 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -27,6 +27,17 @@ config AL3320A
 To compile this driver as a module, choose M here: the
 module will be called al3320a.
 
+config AP3223
+   tristate "AP3223 ambient light and proximity sensor"
+   depends on I2C
+   select REGMAP_I2C
+   help
+Say Y here if you want to build a driver for the Dyna Image AP3223
+ambient light and proximity sensor.
+
+To compile this driver as a module, choose M here: the
+module will be called ap3223.
+
 config APDS9300
tristate "APDS9300 ambient light sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index b12a516..13a74f9 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -5,6 +5,7 @@
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_ADJD_S311)+= adjd_s311.o
 obj-$(CONFIG_AL3320A)  += al3320a.o
+obj-$(CONFIG_AP3223)   += ap3223.o
 obj-$(CONFIG_APDS9300) += apds9300.o
 obj-$(CONFIG_CM32181)  += cm32181.o
 obj-$(CONFIG_CM3232)   += cm3232.o
diff --git a/drivers/iio/light/ap3223.c b/drivers/iio/light/ap3223.c
new file mode 100644
index 000..6b457c1
--- /dev/null
+++ b/drivers/iio/light/ap3223.c
@@ -0,0 +1,706 @@
+/*
+ * Copyright (C) 2015 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ * Note about the original authors:
+ *
+ * The driver for AP3223 was originally distributed by dyna image in a
+ * different framework (as an input driver). This driver uses code from
+ * that driver and converts it to iio framework. The non-iio driver from
+ * dyna image is not available online anywhere, so there is no reference
+ * for it here. However, that driver is also GPLv2.
+ * The following is part of the header found in that file
+ * (The GPL notice from the original header is removed)
+ *
+ * >> This file is part of the AP3223, AP3212C and AP3216C sensor driver.
+ * >> AP3426 is combined proximity and ambient light sensor.
+ * >> AP3216C is combined proximity, ambient light sensor and IRLED.
+ * >>
+ * >> Contact: John Huang 
+ * >> Templeton Tsai 
+ *
+ * Another author initials mentioned in that file was just YC (and no name).
+ *
+ * Not sure for what kernel version the driver from dyna image was written for.
+ * Vic Lee  made modifications to it to run on 3.14.
+ *
+ * Datasheet:
+ * 
http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2&dpid=8#doc
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AP3223_DRV_NAME "ap3223"
+
+/* ap3223 control registers */
+
+#defineAP3223_REG_SYS_CTRL 0x00
+#define AP3223_REG_SYS_CTRL_SHIFT  (0)
+#define AP3223_REG_SYS_CTRL_MASK   0x07
+
+/* System Mode (AP3223_REG_SYS_CTRL) */
+
+#define AP3223_SYS_DEV_DOWN0x00
+#define AP3223_SYS_ALS_ENABLE  0x01
+#define AP3223_SYS_PS_ENABLE   0x02
+#define AP3223_SYS_ALS_PS_ENABLE   0x03
+#define AP3223_SYS_DEV_RESET   0x04
+
+#define AP3223_REG_SYS_INTSTATUS   0x01
+#define AP3223_REG_SYS_INT_SHIFT   (0)
+#define AP3223_REG_SYS_INT_ALS_SHIFT   (0)
+#define AP3223_REG_SYS_INT_PS_SHIFT(1)
+#define AP3223_REG_SYS_INT_OBJ_SHIFT   (4)
+#define AP3223_REG_SYS_INT_IR_OV_SHIFT (5)
+
+/* INT FLAG BIT MASK */
+
+#define AP3223_REG_SYS_INT_MASK0x03
+#define AP3223_REG_SYS_INT_AMASK   0x01
+#define AP3223_REG_SYS_INT_PMASK   0x02
+#define AP3223_REG_SYS_INT_OBJ_MASK0x10
+#define AP3223_REG_SYS_INT_IR_OV_MASK  0x20
+
+#define AP3223_REG_SYS_INTCTRL 0x02
+
+/* INT Clear Manner */
+
+#defineAP3223_SYS_INT_CLEAR_AU

[PATCH v2 2/2] iio:light:tsl2563: Add DT support

[Suresh Rajashekara]

* Add Device Tree support for the Dyna Image AP3223 ambient light sensor and
* proximity driver,
* Document the binding and
* Add a vendor prefix for Dyna Image

v2
* Seperating the device tree changes from code

Signed-off-by: Suresh Rajashekara 
---
 Documentation/devicetree/bindings/iio/light/ap3223.txt | 18 ++
 Documentation/devicetree/bindings/vendor-prefixes.txt  |  1 +
 2 files changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/light/ap3223.txt

diff --git a/Documentation/devicetree/bindings/iio/light/ap3223.txt 
b/Documentation/devicetree/bindings/iio/light/ap3223.txt
new file mode 100644
index 000..b255d27
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/ap3223.txt
@@ -0,0 +1,18 @@
+* Dyna Image AP3223 ambient light sensor and proximity sensor
+
+http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2&dpid=8
+
+Required properties:
+
+  - compatible : should be "dynaimage,ap3223"
+  - reg : the I2C address of the sensor
+
+Example:
+
+ap3223@1c {
+   compatible = "dynaimage,ap3223";
+   reg = <0x1c>;
+
+   pinctrl-0 = <&ap3223_pins>;
+   pinctrl-names = "default";
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 5f20add..704da45 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -46,6 +46,7 @@ digilent  Diglent, Inc.
 dlgDialog Semiconductor
 dlink  D-Link Corporation
 dmoData Modul AG
+dynaimage  Dyna-Image
 ebvEBV Elektronik
 edtEmerging Display Technologies
 elan   Elan Microelectronic Corp.
-- 
2.6.0.rc2.230.g3dd15c0

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

[PATCH v2 1/2] iio:light: Add Dyna-Image AP3223 ambient light and proximity driver

[Suresh Rajashekara]

Minimal implementation with support for raw light and proximity reading.

This is based on the driver provided by the vendor
(which was an input driver). Authors of the
driver from the vendor included
* John Huang 
* Templeton Tsai 
* Vic Lee 

v2
* Using regmap framework
* Error handling
* Code cleanups following comments

Signed-off-by: Suresh Rajashekara 
---
 drivers/iio/light/Kconfig  |  11 +
 drivers/iio/light/Makefile |   1 +
 drivers/iio/light/ap3223.c | 706 +
 3 files changed, 718 insertions(+)
 create mode 100644 drivers/iio/light/ap3223.c

diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index ae68c64..5c93ef0 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -27,6 +27,17 @@ config AL3320A
 To compile this driver as a module, choose M here: the
 module will be called al3320a.
 
+config AP3223
+   tristate "AP3223 ambient light and proximity sensor"
+   depends on I2C
+   select REGMAP_I2C
+   help
+Say Y here if you want to build a driver for the Dyna Image AP3223
+ambient light and proximity sensor.
+
+To compile this driver as a module, choose M here: the
+module will be called ap3223.
+
 config APDS9300
tristate "APDS9300 ambient light sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index b12a516..13a74f9 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -5,6 +5,7 @@
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_ADJD_S311)+= adjd_s311.o
 obj-$(CONFIG_AL3320A)  += al3320a.o
+obj-$(CONFIG_AP3223)   += ap3223.o
 obj-$(CONFIG_APDS9300) += apds9300.o
 obj-$(CONFIG_CM32181)  += cm32181.o
 obj-$(CONFIG_CM3232)   += cm3232.o
diff --git a/drivers/iio/light/ap3223.c b/drivers/iio/light/ap3223.c
new file mode 100644
index 000..6b457c1
--- /dev/null
+++ b/drivers/iio/light/ap3223.c
@@ -0,0 +1,706 @@
+/*
+ * Copyright (C) 2015 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ * Note about the original authors:
+ *
+ * The driver for AP3223 was originally distributed by dyna image in a
+ * different framework (as an input driver). This driver uses code from
+ * that driver and converts it to iio framework. The non-iio driver from
+ * dyna image is not available online anywhere, so there is no reference
+ * for it here. However, that driver is also GPLv2.
+ * The following is part of the header found in that file
+ * (The GPL notice from the original header is removed)
+ *
+ * >> This file is part of the AP3223, AP3212C and AP3216C sensor driver.
+ * >> AP3426 is combined proximity and ambient light sensor.
+ * >> AP3216C is combined proximity, ambient light sensor and IRLED.
+ * >>
+ * >> Contact: John Huang 
+ * >> Templeton Tsai 
+ *
+ * Another author initials mentioned in that file was just YC (and no name).
+ *
+ * Not sure for what kernel version the driver from dyna image was written for.
+ * Vic Lee  made modifications to it to run on 3.14.
+ *
+ * Datasheet:
+ * 
http://www.dyna-image.com/english/product/optical-sensor-detail.php?cpid=2&dpid=8#doc
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AP3223_DRV_NAME "ap3223"
+
+/* ap3223 control registers */
+
+#defineAP3223_REG_SYS_CTRL 0x00
+#define AP3223_REG_SYS_CTRL_SHIFT  (0)
+#define AP3223_REG_SYS_CTRL_MASK   0x07
+
+/* System Mode (AP3223_REG_SYS_CTRL) */
+
+#define AP3223_SYS_DEV_DOWN0x00
+#define AP3223_SYS_ALS_ENABLE  0x01
+#define AP3223_SYS_PS_ENABLE   0x02
+#define AP3223_SYS_ALS_PS_ENABLE   0x03
+#define AP3223_SYS_DEV_RESET   0x04
+
+#define AP3223_REG_SYS_INTSTATUS   0x01
+#define AP3223_REG_SYS_INT_SHIFT   (0)
+#define AP3223_REG_SYS_INT_ALS_SHIFT   (0)
+#define AP3223_REG_SYS_INT_PS_SHIFT(1)
+#define AP3223_REG_SYS_INT_OBJ_SHIFT   (4)
+#define AP3223_REG_SYS_INT_IR_OV_SHIFT (5)
+
+/* INT FLAG BIT MASK */
+
+#define AP3223_REG_SYS_INT_MASK0x03
+#define AP3223_REG_SYS_INT_AMASK   0x01
+#define AP3223_REG_SYS_INT_PMASK   0x02
+#define AP3223_REG_SYS_INT_OBJ_MASK0x10
+#define AP3223_REG_SYS_INT_IR_OV_MASK  0x20
+
+#define AP3223_REG_SYS_INTCTRL 0x02
+
+/* INT Clear Manner */
+
+#defineAP3223_SYS_INT_CLEAR_AUTO   0x00
+#defineAP3223_SYS_INT_CLEAR_MA

Re: [PATCH v5 2/4] Documentation: arm64/arm: dt bindings for numa.

[Benjamin Herrenschmidt]

On Tue, 2015-09-29 at 14:08 +0530, Ganapatrao Kulkarni wrote:
> (sending again, by mistake it was set to html mode)

The representation consists of a hierarchy of domains, the idea being
that resources are grouped in domains of similar average performance
relative to each other.

The platform decides which "levels" of that hierarchy are significant. 

The "ibm,associativity" property allows to determine the associatitivy
between two resources (ie nodes) at a given level.

Unfortunately that property went through changes, so another property
in the DT (ibm,architecture-vec-5) contains, among a bunch of other
things, a bit indicating which form of the ibm,associativity property
is used. I'm going to stick to the new "form 1" in this description.

The ibm,associativity contains one or more lists of numbers (32-bit
cells), which represent the domains:

< C1 , L1_1, L1_2, ... , C2, L2_1, L2_2, ... >

Where C1 (count 1) is the number of items for list 1, and L1_1,
L1_2, ... L1_C1 are the items for list 1, and same for C2/L2.

The entries in those lists are domain numbers from the highest level of
grouping to the lowest (successive numbers are sub divisions)
for example drawer#, socket#, chip#, core#... with the lowest level
being the actual resource itself. So within a domain that last number
is generally unique.

Different resources can have different number of levels, for example if
we have a grouping of node,socket,chip,core, a CPU core node would have
a list with all 4 but a memory controller on a chip might have only the
first 3.

This is an important statement in the spec:

<<
The user of this information is cautioned not to imply
any specific physical/logical significance of the various intermediate
levels.
>>

We can have multiple lists because a given resource can be connected
via multiple path in the same platform.

That means that to properly calculate the distance to another resource,
all the path need to be looked at (assuming the HW will pick the
shortest).

Additionally, to help the OS, another property "ibm,associativity
-reference-points" property indicates which levels (which indices in
the above lists) are of biggest significance to the platform. This can
typically be used by an OS to decide what to consider a "NUMA node"
if the OS cannot operate on distances alone. This is a list of 1-based
numbers representing indices in the associativity list. They should
be in order of significance of the boundary.

Finally, the ibm,max-associativity-domains (in the /rtas node on
pseries) is an array of cells < C, M1, M2, ... MC > (first is
count) containing for each domain/level the max number supported
by the platform.

Ben.

> On Tue, Sep 29, 2015 at 2:05 PM, Ganapatrao Kulkarni
>  wrote:
> > Hi Mark,
> > 
> > I have tried to answer your comments, in the meantime we are
> > waiting for Ben
> > to share the details.
> > 
> > On Fri, Aug 28, 2015 at 6:02 PM, Mark Rutland  > > wrote:
> > > 
> > > Hi,
> > > 
> > > On Fri, Aug 14, 2015 at 05:39:32PM +0100, Ganapatrao Kulkarni
> > > wrote:
> > > > DT bindings for numa map for memory, cores and IOs using
> > > > arm,associativity device node property.
> > > 
> > > Given this is just a copy of ibm,associativity, I'm not sure I
> > > see much
> > > point in renaming the properties.
> > > 
> > > However, (somewhat counter to that) I'm also concerned that this
> > > isn't
> > > sufficient for systems we're beginning to see today (more on that
> > > below), so I don't think a simple copy of ibm,associativity is
> > > good
> > > enough.
> > 
> > it is just copy right now, however it can evolve when we come
> > across more
> > arm64 numa platforms
> > > 
> > > 
> > > > 
> > > > Signed-off-by: Ganapatrao Kulkarni <
> > > > gkulka...@caviumnetworks.com>
> > > > ---
> > > >  Documentation/devicetree/bindings/arm/numa.txt | 212
> > > > +
> > > >  1 file changed, 212 insertions(+)
> > > >  create mode 100644
> > > > Documentation/devicetree/bindings/arm/numa.txt
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/arm/numa.txt
> > > > b/Documentation/devicetree/bindings/arm/numa.txt
> > > > new file mode 100644
> > > > index 000..dc3ef86
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/arm/numa.txt
> > > > @@ -0,0 +1,212 @@
> > > > 
> > > > +==
> > > > 
> > > > +NUMA binding description.
> > > > 
> > > > +==
> > > > 
> > > > +
> > > > 
> > > > +==
> > > > 
> > > > +1 - Introduction
> > > > 
> > > > +==
> > > > 
> > > > +
> > > > +Systems employing a Non Uniform Memory Access (NUMA)
> > > > architecture
> > > > contain
> > > > +collections of hardware resources including processors,
> > > > memory, and I/O
>

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Krzysztof Kozlowski]

On 29.09.2015 20:57, Javier Martinez Canillas wrote:
> There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
> Rev4 and Rev5. The only difference between these 2 revisions is the codec,
> Rev4 has a max98095 codec while Rev5 has a max98090.
> 
> Mainline only supports Rev4 so this patch moves the common device nodes to
> a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.
> 
> The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> The DTS in the vendor ChromeOS tree are called exynos5250-snow-rev{4,5}.dtb
> but I decided to leave Rev4 as exynos5250-snow.dtb to avoid breaking u-boot
> that has CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" in snow_defconfig.
> 
> Also, ChromiumOS Rev4 DTS has "google,snow-rev4" in its compatible string
> but was not added in mainline since Rev4 firmware fallbacks to "google,snow"
> and Rev5 searches for "google,snow-rev5". That way the compatible string
> could be consistent with the DTS naming and still be able to pack both Rev4
> and Rev5 FDT in the same FIT image and let the firmware pick the correct FDT.
> 
>  arch/arm/boot/dts/Makefile|   1 +
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
> ++
>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>  arch/arm/boot/dts/exynos5250-snow.dts | 666 +
>  4 files changed, 733 insertions(+), 665 deletions(-)
>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-common.dtsi
>  create mode 100644 arch/arm/boot/dts/exynos5250-snow-rev5.dts

Now the exynos5250-snow.dts means in fact Rev4... but there is no
information in DTS about it. I think adding compatible
"google,snow-rev4" makes sense:
1. For informational purposes (this could be also handled with a comment).
2. Later one could decide to switch the default meaning of "google,snow"
to Rev5 and the real compatible (rev4) will be there already.

Could you add the new compatible and fix patch issues pointed by Doug?

Best regards,
Krzysztof

--
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] ARM: dts: exynos4412-trats2: remove regulator-compatible usage

[Krzysztof Kozlowski]

On 28.09.2015 19:38, Javier Martinez Canillas wrote:
> The regulator-compatible property from the regulator DT binding was
> deprecated and the correct approach is to use the node's name.
> 
> This patch has no functional changes but by not using a deprecated
> property, new DTS based on this one will not carry the same issue.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> Changes in v2:
> - Fixed typo on LDO10. Pointed out by Anand Moon.
> 
>  arch/arm/boot/dts/exynos4412-trats2.dts | 105 
> +++-
>  1 file changed, 35 insertions(+), 70 deletions(-)
> 

Tested on Trats2 board:
Tested-by: Krzysztof Kozlowski 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

--
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/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey

[Dmitry Torokhov]

On Mon, Sep 28, 2015 at 08:19:27AM +, Opensource [Steve Twiss] wrote:
> 
> > Subject: Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings 
> > for DA9062 OnKey
> > 
> > On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> > > On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:
> > > > From: S Twiss 
> > > >
> > > > Add device tree bindings for the DA9062 OnKey driver component
> > > >
> > > > Signed-off-by: Steve Twiss 
> > > >
> > > > ---
> > > > Changes in V3:
> > > >  - Child driver specifics separated out into separate document
> > > >in this case ../input/da9062-onkey.txt
> > > > Changes in V2:
> > > >  - No change
> > > >
> > > > This patch applies against linux-next and next-20150708
> > > >
> > > >
> > > >  .../devicetree/bindings/input/da9062-onkey.txt | 36
> > ++
> > > >  Documentation/devicetree/bindings/mfd/da9062.txt   |  3 ++
> > >
> > > I dropped bits for mfd/da9062.txt, changed to mention both 9062 and
> > > 9063, folded into the onkey patch and applied.
> > 
> > Argh, da9062 core is not in mainline yet... OK, below is the patch I
> > had; if Lee does not pick it up I'll re-apply it when da9062 core hits
> > mainline.
> > 
> 
> Hi Lee and Dmitry,
> 
> This patch seems to have been missed. It is the main OnKey driver for DA9062 
> and this
> component was waiting for the DA9062 MFD core to make it into 
> linux-mainline/v4.3-rc1.
> 
> Is there any reply on this yet please? There just seems to be a little patch 
> administration
> problem holding things up.

I queued it for 4.4.

Thanks.

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

[PATCH] ARM: shmobile: porter: initial device tree

[Sergei Shtylyov]

Add the initial device tree for the R8A7791 SoC based Porter low cost board
(which  is a  slightly modified version  of the Henninger board).

SCIF0 serial port support is included, so that the serial console can work. 

Signed-off-by: Sergei Shtylyov 

---
This patch is against the 'renesas-devel-20150928-v4.3-rc3' tag of Simon
Horman's 'renesas.git' repo.

 arch/arm/boot/dts/Makefile   |1 
 arch/arm/boot/dts/r8a7791-porter.dts |   54 +++
 2 files changed, 55 insertions(+)

Index: renesas/arch/arm/boot/dts/Makefile
===
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -532,6 +532,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r8a7790-lager.dtb \
r8a7791-henninger.dtb \
r8a7791-koelsch.dtb \
+   r8a7791-porter.dtb \
r8a7793-gose.dtb \
r8a7794-alt.dtb \
r8a7794-silk.dtb \
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -0,0 +1,54 @@
+/*
+ * Device Tree Source for the Porter board
+ *
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "r8a7791.dtsi"
+
+/ {
+   model = "Porter";
+   compatible = "renesas,porter", "renesas,r8a7791";
+
+   aliases {
+   serial0 = &scif0;
+   };
+
+   chosen {
+   bootargs = "console=ttySC0,115200 ignore_loglevel";
+   stdout-path = &scif0;
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x4000>;
+   };
+
+   memory@2 {
+   device_type = "memory";
+   reg = <2 0x 0 0x4000>;
+   };
+};
+
+&extal_clk {
+   clock-frequency = <2000>;
+};
+
+&pfc {
+   scif0_pins: serial0 {
+   renesas,groups = "scif0_data_d";
+   renesas,function = "scif0";
+   };
+};
+
+&scif0 {
+   pinctrl-0 = <&scif0_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+};

--
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] thermal: Add Mediatek thermal controller support

[Eduardo Valentin]

On Wed, Sep 23, 2015 at 03:37:42PM +0200, 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
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 0390044..dadd1eb 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -348,6 +348,14 @@ config INTEL_PCH_THERMAL
> Thermal reporting device will provide temperature reading,
> programmable trip points and other information.
>  
> +config MTK_THERMAL
> + tristate "Temperature sensor driver for mediatek SoCs"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + default y
> + help
> +   Enable this option if you want to have support for thermal management
> +   controller present in Mediatek SoCs
> +
>  menu "Texas Instruments thermal drivers"
>  source "drivers/thermal/ti-soc-thermal/Kconfig"
>  endmenu
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 26f1608..5f979e7 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -45,3 +45,4 @@ obj-$(CONFIG_INTEL_PCH_THERMAL) += intel_pch_thermal.o
>  obj-$(CONFIG_ST_THERMAL) += st/
>  obj-$(CONFIG_TEGRA_SOCTHERM) += tegra_soctherm.o
>  obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
> +obj-$(CONFIG_MTK_THERMAL)+= mtk_thermal.o
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> new file mode 100644
> index 000..6be1a6c
> --- /dev/null
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -0,0 +1,537 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Hanyi Wu 
> + *
> + * 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 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

You dont seam to be using this header. Can you please clean up to have
only the headers you need?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* AUXADC Registers */
> +#define AUXADC_CON0_V0x000
> +#define AUXADC_CON1_V0x004
> +#define AUXADC_CON1_SET_V0x008
> +#define AUXADC_CON1_CLR_V0x00c
> +#define AUXADC_CON2_V0x010
> +#define AUXADC_DATA(channel) (0x14 + (channel) * 4)
> +#define AUXADC_MISC_V0x094
> +
> +#define AUXADC_CON1_CHANNEL(x)   BIT(x)
> +
> +#define APMIXED_SYS_TS_CON1  0x604
> +
> +/* Thermal Controller Registers */
> +#define TEMP_MONCTL0 0x000
> +#define TEMP_MONCTL1 0x004
> +#define TEMP_MONCTL2 0x008
> +#define TEMP_MONIDET00x014
> +#define TEMP_MONIDET10x018
> +#define TEMP_MSRCTL0 0x038
> +#define TEMP_AHBPOLL 0x040
> +#define TEMP_AHBTO   0x044
> +#define TEMP_ADCPNP0 0x048
> +#define TEMP_ADCPNP1 0x04c
> +#define TEMP_ADCPNP2 0x050
> +#define TEMP_ADCPNP3 0x0b4
> +
> +#define TEMP_ADCMUX  0x054
> +#define TEMP_ADCEN   0x060
> +#define TEMP_PNPMUXADDR  0x064
> +#define TEMP_ADCMUXADDR  0x068
> +#define TEMP_ADCENADDR   0x074
> +#define TEMP_ADCVALIDADDR0x078
> +#define TEMP_ADCVOLTADDR 0x07c
> +#define TEMP_RDCTRL  0x080
> +#define TEMP_ADCVALIDMASK0x084
> +#define TEMP_ADCVOLTAGESHIFT 0x088
> +#define TEMP_ADCWRITECTRL0x08c
> +#define TEMP_MSR00x090
> +#define TEMP_MSR10x094
> +#define TEMP_MSR20x098
> +#define TEMP_MSR30x0B8
> +
> +#define TEMP_SPARE0  0x0f0
> +
> +#define PTPCORESEL   0x400
> +
> +#define TEMP_MONCTL1_PERIOD_UNIT(x)  ((x) & 0x3ff)
> +
> +#define TEMP_MONCTL2_FILTER_INTERVAL(x)  (((x) & 0x3ff)) << 16
> +#define TEMP_MONCTL2_SENSOR_INTERVAL(x)  ((x) & 0x3ff)
> +
> +#define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)(x)
> +
> +#define TEMP_ADCWRITECTRL_ADC_PNP_WRITE  BIT(0)
> +#define TEMP_ADCWRITECTRL_ADC_MUX_WRITE

Re: [PATCH 0/4] memory: pl17x: add support of PL175 and PL176 controllers

[Vladimir Zapolskiy]

Hi Joachim,

On 29.09.2015 23:39, Joachim Eastwood wrote:
> Hi Vladimir,
> 
> On 28 September 2015 at 18:50, Vladimir Zapolskiy  wrote:
>> The change adds support of ARM PrimeCell PL175 MPMC and PL176 MPMC,
>> the static memory controllers on devices are similar to one found on
>> ARM PrimeCell PL172, add support to the existing driver.
>>
>> Vladimir Zapolskiy (4):
>>   memory: pl172: correct MPMC peripheral ID register bits
>>   memory: pl172: add ARM PrimeCell PL175 MPMC support
>>   memory: pl172: add ARM PrimeCell PL176 MPMC support
>>   doc: dt: arm,pl172: add description of PL175 and PL176 controllers
> 
> Changes look good to me.
> 
> What LPC32xx board did you test this on, btw?

I tested PL175 on Timll Devkit3250 board with 4Mb NOR.

> Also if you have added the controller to lpc32xx.dtsi it would be
> great if you could also submit those changes to the lpc32xx
> maintainer.
> 

Right, this is in my plans. To avoid any mess in the controller driver,
mach-lpc32xx must be converted to common clock framework firstly, that's
what I'm doing at the moment, then I'll send the corresponding EMC
updates in lpc32xx.dtsi.

By the way I've tested your clocksource driver on LPC32xx and it works
fine, but again clean switching to it is not possible until LPC32xx
clocks are out of the common clock framework.

--
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 v12 3/5] mtd: nand: vf610_nfc: add device tree bindings

[Brian Norris]

On Wed, Sep 02, 2015 at 06:06:35PM -0700, Stefan Agner wrote:
> Signed-off-by: Bill Pringlemeir 
> Acked-by: Shawn Guo 
> Signed-off-by: Stefan Agner 
> ---
>  .../devicetree/bindings/mtd/vf610-nfc.txt  | 59 
> ++
>  1 file changed, 59 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt 
> b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
> new file mode 100644
> index 000..6be4871
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
> @@ -0,0 +1,59 @@
> +Freescale's NAND flash controller (NFC)
> +
> +This variant of the Freescale NAND flash controller (NFC) can be found on
> +Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
> +
> +Required properties:
> +- compatible: Should be set to "fsl,vf610-nfc".
> +- reg: address range of the NFC.
> +- interrupts: interrupt of the NFC.
> +- #address-cells: shall be set to 1. Encode the nand CS.
> +- #size-cells : shall be set to 0.
> +- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>;
> +- assigned-clock-rates: The NAND bus timing is derived from this clock
> +rate and should not exceed maximum timing for any NAND memory chip
> +in a board stuffing. Typical NAND memory timings derived from this
> +clock are found in the SoC hardware reference manual. Furthermore,
> +there might be restrictions on maximum rates when using hardware ECC.
> +
> +- #address-cells, #size-cells : Must be present if the device has sub-nodes
> +  representing partitions.
> +
> +Required children nodes:
> +Children nodes represent the available nand chips. Currently the driver can
> +only handle one NAND chip.
> +
> +Required properties:
> +- compatible: Should be set to "fsl,vf610-nfc-cs".
> +- nand-bus-width: see nand.txt
> +- nand-ecc-mode: see nand.txt
> +
> +Required properties for hardware ECC:
> +- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
> +- nand-ecc-step-size: step size equals page size, currently only 2k pages are
> +supported
> +- nand-on-flash-bbt: see nand.txt
> +
> +Example:
> +
> + nfc: nand@400e {
> + compatible = "fsl,vf610-nfc";
> + #address-cells = <1>;
> + #size-cells = <1>;

Fixed this to <0> ^^^

and pushed to l2-mtd.git. I'll assume the DTS updates can be rebased and
taken through arm-soc

> + reg = <0x400e 0x4000>;
> + interrupts = ;
> + clocks = <&clks VF610_CLK_NFC>;
> + clock-names = "nfc";
> + assigned-clocks = <&clks VF610_CLK_NFC>;
> + assigned-clock-rates = <3300>;
> +
> + nand@0 {
> + compatible = "fsl,vf610-nfc-nandcs";
> + reg = <0>;
> + nand-bus-width = <8>;
> + nand-ecc-mode = "hw";
> + nand-ecc-strength = <32>;
> + nand-ecc-step-size = <2048>;
> + nand-on-flash-bbt;
> + };
> + };
> -- 
> 2.5.1
> 

Brian
--
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 v12 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

[Brian Norris]

Pushed this patch to l2-mtd.git, as it looks pretty much good. Although,
I'd like raw read support...

On Wed, Sep 02, 2015 at 06:06:34PM -0700, Stefan Agner wrote:
> This adds hardware ECC support using the BCH encoder in the NFC IP.
> The ECC encoder supports up to 32-bit correction by using 60 error
> correction bytes. There is no sub-page ECC step, ECC is calculated
> always accross the whole page (up to 2k pages).
> 
> Limitations:
> - HW ECC: Only 2K page with 64+ OOB.
> - HW ECC: Only 24 and 32-bit error correction implemented.
> 
> Raw writes have been tested using the generic nand_write_page_raw
> implementation. However, raw reads are currently not possible
> because the controller need to know whether we are going to use
> the ECC mode already at NAND_CMD_READ0 command time. At this point
> we do not have the information whether it is a raw read or a
> regular read at driver level...

Hmm, can you get this in ecc.read_page_raw()?
--
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 v12 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

[Brian Norris]

On Fri, Sep 04, 2015 at 07:10:10AM +0300, Alexey Klimov wrote:
> On Thu, Sep 3, 2015 at 4:06 AM, Stefan Agner  wrote:
> > --- /dev/null
> > +++ b/drivers/mtd/nand/vf610_nfc.c

> > +static int vf610_nfc_probe(struct platform_device *pdev)
> > +{
> > +   struct vf610_nfc *nfc;
> > +   struct resource *res;
> > +   struct mtd_info *mtd;
> > +   struct nand_chip *chip;
> > +   struct device_node *child;
> > +   const struct of_device_id *of_id;
> > +   int err = 0;
> 
> According to usage you don't need to initialize err to zero here.

Fixed this one.

> > +   int irq;
> > +
> > +   nfc = devm_kzalloc(&pdev->dev, sizeof(*nfc), GFP_KERNEL);
> > +   if (!nfc)
> > +   return -ENOMEM;
> > +
> > +   nfc->dev = &pdev->dev;
> > +   mtd = &nfc->mtd;
> > +   chip = &nfc->chip;
> > +
> > +   mtd->priv = chip;
> > +   mtd->owner = THIS_MODULE;
> > +   mtd->dev.parent = nfc->dev;
> > +   mtd->name = DRV_NAME;
> > +
> > +   irq = platform_get_irq(pdev, 0);
> > +   if (irq <= 0)
> > +   return -EINVAL;
> > +
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   nfc->regs = devm_ioremap_resource(nfc->dev, res);
> > +   if (IS_ERR(nfc->regs))
> > +   return PTR_ERR(nfc->regs);
> > +
> > +   nfc->clk = devm_clk_get(&pdev->dev, NULL);
> > +   if (IS_ERR(nfc->clk))
> > +   return PTR_ERR(nfc->clk);
> > +
> > +   err = clk_prepare_enable(nfc->clk);
> > +   if (err) {
> > +   dev_err(nfc->dev, "Unable to enable clock!\n");
> > +   return err;
> > +   }
> 
> After fixing that feel free to use:
> 
> Reviewed-by: Alexey Klimov 

Also, fixed up the nand_chip field name change (from 'dn' to
'flash_node'), and pushed to l2-mtd.git

Thanks,
Brian
--
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 0/4] memory: pl17x: add support of PL175 and PL176 controllers

[Joachim Eastwood]

Hi Vladimir,

On 28 September 2015 at 18:50, Vladimir Zapolskiy  wrote:
> The change adds support of ARM PrimeCell PL175 MPMC and PL176 MPMC,
> the static memory controllers on devices are similar to one found on
> ARM PrimeCell PL172, add support to the existing driver.
>
> Vladimir Zapolskiy (4):
>   memory: pl172: correct MPMC peripheral ID register bits
>   memory: pl172: add ARM PrimeCell PL175 MPMC support
>   memory: pl172: add ARM PrimeCell PL176 MPMC support
>   doc: dt: arm,pl172: add description of PL175 and PL176 controllers

Changes look good to me.

What LPC32xx board did you test this on, btw?

Also if you have added the controller to lpc32xx.dtsi it would be
great if you could also submit those changes to the lpc32xx
maintainer.


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

[PATCH] arm64: dts: add all hi6220 uart nodes

[Tyler Baker]

This patch adds all UART nodes for the Hi6220 SoC. Recently a board[1] has
been developed to standardize UART access across all the 96boards consumer
edition boards. To use this hardware on HiKey we must configure and enable
UART3. However, to ensure backward compatibility we must keep UART0 enabled
as well.

I have removed the hard coded clock index values in favor of using the ones
already defined in include/dt-bindings/clock/hi6220-clock.h.

This patch was boot tested on top of next-20150929, with both UART
configurations.

[1] http://www.seeedstudio.com/depot/96Boards-UART-p-2525.html?ref=newInBazaar

Signed-off-by: Tyler Baker 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |  4 +++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  | 43 +-
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index e36a539..34486bc 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -18,6 +18,10 @@
 
aliases {
serial0 = &uart0;
+   serial1 = &uart1;
+   serial2 = &uart2;
+   serial3 = &uart3;
+   serial4 = &uart4;
};
 
chosen {
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..82d2488 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 
 / {
compatible = "hisilicon,hi6220";
@@ -164,8 +165,48 @@
compatible = "arm,pl011", "arm,primecell";
reg = <0x0 0xf8015000 0x0 0x1000>;
interrupts = ;
-   clocks = <&ao_ctrl 36>, <&ao_ctrl 36>;
+   clocks = <&ao_ctrl HI6220_UART0_PCLK>,
+<&ao_ctrl HI6220_UART0_PCLK>;
clock-names = "uartclk", "apb_pclk";
};
+
+   uart1: uart@f7111000 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x0 0xf7111000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&sys_ctrl HI6220_UART1_PCLK>,
+<&sys_ctrl HI6220_UART1_PCLK>;
+   clock-names = "uartclk", "apb_pclk";
+   status = "disabled";
+   };
+
+   uart2: uart@f7112000 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x0 0xf7112000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&sys_ctrl HI6220_UART2_PCLK>,
+<&sys_ctrl HI6220_UART2_PCLK>;
+   clock-names = "uartclk", "apb_pclk";
+   status = "disabled";
+   };
+
+   uart3: uart@f7113000 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x0 0xf7113000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&sys_ctrl HI6220_UART3_PCLK>,
+<&sys_ctrl HI6220_UART3_PCLK>;
+   clock-names = "uartclk", "apb_pclk";
+   };
+
+   uart4: uart@f7114000 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x0 0xf7114000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&sys_ctrl HI6220_UART4_PCLK>,
+<&sys_ctrl HI6220_UART4_PCLK>;
+   clock-names = "uartclk", "apb_pclk";
+   status = "disabled";
+   };
};
 };
-- 
2.1.4

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

Re: [PATCH 2/3] ARM: dts: sun6i: Turn on gmac on Colombus

[Hans de Goede]

Hi,

On 08/21/2015 12:12 AM, Maxime Ripard wrote:

On Thu, Aug 20, 2015 at 08:23:27AM +0200, Hans de Goede wrote:

Hi,

On 08/19/2015 05:17 PM, Maxime Ripard wrote:

On Fri, Aug 07, 2015 at 05:22:34PM +0200, Hans de Goede wrote:

We've everything we need to support the gmac on Colombus, turn it on.

Signed-off-by: Hans de Goede 


I recall that the phy was powered by one of the AXP221 regulators,
does it require some additional stuff (like a recent u-boot), or does
it just work and my memory is bad :) ?


I think it just works, it MAY be connected to aldo1 but according to
the git history for the u-boot defconfig that one is used for wifi not
for the gmac, and we do not enable any other "spare" regulators in the
u-boot config.

I do not have any schematics, so no way to say for sure.

I can confirm that the GMAC work fine with the latest u-boot
master. Looking in the history we've always enabled ALDO1
on the Colombus in upstream u-boot, so this should all just work.


Except that if it is the case, the DT was working fine with the stock
bootloader, and it doesn't anymore, while we have no way to upgrade
it.


Ok, I've finally made some time to test this, the gmac works fine
with aldo1 disabled, so I believe this patch can be merged as is.

Regards,

Hans
--
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] Docs: dt: fsl-mc update binding to include definition of ranges

[Jose Rivera]

> -Original Message-
> From: Stuart Yoder [mailto:stuart.yo...@freescale.com]
> Sent: Friday, September 25, 2015 4:08 PM
> To: robh...@kernel.org; mark.rutl...@arm.com
> Cc: devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; Rivera
> Jose-B46482; Sharma Bhupesh-B45370; katz Itai-RM05202; Yoder Stuart-
> B08248
> Subject: [PATCH 2/3] Docs: dt: fsl-mc update binding to include
> definition of ranges
> 
> Define a ranges property to specify the mapping between the MC address
> space and the system address space.
> 
> Signed-off-by: Stuart Yoder 
> ---
>  .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 30
> +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index 6aac955..848975f 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -35,6 +35,26 @@ Required properties:
>  Definition: Must be present and point to the MSI controller node
>  handling message interrupts for the MC.
> 
> +- ranges
> +Value type: 
> +Definition: A standard property.  Defines the mapping between
> the child
> +MC address space and the parent system address
> space.
> +
> +The MC address space is defined by 3 components:
> + 
> +
> +Valid values for region type are
> +   0x0 - MC portals
> +   0x1 - QBMAN portals
> +
> +- #address-cells
> +Value type: 
> +Definition: Must be 3.  (see definition in 'ranges' property)
> +
> +- #size-cells
> +Value type: 
> +Definition: Must be 1.
> +
>  Example:
> 
>  fsl_mc: fsl-mc@80c00 {
> @@ -42,5 +62,13 @@ Example:
>  reg = <0x0008 0x0c00 0 0x40>,/* MC portal
> base */
><0x 0x0834 0 0x4>; /* MC control
> reg */
>  msi-parent = <&its>;
> -};
> +#address-cells = <3>;
> +#size-cells = <1>;
> 
> +/*
> + * Region type 0x0 - MC portals
> + * Region type 0x1 - QBMAN portals
> + */
> +ranges = <0x0 0x0 0x0 0x8 0x0c00 0x400
> +  0x1 0x0 0x0 0x8 0x1800 0x800>;
> +};
> --
> 2.3.3

Acked-by: J. German Rivera 

--
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] Docs: dt: fsl-mc: update binding to define dpmac subnodes

[Jose Rivera]

> -Original Message-
> From: Stuart Yoder [mailto:stuart.yo...@freescale.com]
> Sent: Friday, September 25, 2015 4:08 PM
> To: robh...@kernel.org; mark.rutl...@arm.com
> Cc: devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; Rivera
> Jose-B46482; Sharma Bhupesh-B45370; katz Itai-RM05202; Yoder Stuart-
> B08248
> Subject: [PATCH 3/3] Docs: dt: fsl-mc: update binding to define dpmac
> subnodes
> 
> The fsl-mc node may optionally have dpmac sub-nodes that describe the
> relationship between the Ethernet MACs which belong to the MC and the
> Ethernet PHYs on the system board.
> 
> Signed-off-by: Stuart Yoder 
> ---
>  .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 45
> ++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index 848975f..6611a7c 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -55,6 +55,40 @@ Required properties:
>  Value type: 
>  Definition: Must be 1.
> 
> +Sub-nodes:
> +
> +The fsl-mc node may optionally have dpmac sub-nodes that
> describe
> +the relationship between the Ethernet MACs which belong to the
> MC
> +and the Ethernet PHYs on the system board.
> +
> +The dpmac nodes must be under a node named "dpmacs" which
> contains
> +the following properties:
> +
> +- #address-cells
> +  Value type: 
> +  Definition: Must be present if dpmac sub-nodes are defined
> and must
> +  have a value of 1.
> +
> +- #size-cells
> +  Value type: 
> +  Definition: Must be present if dpmac sub-nodes are defined
> and must
> +  have a value of 0.
> +
> +These nodes must have the following properties:
> +
> +- compatible
> +  Value type: 
> +  Definition: Must be "fsl,qoriq-mc-dpmac".
> +
> +- reg
> +  Value type: 
> +  Definition: Specifies the id of the dpmac.
> +
> +- phy-handle
> +  Value type: 
> +  Definition: Specifies the phandle to the PHY device node
> associated
> +  with the this dpmac.
> +
>  Example:
> 
>  fsl_mc: fsl-mc@80c00 {
> @@ -71,4 +105,15 @@ Example:
>   */
>  ranges = <0x0 0x0 0x0 0x8 0x0c00 0x400
>0x1 0x0 0x0 0x8 0x1800 0x800>;
> +
> +dpmacs {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +dpmac@1 {
> +compatible = "fsl,qoriq-mc-dpmac";
> +reg = <1>;
> +phy-handle = <&mdio0_phy0>;
> +}
> +}
>  };
> --
> 2.3.3

Acked-by: J. German Rivera 

--
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] Docs: dt: fsl-mc: update binding to include msi-parent

[Jose Rivera]

> -Original Message-
> From: Stuart Yoder [mailto:stuart.yo...@freescale.com]
> Sent: Friday, September 25, 2015 4:08 PM
> To: robh...@kernel.org; mark.rutl...@arm.com
> Cc: devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; Rivera
> Jose-B46482; Sharma Bhupesh-B45370; katz Itai-RM05202; Yoder Stuart-
> B08248
> Subject: [PATCH 1/3] Docs: dt: fsl-mc: update binding to include msi-
> parent
> 
> The Freescale Management Complex and all associated objects use message
> interrupts, and thus an msi-parent is required.
> 
> Signed-off-by: Stuart Yoder 
> ---
>  Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index c7a26ca..6aac955 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -30,11 +30,17 @@ Required properties:
>  region may not be present in some scenarios,
> such
>  as in the device tree presented to a virtual
> machine.
> 
> +- msi-parent
> +Value type: 
> +Definition: Must be present and point to the MSI controller node
> +handling message interrupts for the MC.
> +
>  Example:
> 
>  fsl_mc: fsl-mc@80c00 {
>  compatible = "fsl,qoriq-mc";
>  reg = <0x0008 0x0c00 0 0x40>,/* MC portal
> base */
><0x 0x0834 0 0x4>; /* MC control
> reg */
> +msi-parent = <&its>;
>  };
> 
> --
> 2.3.3

Acked-by: J. German Rivera 

--
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/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC

[Andrew F. Davis]

On 09/29/2015 01:38 PM, Mark Brown wrote:

On Tue, Sep 29, 2015 at 01:08:50PM -0500, Andrew F. Davis wrote:

On 09/29/2015 10:13 AM, Mark Brown wrote:



sure that will save me anything as my probe function is called with a DT
match already, so no searching is needed.



You've not understood what that change is replacing, the code I'm
quoting above is exactly that code.  Check out some of the existing
drivers using this API.



Looking at other drivers that use this API they all call regulator_register
in a loop in their probe, once for each possible regulator, in this case
letting the API do the DT node search makes sense. My probe on the other-hand
is only called when we already have a DT match, therefor searching is not
necessary and all I have to do is call of_get_regulator_init_data myself on
the already found DT node. No need to add node names to my regulator_desc
and make the API re-search for the node.


Oh, ick.  The binding has a compatible string in the individual
regulator bindings which is broken unless there really are lots of
variants being configured via DT (which is just not the case here).
It's not only more typing in the DT,


I don't see this, the alternative is matching to this "regulator-compatible",
why not just use the existing compatible.


it also means that we can't read
back the configuration of the device unless the user goes and creates a
DT which explicitly lists each regulator on the device which is
unhelpful.  We should be able to read back the configurations of all the
regulators by simply listing the device in DT.



Could you expand this? I'm not sure I understand why we still cant do this
using this new way.

Bindings should have compatible strings when they describe hardware like this,
we can then do stuff like put the LDO and DCDC drivers in separate modules for
instance, letting DT only load what we need. There are other benefits like
not having to search our own DT binding for data, and we only get probed for
devices in the DT.

This also eliminates the need for MFD_CORE, we just call
of_platform_populate on ourself and DT helpers do the rest. Why hard code
mfd_cell's and do matching when DT does the same thing.


The fact that this is different to the bindings for other regulator
drivers and requires more code ought to have been a big warning sign
here :(



The binding is the same as the new tps65218 driver, different isn't always
a warning sign. And what do you mean "requires more code"? This regulator
driver is smaller than almost any other. DT takes care of everything for
us relating to hardware instantiation like it should.
--
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/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC

[Mark Brown]

On Tue, Sep 29, 2015 at 01:08:50PM -0500, Andrew F. Davis wrote:
> On 09/29/2015 10:13 AM, Mark Brown wrote:

> >>sure that will save me anything as my probe function is called with a DT
> >>match already, so no searching is needed.

> >You've not understood what that change is replacing, the code I'm
> >quoting above is exactly that code.  Check out some of the existing
> >drivers using this API.

> Looking at other drivers that use this API they all call regulator_register
> in a loop in their probe, once for each possible regulator, in this case
> letting the API do the DT node search makes sense. My probe on the other-hand
> is only called when we already have a DT match, therefor searching is not
> necessary and all I have to do is call of_get_regulator_init_data myself on
> the already found DT node. No need to add node names to my regulator_desc
> and make the API re-search for the node.

Oh, ick.  The binding has a compatible string in the individual
regulator bindings which is broken unless there really are lots of
variants being configured via DT (which is just not the case here).
It's not only more typing in the DT, it also means that we can't read
back the configuration of the device unless the user goes and creates a
DT which explicitly lists each regulator on the device which is
unhelpful.  We should be able to read back the configurations of all the
regulators by simply listing the device in DT.

The fact that this is different to the bindings for other regulator
drivers and requires more code ought to have been a big warning sign
here :(


signature.asc
Description: Digital signature

Re: [PATCH v3 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC

[Andrew F. Davis]

On 09/28/2015 11:01 AM, Grygorii Strashko wrote:

On 09/24/2015 09:52 AM, Andrew F. Davis wrote:

This patch adds support for TPS65912 mfd device. It provides
communication through the I2C and SPI interfaces. It contains
the following components:

   - Regulators
   - GPIO controller

Signed-off-by: Andrew F. Davis 
---
   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 ++
   include/linux/mfd/tps65912.h | 393 
+++
   6 files changed, 705 insertions(+)
   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 include/linux/mfd/tps65912.h



[...]


+
+/*
+ * struct tps_info - packages regulator constraints
+ * @id: Id of the regulator
+ * @name: Voltage regulator name
+ * @min_uV: Minimum micro volts
+ * @max_uV: Minimum micro volts
+ *
+ * This data is used to check the regulator voltage limits while setting.
+ */
+struct tps_info {
+   int id;
+   const char *name;
+   int min_uV;
+   int max_uV;
+};


Could you move structure's definitions to the corresponding c-files
if they are used only locally in this files, pls?



ACK


+
+/*
+ * struct tps65912 - state holder for the tps65912 driver
+ *
+ * Device data may be used to access the TPS65912 chip
+ */
+struct tps65912 {
+   struct device *dev;
+   unsigned int id;
+
+   /* IRQ Data */
+   int irq;
+   struct regmap_irq_chip_data *irq_data;
+
+   struct regulator_desc desc[TPS65912_NUM_REGULATOR];
+   struct tps_info *info[TPS65912_NUM_REGULATOR];


seems above two field are not used (and id?).



The idea was for a someday use, but because I never did that I'll
remove them for now.

Thanks,
Andrew


+   struct regmap *regmap;
+};
+
+static const struct regmap_range tps65912_yes_ranges[] = {
+   regmap_reg_range(TPS65912_INT_STS, TPS65912_GPIO5),
+};
+
+static const struct regmap_access_table tps65912_volatile_table = {
+   .yes_ranges = tps65912_yes_ranges,
+   .n_yes_ranges = ARRAY_SIZE(tps65912_yes_ranges),
+};
+
+static const struct regmap_config tps65912_regmap_co   nfig = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .cache_type = REGCACHE_RBTREE,
+   .volatile_table = &tps65912_volatile_table,
+};
+
+int tps65912_device_init(struct tps65912 *tps);
+int tps65912_device_exit(struct tps65912 *tps);
+
+#endif /*  __LINUX_MFD_TPS65912_H */





--
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] Documentation: add DT bindings for ARM SCPI sensors

[Rob Herring]

On Tue, Sep 15, 2015 at 11:50 AM, Punit Agrawal  wrote:
> The System Control Processor (SCP) provides access to SoC sensors via
> the System Control and Power Interface (SCPI) Message Protocol. Add
> bindings to allow probing of these sensors. Also support referencing
> of the sensors for setting up thermal zones via the thermal DT
> bindings.
>
> Signed-off-by: Punit Agrawal 
> Cc: Rob Herring 

Acked-by: Rob Herring 

> Cc: Mark Rutland 
> Cc: Sudeep Holla 
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 38 
> ++
>  1 file changed, 38 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt 
> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index f002460..86302de 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -72,8 +72,25 @@ Required sub-node properties:
>  - compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
>shared memory on Juno platforms
>
> +Sensor bindings for the sensors based on SCPI Message Protocol
> +--
> +SCPI provides an API to access the various sensors on the SoC.
> +
> +Required properties:
> +- compatible : should be "arm,scpi-sensors".
> +- #thermal-sensor-cells: should be set to 1. This property follows the
> +thermal device tree bindings[2].
> +
> +Valid cell values are raw identifiers (Sensor
> +ID) as used by the firmware. Refer to
> +platform documentation for your
> +implementation for the IDs to use. For Juno
> +R0 and Juno R1 refer to [3].
> +
>  [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
>  [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +[2] Documentation/devicetree/bindings/thermal/thermal.txt
> +[3] 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
>
>  Example:
>
> @@ -122,6 +139,11 @@ scpi_protocol: scpi@2e00 {
> clock-output-names = "pxlclk0", "pxlclk1";
> };
> };
> +
> +   scpi_sensors0: sensors {
> +   compatible = "arm,scpi-sensors";
> +   #thermal-sensor-cells = <1>;
> +   };
>  };
>
>  cpu@0 {
> @@ -136,6 +158,17 @@ hdlcd@7ff6 {
> clocks = <&scpi_clk 4>;
>  };
>
> +thermal-zones {
> +   soc_thermal {
> +   polling-delay-passive = <100>;
> +   polling-delay = <1000>;
> +
> +   /* sensor ID */
> +   thermal-sensors = <&scpi_sensors0 3>;
> +   ...
> +   };
> +};
> +
>  In the above example, the #clock-cells is set to 1 as required.
>  scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0,
>  1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0
> @@ -148,3 +181,8 @@ scpi_dvfs i.e. "atlclk".
>  Similarly the second example is hdlcd@7ff6 and it has pxlclk1 as input
>  clock. '4' in the clock specifier here points to the second entry
>  in the output clocks of scpi_clocks  i.e. "pxlclk1"
> +
> +The thermal-sensors property in the soc_thermal node uses the
> +temperature sensor provided by SCP firmware to setup a thermal
> +zone. The ID "3" is the sensor identifier for the temperature sensor
> +as used by the firmware.
> --
> 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 v3 4/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC

[Andrew F. Davis]

On 09/29/2015 10:13 AM, Mark Brown wrote:

On Fri, Sep 25, 2015 at 03:10:04PM -0500, Andrew F. Davis wrote:

On 09/25/2015 01:05 PM, Mark Brown wrote:

On Thu, Sep 24, 2015 at 09:52:53AM -0500, Andrew F. Davis wrote:



+   match = of_match_device(tps65912_regulator_of_match_table, &pdev->dev);
+   if (!match)
+   return -ENODEV;



+   template = match->data;
+   id = template->id;
+   init_data = of_get_regulator_init_data(&pdev->dev, pdev->dev.of_node,
+  ®ulators[id]);



Don't open code this stuff, use the core DT matching in the
regulator_desc instead.



I assume you are referring to your additions in a0c7b164ad11? If so I'm not


Please don't refer to commits by ID only, include a human readable
description of the commit for the benefit of any humans who might read
your mail.



Forgot about those pesky humans :), OK, will do from now on.


sure that will save me anything as my probe function is called with a DT
match already, so no searching is needed.


You've not understood what that change is replacing, the code I'm
quoting above is exactly that code.  Check out some of the existing
drivers using this API.



Looking at other drivers that use this API they all call regulator_register
in a loop in their probe, once for each possible regulator, in this case
letting the API do the DT node search makes sense. My probe on the other-hand
is only called when we already have a DT match, therefor searching is not
necessary and all I have to do is call of_get_regulator_init_data myself on
the already found DT node. No need to add node names to my regulator_desc
and make the API re-search for the node.

I have further cleaned up this code to show this.

If this is acceptable, I'll push the re-spin so you can review further.


Please also use subject lines mathcing the style for the subsystem.



I'm not sure I know what you mean? What is wrong with my subject line, it looks
like the others I've looked at?


You are using "regulators:", the regulator API uses "regulator:" - this
should be really clear if you do something like a git shortlog.



Ah, slipped right past me, thanks for clarifying, fixed.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3 1/5] Input: goodix - reset device at init

[Tirdea, Irina]

> -Original Message-
> From: Bastien Nocera [mailto:had...@hadess.net]
> Sent: 29 September, 2015 5:04
> To: Tirdea, Irina; linux-in...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; Rob Herring; Pawel Moll; Ian Campbell; 
> Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark
> Rutland; devicetree@vger.kernel.org
> Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init
> 
> On Fri, 2015-09-25 at 21:04 +, Tirdea, Irina wrote:
> >

> >
> > The warning from your dmesg output will not cause probe to fail.
> > If you look at the code for byt_gpio_direction_output, it will just
> > print
> > a warning and continue [1]:
> > WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN,
> > "Potential Error: Setting GPIO with direct_irq_en to
> > output");
> > I thought probe finishes successfully, but due to the warning in
> > dmesg you
> > are not sure whether the IRQ GPIO pin can be used as output.
> > If probe fails, it must be for another reason than the direct_irq_en
> > warning.
> >
> > > Would you have a patch for me to test that would bypass this error,
> > > or
> > > at least fallback gracefully to not resetting, not probing GPIOs if
> > > they're badly setup?
> >
> > If the driver fails to initialize the GPIOs, it will at least print
> > some
> > "Failed to get GPIO" warnings in dmesg. Do you have such messages in
> > dmesg or any additional information on why probe fails?
> >
> > The current code will ignore GPIOs if they are not defined in ACPI
> > (see the check for -ENOENT), but does not ignore other error codes.
> > If you want to bypass all GPIO errors, you can use the code below.
> 
> The failure isn't there, it's when running goodix_i2c_test():
> Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: i2c test failed 
> attempt 1: -121
> Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: i2c test failed 
> attempt 2: -121
> Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: I2C communication 
> failure: -121
> Sep 25 16:39:20 winbook kernel: Goodix-TS: probe of i2c-GDIX1001:00 failed 
> with error -121
> 

Are you using v6 of the patches? There was an issue with reset that Aleksei 
reported
and was fixed in v6 (although he had a different i2c error and a different 
scenario).

> The GPIO setup seems to work (bar the warnings), and the reset as well,
> but then the device fails to communicate. Likely a fallout from the
> reset actually failing.
> 
> Swapping around the RST and INT pins leads to the same problem. Either
> this device's GPIO PINs aren't actually functional, and the firmware
> contains garbage, or something else is wrong.
> 

I agree. Either the interrupt pin cannot be used as output in your configuration
or there are some specifics in the ACPI tables that prevent using these pins. 

> I'm not sure how we can detect, and blacklist, those devices. At least
> my original device, the Onda v975w, and the WinBook TW100 would have
> those problems.
> 

I can use DMI quirks to exclude these devices from using the features that
depend on the gpio pins. I already have the DMI information for WinBook TW100
and WinBook TW700. Could you tell me the DMI_SYS_VENDOR and
DMI_PRODUCT_NAME for Onda v975w so I can add it as well?

Thanks,
Irina

> Cheers

Re: [PATCHv2 1/2] iio: adc: Add TI ADS868X

[Jonathan Cameron]

On 28/09/15 17:26, Sean Nyekjær wrote:
> Hi
> 
> Just to clear thing up :-)
> 
> All the mess in the write_raw functions are from the allowed scales.
> if you are in ±0.625×Vref mode you are not allowed set an offset value of 0.
Ah.  Thanks for clarifying that.
> 
> INPUT RANGE POSITIVE FULL SCALE NEGATIVE FULL SCALE FULL-SCALE RANGE
> ±2.5 × V REF 10.24 V –10.24 V 20.48 V
> ±1.25 × V REF 5.12 V –5.12 V 10.24 V
> ±0.625 × V REF 2.56 V –2.56 V 5.12 V
> 0 to 2.5 × V REF 10.24 V 0V 10.24 V
> 0 to 1.25 × V REF 5.12 V 0V 5.12 V
> 
> I will update the driver with your comments :-)
> 
> /Sean
> 
> On 2015-09-27 16:38, Jonathan Cameron wrote:
>> On 25/09/15 07:29, Sean Nyekjaer wrote:
>>> This patch adds support for the Texas Intruments ADS868x ADC.
>>>
>>> Signed-off-by: Sean Nyekjaer 
>>> Reviewed-by: Martin Hundebøll 
>> Hi
>>
>> The driver is fundamentally good, but I think a few small changes would make
>> it less complex to read which is always a good thing!
>>
>> Comments inline.
>>
>> Jonathan
>>> ---
>>> Changes since v1:
>>> - Now possible to read and write the actual offset and scale values
>>> - Removed unused includes
>>> - Removed unused buffer references
>>>
>>>   drivers/iio/adc/Kconfig  |  10 +
>>>   drivers/iio/adc/Makefile |   1 +
>>>   drivers/iio/adc/ti-ads868x.c | 456 
>>> +++
>>>   3 files changed, 467 insertions(+)
>>>   create mode 100644 drivers/iio/adc/ti-ads868x.c
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index deea62c..39924d5 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -322,6 +322,16 @@ config TI_ADC128S052
>>> This driver can also be built as a module. If so, the module will be
>>> called ti-adc128s052.
>>>   +config TI_ADS868X
>>> +tristate "Texas Instruments ADS8684/8"
>>> +depends on SPI && OF
>>> +help
>>> +  If you say yes here you get support for Texas Instruments ADS8684 and
>>> +  and ADS8688 ADC chips
>>> +
>>> +  This driver can also be built as a module. If so, the module will be
>>> +  called ti-ads868x.
>>> +
>>>   config TI_AM335X_ADC
>>>   tristate "TI's AM335X ADC driver"
>>>   depends on MFD_TI_AM335X_TSCADC
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index fa5723a..75170d2 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -31,6 +31,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>>   obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>>   obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>>   obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>>> +obj-$(CONFIG_TI_ADS868X) += ti-ads868x.o
>>>   obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>>   obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>>>   obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
>>> diff --git a/drivers/iio/adc/ti-ads868x.c b/drivers/iio/adc/ti-ads868x.c
>>> new file mode 100644
>>> index 000..66d9b64
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/ti-ads868x.c
>>> @@ -0,0 +1,456 @@
>>> +/*
>>> + * Copyright (C) 2015 Prevas A/S
>>> + *
>>> + * 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.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#define ADS868X_CMD_REG(x)(x << 8)
>>> +#define ADS868X_CMD_REG_NOOP0x00
>>> +#define ADS868X_CMD_REG_RST0x85
>>> +#define ADS868X_CMD_REG_MAN_CH(chan)(0xC0 | (4 * chan))
>>> +#define ADS868X_CMD_DONT_CARE_BITS16
>>> +
>>> +#define ADS868X_PROG_REG(x)(x << 9)
>>> +#define ADS868X_PROG_REG_RANGE_CH(chan)(0x05 + chan)
>>> +#define ADS868X_PROG_WR_BITBIT(8)
>>> +#define ADS868X_PROG_DONT_CARE_BITS8
>>> +
>>> +#define ADS868X_VREF_MV4096
>>> +#define ADS868X_REALBITS16
>>> +
>>> +struct ads868x_chip_info {
>>> +unsigned int id;
>>> +const struct iio_chan_spec *channels;
>>> +unsigned int num_channels;
>>> +unsigned int flags;
>> flags isn't used that I can see.
>>> +const struct iio_info *iio_info;
>> Why bother? Right now you only have one iio_info structure for both
>> supported parts.  Just use it directly and drop it form this structure.
>>> +};
>>> +
>>> +struct ads868x_state {
>>> +const struct ads868x_chip_info*chip_info;
>>> +struct spi_device*spi;
>>> +struct regulator*reg;
>>> +unsigned intvref_mv;
>> prefer u8 type to a char as it clearly isn't actually a character.
>>
>> See below for more detail, but I'd suggest having a contiguous enum to
>> reference into the below ranges structure then store that in your
>> device instance specific structure rather than these values.
>> It avoids a fair bit of searchin

Re: [PATCH] ARM: dts: Add Exynos5250 Snow Rev5+ support

[Doug Anderson]

Javier,

On Tue, Sep 29, 2015 at 4:57 AM, Javier Martinez Canillas
 wrote:
> There are 2 revisions of the Exynos5250 Snow Chromebook that were shipped:
> Rev4 and Rev5. The only difference between these 2 revisions is the codec,
> Rev4 has a max98095 codec while Rev5 has a max98090.
>
> Mainline only supports Rev4 so this patch moves the common device nodes to
> a DTSI file and adds a DTS for the Exynos5250 Snow Rev5.
>
> The Snow Rev5 DTS is based on the DTS found in the ChromiumOS 3.8 tree.
>
> Signed-off-by: Javier Martinez Canillas 
>
> ---
>
> The DTS in the vendor ChromeOS tree are called exynos5250-snow-rev{4,5}.dtb
> but I decided to leave Rev4 as exynos5250-snow.dtb to avoid breaking u-boot
> that has CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" in snow_defconfig.
>
> Also, ChromiumOS Rev4 DTS has "google,snow-rev4" in its compatible string
> but was not added in mainline since Rev4 firmware fallbacks to "google,snow"
> and Rev5 searches for "google,snow-rev5". That way the compatible string
> could be consistent with the DTS naming and still be able to pack both Rev4
> and Rev5 FDT in the same FIT image and let the firmware pick the correct FDT.

Looking at all the notes in the DTS in the ChromeOS tree, this sounds
like it should be fine.


>  arch/arm/boot/dts/Makefile|   1 +
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 684 
> ++
>  arch/arm/boot/dts/exynos5250-snow-rev5.dts|  47 ++
>  arch/arm/boot/dts/exynos5250-snow.dts | 666 +
>  4 files changed, 733 insertions(+), 665 deletions(-)

Thanks!  Note:

$ pwclient git-am 7285451
Applying patch #7285451 using 'git am'
Description: ARM: dts: Add Exynos5250 Snow Rev5+ support
Applying: ARM: dts: Add Exynos5250 Snow Rev5+ support
.git/rebase-apply/patch:774: new blank line at EOF.
+
warning: 1 line adds whitespace errors.


One other nit is that the exynos5250-snow.dts" ends up with the
"max98095" pinctrl properties sorted differently than the
"exynos5250-snow-rev5.dts".  Is it worth reordering the
"exynos5250-snow.dts" in the same patch?

Otherwise this looks fine to me.

Reviewed-by: Douglas Anderson 
--
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 0/9] Making the generic ACPI GSI layer irqdomain aware

[Marc Zyngier]

On 29/09/15 18:11, Rob Herring wrote:
> On Mon, Sep 28, 2015 at 11:42 AM, Marc Zyngier  wrote:
>> The irqdomain code is not entierely ACPI friendly, as it has some
>> built-in knowledge of the device-tree. Nothing too harmful, but enough
>> to scare the ARM ACPI developpers which end up with their own version
>> of the square wheel.
>>
>> This small patch series adapts the irqdomain code to remove the
>> hurdles that prevent the full blown irqdomain subsystem to be used on
>> ACPI, creates an interface between the GSI layer and the irqdomain,
>> and as an example, convert the ARM GIC ACPI support to use irqdomains
>> as originally intended.
>>
>> Overall, this gives us a way to use irqdomains on both DT and ACPI
>> enabled platforms, having very little changes made to the actual
>> drivers (other than the probing infrastructure). Because we keep the
>> flow of information between the various layers identical between ACPI
>> and DT, we immediately benefit from the existing infrastructure. The
>> "convert the GSI information to be DT friendly" is admitedly not very
>> pretty, but I see it as a stepping stone towards unifying the two
>> structures.
> 
> Did I miss v1-v3 or did the DT change just show up? I probably tuned
> out with ACPI in the subject.

No, that's new. It was far worse before.

> Needing fake DT nodes for ACPI is just wrong. There's got to be
> another, better way.

Well, the alternative is to rewrite the whole of irqdomain and
everything that gets called from there in terms of fwnode_handle. Which
will trickle in the whole of OF as well.

Note that the fake DT node doesn't represent an ACPI object at all. It
is an identifier for an irqdomain, and that's where it stops.

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 v4 0/9] Making the generic ACPI GSI layer irqdomain aware

[Rob Herring]

On Mon, Sep 28, 2015 at 11:42 AM, Marc Zyngier  wrote:
> The irqdomain code is not entierely ACPI friendly, as it has some
> built-in knowledge of the device-tree. Nothing too harmful, but enough
> to scare the ARM ACPI developpers which end up with their own version
> of the square wheel.
>
> This small patch series adapts the irqdomain code to remove the
> hurdles that prevent the full blown irqdomain subsystem to be used on
> ACPI, creates an interface between the GSI layer and the irqdomain,
> and as an example, convert the ARM GIC ACPI support to use irqdomains
> as originally intended.
>
> Overall, this gives us a way to use irqdomains on both DT and ACPI
> enabled platforms, having very little changes made to the actual
> drivers (other than the probing infrastructure). Because we keep the
> flow of information between the various layers identical between ACPI
> and DT, we immediately benefit from the existing infrastructure. The
> "convert the GSI information to be DT friendly" is admitedly not very
> pretty, but I see it as a stepping stone towards unifying the two
> structures.

Did I miss v1-v3 or did the DT change just show up? I probably tuned
out with ACPI in the subject.

Needing fake DT nodes for ACPI is just wrong. There's got to be
another, better way.

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

Re: [PATCH v6 20/22] driver core: Allow deferring probes until late init

[Rob Herring]

On Tue, Sep 29, 2015 at 3:05 AM, Tomeu Vizoso
 wrote:
> On 26 September 2015 at 20:15, Rob Herring  wrote:
>> On 09/21/2015 09:03 AM, Tomeu Vizoso wrote:
>>> Add a field to struct device that instructs the device-driver core to
>>> defer the probe of this device until the late_initcall level.
>>
>> This is true until the next patch with moves deferred probe processing
>> to device_initcall_sync. So disabling this option alone won't totally
>> revert to current behaviour. I guess patch 21 could be reverted if
>> necessary.
>
> Actually, the goal with that commit was to prevent potential problems
> due to the increased pressure on late_initcall, as suggested by
> Grygorii Strashko, but I haven't found yet any evidence of it being
> needed, and in my testing the series boot all boards in kernelci with
> or without this commit. So I would just not commit it for now and only
> consider applying it later if someone reports a problem.

I had similar concerns with assumptions about ordering WRT
late_initcall. I would keep this for now.

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 v3 4/4] MAINTAINERS: da7219: Add entry to cover DA7219 bindings document

[Adam Thomson]

This adds an entry to indicate the DA7219 bindings document (and
other Dialog codecs bindings documents) are supported.

Signed-off-by: Adam Thomson 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9f6685f..2a14a19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3367,6 +3367,7 @@ M:Support Opensource 

 W: http://www.dialog-semiconductor.com/products
 S: Supported
 F: Documentation/hwmon/da90??
+F: Documentation/devicetree/bindings/sound/da[79]*.txt
 F: drivers/gpio/gpio-da90??.c
 F: drivers/hwmon/da90??-hwmon.c
 F: drivers/iio/adc/da91??-*.c
--
1.9.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 v3 2/4] ASoC: codecs: Add da7219 codec driver

[Adam Thomson]

This adds support for the DA7219 audio codec with built-in advanced
accessory detect features.

Signed-off-by: Adam Thomson 
---
 include/sound/da7219-aad.h|   99 +++
 include/sound/da7219.h|   55 ++
 sound/soc/codecs/Kconfig  |4 +
 sound/soc/codecs/Makefile |2 +
 sound/soc/codecs/da7219-aad.c |  823 +
 sound/soc/codecs/da7219-aad.h |  212 +
 sound/soc/codecs/da7219.c | 1940 +
 sound/soc/codecs/da7219.h |  820 +
 8 files changed, 3955 insertions(+)
 create mode 100644 include/sound/da7219-aad.h
 create mode 100644 include/sound/da7219.h
 create mode 100644 sound/soc/codecs/da7219-aad.c
 create mode 100644 sound/soc/codecs/da7219-aad.h
 create mode 100644 sound/soc/codecs/da7219.c
 create mode 100644 sound/soc/codecs/da7219.h

diff --git a/include/sound/da7219-aad.h b/include/sound/da7219-aad.h
new file mode 100644
index 000..17802fb
--- /dev/null
+++ b/include/sound/da7219-aad.h
@@ -0,0 +1,99 @@
+/*
+ * da7219-aad.h - DA7322 ASoC Codec AAD Driver Platform Data
+ *
+ * Copyright (c) 2015 Dialog Semiconductor Ltd.
+ *
+ * Author: Adam Thomson 
+ *
+ * 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.
+ */
+
+#ifndef __DA7219_AAD_PDATA_H
+#define __DA7219_AAD_PDATA_H
+
+enum da7219_aad_micbias_pulse_lvl {
+   DA7219_AAD_MICBIAS_PULSE_LVL_OFF = 0,
+   DA7219_AAD_MICBIAS_PULSE_LVL_2_8V = 6,
+   DA7219_AAD_MICBIAS_PULSE_LVL_2_9V,
+};
+
+enum da7219_aad_btn_cfg {
+   DA7219_AAD_BTN_CFG_2MS = 1,
+   DA7219_AAD_BTN_CFG_5MS,
+   DA7219_AAD_BTN_CFG_10MS,
+   DA7219_AAD_BTN_CFG_50MS,
+   DA7219_AAD_BTN_CFG_100MS,
+   DA7219_AAD_BTN_CFG_200MS,
+   DA7219_AAD_BTN_CFG_500MS,
+};
+
+enum da7219_aad_mic_det_thr {
+   DA7219_AAD_MIC_DET_THR_200_OHMS = 0,
+   DA7219_AAD_MIC_DET_THR_500_OHMS,
+   DA7219_AAD_MIC_DET_THR_750_OHMS,
+   DA7219_AAD_MIC_DET_THR_1000_OHMS,
+};
+
+enum da7219_aad_jack_ins_deb {
+   DA7219_AAD_JACK_INS_DEB_5MS = 0,
+   DA7219_AAD_JACK_INS_DEB_10MS,
+   DA7219_AAD_JACK_INS_DEB_20MS,
+   DA7219_AAD_JACK_INS_DEB_50MS,
+   DA7219_AAD_JACK_INS_DEB_100MS,
+   DA7219_AAD_JACK_INS_DEB_200MS,
+   DA7219_AAD_JACK_INS_DEB_500MS,
+   DA7219_AAD_JACK_INS_DEB_1S,
+};
+
+enum da7219_aad_jack_det_rate {
+   DA7219_AAD_JACK_DET_RATE_32_64MS = 0,
+   DA7219_AAD_JACK_DET_RATE_64_128MS,
+   DA7219_AAD_JACK_DET_RATE_128_256MS,
+   DA7219_AAD_JACK_DET_RATE_256_512MS,
+};
+
+enum da7219_aad_jack_rem_deb {
+   DA7219_AAD_JACK_REM_DEB_1MS = 0,
+   DA7219_AAD_JACK_REM_DEB_5MS,
+   DA7219_AAD_JACK_REM_DEB_10MS,
+   DA7219_AAD_JACK_REM_DEB_20MS,
+};
+
+enum da7219_aad_btn_avg {
+   DA7219_AAD_BTN_AVG_1 = 0,
+   DA7219_AAD_BTN_AVG_2,
+   DA7219_AAD_BTN_AVG_4,
+   DA7219_AAD_BTN_AVG_8,
+};
+
+enum da7219_aad_adc_1bit_rpt {
+   DA7219_AAD_ADC_1BIT_RPT_1 = 0,
+   DA7219_AAD_ADC_1BIT_RPT_2,
+   DA7219_AAD_ADC_1BIT_RPT_4,
+   DA7219_AAD_ADC_1BIT_RPT_8,
+};
+
+struct da7219_aad_pdata {
+   int irq;
+
+   enum da7219_aad_micbias_pulse_lvl micbias_pulse_lvl;
+   u32 micbias_pulse_time;
+   enum da7219_aad_btn_cfg btn_cfg;
+   enum da7219_aad_mic_det_thr mic_det_thr;
+   enum da7219_aad_jack_ins_deb jack_ins_deb;
+   enum da7219_aad_jack_det_rate jack_det_rate;
+   enum da7219_aad_jack_rem_deb jack_rem_deb;
+
+   u8 a_d_btn_thr;
+   u8 d_b_btn_thr;
+   u8 b_c_btn_thr;
+   u8 c_mic_btn_thr;
+
+   enum da7219_aad_btn_avg btn_avg;
+   enum da7219_aad_adc_1bit_rpt adc_1bit_rpt;
+};
+
+#endif /* __DA7219_AAD_PDATA_H */
diff --git a/include/sound/da7219.h b/include/sound/da7219.h
new file mode 100644
index 000..3f39e13
--- /dev/null
+++ b/include/sound/da7219.h
@@ -0,0 +1,55 @@
+/*
+ * da7219.h - DA7219 ASoC Codec Driver Platform Data
+ *
+ * Copyright (c) 2015 Dialog Semiconductor
+ *
+ * Author: Adam Thomson 
+ *
+ * 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.
+ */
+
+#ifndef __DA7219_PDATA_H
+#define __DA7219_PDATA_H
+
+/* LDO */
+enum da7219_ldo_lvl_sel {
+   DA7219_LDO_LVL_SEL_1_05V = 0,
+   DA7219_LDO_LVL_SEL_1_10V,
+   DA7219_LDO_LVL_SEL_1_20V,
+   DA7219_LDO_LVL_SEL_1_40V,
+};
+
+/* Mic Bias */
+enum da7219_micbias_voltage {
+   DA7219_MICBIAS_1_8V = 1,
+   DA7219_MICBIAS_2_0V,
+   DA7219_MICBIAS_2_2V,
+   DA7219_MICBIAS_2_4V,
+   DA7219_MICBIAS_2_6V,
+};
+
+/* Mic input type */
+enum da7219_mic_amp_in_sel {
+   DA7219_MIC_AMP_IN_SEL_DIFF = 0,
+   DA7219_MIC

[PATCH v3 3/4] ASoC: da7219: Add bindings documentation for DA7219 audio codec

[Adam Thomson]

Signed-off-by: Adam Thomson 
---
 Documentation/devicetree/bindings/sound/da7219.txt | 106 +
 1 file changed, 106 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/da7219.txt

diff --git a/Documentation/devicetree/bindings/sound/da7219.txt 
b/Documentation/devicetree/bindings/sound/da7219.txt
new file mode 100644
index 000..1b70309
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/da7219.txt
@@ -0,0 +1,106 @@
+Dialog Semiconductor DA7219 Audio Codec bindings
+
+DA7219 is an audio codec with advanced accessory detect features.
+
+==
+
+Required properties:
+- compatible : Should be "dlg,da7219"
+- reg: Specifies the I2C slave address
+
+- interrupt-parent : Specifies the phandle of the interrupt controller to which
+  the IRQs from DA7219 are delivered to.
+- interrupts : IRQ line info for DA7219.
+  (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt 
for
+   further information relating to interrupt properties)
+
+- VDD-supply: VDD power supply for the device
+- VDDMIC-supply: VDDMIC power supply for the device
+- VDDIO-supply: VDDIO power supply for the device
+  (See Documentation/devicetree/bindings/regulator/regulator.txt for further
+   information relating to regulators)
+
+Optional properties:
+- interrupt-names : Name associated with interrupt line. Should be "wakeup" if
+  interrupt is to be used to wake system, otherwise "irq" should be used.
+- wakeup-source: Flag to indicate this device can wake system (suspend/resume).
+
+- clocks : phandle and clock specifier for codec MCLK.
+- clock-names : Clock name string for 'clocks' attribute, should be "mclk".
+
+- dlg,ldo-lvl : Required internal LDO voltage (mV) level for digital engine
+   [<1050>, <1100>, <1200>, <1400>]
+- dlg,micbias-lvl : Voltage (mV) for Mic Bias
+   [<1800>, <2000>, <2200>, <2400>, <2600>]
+- dlg,mic-amp-in-sel : Mic input source type
+   ["diff", "se_p", "se_n"]
+
+==
+
+Child node - 'da7219_aad':
+
+Optional properties:
+- dlg,micbias-pulse-lvl : Mic bias higher voltage pulse level (mV).
+   [<2800>, <2900>]
+- dlg,micbias-pulse-time : Mic bias higher voltage pulse duration (ms)
+- dlg,btn-cfg : Periodic button press measurements for 4-pole jack (ms)
+   [<2>, <5>, <10>, <50>, <100>, <200>, <500>]
+- dlg,mic-det-thr : Impedance threshold for mic detection measurement (Ohms)
+   [<200>, <500>, <750>, <1000>]
+- dlg,jack-ins-deb : Debounce time for jack insertion (ms)
+   [<5>, <10>, <20>, <50>, <100>, <200>, <500>, <1000>]
+- dlg,jack-det-rate: Jack type detection latency (3/4 pole)
+   ["32ms_64ms", "64ms_128ms", "128ms_256ms", "256ms_512ms"]
+- dlg,jack-rem-deb : Debounce time for jack removal (ms)
+   [<1>, <5>, <10>, <20>]
+- dlg,a-d-btn-thr : Impedance threshold between buttons A and D
+   [0x0 - 0xFF]
+- dlg,d-b-btn-thr : Impedance threshold between buttons D and B
+   [0x0 - 0xFF]
+- dlg,b-c-btn-thr : Impedance threshold between buttons B and C
+   [0x0 - 0xFF]
+- dlg,c-mic-btn-thr : Impedance threshold between button C and Mic
+   [0x0 - 0xFF]
+- dlg,btn-avg : Number of 8-bit readings for averaged button measurement
+   [<1>, <2>, <4>, <8>]
+- dlg,adc-1bit-rpt : Repeat count for 1-bit button measurement
+   [<1>, <2>, <4>, <8>]
+
+==
+
+Example:
+
+   codec: da7219@1a {
+   compatible = "dlg,da7219";
+   reg = <0x1a>;
+
+   interrupt-parent = <&gpio6>;
+   interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
+
+   VDD-supply = <®_audio>;
+   VDDMIC-supply = <®_audio>;
+   VDDIO-supply = <®_audio>;
+
+   clocks = <&clks 201>;
+   clock-names = "mclk";
+
+   dlg,ldo-lvl = <1200>;
+   dlg,micbias-lvl = <2600>;
+   dlg,mic-amp-in-sel = "diff";
+
+   da7219_aad {
+   dlg,btn-cfg = <50>;
+   dlg,mic-det-thr = <500>;
+   dlg,jack-ins-deb = <20>;
+   dlg,jack-det-rate = "32ms_64ms";
+   dlg,jack-rem-deb = <1>;
+
+   dlg,a-d-btn-thr = <0xa>;
+   dlg,d-b-btn-thr = <0x16>;
+   dlg,b-c-btn-thr = <0x21>;
+   dlg,c-mic-btn-thr = <0x3E>;
+
+   dlg,btn-avg = <4>;
+   dlg,adc-1bit-rpt = <1>;
+   };
+   };
--
1.9.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/5] mfd: tps65912: Add driver for the TPS65912 PMIC

[Andrew F. Davis]

On 09/29/2015 02:19 AM, Lee Jones wrote:

On Mon, 28 Sep 2015, Andrew F. Davis wrote:


On 09/25/2015 04:24 PM, Lee Jones wrote:

On Fri, 25 Sep 2015, Andrew F. Davis wrote:


On 09/25/2015 11:50 AM, Lee Jones wrote:

On Thu, 24 Sep 2015, Andrew F. Davis wrote:


This patch adds support for TPS65912 mfd device. It provides
communication through the I2C and SPI interfaces. It contains
the following components:

  - Regulators
  - GPIO controller

Signed-off-by: Andrew F. Davis 
---
  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 ++
  include/linux/mfd/tps65912.h | 393 +++
  6 files changed, 705 insertions(+)
  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 include/linux/mfd/tps65912.h


[...]


+#define TPS65912_IRQ(_name, _reg, _offset) \
+   [TPS65912_IRQ_ ## _name] = {\
+   .mask = TPS65912_ ## _reg ## _ ## _name,\
+   .reg_offset = _offset,  \
+   }


I told you about this already.

If you want this set to be merged for v4.3 then you'll need commit
b4fe8ba ("regmap: Add generic macro to define regmap_irq") from my
tree.


You asked me to submit this to Mark Brown, I didn't realize you also
wanted me to use the one in your tree. Using yours will make my lines
over 80 chars and so it kind of defeats the purpose but I'll do it
for v4.


I asked two of you to upstream a generic incarnation of your
implementation.  The other guy got there first.  Now I want everyone
to use it instead of hand-rolling their own.



Got it.


[...]


+static struct i2c_driver tps65912_i2c_driver = {
+   .driver = {
+   .name   = "tps65912",
+   .of_match_table = tps65912_i2c_of_match_table,


of_match_ptr()



Why? tps65912_i2c_of_match_table is always compiled in.


But it needn't be.



This driver is DT only, would it make more sense to just add a dependency
on CONFIG_OF in the Kconfig?


Yes, that is the alternitive.


I don't see many other drivers that are DT
only doing this, the driver should compile just fine without OF enabled,
it just wont have DT functionality, so is it really dependent on OF?


Then it should be "depends on OF || COMPILE_TEST"



OK, I'll add this.


The of_match_ptr(x) macro looks to be useful when the x is conditionally
compiled in, but in my case the x (my of_device_id table) is always compiled.



--
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] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Jon Hunter]

On 29/09/15 16:34, Arnd Bergmann wrote:
> On Tuesday 29 September 2015 15:18:07 Jon Hunter wrote:
>> On 29/09/15 13:39, Arnd Bergmann wrote:
>>> Ok, that makes more sense then. A few questions still:
>>>
>>> * Would the admaif in turn provide a #dma-cells and have the real slaves
>>>   hooked up to it?
>>
>> I don't think that that would be necessary. If you look at the existing
>> tegra i2s binding [0], there is a ahub-cif-ids property which maps the
>> actual slave to the apbif (equivalent of the adma-if). This ID is used
>> to get the appropriate dma channel for this client interface (cif).
>>
>>> * How do you model the xbar in this scenario?
>>
>> The xbar is common to existing tegra devices and today is configured via
>> the ahub-cif-ids property.
> 
> I see, so instead of modeling the xbar as part of the DMA engine in DT, you
> model it as part of the slave. This probably adds a bit of complexity
> and a somewhat nonstandard binding, but it's too late to change that anyway.
> 
>>> * How does the adma driver know whether you are using a rx or tx channel
>>>   in the above example, should that perhaps be another cell in dma
>>>   specifier? It seems that the numbers are all overlapping between rx and
>>>   tx (each has 1 through 10).
>>
>> The channels can be configured to be either rx or tx and yes the IDs do
>> overlap so you have 1-10 for both rx and tx. However, if you are asking
>> how do I ensure that only one channel uses a specific hardware request,
>> then yes I probably need to add the direction to the specifier to ensure
>> only one channel uses a request at any given time.
> 
> If each channel is either rx or tx, but the two cannot be used simultaneously,
> you can just list each of them only once, like this:
> 
>   dmas = <&adma 0>, <&adma 1>, <&adma 2>, ...
>   dma-names = "if0", "if1", "if2", ...
> 
> Otherwise you end up allocating twice the number of channels that you
> really need.

Each dma channel can be configured for either tx or rx. There are 10 tx
ports on the adma-if and 10 rx. So you could have 20 dma channels
configured for each one of the tx and rx ports. It is a bit confusing
because rx port 1 has a request signal of 1 and tx port 1 has a request
signal of 1 as well. So if you are wondering how the dma distinguishes
between rx port 1 and tx port 1, it does so by having a separate field
for the tx and rx request in the dma channel control register.

Cheers
Jon


--
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 v3 1/4] ASoC: Add SOC_DOUBLE_R_EXT

[Adam Thomson]

_EXT version of SOC_DOUBLE_R required to allow for custom handlers.

Signed-off-by: Adam Thomson 
---
 include/sound/soc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index 884e728..2d79cb5 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -217,6 +217,13 @@
.get = xhandler_get, .put = xhandler_put, \
.private_value = \
SOC_DOUBLE_VALUE(reg, shift_left, shift_right, max, invert, 0) }
+#define SOC_DOUBLE_R_EXT(xname, reg_left, reg_right, xshift, xmax, xinvert,\
+xhandler_get, xhandler_put) \
+{  .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = (xname), \
+   .info = snd_soc_info_volsw, \
+   .get = xhandler_get, .put = xhandler_put, \
+   .private_value = SOC_DOUBLE_R_VALUE(reg_left, reg_right, xshift, \
+   xmax, xinvert) }
 #define SOC_SINGLE_EXT_TLV(xname, xreg, xshift, xmax, xinvert,\
 xhandler_get, xhandler_put, tlv_array) \
 {  .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \
--
1.9.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 v3 0/4] ASoC: Add support for DA7219 audio codec

[Adam Thomson]

This patch set adds support for the DA7219 audio codec with built-in
advanced accessory detection functionality. Patch set includes codec driver,
associated DT bindings documentation and MAINTAINERS file updates to cover new
bindings.

This patch set is baselined against the v4.3-rc3 kernel version.

Changes in v3:
 - Actually set clk_src in dai_sysclk() function of codec, so future calls can
   correctly identify if work is to be done or not.

Changes in v2:
 - Add SOC_DOUBLE_R_EXT support to ASoC core.
 - Use of upper-case naming for controls, where missing.
 - Use of Playback/Capture Digital naming for certain ADC/DAC controls.
 - CP mchange and vol_thresh DT bindings removed, now Kcontrols
 - Kcontrols and DAPM now locked as part of hptest work, and specific controls
   affected have had locking introduced.
 - Timeout for btn_det work when checking micbias status.
 - Added comments to describe reasoning for work use with hptest, btn_det.
 - Added comments to tonegen_freq_put/get to clarify endian conversion, and
   code now uses regmap_raw_read/write calls instead of bulk.
 - DT parsing code now prints dev_warn() for invalid settings.
 - SOC_VALUE_ENUM_SINGLE now used for hpf_mode handling, instead of customer
   get/put handlers.
 - DTMF key control now a SOC_ENUM to correctly describe supported keys,
   including non-numeric.
 - MIXIN_L_MIX_EN bit set as part of DAPM now (SUPPLY), rather than in probe.
 - Fix dai_sysclk() function to correctly check for no change, using clk_id as
   well as freq.
 - Error checking added for clk_set_rate() call.
 - Improved error checking for devm_clk_get() call.
 - Removed explicit use of device_may_wakeup() and enable/disable_irq_wake().
   Now taken care of by I2C core so DT bindings updated accordingly to
   document this.
 - hptest work now uses cache to keep state, instead of reading registers
   individually. Cache is bypassed, then when test executed and complete,
   regcache_sync_region() used to restore settings to pre-test values.
 - Regulator consumer framework usage added, in particular to determine VDDIO
   level in use so device can be configured accordingly. DT documents updated
   to reflect this.

Adam Thomson (4):
  ASoC: Add SOC_DOUBLE_R_EXT
  ASoC: codecs: Add da7219 codec driver
  ASoC: da7219: Add bindings documentation for DA7219 audio codec
  MAINTAINERS: da7219: Add entry to cover DA7219 bindings document

 Documentation/devicetree/bindings/sound/da7219.txt |  106 ++
 MAINTAINERS|1 +
 include/sound/da7219-aad.h |   99 +
 include/sound/da7219.h |   55 +
 include/sound/soc.h|7 +
 sound/soc/codecs/Kconfig   |4 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/da7219-aad.c  |  823 +
 sound/soc/codecs/da7219-aad.h  |  212 +++
 sound/soc/codecs/da7219.c  | 1940 
 sound/soc/codecs/da7219.h  |  820 +
 11 files changed, 4069 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/da7219.txt
 create mode 100644 include/sound/da7219-aad.h
 create mode 100644 include/sound/da7219.h
 create mode 100644 sound/soc/codecs/da7219-aad.c
 create mode 100644 sound/soc/codecs/da7219-aad.h
 create mode 100644 sound/soc/codecs/da7219.c
 create mode 100644 sound/soc/codecs/da7219.h

--
1.9.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 linux-next 0/4] mtd: spi-nor: fix Quad SPI memory support

[Mark Brown]

On Mon, Sep 28, 2015 at 04:10:17PM +0200, Cyrille Pitchen wrote:
> Hi all,

Please don't top post.  

> Brian, Mark, Marek, with this series I've removed the Atmel QSPI controller
> driver to focus only on the common spi-nor framework. I will send a dedicated

I'm deleting most of these threads unread unless there is some specific
mention of SPI in the subject line of a patch.  I don't really have much
to contribute on the flash-specific portions of the discussion.


signature.asc
Description: Digital signature

Re: [PATCH 3/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Arnd Bergmann]

On Tuesday 29 September 2015 15:18:07 Jon Hunter wrote:
> On 29/09/15 13:39, Arnd Bergmann wrote:
> > Ok, that makes more sense then. A few questions still:
> > 
> > * Would the admaif in turn provide a #dma-cells and have the real slaves
> >   hooked up to it?
> 
> I don't think that that would be necessary. If you look at the existing
> tegra i2s binding [0], there is a ahub-cif-ids property which maps the
> actual slave to the apbif (equivalent of the adma-if). This ID is used
> to get the appropriate dma channel for this client interface (cif).
> 
> > * How do you model the xbar in this scenario?
> 
> The xbar is common to existing tegra devices and today is configured via
> the ahub-cif-ids property.

I see, so instead of modeling the xbar as part of the DMA engine in DT, you
model it as part of the slave. This probably adds a bit of complexity
and a somewhat nonstandard binding, but it's too late to change that anyway.

> > * How does the adma driver know whether you are using a rx or tx channel
> >   in the above example, should that perhaps be another cell in dma
> >   specifier? It seems that the numbers are all overlapping between rx and
> >   tx (each has 1 through 10).
> 
> The channels can be configured to be either rx or tx and yes the IDs do
> overlap so you have 1-10 for both rx and tx. However, if you are asking
> how do I ensure that only one channel uses a specific hardware request,
> then yes I probably need to add the direction to the specifier to ensure
> only one channel uses a request at any given time.

If each channel is either rx or tx, but the two cannot be used simultaneously,
you can just list each of them only once, like this:

dmas = <&adma 0>, <&adma 1>, <&adma 2>, ...
dma-names = "if0", "if1", "if2", ...

Otherwise you end up allocating twice the number of channels that you
really need.

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/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC

[Mark Brown]

On Fri, Sep 25, 2015 at 03:10:04PM -0500, Andrew F. Davis wrote:
> On 09/25/2015 01:05 PM, Mark Brown wrote:
> >On Thu, Sep 24, 2015 at 09:52:53AM -0500, Andrew F. Davis wrote:

> >>+   match = of_match_device(tps65912_regulator_of_match_table, &pdev->dev);
> >>+   if (!match)
> >>+   return -ENODEV;

> >>+   template = match->data;
> >>+   id = template->id;
> >>+   init_data = of_get_regulator_init_data(&pdev->dev, pdev->dev.of_node,
> >>+  ®ulators[id]);

> >Don't open code this stuff, use the core DT matching in the
> >regulator_desc instead.

> I assume you are referring to your additions in a0c7b164ad11? If so I'm not

Please don't refer to commits by ID only, include a human readable
description of the commit for the benefit of any humans who might read
your mail.

> sure that will save me anything as my probe function is called with a DT
> match already, so no searching is needed.

You've not understood what that change is replacing, the code I'm
quoting above is exactly that code.  Check out some of the existing
drivers using this API.

> >Please also use subject lines mathcing the style for the subsystem.

> I'm not sure I know what you mean? What is wrong with my subject line, it 
> looks
> like the others I've looked at?

You are using "regulators:", the regulator API uses "regulator:" - this
should be really clear if you do something like a git shortlog.


signature.asc
Description: Digital signature

Re: [PATCH v4 1/5] Documentation: add DT bindings for ARM SCPI sensors

[Punit Agrawal]

Punit Agrawal  writes:

> Punit Agrawal  writes:
>
>> The System Control Processor (SCP) provides access to SoC sensors via
>> the System Control and Power Interface (SCPI) Message Protocol. Add
>> bindings to allow probing of these sensors. Also support referencing
>> of the sensors for setting up thermal zones via the thermal DT
>> bindings.
>>
>> Signed-off-by: Punit Agrawal 
>> Cc: Rob Herring 
>> Cc: Mark Rutland 
>> Cc: Sudeep Holla 
>
> Gentle reminder for review of the below bindings. They've been updated
> based on feedback on the earlier version [a].
>
> If there are no further comments, I'd like to request an ack from the DT
> reviewers.

Ping!

>
> [a] 
> http://thread.gmane.org/gmane.linux.power-management.general/65475/focus=134976
>
>> ---
>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 38 
>> ++
>>  1 file changed, 38 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt 
>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index f002460..86302de 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -72,8 +72,25 @@ Required sub-node properties:
>>  - compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
>> shared memory on Juno platforms
>>  
>> +Sensor bindings for the sensors based on SCPI Message Protocol
>> +--
>> +SCPI provides an API to access the various sensors on the SoC.
>> +
>> +Required properties:
>> +- compatible : should be "arm,scpi-sensors".
>> +- #thermal-sensor-cells: should be set to 1. This property follows the
>> + thermal device tree bindings[2].
>> +
>> + Valid cell values are raw identifiers (Sensor
>> + ID) as used by the firmware. Refer to
>> + platform documentation for your
>> + implementation for the IDs to use. For Juno
>> + R0 and Juno R1 refer to [3].
>> +
>>  [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
>>  [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> +[2] Documentation/devicetree/bindings/thermal/thermal.txt
>> +[3] 
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
>>  
>>  Example:
>>  
>> @@ -122,6 +139,11 @@ scpi_protocol: scpi@2e00 {
>>  clock-output-names = "pxlclk0", "pxlclk1";
>>  };
>>  };
>> +
>> +scpi_sensors0: sensors {
>> +compatible = "arm,scpi-sensors";
>> +#thermal-sensor-cells = <1>;
>> +};
>>  };
>>  
>>  cpu@0 {
>> @@ -136,6 +158,17 @@ hdlcd@7ff6 {
>>  clocks = <&scpi_clk 4>;
>>  };
>>  
>> +thermal-zones {
>> +soc_thermal {
>> +polling-delay-passive = <100>;
>> +polling-delay = <1000>;
>> +
>> +/* sensor ID */
>> +thermal-sensors = <&scpi_sensors0 3>;
>> +...
>> +};
>> +};
>> +
>>  In the above example, the #clock-cells is set to 1 as required.
>>  scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0,
>>  1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0
>> @@ -148,3 +181,8 @@ scpi_dvfs i.e. "atlclk".
>>  Similarly the second example is hdlcd@7ff6 and it has pxlclk1 as input
>>  clock. '4' in the clock specifier here points to the second entry
>>  in the output clocks of scpi_clocks  i.e. "pxlclk1"
>> +
>> +The thermal-sensors property in the soc_thermal node uses the
>> +temperature sensor provided by SCP firmware to setup a thermal
>> +zone. The ID "3" is the sensor identifier for the temperature sensor
>> +as used by the firmware.
> --
> 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
--
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 v9 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller

[Sergei Shtylyov]

On 09/29/2015 06:01 AM, Chunfeng Yun wrote:


add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.

Signed-off-by: Chunfeng Yun 
---
  .../devicetree/bindings/usb/mt8173-xhci.txt| 52 ++
  1 file changed, 52 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
new file mode 100644
index 000..0c96273
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -0,0 +1,52 @@

[...]

+
+Example:
+usb30: usb@1127 {

[...]

+   status = "okay";


   This line is not needed.

[...]

MBR, Sergei

--
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 v9 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs

[Sergei Shtylyov]

Hello.

On 09/29/2015 06:01 AM, Chunfeng Yun wrote:


add a DT binding documentation of usb3.0 phy for MT65xx
SoCs from Mediatek.

Acked-by: Rob Herring 
Signed-off-by: Chunfeng Yun 
---
  .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 68 ++
  1 file changed, 68 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
new file mode 100644
index 000..00100cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -0,0 +1,68 @@
+mt65xx USB3.0 PHY binding
+--
+
+This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
+
+Required properties (controller (parent) node):
+ - compatible  : should be "mediatek,mt8173-u3phy"
+ - reg : offset and length of register for phy, exclude port's
+ register.
+ - clocks  : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain
+ "u3phya_ref": for reference clock of usb3.0 analog phy.
+
+Required nodes : a sub-node is required for each port the controller
+ provides. Address range information including the usual
+ 'reg' property is used inside these nodes to describe
+ the controller's topology.
+
+Required properties (port (child) node):
+- reg  : address and length of the register set for the port.
+- #phy-cells   : should be 1 (See second example)
+ cell after port phandle is phy type from:
+   - PHY_TYPE_USB2
+   - PHY_TYPE_USB3
+
+Example:
+
+u3phy: usb-phy@1129 {
+   compatible = "mediatek,mt8173-u3phy";
+   reg = <0 0x1129 0 0x800>;
+   clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+   clock-names = "u3phya_ref";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;


   You don't describe the above 3 props neither as mandatory nor optional.

[...]

+Specifying phy control of devices
+-
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the phy port node and a device type;
+phy-names for each port are optional.
+
+Example:
+
+#include 
+
+usb30: usb@1127 {
+   ...
+   phys = <&phy_port0 PHY_TYPE_USB3>;
+   phy-names = "usb3-0";
+   ...
+};


   Isn't the above already described in 
Documentation/devicetree/bindings/phy/phy-bindings.txt?


MBR, Sergei

--
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 RESEND] ARM: dts: Fix Makefile target for sun4i-a10-itead-iteaduino-plus

[Josh Boyer]

On Sun, Sep 6, 2015 at 7:20 AM, Maxime Ripard
 wrote:
> On Fri, Sep 04, 2015 at 08:49:34AM -0400, Josh Boyer wrote:
>> Commit 79ae3e66f8d (ARM: dts: sun4i: Add Iteaduino Plus A10) added a new
>> make target for the sun4i-a10-itead-iteaduino-plus dts file, but mistakenly
>> used .dts instead of the correct .dtb suffix.  This resulted in a build error
>> like:
>>
>> scripts/Makefile.dtbinst:42: target 
>> 'sun4i-a10-itead-iteaduino-plus.dts' doesn't match the target pattern
>>
>> when doing a make dtbs_install.
>>
>> Fix it to use the proper file name.
>>
>> Signed-off-by: Josh Boyer 
>
> Queued, thanks!

Are you going to push this to Olof or Linus for the 4.3 release?  I
don't see it in Linus' tree and this is still broken there.

josh
--
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] hwrng: Add support for STMicroelectronics' RNG IP

[Lee Jones]

On Fri, 18 Sep 2015, Lee Jones wrote:
> On Fri, 18 Sep 2015, Herbert Xu wrote:
> > On Fri, Sep 18, 2015 at 03:53:50PM +0100, Lee Jones wrote:
> > > On 18 September 2015 at 15:07, Herbert Xu  
> > > wrote:
> > > > On Thu, Sep 17, 2015 at 02:45:50PM +0100, Lee Jones wrote:
> > > >> v1 => v2:
> > > >>  - New patch: Also fixing /dev/hw_random => /dev/hwrng in Kconfig
> > > >>  - Fix 2099 => 2009 typo in commit log
> > > >>  - Fix 'number of random numbers sourced' return value
> > > >>  - Treat devm_clk_get()'s return value correctly
> > > >>  - Check return value of clk_prepare_enable()
> > > >>  - Use sysfs_streq() instead of manually stripping '\n' from sysfs
> > > >
> > > > All applied.  Thanks.
> > > 
> > > Just to be clear.  Which patches have you applied?
> > 
> > All of your patches.
> 
> I think it's okay for you to take all but patch 6.
> 
> Patch 6 is an ARM patch and needs to go into ARM SoC via
> STMicroelectronics STi tree.

Hi Herbert,

I see that your tree is 8 days old, so this may have been resolved
already, but would you be kind enough to ensure you remove the 6th
(ARM) patch from your repo please?  I wouldn't want it to cause
conflicts and for Maxime and yourself to get shouted at by Linus.

Much appreciated.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Jon Hunter]

On 29/09/15 09:13, Jon Hunter wrote:
> 
> On 28/09/15 17:36, Stephen Warren wrote:
>> On 09/28/2015 08:57 AM, Jon Hunter wrote:
>>>
>>> On 25/09/15 16:47, Arnd Bergmann wrote:
 On Friday 25 September 2015 16:38:55 Jon Hunter wrote:
> On 25/09/15 16:17, Jon Hunter wrote:
>>
>> On 25/09/15 16:03, Arnd Bergmann wrote:
>>> On Friday 25 September 2015 15:56:40 Jon Hunter wrote:
 +   case DMA_MEM_TO_DEV:
 +   burst_size = fls(tdc->config.dst_maxburst);
 +   ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(num_bufs
 - 1);
 +   ch_regs->ctrl =
 ADMA_CH_CTRL_XFER_DIR(ADMA_MEM_TO_AHUB) |
 +  
 ADMA_CH_CTRL_TX_REQ(tdc->config.slave_id);
 +   ch_regs->src_addr = buf_addr;
 +   break;
 +
 +   case DMA_DEV_TO_MEM:
 +   burst_size = fls(tdc->config.src_maxburst);
 +   ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(num_bufs
 - 1);
 +   ch_regs->ctrl =
 ADMA_CH_CTRL_XFER_DIR(ADMA_AHUB_TO_MEM) |
 +  
 ADMA_CH_CTRL_RX_REQ(tdc->config.slave_id);
 +   ch_regs->trg_addr = buf_addr;
 +   break;
>>>
>>> Do not use the 'slave_id' field here to identify the slave device,
>>> that
>>> concept is broken. Instead, put the slave identification into the
>>> dma specifier in DT and read it out in your xlate function.
>>
>> Why is it broken?
>>
>> What happens if I don't know the slave-id? In other words, the
>> slave-id
>> can be dynamically allocated and associated with a given slave.
>
> I guess thinking about it some more, the driver could assign an id
> itself to a given channel and I could avoid using slave_id here. There
> are 22 channels and 10 tx and 10 rx requests.

 This sounds roughly right. So you could pick the ch_regs->ctrl value
 when you allocate the tegra_adma_chan structure, and then map it to
 the slave in the xlate() function.
>>>
>>> Actually, what I mentioned about would not work as it is not the DMA
>>> that should assign the requests to the channel.
>>>
>>> I think that I have poorly described the hardware and how it works, so
>>> let me try and explain a bit more.
>>>
>>>  From a hardware perspective it looks like the following ...
>>>
>>> memory <-> adma <-> adma-if <-> xbar <-> clients
>>>
>>> where:
>>> - memory is the system memory
>>> - adma is the dma controller
>>> - adma-if is the dma interface to a crossbar
>>> - xbar is the crossbar
>>> - clients are various audio interfaces, such as i2s, etc
>>>
>>> The adma-if is essentially a mux with 10 tx and 10 rx ports. Any of the
>>> 22 adma channels can be mapped to any of the 10 tx or rx ports. The
>>> request signal used by the adma is determined by which port it is
>>> configured to use. However, what makes this even more configurable is
>>> the xbar is also a mux that can route adma-if ports to the various
>>> clients.
>>>
>>> So potentially, you could use any adma channel and any port to route
>>> audio to any of the clients. However, the adma-if needs to know which
>>> adma channel is mapped to which port
>>
>> It does? I'm pretty sure it didn't in earlier chips; what changed?
> 
> I *believe* that T210 is the first one to have the ADMA controller where
> as previous chips used the APB-DMA controller. Looking at the APB-DMA on
> T124 I can see that there is a fixed REQ_SEL value for each of the APBIF
> (equivalent of the ADMA-IF on T210).

Actually, I think that T210 is the same as the previous chips. Because
of the xbar you could potentially have various different routing
possibilities between the DMA, CIF and client. However, the request
signal between the DMA and CIF is fixed.

Sorry, I think my brain melted while traversing the audio subsystem.

Jon
--
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] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Jon Hunter]

On 29/09/15 13:39, Arnd Bergmann wrote:

[snip]

> Ok, that makes more sense then. A few questions still:
> 
> * Would the admaif in turn provide a #dma-cells and have the real slaves
>   hooked up to it?

I don't think that that would be necessary. If you look at the existing
tegra i2s binding [0], there is a ahub-cif-ids property which maps the
actual slave to the apbif (equivalent of the adma-if). This ID is used
to get the appropriate dma channel for this client interface (cif).

> * How do you model the xbar in this scenario?

The xbar is common to existing tegra devices and today is configured via
the ahub-cif-ids property.

> * How does the adma driver know whether you are using a rx or tx channel
>   in the above example, should that perhaps be another cell in dma
>   specifier? It seems that the numbers are all overlapping between rx and
>   tx (each has 1 through 10).

The channels can be configured to be either rx or tx and yes the IDs do
overlap so you have 1-10 for both rx and tx. However, if you are asking
how do I ensure that only one channel uses a specific hardware request,
then yes I probably need to add the direction to the specifier to ensure
only one channel uses a request at any given time.

Cheers
Jon

[0]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt
--
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] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Arnd Bergmann]

On Tuesday 29 September 2015 14:42:15 Peter Griffin wrote:
> On Tue, 29 Sep 2015, Arnd Bergmann wrote:
> > On Tuesday 29 September 2015 13:11:55 Peter Griffin wrote:
> > > Does it? I didn't think it did.
> > > 
> > > Using the instance number as a DT property defers the decision over what 
> > > firmware to
> > > load to the driver, which can choose whatever firmware name it wishes.
> > > 
> > > e.g. in v4.3 it could load xyz.elf, in v4.4 it could choose abc.elf. The 
> > > DT will remain
> > > unchanged, but the use of that fdma instance has changed.
> > > 
> > > We currently only have one firmware for each instance with the "use" 
> > > compiled into it.
> > > If in the future we had two firmwares with different "uses" for the same 
> > > instance some extra
> > > logic would be required in the driver to make a decision on which 
> > > firmware to load.
> > 
> > Ok, I probably need some more background about what the firmware on this
> > device does, and what it could do with a different firmware. Could you
> > elaborate?
> 
> So the fdma hw is a dma engine based around a xp70 slim core. It supports: -
> * block memory move between 2 system locations
> * paced transfer from system memory to paced peripheral
> * paced transfer from a paced peripheral to system memory
> 
> I believe each firmware for each instance supports those 3 things.

Ok

> However the xp70 also has some ancilary HW to facilitate Start Code Detection.
> It is this feature which I believe would require a different firmware if we 
> wanted to make
> use of it. Looking at the functional spec each xp70 also
> has 16 gp output signals which we could also control from the firmware. 
> Whether
> these are actually connected to anything useful inside the SoC I don't know.

I still don't understand what Start Code Detection is here.

> > > > and you correctly describe the problem with
> > > > using the compatible string for the firmware name if the driver for the 
> > > > FDMA
> > > > does not actually care what firmware is being used here.
> > > > 
> > > > Whatever code makes the decision as to how the FDMA is used should also
> > > > decide on the name of the firmware file.
> > > 
> > > The code which makes this decision currently is the st_fdma.c driver. 
> > > However it does
> > > need to know which fdma controller it is operating on to make this 
> > > decision correctly.
> > > 
> > > Apart from passing the fdma instance number in DT, how else can we 
> > > determine which
> > > controller we are?
> > > 
> > > I guess we could infer it by having a table in the driver containing the 
> > > base addresses
> > > of the controllers for a given SoC, and match that against what DT passes 
> > > us in the
> > > reg property. But that seems ugly, and is encoding the same information 
> > > in two
> > > different places.
> > > 
> > > I'm open to suggestions if there is a better way to do this.
> > 
> > Using the address would be the same thing, that doesn't change the
> > fundamental logic. Can you explain why it matters which instance
> > a firmware is used on for this driver?
> 
> The reason we care, is that each instance has its own firmware file.
> 
> I just did a hexdump on the 3 different firmwares and compared them. Although 
> the majority
> of the binary is the same, there are various bytes which change at several 
> different offsets
> in the firmware file depending on the instance.
> 
> I don't have a xp70 toolchain or know enough about the cpu architecture to 
> analyze what exactly
> the firmware is doing at these locations.

This sounds like we should indeed treat them as different things: We don't
know what the difference is, but we know that each of them needs a different
firmware, and presumably if you get a new SoC variant, it will in turn
need three new ones.

In this case, I'd say using the compatible string to identify them is best,
using whatever the SoC documentation uses to describe them. You can use the
of_device_id data fields to look up the firmware name then.

If the output signals end up being connected to something we want to
control through the firmware, that also makes sense for a new compatible
string, as the driver needs to know about the feature in order to
communicate with the firmware, and the DT needs to be able to describe
the pins (e.g. by making the node act as a GPIO controller) in a way that
requires a different string, too.

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 v2 2/2] ASoC: atmel-i2s: add driver for the new Atmel I2S controller

[Cyrille Pitchen]

This patch adds support for the Atmel I2S controller embedded into
sama5d2x SoCs.

Signed-off-by: Cyrille Pitchen 
---
 sound/soc/atmel/Kconfig |  10 +
 sound/soc/atmel/Makefile|   2 +
 sound/soc/atmel/atmel-i2s.c | 760 
 3 files changed, 772 insertions(+)
 create mode 100644 sound/soc/atmel/atmel-i2s.c

diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 1489cd461aec..c026c207a386 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -30,6 +30,16 @@ config SND_ATMEL_SOC_SSC
default y if SND_ATMEL_SOC_SSC_DMA=y || SND_ATMEL_SOC_SSC_PDC=y
default m if SND_ATMEL_SOC_SSC_DMA=m || SND_ATMEL_SOC_SSC_PDC=m
 
+config SND_ATMEL_SOC_I2S
+   tristate "SoC Audio support for the Atmel I2S module"
+   select SND_SOC_GENERIC_DMAENGINE_PCM
+   select REGMAP_MMIO
+   depends on OF && (ARCH_AT91 || COMPILE_TEST)
+   help
+ Say Y or M if you want to add support for codecs attached to
+ the Atmel I2S interface. You will also need
+ to select the audio interfaces to support below.
+
 config SND_AT91_SOC_SAM9G20_WM8731
tristate "SoC Audio support for WM8731-based At91sam9g20 evaluation 
board"
depends on ARCH_AT91 || COMPILE_TEST
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index b327e5cc8de3..4d960464aecb 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -2,10 +2,12 @@
 snd-soc-atmel-pcm-pdc-objs := atmel-pcm-pdc.o
 snd-soc-atmel-pcm-dma-objs := atmel-pcm-dma.o
 snd-soc-atmel_ssc_dai-objs := atmel_ssc_dai.o
+snd-soc-atmel-i2s-objs := atmel-i2s.o
 
 obj-$(CONFIG_SND_ATMEL_SOC_PDC) += snd-soc-atmel-pcm-pdc.o
 obj-$(CONFIG_SND_ATMEL_SOC_DMA) += snd-soc-atmel-pcm-dma.o
 obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
+obj-$(CONFIG_SND_ATMEL_SOC_I2S) += snd-soc-atmel-i2s.o
 
 # AT91 Machine Support
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
diff --git a/sound/soc/atmel/atmel-i2s.c b/sound/soc/atmel/atmel-i2s.c
new file mode 100644
index ..9e15acabbaab
--- /dev/null
+++ b/sound/soc/atmel/atmel-i2s.c
@@ -0,0 +1,760 @@
+/*
+ * Driver for Atmel I2S controller
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Author: Cyrille Pitchen 
+ *
+ * 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 in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ATMEL_I2SC_MAX_TDM_CHANNELS8
+
+/*
+ *  I2S Controller Register map 
+ */
+#define ATMEL_I2SC_CR  0x  /* Control Register */
+#define ATMEL_I2SC_MR  0x0004  /* Mode Register */
+#define ATMEL_I2SC_SR  0x0008  /* Status Register */
+#define ATMEL_I2SC_SCR 0x000c  /* Status Clear Register */
+#define ATMEL_I2SC_SSR 0x0010  /* Status Set Register */
+#define ATMEL_I2SC_IER 0x0014  /* Interrupt Enable Register */
+#define ATMEL_I2SC_IDR 0x0018  /* Interrupt Disable Register */
+#define ATMEL_I2SC_IMR 0x001c  /* Interrupt Mask Register */
+#define ATMEL_I2SC_RHR 0x0020  /* Receiver Holding Register */
+#define ATMEL_I2SC_THR 0x0024  /* Transmitter Holding Register */
+#define ATMEL_I2SC_VERSION 0x0028  /* Version Register */
+
+
+/*
+ *  Control Register (Write-only) 
+ */
+#define ATMEL_I2SC_CR_RXEN BIT(0)  /* Receiver Enable */
+#define ATMEL_I2SC_CR_RXDISBIT(1)  /* Receiver Disable */
+#define ATMEL_I2SC_CR_CKEN BIT(2)  /* Clock Enable */
+#define ATMEL_I2SC_CR_CKDISBIT(3)  /* Clock Disable */
+#define ATMEL_I2SC_CR_TXEN BIT(4)  /* Transmitter Enable */
+#define ATMEL_I2SC_CR_TXDISBIT(5)  /* Transmitter Disable */
+#define ATMEL_I2SC_CR_SWRSTBIT(7)  /* Software Reset */
+
+
+/*
+ *  Mode Register (Read/Write) 
+ */
+#define ATMEL_I2SC_MR_MODE_MASKGENMASK(0, 0)
+#define ATMEL_I2SC_MR_MODE_SLAVE   (0 << 0)
+#define ATMEL_I2SC_MR_MODE_MASTER  (1 << 0)
+
+#define ATMEL_I2SC_MR_DATALENGTH_MASK  GENMASK(4, 2)
+#define ATMEL_I2SC_MR_DATALENGTH_32_BITS   (0 << 2)
+#define ATMEL_I2SC_MR_DATALENGTH_24_BITS   (1 << 2)
+#define ATMEL_I2SC_MR_DATALENGTH_20_BITS   (2 << 2)
+#define ATMEL_I2SC_MR_DATALENGTH_18_BITS   (3 << 2)
+#define ATMEL_I2SC_MR_DATALENGTH_16_BITS   (4 << 2)
+#define ATMEL_I2SC_MR_DATALENGTH_16_BITS_COMPACT   (5 << 2)
+

[PATCH v2 1/2] ASoC: atmel-i2s: add DT bindings for I2S controller

[Cyrille Pitchen]

This patch adds DT bindings for the new Atmel I2S controller embedded
inside sama5d2x SoCs.

Signed-off-by: Cyrille Pitchen 
---
 .../devicetree/bindings/sound/atmel-i2s.txt| 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-i2s.txt

diff --git a/Documentation/devicetree/bindings/sound/atmel-i2s.txt 
b/Documentation/devicetree/bindings/sound/atmel-i2s.txt
new file mode 100644
index ..83bc6b9070bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel-i2s.txt
@@ -0,0 +1,43 @@
+* Atmel I2S controller
+
+Required properties:
+- compatible: Should be "atmel,sama5d2-i2s".
+- reg:Should be the physical base address of the controller and the
+  length of memory mapped region.
+- interrupts: Should contain the interrupt for the controller.
+- dmas:   Should be a list of pairs of DMA controller phandle and 
flags.
+- dma-names:  Should be a list of DMA channel name among "rx", "tx" or
+  "rx-tx".
+- clocks: Should be a list of phandles of clocks used by the controller
+  (1).
+- clock-names:Should be a list matching the clocks phandles list:
+  - "pclk" (peripheral clock) Required.
+  - "gclk" (generated clock) Optional (1).
+  - "aclk" (Audio PLL clock) Optional (1).
+
+Optional properties:
+- pinctrl-0:  Should specify pin control groups used for this controller.
+- princtrl-names: Should contain only one value - "default".
+
+
+(1) : Only the peripheral clock is required. The generated clock and the Audio
+  PLL clock are optional and should only be set together.
+
+Example:
+
+   i2s@f805 {
+   compatible = "atmel,sama5d2-i2s";
+   reg = <0xf805 0x300>;
+   interrupts = <54 IRQ_TYPE_LEVEL_HIGH 7>;
+   dmas = <&dma0
+   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(31))>,
+  <&dma0
+   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(32))>;
+   dma-names = "tx", "rx";
+   clocks = <&i2s0_clk>, <&i2s0_gclk>, <&audio_pll_pmc>;
+   clock-names = "pclk", "gclk", "aclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2s0_default>;
+   };
-- 
1.8.2.2

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

[PATCH v2 0/2] ASoC: add driver for Atmel I2S controller

[Cyrille Pitchen]

This series of patches adds support to the new Atmel I2S controller embedded
on sama5d2 SoCs.


ChangeLog

v2:
- initialize dev->dev before calling dev->caps->mck_init().

Cyrille Pitchen (2):
  ASoC: atmel-i2s: add DT bindings for I2S controller
  ASoC: atmel-i2s: add driver for the new Atmel I2S controller

 .../devicetree/bindings/sound/atmel-i2s.txt|  43 ++
 sound/soc/atmel/Kconfig|  10 +
 sound/soc/atmel/Makefile   |   2 +
 sound/soc/atmel/atmel-i2s.c| 760 +
 4 files changed, 815 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-i2s.txt
 create mode 100644 sound/soc/atmel/atmel-i2s.c

-- 
1.8.2.2

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

Re: [PATCH/RFC v2 4/4] clk: shmobile: rcar-gen2: Switch from old MSTP to new MSSR driver

[Geert Uytterhoeven]

Hi Magnus,

On Tue, Sep 29, 2015 at 3:30 PM, Magnus Damm  wrote:
> On Tue, Sep 29, 2015 at 9:48 PM, Geert Uytterhoeven
>  wrote:
>> On Tue, Sep 22, 2015 at 5:44 PM, Geert Uytterhoeven
>>  wrote:
>>> --- a/drivers/clk/shmobile/clk-rcar-gen2.c
>>> +++ b/drivers/clk/shmobile/clk-rcar-gen2.c
>>> @@ -431,7 +431,7 @@ static void __init rcar_gen2_cpg_clocks_init(struct 
>>> device_node *np)
>>>
>>> of_clk_add_provider(np, of_clk_src_onecell_get, &cpg->data);
>>>
>>> -   cpg_mstp_add_clk_domain(np);
>>> +   cpg_mssr_add_clk_domain(np);
>>
>> Of course this should become conditional on the presence of the new
>> "renesas,r8a7791-cpg-mssr" compatible value, to preserve
>> backwards-compatibility with old DTSes.
>
> Yeah, and we should probably link in both clk-mstp.o and clk-mssr.o
> for older SoCs.

Yep, been there, done that (local code updated and working ;-)

The conditional in drivers/sh/pm_runtime.c is getting a bit too gory for my
appetite. I think we should make PM (and thus PM_GENERIC_DOMAINS) mandatory.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Peter Griffin]

Hi Arnd,

On Tue, 29 Sep 2015, Arnd Bergmann wrote:

> On Tuesday 29 September 2015 13:11:55 Peter Griffin wrote:
> > Hi Arnd,
> > 
> > On Tue, 29 Sep 2015, Arnd Bergmann wrote:
> > 
> > > On Tuesday 29 September 2015 11:04:40 Peter Griffin wrote:
> > > > 
> > > > "The hardware is identical, and different firmware is used to apply
> > > >it in different ways."
> > > > 
> > > > Which is the case with fdma. By encoding the "way you wish to apply it" 
> > > > into the
> > > > compatible string, it causes problems if you want to change for example 
> > > > fdma0
> > > > to do some other function other than audio.
> > > > 
> > > > You then require a DT update, (when the hardware hasn't changed, just 
> > > > the
> > > > firmware) which is the same problem as using the filename directly in 
> > > > DT.
> > > > 
> > > > Therefore I believe it is important that the DT binding does *not* 
> > > > encode the
> > > > way the hardware is to be applied into the binding in *any* way, and 
> > > > defers this
> > > >  decision to the driver.
> > > > That is the rationale / reasoning behind choosing the fdma instance 
> > > > number.
> > > > 
> > > > Assuming you agree with my arguments above, then the choice becomes 
> > > > between 
> > > > having a fdma instance DT property, or having lots of compatibles where 
> > > > the only
> > > > difference is the appending of the instance number. I think out of the 
> > > > two I prefer
> > > > my original approach.
> > > > 
> > > > Any thoughts from the DT folks?
> > > 
> > > To me both approaches sound wrong: basing the firmware name on the 
> > > instance
> > > number requires that each instance is always used in the same way, which
> > > is not guaranteed to be the case,
> > 
> > Does it? I didn't think it did.
> > 
> > Using the instance number as a DT property defers the decision over what 
> > firmware to
> > load to the driver, which can choose whatever firmware name it wishes.
> > 
> > e.g. in v4.3 it could load xyz.elf, in v4.4 it could choose abc.elf. The DT 
> > will remain
> > unchanged, but the use of that fdma instance has changed.
> > 
> > We currently only have one firmware for each instance with the "use" 
> > compiled into it.
> > If in the future we had two firmwares with different "uses" for the same 
> > instance some extra
> > logic would be required in the driver to make a decision on which firmware 
> > to load.
> 
> Ok, I probably need some more background about what the firmware on this
> device does, and what it could do with a different firmware. Could you
> elaborate?

So the fdma hw is a dma engine based around a xp70 slim core. It supports: -
* block memory move between 2 system locations
* paced transfer from system memory to paced peripheral
* paced transfer from a paced peripheral to system memory

I believe each firmware for each instance supports those 3 things.

However the xp70 also has some ancilary HW to facilitate Start Code Detection.
It is this feature which I believe would require a different firmware if we 
wanted to make
use of it. Looking at the functional spec each xp70 also
has 16 gp output signals which we could also control from the firmware. Whether
these are actually connected to anything useful inside the SoC I don't know.

> > > and you correctly describe the problem with
> > > using the compatible string for the firmware name if the driver for the 
> > > FDMA
> > > does not actually care what firmware is being used here.
> > > 
> > > Whatever code makes the decision as to how the FDMA is used should also
> > > decide on the name of the firmware file.
> > 
> > The code which makes this decision currently is the st_fdma.c driver. 
> > However it does
> > need to know which fdma controller it is operating on to make this decision 
> > correctly.
> > 
> > Apart from passing the fdma instance number in DT, how else can we 
> > determine which
> > controller we are?
> > 
> > I guess we could infer it by having a table in the driver containing the 
> > base addresses
> > of the controllers for a given SoC, and match that against what DT passes 
> > us in the
> > reg property. But that seems ugly, and is encoding the same information in 
> > two
> > different places.
> > 
> > I'm open to suggestions if there is a better way to do this.
> 
> Using the address would be the same thing, that doesn't change the
> fundamental logic. Can you explain why it matters which instance
> a firmware is used on for this driver?

The reason we care, is that each instance has its own firmware file.

I just did a hexdump on the 3 different firmwares and compared them. Although 
the majority
of the binary is the same, there are various bytes which change at several 
different offsets
in the firmware file depending on the instance.

I don't have a xp70 toolchain or know enough about the cpu architecture to 
analyze what exactly
the firmware is doing at these locations.

regards,

Peter.


--
To unsubscribe from this list: send the line "unsubscrib

Re: [PATCH/RFC v2 4/4] clk: shmobile: rcar-gen2: Switch from old MSTP to new MSSR driver

[Magnus Damm]

Hi Geert,

On Tue, Sep 29, 2015 at 9:48 PM, Geert Uytterhoeven
 wrote:
> On Tue, Sep 22, 2015 at 5:44 PM, Geert Uytterhoeven
>  wrote:
>> --- a/drivers/clk/shmobile/clk-rcar-gen2.c
>> +++ b/drivers/clk/shmobile/clk-rcar-gen2.c
>> @@ -431,7 +431,7 @@ static void __init rcar_gen2_cpg_clocks_init(struct 
>> device_node *np)
>>
>> of_clk_add_provider(np, of_clk_src_onecell_get, &cpg->data);
>>
>> -   cpg_mstp_add_clk_domain(np);
>> +   cpg_mssr_add_clk_domain(np);
>
> Of course this should become conditional on the presence of the new
> "renesas,r8a7791-cpg-mssr" compatible value, to preserve
> backwards-compatibility with old DTSes.

Yeah, and we should probably link in both clk-mstp.o and clk-mssr.o
for older SoCs.

Cheers,

/ magnus
--
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/2] ASoC: atmel-i2s: add driver for the new Atmel I2S controller

[Cyrille Pitchen]

Le 28/09/2015 17:05, Cyrille Pitchen a écrit :
[...]
> + /* Get audio clocks to generate the I2S Master Clock (I2S_MCK) */
> + dev->aclk = devm_clk_get(&pdev->dev, "aclk");
> + dev->gclk = devm_clk_get(&pdev->dev, "gclk");
> + if (IS_ERR(dev->aclk) && IS_ERR(dev->gclk)) {
> + /* Master Mode not supported */
> + dev->aclk = NULL;
> + dev->gclk = NULL;
> + } else if (IS_ERR(dev->gclk)) {
> + err = PTR_ERR(dev->gclk);
> + dev_err(&pdev->dev,
> + "failed to get the PMC generated clock: %d\n", err);
> + return err;
> + } else if (IS_ERR(dev->aclk)) {
> + err = PTR_ERR(dev->aclk);
> + dev_err(&pdev->dev,
> + "failed to get the PLL audio clock: %d\n", err);
> + return err;
> + }
> +
> + /* Do hardware specific settings to initialize I2S_MCK generator */
> + if (dev->caps && dev->caps->mck_init) {
> + err = dev->caps->mck_init(dev, np);
> + if (err)
> + return err;
> + }
> +
> + /* Enable the peripheral clock. */
> + err = clk_prepare_enable(dev->pclk);
> + if (err)
> + return err;
> +
> + dev->dev = &pdev->dev;
> + dev->regmap = regmap;
> + platform_set_drvdata(pdev, dev);

those last 3 lines should be moved before calling dev->caps->mck_init(),
otherwise dev->dev would not be initialized yet if dev_err() is called by
atmel_i2s_sama5d2_mck_init().

Will be fixed in the next series.
[...]
--
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: [PATCHv3 1/2] iio: adc: Add TI ADS8688

[Peter Meerwald]

> This patch adds support for the Texas Intruments ADS8688 ADC.

nitpicking below

> Signed-off-by: Sean Nyekjaer 
> Reviewed-by: Martin Hundebøll 
> ---
> Changes since v2:
> - Removed unused variables
> - Removed unnecessary mutex lock
> - Range array is a enum
> - Made the read and write functions less complex and easier to read
> - Added inline comments
> - Added callback to write_raw_get_fmt
> 
> Changes since v1:
> - Now possible to read and write the actual offset and scale values
> - Removed unused includes
> - Removed unused buffer references
> 
>  drivers/iio/adc/Kconfig  |  10 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads8688.c | 463 
> +++
>  3 files changed, 474 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads8688.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index deea62c..9605aa0 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -322,6 +322,16 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS8688
> + tristate "Texas Instruments ADS8688"
> + depends on SPI && OF
> + help
> +   If you say yes here you get support for Texas Instruments ADS8684 and
> +   and ADS8688 ADC chips
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads8688.
> +
>  config TI_AM335X_ADC
>   tristate "TI's AM335X ADC driver"
>   depends on MFD_TI_AM335X_TSCADC
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index fa5723a..08a4dda 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> +obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>  obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
> diff --git a/drivers/iio/adc/ti-ads8688.c b/drivers/iio/adc/ti-ads8688.c
> new file mode 100644
> index 000..fc422c3
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads8688.c
> @@ -0,0 +1,463 @@
> +/*
> + * Copyright (C) 2015 Prevas A/S
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define ADS8688_CMD_REG(x)   (x << 8)
> +#define ADS8688_CMD_REG_NOOP 0x00
> +#define ADS8688_CMD_REG_RST  0x85
> +#define ADS8688_CMD_REG_MAN_CH(chan) (0xC0 | (4 * chan))
> +#define ADS8688_CMD_DONT_CARE_BITS   16
> +
> +#define ADS8688_PROG_REG(x)  (x << 9)
> +#define ADS8688_PROG_REG_RANGE_CH(chan)  (0x05 + chan)
> +#define ADS8688_PROG_WR_BIT  BIT(8)
> +#define ADS8688_PROG_DONT_CARE_BITS  8
> +
> +#define ADS8688_REG_PLUSMINUS25VREF  0
> +#define ADS8688_REG_PLUSMINUS125VREF 1
> +#define ADS8688_REG_PLUSMINUS0625VREF2
> +#define ADS8688_REG_PLUS25VREF   5
> +#define ADS8688_REG_PLUS125VREF  6
> +
> +#define ADS8688_VREF_MV  4096
> +#define ADS8688_REALBITS 16
> +
> +/*
> + * enum ads8688_range - ADS8688 reference voltage range
> + * @ADS8688_PLUSMINUS25VREF: Device is configured for input range ±2.5 * VREF
> + * @ADS8688_PLUSMINUS125VREF: Device is configured for input range ±1.25 * 
> VREF
> + * @ADS8688_PLUSMINUS0625VREF: Device is configured for input range ±0.625 * 
> VREF
> + * @ADS8688_PLUS25VREF: Device is configured for input range 0 - 2.5 * VREF
> + * @ADS8688_PLUS125VREF: Device is configured for input range 0 - 1.25 * VREF
> + */
> +enum ads8688_range {
> + ADS8688_PLUSMINUS25VREF,
> + ADS8688_PLUSMINUS125VREF,
> + ADS8688_PLUSMINUS0625VREF,
> + ADS8688_PLUS25VREF,
> + ADS8688_PLUS125VREF,
> +};
> +
> +struct ads8688_chip_info {
> + const struct iio_chan_spec *channels;
> + unsigned int num_channels;
> +};
> +
> +struct ads8688_state {
> + const struct ads8688_chip_info  *chip_info;
> + struct spi_device   *spi;
> + struct regulator*reg;
> + unsigned intvref_mv;
> + enum ads8688_range  range[8];
> + union {
> + __be32 d32;
> + u8 d8[4];
> + } data[2] cacheline_aligned;
> +};
> +
> +enum ads8688_id {
> + ID_ADS8684,
> + ID_ADS8688,
> +};
> +
> +struct ads8688_ranges {
> + enum ads8688_range range;
> + unsigned int scale;
> + int offset;
> + u8 reg;
> +};
> +
> +static const struct ads8688_ranges ads8688_range_def[5

How to parse delete-property annotations

[Stefan Monnier]

[ In the context of Emacs's dts-mode (http://elpa.gnu.org/packages/dts-mode). ]

I recently came across the following piece of DTS code:

   &usbphy {
/* Unset otg detect pins as we force dr_mode */
/delete-property/ usb0_id_det-gpio;
/delete-property/ usb0_vbus_det-gpio;
   };

and was wondering how dts-mode should understand this.  `dts-mode'
doesn't try to understand the actual *meaning* of such code, but it does
try to understand the syntax (i.e. how the abstract-syntax-tree would
look like).

Is "/delete-property/" is special syntax in itself, or is it a special
case of a more general syntax (like "/.../ blabla;")?  Where exactly is
it allowed to appear?
Could someone point me to some documentation explaining/describing this syntax?


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