[PATCHv2 3/4] devicetree: add rpi power domain driver bindings

[Alexander Aring]

This patch adds devicetree tree bindings for the Raspberry Pi power
domain driver.

Signed-off-by: Alexander Aring 
Acked-by: Rob Herring 
---
 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt

diff --git 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
new file mode 100644
index 000..c3abc24
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
@@ -0,0 +1,25 @@
+Raspberry Pi power domain driver
+
+Required properties:
+
+- compatible:  Should be "raspberrypi,bcm2835-power".
+- firmware:Reference to the RPi firmware device node.
+- #power-domain-cells: Should be <1>, we providing multiple power domains.
+
+The valid defines for power domain are:
+
+ RPI_POWER_DOMAIN_USB
+
+Example:
+
+power: power {
+   compatible = "raspberrypi,bcm2835-power";
+   firmware = <>;
+   #power-domain-cells = <1>;
+};
+
+Example for using power domain:
+
+ {
+   power-domains = < RPI_POWER_DOMAIN_USB>;
+};
-- 
2.6.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

[PATCHv2 1/4] power: domain: add pm_genpd_exit

[Alexander Aring]

This patch adds function pm_genpd_exit for undo a pm_genpd_init. This
is useful for multiple power domains while probing. If the probing fails
after one pm_genpd_init was called we need to undo all previous
registrations of generic pm domains inside the gpd_list list.

There is a check on IS_ERR_OR_NULL(genpd) which is useful to check again
registered power domains and not registered domains, the driver can use
this mechanism to have an array with registered and non-registered power
domains, where non-registered power domains are NULL.

Cc: Rafael J. Wysocki 
Cc: Kevin Hilman 
Cc: Ulf Hansson 
Cc: Pavel Machek 
Cc: Len Brown 
Cc: Greg Kroah-Hartman 
Signed-off-by: Alexander Aring 
---
 drivers/base/power/domain.c | 22 ++
 include/linux/pm_domain.h   |  4 
 2 files changed, 26 insertions(+)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e03b1ad..311cb0e 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1509,6 +1509,28 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
 }
 EXPORT_SYMBOL_GPL(pm_genpd_init);
 
+/**
+ * pm_genpd_exit - Uninitialize a generic I/O PM domain object.
+ * @genpd: PM domain object to uninitialize.
+ */
+void pm_genpd_exit(struct generic_pm_domain *genpd)
+{
+   if (IS_ERR_OR_NULL(genpd))
+   return;
+
+   /* check if domain is still in registered inside the pm subsystem */
+   WARN_ON_ONCE(!list_empty(>master_links) ||
+!list_empty(>slave_links) ||
+!list_empty(>dev_list));
+
+   mutex_lock(_list_lock);
+   list_del(>gpd_list_node);
+   mutex_unlock(_list_lock);
+
+   mutex_destroy(>lock);
+}
+EXPORT_SYMBOL_GPL(pm_genpd_exit);
+
 #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
 /*
  * Device Tree based PM domain providers.
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index ba4ced3..5020b36 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -123,6 +123,7 @@ extern int pm_genpd_remove_subdomain(struct 
generic_pm_domain *genpd,
 struct generic_pm_domain *target);
 extern void pm_genpd_init(struct generic_pm_domain *genpd,
  struct dev_power_governor *gov, bool is_off);
+extern void pm_genpd_exit(struct generic_pm_domain *genpd);
 
 extern struct dev_power_governor simple_qos_governor;
 extern struct dev_power_governor pm_domain_always_on_gov;
@@ -161,6 +162,9 @@ static inline void pm_genpd_init(struct generic_pm_domain 
*genpd,
 struct dev_power_governor *gov, bool is_off)
 {
 }
+static inline void pm_genpd_exit(struct generic_pm_domain *genpd)
+{
+}
 #endif
 
 static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
-- 
2.6.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

[PATCHv2 4/4] ARM: bcm2835: update rpi devicetree entries

[Alexander Aring]

This patch updates the Raspberry Pi devicetree bindings to support the
power domain driver and enable the USB power domain.

Signed-off-by: Alexander Aring 
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 +++
 arch/arm/boot/dts/bcm2835.dtsi |  2 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 3572f03..f828202 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,3 +1,4 @@
+#include 
 #include "bcm2835.dtsi"
 
 / {
@@ -20,6 +21,12 @@
compatible = "raspberrypi,bcm2835-firmware";
mboxes = <>;
};
+
+   power: power {
+   compatible = "raspberrypi,bcm2835-power";
+   firmware = <>;
+   #power-domain-cells = <1>;
+   };
};
 };
 
@@ -60,3 +67,7 @@
status = "okay";
bus-width = <4>;
 };
+
+ {
+   power-domains = < RPI_POWER_DOMAIN_USB>;
+};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index aef64de..6d62af0 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -177,7 +177,7 @@
status = "disabled";
};
 
-   usb@7e98 {
+   usb: usb@7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
interrupts = <1 9>;
-- 
2.6.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

[PATCHv2 2/4] ARM: bcm2835: add rpi power domain driver

[Alexander Aring]

This patch adds support for RPi several Power Domains and enable support
to enable the USB Power Domain when it's not enabled before.

This patch based on Eric Anholt's patch to support Power Domains. He had
an issue about -EPROBE_DEFER inside the power domain subsystem, this
issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER
if we fail to init or turn-on domain").

Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Eric Anholt 
Signed-off-by: Alexander Aring 
Signed-off-by: Eric Anholt 
---
 arch/arm/mach-bcm/Kconfig   |  10 ++
 arch/arm/mach-bcm/Makefile  |   1 +
 arch/arm/mach-bcm/raspberrypi-power.c   | 180 
 include/dt-bindings/arm/raspberrypi-power.h |  14 +++
 4 files changed, 205 insertions(+)
 create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-power.h

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 8c53c55..0f23bad 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -134,6 +134,16 @@ config ARCH_BCM2835
  This enables support for the Broadcom BCM2835 SoC. This SoC is
  used in the Raspberry Pi and Roku 2 devices.
 
+config RASPBERRYPI_POWER
+   bool "Raspberry Pi power domain driver"
+   depends on ARCH_BCM2835 || COMPILE_TEST
+   depends on RASPBERRYPI_FIRMWARE
+   select PM_GENERIC_DOMAINS if PM
+   select PM_GENERIC_DOMAINS_OF if PM
+   help
+ This enables support for the RPi power domains which can be enabled
+ or disabled via the RPi firmware.
+
 config ARCH_BCM_63XX
bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7
depends on MMU
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 892261f..fec2d6b 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -36,6 +36,7 @@ endif
 
 # BCM2835
 obj-$(CONFIG_ARCH_BCM2835) += board_bcm2835.o
+obj-$(CONFIG_RASPBERRYPI_POWER)+= raspberrypi-power.o
 
 # BCM5301X
 obj-$(CONFIG_ARCH_BCM_5301X)   += bcm_5301x.o
diff --git a/arch/arm/mach-bcm/raspberrypi-power.c 
b/arch/arm/mach-bcm/raspberrypi-power.c
new file mode 100644
index 000..3b61f18
--- /dev/null
+++ b/arch/arm/mach-bcm/raspberrypi-power.c
@@ -0,0 +1,180 @@
+/*
+ * 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.
+ *
+ * Authors:
+ * (C) 2015 Pengutronix, Alexander Aring 
+ * Eric Anholt 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RPI_POWER_DOMAIN(_domain, _name)   \
+   [_domain] = {   \
+   .domain = _domain,  \
+   .enabled = true,\
+   .base = {   \
+   .name = _name,  \
+   .power_off = rpi_domain_off,\
+   .power_on = rpi_domain_on,  \
+   },  \
+   }
+
+struct rpi_power_domain {
+   u32 domain;
+   bool enabled;
+   struct generic_pm_domain base;
+};
+
+struct rpi_power_domain_packet {
+   u32 domain;
+   u32 on;
+} __packet;
+
+static struct rpi_firmware *fw;
+static struct genpd_onecell_data rpi_genpd_xlate;
+
+/*
+ * Asks the firmware to enable or disable power on a specific power
+ * domain.
+ */
+static int rpi_firmware_set_power(u32 domain, bool on)
+{
+   struct rpi_power_domain_packet packet;
+
+   packet.domain = domain;
+   packet.on = on;
+   return rpi_firmware_property(fw, RPI_FIRMWARE_SET_POWER_STATE, ,
+sizeof(packet));
+}
+
+/* Asks the firmware to if power is on for a specific power domain. */
+static int rpi_firmware_power_is_on(u32 domain)
+{
+   struct rpi_power_domain_packet packet;
+   int ret;
+
+   packet.domain = domain;
+   ret = rpi_firmware_property(fw, RPI_FIRMWARE_GET_POWER_STATE, ,
+   sizeof(packet));
+   if (ret < 0)
+   return ret;
+
+   return packet.on & BIT(0);
+}
+
+static int rpi_domain_off(struct generic_pm_domain *domain)
+{
+   struct rpi_power_domain *rpi_domain =
+   container_of(domain, struct rpi_power_domain, base);
+
+   return rpi_firmware_set_power(rpi_domain->domain, false);
+}
+
+static int rpi_domain_on(struct generic_pm_domain *domain)
+{
+   struct rpi_power_domain *rpi_domain =
+   container_of(domain, struct rpi_power_domain, base);
+
+   return rpi_firmware_set_power(rpi_domain->domain, 

[PATCHv2 0/4] ARM: bcm2835: add support for rpi power domain driver

[Alexander Aring]

Hi,

this patch series contains at first a patch for the power domain subsystem
which offers to exit generic power domains when init was called before.

The RPi Power-Domains need to be enabled/disabled by interacting with the
RPi firmware which can fail. To cleanup the probing we need to undo the
power domains again which was registered before.

- Alex

changes since PATCHv2:
 - rename pm_genpd_uninit to pm_genpd_exit. I adapted here a review note
   from another patch. Usually kernel naming style is like "foobar_init"
   and "foobar_exit" but rarely "uninit". That's why I don't add the ack
   from Ulf Hansson here.
 - split dtsi updates into a separate patch.
 - remove testing steps from commit message.
 - change to "depends on ARCH_BCM2835 || COMPILE_TEST".
 - Add Rob Herring ack.
 - Add Eric Anholt sob.

changes since PATCH (was RFCv2 before):
 - add WARN_ON_ONCE if there are still references from generic power domain
   inside the power domain subsystem when running pm_genpd_uninit.
 - add mutex_destroy when running pm_genpd_uninit.
 - split devicetree binding for rpi power domain driver into a separate patch.
 - rename config RASPBERRY_POWER to RASPBERRYPI_POWER
 - order list of  includes alphabetical.
 - use rpi_ prefix than raspberrypi_ prefix.
 - rename _DT_BINDINGS_ARM_BCM2835_MBOX_POWER_H to 
_DT_BINDINGS_ARM_BCM2835_RPI_POWER_H

changes since RFCv2:
 - add pm_genpd_uninit to handle probing failure.
 - move power domain drive to his own driver in arch/arm/mach-bcm/
   Also add own devicetree node for this driver, "raspberrypi,bcm2835-power".
 - Removing all power domains which might exists for the firmware API but
   we currently have no use-case for it. I tried to keep the same domain
   numbering in generic power domains subsystem like they are offered from
   the firmware API. This works, all power_domains which are NULL inside
   the array of genpd_onecell_data.domains[#] will be ignored.
 - Adding Eric Anholt and me to the authors.
 - Creating devicetree documentation for the power domain driver.
 - fix error handling in raspberrypi_firmware_set_power.
 - Remove comment about mapping between power domains array, this is not
   necessary anymore. I add a "enabled" attribute to raspberrypi_power_domain
   which indicates if a domain should be registered or not (zeroed values
   does not indicate such handling, but enabled is false then).
 - remove "goto mbox" not necessary anymore because an own driver
   implementation.
 - Update devicetrees for changes in v2.

Alexander Aring (4):
  power: domain: add pm_genpd_exit
  ARM: bcm2835: add rpi power domain driver
  devicetree: add rpi power domain driver bindings
  ARM: bcm2835: update rpi devicetree entries

 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  25 +++
 arch/arm/boot/dts/bcm2835-rpi.dtsi |  11 ++
 arch/arm/boot/dts/bcm2835.dtsi |   2 +-
 arch/arm/mach-bcm/Kconfig  |  10 ++
 arch/arm/mach-bcm/Makefile |   1 +
 arch/arm/mach-bcm/raspberrypi-power.c  | 180 +
 drivers/base/power/domain.c|  22 +++
 include/dt-bindings/arm/raspberrypi-power.h|  14 ++
 include/linux/pm_domain.h  |   4 +
 9 files changed, 268 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
 create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-power.h

-- 
2.6.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] ravb: add R8A7791 support

[Geert Uytterhoeven]

Hi Sergei,

On Fri, Nov 27, 2015 at 11:06 PM, Sergei Shtylyov
 wrote:
> Add support  for yet another ARM member of the R-Car family, R-Car M2, also

R-Car M2-W?

> known as R8A7791.

There's also R-Car M2-N, aka R8A7793, but you probably know that ;-)

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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Pali Rohár]

On Sunday 29 November 2015 19:09:39 Russell King - ARM Linux wrote:
> On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > Good. And Arnd likes the idea too. So we might be converging at
> > last which is a good thing.
> 
> I disagree with the idea that there is convergence.  There might be
> convergence towards an idea, but... Here's a mail extract, from July
> 7th, from earlier in this very thread:
> 
> Pali:
> > Me:
> > > Are the ATAGs at a fixed address on the N900?
> > 
> > Yes, in board-rx51.c is:
> > 
> > .atag_offset= 0x100
> > 
> > and Nokia Bootloader (proprietary) store them to that address.
> > 
> > > Can that be handled in
> > > some kind of legacy file for the N900 which calls save_atags() on
> > > it, so we don't end up introducing yet more stuff that we have
> > > to maintain into the distant future?  If not, what about copying
> > > a known working atag structure into a legacy file for the N900?
> > 
> > I already asked question if it is possible to read ATAGs from DT
> > booted kernel. And somebody (do not remember who) wrote to ML,
> > that it is not possible and it can be done in that uncompress
> > code.
> 
> So you're converging on an idea that has already been rejected. 
> That's not a good thing, IMHO.

Or in other case show that such implementation is possible...

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v3 2/2] gpiolib: Add GPIO initialization

[Linus Walleij]

On Tue, Nov 17, 2015 at 11:21 AM, Markus Pargmann  wrote:

>> +int gpiod_initialize(struct gpio_desc *desc, unsigned long lflags,
>> +  enum gpiod_flags dflags)
>> +{
>> + int status;
>> +
>
> Sorry, this is missing a gpiod_parse_flags(). Will fix this and resend 
> tomorrow.

I haven't seen a new version, am I looking in the wrong places?

Yours,
Linus Walleij
--
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] ravb: add R8A7791 support

[Sergei Shtylyov]

Hello.

On 11/29/2015 10:26 PM, Geert Uytterhoeven wrote:


Add support  for yet another ARM member of the R-Car family, R-Car M2, also



R-Car M2-W?


   Right, forgot about the postfixes.


known as R8A7791.


There's also R-Car M2-N, aka R8A7793, but you probably know that ;-)


   Will fix.


Gr{oetje,eeting}s,

 Geert


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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Russell King - ARM Linux]

On Sun, Nov 29, 2015 at 07:19:18PM +0100, Pali Rohár wrote:
> On Sunday 29 November 2015 19:09:39 Russell King - ARM Linux wrote:
> > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > > Good. And Arnd likes the idea too. So we might be converging at
> > > last which is a good thing.
> > 
> > I disagree with the idea that there is convergence.  There might be
> > convergence towards an idea, but... Here's a mail extract, from July
> > 7th, from earlier in this very thread:
> > 
> > Pali:
> > > Me:
> > > > Are the ATAGs at a fixed address on the N900?
> > > 
> > > Yes, in board-rx51.c is:
> > > 
> > > .atag_offset= 0x100
> > > 
> > > and Nokia Bootloader (proprietary) store them to that address.
> > > 
> > > > Can that be handled in
> > > > some kind of legacy file for the N900 which calls save_atags() on
> > > > it, so we don't end up introducing yet more stuff that we have
> > > > to maintain into the distant future?  If not, what about copying
> > > > a known working atag structure into a legacy file for the N900?
> > > 
> > > I already asked question if it is possible to read ATAGs from DT
> > > booted kernel. And somebody (do not remember who) wrote to ML,
> > > that it is not possible and it can be done in that uncompress
> > > code.
> > 
> > So you're converging on an idea that has already been rejected. 
> > That's not a good thing, IMHO.
> 
> Or in other case show that such implementation is possible...

Only those with the problem can do that.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi

[Vishnu Patekar]

Hello Maxime,
Sorry for delayed response.

On Mon, Oct 26, 2015 at 4:20 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Fri, Oct 23, 2015 at 07:46:16AM +0800, Vishnu Patekar wrote:
>> + memory {
>> + reg = <0x4000 0x8000>;
>> + };
>> +
>> + timer {
>> + compatible = "arm,armv7-timer";
>> + interrupts = > IRQ_TYPE_LEVEL_LOW)>,
>> +  > IRQ_TYPE_LEVEL_LOW)>,
>> +  > IRQ_TYPE_LEVEL_LOW)>,
>> +  > IRQ_TYPE_LEVEL_LOW)>;
>
> Shouldn't the number of CPUs be 8?
Yes, It should be 8, also need to change in gic node to 8 CPUs.
No, smp support till now, still I'll change it in next patch version.
>
>> + clock-frequency = <2400>;
>> + arm,cpu-registers-not-fw-configured;
>> + };
>
> Is there some u-boot support for this SoC yet?
recently, I've posted the v2 of u-boot patch.
>
> If so, both the memory node and the clock-frequency and
> arm,cpu-registers-not-fw-configured properties are useless (and
> harmful for the latter).
Correct, As, timer support is added in u-boot, I'll remove these two.
>
>> + soc@01c0 {
>
> Please remove the address. It's both wrong and useless.
>
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + gic: interrupt-controller@01c81000 {
>> + compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
>> + reg = <0x01c81000 0x1000>,
>> +   <0x01c82000 0x1000>,
>> +   <0x01c84000 0x2000>,
>> +   <0x01c86000 0x2000>;
>> + interrupt-controller;
>> + #interrupt-cells = <3>;
>> + interrupts = > IRQ_TYPE_LEVEL_HIGH)>;
>> + };
>> +
>> + pio: pinctrl@01c20800 {
>> + compatible = "allwinner,sun8i-a83t-pinctrl";
>> + interrupts = ,
>> + ,
>> + ;
>
> Please align these lines with the first one, like you did for the
> GIC's reg for example.
Okie.
>
>> + reg = <0x01c20800 0x400>;
>> + clocks = <>;
>> + gpio-controller;
>> + interrupt-controller;
>> + #interrupt-cells = <3>;
>> + #gpio-cells = <3>;
>> +
>> + i2c0_pins_a: i2c0@0 {
>> + allwinner,pins = "PH0", "PH1";
>> + allwinner,function = "i2c0";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + i2c1_pins_a: i2c1@0 {
>> + allwinner,pins = "PH2", "PH3";
>> + allwinner,function = "i2c1";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + i2c2_pins_a: i2c2@0 {
>> + allwinner,pins = "PH4", "PH5";
>> + allwinner,function = "i2c2";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + mmc0_pins_a: mmc0@0 {
>> + allwinner,pins = "PF0", "PF1", "PF2",
>> +  "PF3", "PF4", "PF5";
>> + allwinner,function = "mmc0";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + mmc1_pins_a: mmc1@0 {
>> + allwinner,pins = "PG0", "PG1", "PG2",
>> +  "PG3", "PG4", "PG5";
>> + allwinner,function = "mmc1";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + mmc2_8bit_pins: mmc2_8bit {
>> + allwinner,pins = "PC5", "PC6", "PC8",
>> +  "PC9", "PC10", "PC11",
>> +  "PC12", "PC13", "PC14",
>> +  "PC15";
>> + allwinner,function = "mmc2";
>> + allwinner,drive = ;
>> + allwinner,pull = ;
>> + };
>> +
>> + uart0_pins_a: uart0@0 {
>> + allwinner,pins = "PF2", "PF4";
>> + allwinner,function = "uart0";
>> + allwinner,drive = ;
>> 

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Russell King - ARM Linux]

On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> Good. And Arnd likes the idea too. So we might be converging at last 
> which is a good thing.

I disagree with the idea that there is convergence.  There might be
convergence towards an idea, but... Here's a mail extract, from July
7th, from earlier in this very thread:

Pali:
> Me:
> > Are the ATAGs at a fixed address on the N900?
> 
> Yes, in board-rx51.c is:
> 
> .atag_offset= 0x100
> 
> and Nokia Bootloader (proprietary) store them to that address.
> 
> > Can that be handled in
> > some kind of legacy file for the N900 which calls save_atags() on it, so
> > we don't end up introducing yet more stuff that we have to maintain into
> > the distant future?  If not, what about copying a known working atag
> > structure into a legacy file for the N900?
> >
> 
> I already asked question if it is possible to read ATAGs from DT booted
> kernel. And somebody (do not remember who) wrote to ML, that it is not
> possible and it can be done in that uncompress code.

So you're converging on an idea that has already been rejected.  That's
not a good thing, IMHO.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] dt-bindings: iio: adc: Update mcp342x binding for the mcp3421

[Jonathan Cameron]

On 27/11/15 20:15, Rob Herring wrote:
> On Fri, Nov 27, 2015 at 02:52:52PM +0100, Sascha Hauer wrote:
>> The mcp3421 is the single channel variant of the mcp342x family and
>> can be supported by the mcp342x driver.
>>
>> Signed-off-by: Sascha Hauer 
>> Cc: devicetree@vger.kernel.org
> 
> Acked-by: Rob Herring 
Applied.

Thanks,

Jonathan
> 
>> ---
>>  Documentation/devicetree/bindings/iio/adc/mcp3422.txt | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/mcp3422.txt 
>> b/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
>> index 333139c..dcae4cc 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
>> +++ b/Documentation/devicetree/bindings/iio/adc/mcp3422.txt
>> @@ -1,7 +1,8 @@
>> -* Microchip mcp3422/3/4/6/7/8 chip family (ADC)
>> +* Microchip mcp3421/2/3/4/6/7/8 chip family (ADC)
>>  
>>  Required properties:
>>   - compatible: Should be
>> +"microchip,mcp3421" or
>>  "microchip,mcp3422" or
>>  "microchip,mcp3423" or
>>  "microchip,mcp3424" or
>> -- 
>> 2.6.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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 4/4] ARM: dt: mvebu: ix4-300d: Add ECC properties to NAND flash

[Thomas Petazzoni]

Sebastian,

Adding Ezequiel Garcia in Cc.

On Sat, 28 Nov 2015 12:14:08 +0100, Sebastian Hesselbarth wrote:
> The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection.
> Add the corresponding properties to the NAND node.

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

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

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] iio: light: us5182d: Add property for choosing default power mode

[Jonathan Cameron]

On 24/11/15 10:59, Adriana Reus wrote:
> This chip supports two power modes.
> 1. "one-shot" mode - the chip activates and executes one complete
> conversion loop and then shuts itself down. This is the default mode
> chosen for raw reads.
> 2. "continuous" mode - the chip takes continuous measurements.
> 
> Continuous mode is more expensive power-wise but may be more reliable.
> Add a property so that if preferred, the default power mode for raw
> reads can be set to continuous.
> Separate one-shot enabling in a separate function that will be used
> depending on the chosen power mode. Also create a function for
> powering the chip on and off.
> 
> Signed-off-by: Adriana Reus 
A couple of nitpicks inline...  I've fixed them up when applying to the
togreg branch of iio.git - initially pushed out as testing for the autobuilders
to play with them.

Thanks,

Jonathan
> ---
>  drivers/iio/light/us5182d.c | 90 
> +++--
>  1 file changed, 78 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 49dab3c..7993014 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -99,6 +99,11 @@ enum mode {
>   US5182D_PX_ONLY
>  };
>  
> +enum pmode {
> + US5182D_CONTINUOUS,
> + US5182D_ONESHOT
> +};
> +
>  struct us5182d_data {
>   struct i2c_client *client;
>   struct mutex lock;
> @@ -112,6 +117,9 @@ struct us5182d_data {
>   u16 *us5182d_dark_ths;
>  
>   u8 opmode;
> + u8 power_mode;
> +
> + bool default_continuous;
>  };
>  
>  static IIO_CONST_ATTR(in_illuminance_scale_available,
> @@ -130,13 +138,11 @@ static const struct {
>   u8 reg;
>   u8 val;
>  } us5182d_regvals[] = {
> - {US5182D_REG_CFG0, (US5182D_CFG0_SHUTDOWN_EN |
> - US5182D_CFG0_WORD_ENABLE)},
> + {US5182D_REG_CFG0, US5182D_CFG0_WORD_ENABLE},
>   {US5182D_REG_CFG1, US5182D_CFG1_ALS_RES16},
>   {US5182D_REG_CFG2, (US5182D_CFG2_PX_RES16 |
>   US5182D_CFG2_PXGAIN_DEFAULT)},
>   {US5182D_REG_CFG3, US5182D_CFG3_LED_CURRENT100},
> - {US5182D_REG_MODE_STORE, US5182D_STORE_MODE},
>   {US5182D_REG_CFG4, 0x00},
>  };
>  
> @@ -169,7 +175,7 @@ static int us5182d_get_als(struct us5182d_data *data)
>   return result;
>  }
>  
> -static int us5182d_set_opmode(struct us5182d_data *data, u8 mode)
> +static int us5182d_oneshot_en(struct us5182d_data *data)
>  {
>   int ret;
>  
> @@ -182,6 +188,20 @@ static int us5182d_set_opmode(struct us5182d_data *data, 
> u8 mode)
>* required measurement.
>*/
>   ret = ret | US5182D_CFG0_ONESHOT_EN;
> + return i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
Unwanted extra blank line here...
> +
> +}
> +
> +static int us5182d_set_opmode(struct us5182d_data *data, u8 mode)
> +{
> + int ret;
> +
> + if (mode == data->opmode)
> + return 0;
> +
> + ret = i2c_smbus_read_byte_data(data->client, US5182D_REG_CFG0);
> + if (ret < 0)
> + return ret;
>  
>   /* update mode */
>   ret = ret & ~US5182D_OPMODE_MASK;
> @@ -196,9 +216,6 @@ static int us5182d_set_opmode(struct us5182d_data *data, 
> u8 mode)
>   if (ret < 0)
>   return ret;
>  
> - if (mode == data->opmode)
> - return 0;
> -
>   ret = i2c_smbus_write_byte_data(data->client, US5182D_REG_MODE_STORE,
>   US5182D_STORE_MODE);
>   if (ret < 0)
> @@ -210,6 +227,23 @@ static int us5182d_set_opmode(struct us5182d_data *data, 
> u8 mode)
>   return 0;
>  }
>  
> +static int us5182d_shutdown_en (struct us5182d_data *data, u8 state)
Stray space above.. Checkpatch would have highlighted this for you, please
do run it as a sanity check before you send a series out.

> +{
> + int ret;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return 0;
> +
> + ret = i2c_smbus_read_byte_data(data->client, US5182D_REG_CFG0);
> + if (ret < 0)
> + return ret;
> +
> + ret = ret & ~US5182D_CFG0_SHUTDOWN_EN;
> + ret = ret | state;
> +
> + return i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
> +}
> +
>  static int us5182d_read_raw(struct iio_dev *indio_dev,
>   struct iio_chan_spec const *chan, int *val,
>   int *val2, long mask)
> @@ -222,6 +256,11 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   switch (chan->type) {
>   case IIO_LIGHT:
>   mutex_lock(>lock);
> + if (data->power_mode == US5182D_ONESHOT) {
> + ret = us5182d_oneshot_en(data);
> + if (ret < 0)
> + goto out_err;
> + }
>   ret = us5182d_set_opmode(data, US5182D_OPMODE_ALS);
>  

Re: [PATCH 2/5] Documentation: devicetree: Add property for controlling power saving mode for the us5182 als sensor

[Jonathan Cameron]

On 25/11/15 23:55, Rob Herring wrote:
> On Wed, Nov 25, 2015 at 11:50:30AM +0200, Adriana Reus wrote:
>>
>>
>> On 25.11.2015 02:01, Rob Herring wrote:
>>> On Tue, Nov 24, 2015 at 12:59:49PM +0200, Adriana Reus wrote:
 Add a property to allow changing the default power-saving mode.
 By default, at read raw the chip will activate and provide
 one measurent, then it will shut itself down. However, the
 chip can also work in "continuous" mode which may be more reliable
 but is also more power consuming.

 Signed-off-by: Adriana Reus 
 ---
  Documentation/devicetree/bindings/iio/light/us5182d.txt | 11 +++
  1 file changed, 11 insertions(+)

 diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt 
 b/Documentation/devicetree/bindings/iio/light/us5182d.txt
 index 6f0a530..a619799 100644
 --- a/Documentation/devicetree/bindings/iio/light/us5182d.txt
 +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt
 @@ -7,13 +7,24 @@ Required properties:
  Optional properties:
  - upisemi,glass-coef: glass attenuation factor - compensation factor of
resolution 1000 for material transmittance.
 +
  - upisemi,dark-ths: array of 8 elements containing 16-bit thresholds (adc
  counts) corresponding to every scale.
 +
  - upisemi,upper-dark-gain: 8-bit dark gain compensation factor(4 int and 4
 fractional bits - Q4.4) applied when light > 
 threshold
 +
  - upisemi,lower-dark-gain: 8-bit dark gain compensation factor(4 int and 4
 fractional bits - Q4.4) applied when light < 
 threshold

 +- upisemi,continuous: This chip has two power modes: one-shot (chip takes 
 one
 +  measurement and then shuts itself down) and 
 continuous (
 +  chip takes continuous measurements). The one-shot 
 mode is
 +  more power-friendly but the continuous mode may be 
 more
 +  reliable. If this property is specified the 
 continuous
 +  mode will be used instead of the default one-shot 
 one for
 +  raw reads.
>>>
>>> I could imagine an OS may want to decide this on its own or use a
>>> mixture of the modes.
>>>
>>> Rob
>>>
>>
>> There is no possibility of mixing them up (at the same time), so for example
>> proximity cannot work in one mode and als the other.
>>
>> The one-shot mode can only be used for raw reads (for example when
>> user-space polls in_[proximity|light]_raw). If user-space wants to enable
>> events (activate interrupts when certain thresholds are met - patch 5 of the
>> series), then the chip has to switch to continuous nonetheless because it
>> needs to be active all the time. So one work-flow scenario would be:
>>
>> Consumer1 starts polling the raw interface - default_mode
>> Consumer2 activates events - continuous mode
>> Consumer2 deactivates events - back to default_mode
>>
>> The only choice here is the default mode for raw reads, it currently is
>> one-shot, this patch allows for continuous to be used if preferred.
> 
> Okay, then:
> 
> Acked-by: Rob Herring 
Applied to the togreg branch of iio.git - initially pushed out as testing.

Thanks,

Jonathan
> 
>> --
>> 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 linux-iio" 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 5/5] iio: light: us5182d: Add interrupt support and events

[Jonathan Cameron]

On 24/11/15 10:59, Adriana Reus wrote:
> Add interrupt support and events for proximity.
> Add two threshold events to signal rising and falling directions.
> 
> Signed-off-by: Adriana Reus 
A few bits and bobs inline...
> ---
>  drivers/iio/light/us5182d.c | 272 
> +++-
>  1 file changed, 271 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 60cab4a..4d1f80d 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -20,7 +20,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -30,6 +33,8 @@
>  #define US5182D_CFG0_ONESHOT_EN  BIT(6)
>  #define US5182D_CFG0_SHUTDOWN_EN BIT(7)
>  #define US5182D_CFG0_WORD_ENABLE BIT(0)
> +#define US5182D_CFG0_PROXBIT(3)
> +#define US5182D_CFG0_PX_IRQ  BIT(2)
>  
>  #define US5182D_REG_CFG1 0x01
>  #define US5182D_CFG1_ALS_RES16   BIT(4)
> @@ -41,6 +46,7 @@
>  
>  #define US5182D_REG_CFG3 0x03
>  #define US5182D_CFG3_LED_CURRENT100  (BIT(4) | BIT(5))
> +#define US5182D_CFG3_INT_SOURCE_PX   BIT(3)
>  
>  #define US5182D_REG_CFG4 0x10
>  
> @@ -55,6 +61,13 @@
>  #define US5182D_REG_AUTO_LDARK_GAIN  0x29
>  #define US5182D_REG_AUTO_HDARK_GAIN  0x2a
>  
> +/* Thresholds for events: px low (0x08-l, 0x09-h), px high (0x0a-l 0x0b-h) */
> +#define US5182D_REG_PXL_TH   0x08
> +#define US5182D_REG_PXH_TH   0x0a
> +
> +#define US5182D_REG_PXL_TH_DEFAULT   1000
> +#define US5182D_REG_PXH_TH_DEFAULT   3
> +
>  #define US5182D_OPMODE_ALS   0x01
>  #define US5182D_OPMODE_PX0x02
>  #define US5182D_OPMODE_SHIFT 4
> @@ -84,6 +97,8 @@
>  #define US5182D_READ_WORD2
>  #define US5182D_OPSTORE_SLEEP_TIME   20 /* ms */
>  #define US5182D_SLEEP_MS 3000 /* ms */
> +#define US5182D_PXH_TH_DISABLE   0x
> +#define US5182D_PXL_TH_DISABLE   0x
>  
>  /* Available ranges: [12354, 7065, 3998, 2202, 1285, 498, 256, 138] lux */
>  static const int us5182d_scales[] = {188500, 107800, 61000, 33600, 19600, 
> 7600,
> @@ -119,6 +134,12 @@ struct us5182d_data {
>   u8 upper_dark_gain;
>   u16 *us5182d_dark_ths;
>  
> + u16 px_low_th;
> + u16 px_high_th;
> +
> + int rising_en;
> + int falling_en;
> +
>   u8 opmode;
>   u8 power_mode;
>  
> @@ -148,10 +169,26 @@ static const struct {
>   {US5182D_REG_CFG1, US5182D_CFG1_ALS_RES16},
>   {US5182D_REG_CFG2, (US5182D_CFG2_PX_RES16 |
>   US5182D_CFG2_PXGAIN_DEFAULT)},
> - {US5182D_REG_CFG3, US5182D_CFG3_LED_CURRENT100},
> + {US5182D_REG_CFG3, US5182D_CFG3_LED_CURRENT100 |
> +US5182D_CFG3_INT_SOURCE_PX},
>   {US5182D_REG_CFG4, 0x00},
>  };
>  
> +static const struct iio_event_spec us5182d_events[] = {
> + {
> + .type = IIO_EV_TYPE_THRESH,
> + .dir = IIO_EV_DIR_RISING,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_ENABLE),
> + },
> + {
> + .type = IIO_EV_TYPE_THRESH,
> + .dir = IIO_EV_DIR_FALLING,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_ENABLE),
> + },
> +};
> +
>  static const struct iio_chan_spec us5182d_channels[] = {
>   {
>   .type = IIO_LIGHT,
> @@ -161,6 +198,8 @@ static const struct iio_chan_spec us5182d_channels[] = {
>   {
>   .type = IIO_PROXIMITY,
>   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .event_spec = us5182d_events,
> + .num_event_specs = ARRAY_SIZE(us5182d_events),
>   }
>  };
>  
> @@ -477,11 +516,199 @@ static int us5182d_write_raw(struct iio_dev *indio_dev,
>   return -EINVAL;
>  }
>  
> +static int us5182d_setup_prox(struct iio_dev *indio_dev,
> +   enum iio_event_direction dir, u16 val)
> +{
> + struct us5182d_data *data = iio_priv(indio_dev);
> + int ret = 0;
> +
> + if (dir == IIO_EV_DIR_FALLING)
> + ret = i2c_smbus_write_word_data(data->client,
> + US5182D_REG_PXL_TH, val);
> +
> + if (dir == IIO_EV_DIR_RISING)
> + ret = i2c_smbus_write_word_data(data->client,
> + US5182D_REG_PXH_TH, val);
> +
> + return ret;
return directly above, no need for the local ret variable and return
0 here.
> +}
> +
> +static int 

Re: [PATCH 4/5] iio: light: us8152d: Add power management support

[Jonathan Cameron]

On 24/11/15 10:59, Adriana Reus wrote:
> Add power management for sleep as well as runtime pm.
> 
> Signed-off-by: Adriana Reus 
Mostly fine, but a comment on a possible future tidy up inline.

Applied to the togreg branch of iio.git - initially pushed out as
testing for the autobuilders to play with it.

> ---
>  drivers/iio/light/us5182d.c | 95 
> +
>  1 file changed, 88 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 3d959f3..60cab4a 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -23,6 +23,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #define US5182D_REG_CFG0 0x00
>  #define US5182D_CFG0_ONESHOT_EN  BIT(6)
> @@ -81,6 +83,7 @@
>  #define US5182D_READ_BYTE1
>  #define US5182D_READ_WORD2
>  #define US5182D_OPSTORE_SLEEP_TIME   20 /* ms */
> +#define US5182D_SLEEP_MS 3000 /* ms */
>  
>  /* Available ranges: [12354, 7065, 3998, 2202, 1285, 498, 256, 138] lux */
>  static const int us5182d_scales[] = {188500, 107800, 61000, 33600, 19600, 
> 7600,
> @@ -298,6 +301,26 @@ static int us5182d_shutdown_en (struct us5182d_data 
> *data, u8 state)
>   return ret;
>  }
>  
> +
> +static int us5182d_set_power_state(struct us5182d_data *data, bool on)
> +{
> + int ret;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return 0;
> +
> + if (on) {
> + ret = pm_runtime_get_sync(>client->dev);
> + if (ret < 0)
> + pm_runtime_put_noidle(>client->dev);
> + } else {
> + pm_runtime_mark_last_busy(>client->dev);
> + ret = pm_runtime_put_autosuspend(>client->dev);
> + }
> +
> + return ret;
> +}
> +
>  static int us5182d_read_raw(struct iio_dev *indio_dev,
>   struct iio_chan_spec const *chan, int *val,
>   int *val2, long mask)
> @@ -315,15 +338,20 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   if (ret < 0)
>   goto out_err;
>   }
> - ret = us5182d_als_enable(data);
> + ret = us5182d_set_power_state(data, true);
>   if (ret < 0)
>   goto out_err;
> -
> + ret = us5182d_als_enable(data);
> + if (ret < 0)
> + goto out_poweroff;
>   ret = us5182d_get_als(data);
>   if (ret < 0)
> + goto out_poweroff;
> + *val = ret;
> + ret = us5182d_set_power_state(data, false);
> + if (ret < 0)
>   goto out_err;
>   mutex_unlock(>lock);
> - *val = ret;
>   return IIO_VAL_INT;
>   case IIO_PROXIMITY:
I'd argue the complexity of this has reached the point where ideally you'd
break it out to a function.  The jumps out of the switch statement are 
particularly nasty from a readability point of view.

Perhaps a job for a followup patch?
>   mutex_lock(>lock);
> @@ -332,17 +360,22 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   if (ret < 0)
>   goto out_err;
>   }
> - ret = us5182d_px_enable(data);
> + ret = us5182d_set_power_state(data, true);
>   if (ret < 0)
>   goto out_err;
> -
> + ret = us5182d_px_enable(data);
> + if (ret < 0)
> + goto out_poweroff;
>   ret = i2c_smbus_read_word_data(data->client,
>  US5182D_REG_PDL);
>   if (ret < 0)
> + goto out_poweroff;
> + *val = ret;
> + ret = us5182d_set_power_state(data, false);
> + if (ret < 0)
>   goto out_err;
>   mutex_unlock(>lock);
> - *val = ret;
> - return  IIO_VAL_INT;
> + return IIO_VAL_INT;
This is a little bit of noise that should have been dealt with separately...

>   default:
>   return -EINVAL;
>   }
> @@ -361,6 +394,9 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   }
>  
>   return -EINVAL;
> +
> +out_poweroff:
> + us5182d_set_power_state(data, false);
>  out_err:
>   mutex_unlock(>lock);
>   return ret;
> @@ 

Re: Dynamically adding SPI buses (was: Re: [PATCH v8 0/8] Device Tree Overlays - 8th time's the charm)

[Geert Uytterhoeven]

Hi Mark,

On Fri, Nov 27, 2015 at 2:24 PM, Mark Brown  wrote:
> On Fri, Nov 27, 2015 at 02:06:41PM +0100, Geert Uytterhoeven wrote:
>> (replaying to an old mail, as I'm seeing the exact same behavior with current
>>  overlay code)
>
> I don't seem to have this mail...  I'm not even sure that mailing list
> archive does (at least
>
>http://thread.gmane.org/gmane.linux.kernel.spi.devel/18597
>
> anyway).

It was sent to the devicetree mailing list only, without anyone else CCed.
Probably that's why no one noticed or replied to it before...

>> When adding an SPI master device node to DT, or changing its status to 
>> "okay",
>> of_register_spi_devices() will scan for SPI slaves, and will add all of them.
>> Later, the notifier kicks:
>
>> static int of_spi_notify(struct notifier_block *nb, unsigned long action,
>>  void *arg)
>> {
>> ...
>>
>> case OF_RECONFIG_CHANGE_ADD:
>> master = of_find_spi_master_by_node(rd->dn->parent);
>> if (master == NULL)
>> return NOTIFY_OK;   /* not for us */
>>
>> spi = of_register_spi_device(master, rd->dn);
>
>> Woops, this fails, as the device has been added before!
>> Should the code just check for the existence of the SPI slave first, or would
>> that cause problems when just modifying an existing SPI slave node in DT?
>
> Looking at the I2C code it seems like it's using
> of_node_test_and_set_flag() to check for OF_POPULATED before
> instantiating, doing that manually in every place where it might
> instantiate a device and manually clearing when deinstantiating.

Thanks for looking into that!

> I have to say I don't entirely understand the logic behind how this
> stuff is supposed to work, it's confusing to me why we have separate
> dynamic and static instantiation paths in the first place or why this is
> open coded in the buses.  It seems like a more robust thing here is to
> always use the dynamic path even on static instantiation, or to move it
> more into the driver core.

Indeed.

> Ideally I'd like to see the I2C code factored out into the DT core but
> otherwise probably we have to cut'n'paste it.

I'll give that a try...

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 09/11] clk: lpc32xx: add common clock framework driver

[Vladimir Zapolskiy]

Hi Arnd,

On 20.11.2015 22:20, Arnd Bergmann wrote:
> On Friday 20 November 2015 20:07:46 Vladimir Zapolskiy wrote:
>> On 20.11.2015 16:04, Arnd Bergmann wrote:
>>> On Friday 20 November 2015 03:05:09 Vladimir Zapolskiy wrote:
 +
 +struct clk_proto_t {
 +   const char *name;
 +   const u8 parents[LPC32XX_CLK_PARENTS_MAX];
 +   u8 num_parents;
 +   unsigned long flags;
 +};
 +
 +#define CLK_PREFIX(LITERAL)LPC32XX_CLK_ ## LITERAL
 +#define NUMARGS(...)   (sizeof((int[]){__VA_ARGS__})/sizeof(int))
 +
 +#define LPC32XX_CLK_DEFINE(_idx, _name, _flags, ...)   \
 +   [CLK_PREFIX(_idx)] = {  \
 +   .name = #_name, \
 +   .flags = _flags,\
 +   .parents = { __VA_ARGS__ }, \
 +   .num_parents = NUMARGS(__VA_ARGS__),\
 +}
 +
>>>
>>> Try to not outsmart yourself with the macros. It's better to avoid
>>> string concatenation so it's possible to grep for uses of some
>>> constant.
>>>
>>> I would probably not use a macro at all here and just open-code the
>>> entire table. If you ensure that '0' is not a valid parent, then
>>> you can leave out the .num_parents field and just look for the
>>> zero-termination.
>>
>> Macros are here for simplicity, code size reduction and to avoid some
>> stupid mistakes like different number of .parents and .num_parents.
>>
>> I believe macro unwrapping in this code will add another 1000 LoC and
>> will result in quite unreadable and less maintainable code.
> 
> I mean specifically the macro above:
> 
> static const struct clk_proto_t clk_proto[LPC32XX_CLK_CCF_MAX] __initconst = {
> +   LPC32XX_CLK_DEFINE(XTAL, xtal, 0x0),
> +   LPC32XX_CLK_DEFINE(XTAL_32K, xtal_32k, 0x0),
> +
> +   LPC32XX_CLK_DEFINE(RTC, rtc, 0x0, LPC32XX_CLK_XTAL_32K),
> +   LPC32XX_CLK_DEFINE(OSC, osc, CLK_IGNORE_UNUSED, LPC32XX_CLK_XTAL),
> +   LPC32XX_CLK_DEFINE(SYS, sys, CLK_IGNORE_UNUSED,
> +   LPC32XX_CLK_OSC, LPC32XX_CLK_PLL397X),
> +   LPC32XX_CLK_DEFINE(PLL397X, pll_397x, CLK_IGNORE_UNUSED,
> +   LPC32XX_CLK_RTC),
> 
> can become
> 
> static const struct clk_proto_t clk_proto[] __initconst = {
>   [LPC32XX_CLK_XTAL]  = { "xtal" },
>   [LPC32XX_CLK_XTAL_32K]  = { "xtal_32k" },
>   [LPC32XX_CLK_RTC]   = { "rtc",
>   .parents = { LPC32XX_CLK_XTAL_32K, 0 } },

this one and all below are two lines instead of one.

Also .num_parents is not set at compilation stage, this will require
running over parents arrays for every registered clock on boot, it might
noticeably slow down the booting process on a 200MHz core.

The clocks in the beginning have not so many parents, at the opposite
extreme the situation is worse:

LPC32XX_CLK_DEFINE(TEST1, test1, 0x0,
LPC32XX_CLK_PERIPH, LPC32XX_CLK_RTC, LPC32XX_CLK_OSC),
LPC32XX_CLK_DEFINE(TEST2, test2, 0x0,
LPC32XX_CLK_HCLK, LPC32XX_CLK_PERIPH, LPC32XX_CLK_USB,
LPC32XX_CLK_OSC, LPC32XX_CLK_PLL397X),

vs.

[LPC32XX_CLK_TEST1] = { "test1",
.parents = { LPC32XX_CLK_PERIPH, LPC32XX_CLK_RTC,
 LPC32XX_CLK_OSC, 0 } },
[LPC32XX_CLK_TEST1] = { "test2",
.parents = { LPC32XX_CLK_HCLK, LPC32XX_CLK_PERIPH,
 LPC32XX_CLK_USB, LPC32XX_CLK_OSC,
 LPC32XX_CLK_PLL397X, 0 } },


>   [LPC32XX_CLK_OSC]   = { "osc", CLK_IGNORE_UNUSED,
>   .parents = { LPC32XX_CLK_XTAL, 0 } },
>   [LPC32XX_CLK_SYS]   = { "sys", CLK_IGNORE_UNUSED,
>   .parents = { LPC32XX_CLK_OSC, LPC32XX_CLK_PLL397X, 0) },
>   [LPC32XX_CLK_PLL397X]   = { "pll_397x", CLK_IGNORE_UNUSED,
>   .parents = { LPC32XX_CLK_RTC, 0 },
> 
> Not harder to read at all, not really longer, but easier to grep for.
> 

If it is not principal, I would prefer to keep the original notation,
but convert stringified values to plane strings, all in all the table is
fixed and it is not supposed to be updated anymore.

But in general I got your idea, I can implement it in v2, if you ask.

--
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 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support

[Dmitry Lifshitz]

Hi Nishanth,

Thank you for the provided feedback.

On 11/25/2015 11:36 PM, Nishanth Menon wrote:

On 11/25/2015 12:39 AM, Dmitry Lifshitz wrote:
[...]


diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
new file mode 100644
index 000..b11d7da
--- /dev/null
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts

[...]


+/ {
+   model = "CompuLab CL-SOM-AM57x";
+   compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", "ti,dra74", 
"ti,dra7";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>; /* 512 MB - minimal 
configuration */


I think if you like to enable LPAE, the format might look a little
different..



We would like to have a basic HW support in the mainline. It might be 
enhanced later, once we get to work on LPAE stuff.



+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+
+   led@0 {
+   label = "cl-som-am57x:green";
+   gpios = < 5 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   default-state = "off";
+   };
+   };
+};
+
+_pmx_core {
+   leds_pins_default: leds_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)  
/* gpmc_a15.gpio2_5 */
+   >;
+   };
+
+   i2c1_pins_default: i2c1_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0) 
/* i2c1_sda.sda */
+   DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP | MUX_MODE0) 
/* i2c1_scl.scl */
+   >;
+   };
+
+   tps659038_pins_default: tps659038_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3818, PIN_INPUT_PULLUP | 
MUX_MODE14) /* wakeup0.gpio1_0 */
+   >;
+   };


Generic comment: As per requirements of the SoC -> all pinctrl must be
done in bootloader. this was a recommendation that came in too late
for TI platforms that got introduced in upstream, but that cleanup
should eventually take place as well.



Please, could you provide a reference to those recommendations.
Do you mean pinctrl for PMIC pins only?


+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+   clock-frequency = <40>;
+
+   tps659038: tps659038@58 {
+   compatible = "ti,tps659038";
+   reg = <0x58>;
+   interrupt-parent = <>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;


Also See: https://patchwork.kernel.org/patch/7596541/ ->
Documentation/devicetree/bindings/i2c/i2c.txt -> since you seem to
have a PMIC with power button, you might be able to get wakeup source
also there.



Do you mean just adding "wakeup-source" property?

According to Documentation/devicetree/bindings/i2c/i2c.txt the primary 
interrupt will be used as wakeup interrupt.



+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+
+   #interrupt-cells = <2>;
+   interrupt-controller;
+
+   ti,system-power-controller;


Assuming powerhold signal and BOOT0,1 is proper here, else poweroff
will never work.



Please, could you provide more details regarding this issue.


+
+   tps659038_pmic {
+   compatible = "ti,tps659038-pmic";
+
+   regulators {
+   smps12_reg: smps12 {
+   /* VDD_MPU */
+   regulator-name = "smps12";
+   regulator-min-microvolt = < 85>;
+   regulator-max-microvolt = <125>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps3_reg: smps3 {
+   /* VDD_DDR */
+   regulator-name = "smps3";
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   smps45_reg: smps45 {
+   /* VDD_DSPEVE */
+   regulator-name = "smps45";
+   regulator-min-microvolt = < 85>;
+   regulator-max-microvolt = <116>;


1.25v if you want to 

[PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.

Signed-off-by: Bharat Kumar Gogada 
Signed-off-by: Ravi Kiran Gummaluri 
Acked-by: Rob Herring 
---
Changes for v11:
-> Changed data types of bridge, pcie controller and ecam base address
-> Added programming of E_BREG_BASE_HI, E_ECAM_BASE_HI registers
-> Removed MSI_ADDRESS macro, and using value from device tree
-> Removed unneccessary type casting in nwl_pcie_bridge_init function.
-> Removed mdelay and using msleep in nwl_pcie_bridge_init function.
---
 .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
 drivers/pci/host/Kconfig   |   10 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pcie-xilinx-nwl.c | 1072 
 4 files changed, 1151 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
 create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c

diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..3b2a9ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,68 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+- reg: Should contain Bridge, PCIe Controller registers location,
+   configuration sapce, and length
+- reg-names: Must include the following entries:
+   "breg": bridge registers
+   "pcireg": PCIe controller registers
+   "cfg": configuration space region
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- interrupt-names: Must include the following entries:
+   "msi1, msi0": interrupt asserted when msi is received
+   "intx": interrupt that is asserted when an legacy interrupt is received
+   "misc": interrupt asserted when miscellaneous is received
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+   mapping of the PCI interface to interrupt numbers.
+- ranges: ranges for the PCI memory regions (I/O space region is not
+   supported by hardware)
+   Please refer to the standard PCI bus binding document for a more
+   detailed explanation
+- msi-controller: indicates that this is MSI controller node
+- msi-parent:  MSI parent of the root complex itself
+- legacy-interrupt-controller: Interrupt controller device node for Legacy 
interrupts
+   - interrupt-controller: identifies the node as an interrupt controller
+   - #interrupt-cells: should be set to 1
+   - #address-cells: specifies the number of cells needed to encode an
+   address. The value must be 0.
+
+
+Example:
+
+
+nwl_pcie: pcie@fd0e {
+   #address-cells = <3>;
+   #size-cells = <2>;
+   compatible = "xlnx,nwl-pcie-2.11";
+   #interrupt-cells = <1>;
+   msi-controller;
+   device_type = "pci";
+   interrupt-parent = <>;
+   interrupts = <0 114 4>, <0 115 4>, <0 116 4>, <0 117 4>, <0 118 4>;
+   interrupt-names = "msi0", "msi1", "intx", "dummy", "misc";
+   interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+   interrupt-map = <0x0 0x0 0x0 0x1 _intc 0x1>,
+   <0x0 0x0 0x0 0x2 _intc 0x2>,
+   <0x0 0x0 0x0 0x3 _intc 0x3>,
+   <0x0 0x0 0x0 0x4 _intc 0x4>;
+
+   msi-parent = <_pcie>;
+   reg = <0x0 0xfd0e 0x1000>,
+ <0x0 0xfd48 0x1000>,
+ <0x0 0xe000 0x100>;
+   reg-names = "breg", "pcireg", "cfg";
+   ranges = <0x0200 0x 0xe100 0x 0xe100 0 
0x0f00>;
+
+   pcie_intc: legacy-interrupt-controller {
+   interrupt-controller;
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   };
+
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..24cbcba 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,16 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF
 
+config PCIE_XILINX_NWL
+   bool "NWL PCIe Core"
+   depends on ARCH_ZYNQMP
+   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
+   help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller. The controller can act as Root Port
+or End Point. The current option selection will only
+support root port enabling.
+
 config PCIE_DW
bool
 
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6a56df7 100644
--- 

Re: [PATCH v2 1/3] ARM: sunxi: Introduce Allwinner for A83T support

[Vishnu Patekar]

Hello,
Sorry for delayed response.

On Fri, Oct 23, 2015 at 9:37 AM, Chen-Yu Tsai  wrote:
> On Fri, Oct 23, 2015 at 7:46 AM, Vishnu Patekar
>  wrote:
>> Allwinner A83T is octa-core cortex-a7 based SoC.
>> It's clock control unit and prcm, pinmux are different from previous sun8i
>> series.
>> Its processor cores are arragned in two clusters 4 cores each,
>> similar to A80.
>>
>> Signed-off-by: Vishnu Patekar 
>
> Could you also update Documentation/arm/sunxi/README, so it says A83T
> is supported?
I'll update and send next version.
>
> Otherwise,
>
> Acked-by: Chen-Yu Tsai 
--
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] dt-bindings: Misc fix for the ATH79 DDR controllers

[Alban Bedel]

Fix a few typos and reword the description of the
'#qca,ddr-wb-channel-cells' property.

Signed-off-by: Alban Bedel 
CC: triv...@kernel.org
---
Changlog:
v2: * Fixed the truncated log message because of a
  line starting with a #.
---
 .../bindings/memory-controllers/ath79-ddr-controller.txt  | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/ath79-ddr-controller.txt 
b/Documentation/devicetree/bindings/memory-controllers/ath79-ddr-controller.txt
index efe35a06..c81af75 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/ath79-ddr-controller.txt
+++ 
b/Documentation/devicetree/bindings/memory-controllers/ath79-ddr-controller.txt
@@ -1,6 +1,6 @@
 Binding for Qualcomm  Atheros AR7xxx/AR9xxx DDR controller
 
-The DDR controller of the ARxxx and AR9xxx families provides an interface
+The DDR controller of the AR7xxx and AR9xxx families provides an interface
 to flush the FIFO between various devices and the DDR. This is mainly used
 by the IRQ controller to flush the FIFO before running the interrupt handler
 of such devices.
@@ -11,9 +11,9 @@ Required properties:
   "qca,[ar7100|ar7240]-ddr-controller" as fallback.
   On SoC with PCI support "qca,ar7100-ddr-controller" should be used as
   fallback, otherwise "qca,ar7240-ddr-controller" should be used.
-- reg: Base address and size of the controllers memory area
-- #qca,ddr-wb-channel-cells: has to be 1, the index of the write buffer
-  channel
+- reg: Base address and size of the controller's memory area
+- #qca,ddr-wb-channel-cells: Specifies the number of cells needed to encode
+the write buffer channel index, should be 1.
 
 Example:
 
-- 
2.0.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

[PATCH v2 1/2] dt-bindings: Misc fix for the ATH79 MISC interrupt controllers

[Alban Bedel]

Add a missing quote in the example

Signed-off-by: Alban Bedel 
CC: triv...@kernel.org
---
 .../devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
index ec96b1f..475ae9b 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
@@ -22,7 +22,7 @@ Interrupt Controllers bindings used by client devices.
 Example:
 
interrupt-controller@18060010 {
-   compatible = "qca,ar9132-misc-intc", qca,ar7100-misc-intc";
+   compatible = "qca,ar9132-misc-intc", "qca,ar7100-misc-intc";
reg = <0x18060010 0x4>;
 
interrupt-parent = <>;
-- 
2.0.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 v3 1/4] iio: adc: add IMX7D ADC driver support

[Jonathan Cameron]

On 25/11/15 03:52, Stefan Agner wrote:
> Hi Haibo,
> 
> Some comments below:
> 
> On 2015-11-20 07:48, Haibo Chen wrote:
>> Freescale i.MX7D soc contains a new ADC IP. This patch add this ADC
>> driver support, and the driver only support ADC software trigger.
>>
>> Signed-off-by: Haibo Chen 
>> ---
>>  drivers/iio/adc/Kconfig |   9 +
>>  drivers/iio/adc/Makefile|   1 +
>>  drivers/iio/adc/imx7d_adc.c | 570 
>> 
>>  3 files changed, 580 insertions(+)
>>  create mode 100644 drivers/iio/adc/imx7d_adc.c
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 7868c74..bf0611c 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -194,6 +194,15 @@ config HI8435
>>This driver can also be built as a module. If so, the module will be
>>called hi8435.
>>  
>> +config IMX7D_ADC
>> +tristate "IMX7D ADC driver"
>> +depends on OF
> 
> Hm, not sure, but shouldn't we use a proper depends here? Otherwise this
> will show up as modules in all kinds of distributions.
usual trick is a depends on the platform or COMPILE_TEST
(so that autobuilders will hit it)
> 
>> +help
>> +  Say yes here to build support for IMX7D ADC.
>> +
>> +  This driver can also be built as a module. If so, the module will be
>> +  called imx7d_adc.
>> +
>>  config LP8788_ADC
>>  tristate "LP8788 ADC driver"
>>  depends on MFD_LP8788
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index 99b37a9..282ffc01 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -20,6 +20,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>>  obj-$(CONFIG_HI8435) += hi8435.o
>> +obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>>  obj-$(CONFIG_MAX1027) += max1027.o
>>  obj-$(CONFIG_MAX1363) += max1363.o
>> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
>> new file mode 100644
>> index 000..d9547bf
>> --- /dev/null
>> +++ b/drivers/iio/adc/imx7d_adc.c
>> @@ -0,0 +1,570 @@
>> +/*
>> + * Freescale i.MX7D ADC driver
>> + *
>> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> 
> Can you sort these alphabetically
> 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* ADC register */
>> +#define IMX7D_REG_ADC_CH_A_CFG1 0x00
>> +#define IMX7D_REG_ADC_CH_A_CFG2 0x10
>> +#define IMX7D_REG_ADC_CH_B_CFG1 0x20
>> +#define IMX7D_REG_ADC_CH_B_CFG2 0x30
>> +#define IMX7D_REG_ADC_CH_C_CFG1 0x40
>> +#define IMX7D_REG_ADC_CH_C_CFG2 0x50
>> +#define IMX7D_REG_ADC_CH_D_CFG1 0x60
>> +#define IMX7D_REG_ADC_CH_D_CFG2 0x70
>> +#define IMX7D_REG_ADC_CH_SW_CFG 0x80
>> +#define IMX7D_REG_ADC_TIMER_UNIT0x90
>> +#define IMX7D_REG_ADC_DMA_FIFO  0xa0
>> +#define IMX7D_REG_ADC_FIFO_STATUS   0xb0
>> +#define IMX7D_REG_ADC_INT_SIG_EN0xc0
>> +#define IMX7D_REG_ADC_INT_EN0xd0
>> +#define IMX7D_REG_ADC_INT_STATUS0xe0
>> +#define IMX7D_REG_ADC_CHA_B_CNV_RSLT0xf0
>> +#define IMX7D_REG_ADC_CHC_D_CNV_RSLT0x100
>> +#define IMX7D_REG_ADC_CH_SW_CNV_RSLT0x110
>> +#define IMX7D_REG_ADC_DMA_FIFO_DAT  0x120
>> +#define IMX7D_REG_ADC_ADC_CFG   0x130
>> +
>> +#define IMX7D_EACH_CHANNEL_REG_SHIF 0x20
> 
> I would call that OFFSET, SHIFT is typically used for a bit offset
> within a register.
> 
>> +
>> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_EN(0x1 << 31)
>> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_DISABLE   (0x0 << 
>> 31)
> 
> I would just define the _EN definition (along with using BIT).
> Bitshifting a 0 is not really useful.
> 
>> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SINGLEBIT(30)
>> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_AVG_ENBIT(29)
>> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SEL_SHIF  24
>> +
>> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_4 (0x0 << 
>> 12)
>> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_8 (0x1 << 
>> 12)
>> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_16(0x2 << 12)
>> +#define 

Re: [PATCH 3/5] iio: light: us5182d: Add functions for selectively enabling als and proximity

[Jonathan Cameron]

On 24/11/15 10:59, Adriana Reus wrote:
> Keep track of the als and px enabled/disabled status in
> order to enable them selectively.
> 
> Signed-off-by: Adriana Reus 
Couple more nitpicks, but again fixed up during apply.
> ---
>  drivers/iio/light/us5182d.c | 64 
> ++---
>  1 file changed, 60 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
> index 7993014..3d959f3 100644
> --- a/drivers/iio/light/us5182d.c
> +++ b/drivers/iio/light/us5182d.c
> @@ -119,6 +119,9 @@ struct us5182d_data {
>   u8 opmode;
>   u8 power_mode;
>  
> + bool als_enabled;
> + bool px_enabled;
> +
>   bool default_continuous;
>  };
>  
> @@ -227,6 +230,48 @@ static int us5182d_set_opmode(struct us5182d_data *data, 
> u8 mode)
>   return 0;
>  }
>  
> +static int us5182d_als_enable(struct us5182d_data *data)
> +{
> + int ret;
> + u8 mode;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return us5182d_set_opmode(data, US5182D_ALS_ONLY);
> +
> + if (data->als_enabled)
> + return 0;
> +
> + mode = data->px_enabled ? US5182D_ALS_PX : US5182D_ALS_ONLY;
> +
> + ret = us5182d_set_opmode(data, mode);
> + if (ret < 0)
> + return ret;
> +
> + data->als_enabled = true;
Blank line here ideally.
> + return 0;
> +}
> +
> +static int us5182d_px_enable(struct us5182d_data *data)
> +{
> + int ret;
> + u8 mode;
> +
> + if (data->power_mode == US5182D_ONESHOT)
> + return us5182d_set_opmode(data, US5182D_PX_ONLY);
> +
> + if (data->px_enabled)
> + return 0;
> +
> + mode = data->als_enabled ? US5182D_ALS_PX : US5182D_PX_ONLY;
> +
> + ret = us5182d_set_opmode(data, mode);
> + if (ret < 0)
> + return ret;
> +
> + data->px_enabled = true;
And here...
> + return 0;
> +}
> +
>  static int us5182d_shutdown_en (struct us5182d_data *data, u8 state)
>  {
>   int ret;
> @@ -241,7 +286,16 @@ static int us5182d_shutdown_en (struct us5182d_data 
> *data, u8 state)
>   ret = ret & ~US5182D_CFG0_SHUTDOWN_EN;
>   ret = ret | state;
>  
> - return i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
> + ret = i2c_smbus_write_byte_data(data->client, US5182D_REG_CFG0, ret);
> + if (ret < 0)
> + return ret;
> +
> + if (state & US5182D_CFG0_SHUTDOWN_EN) {
> + data->als_enabled = false;
> + data->px_enabled = false;
> + }
> +
> + return ret;
>  }
>  
>  static int us5182d_read_raw(struct iio_dev *indio_dev,
> @@ -261,7 +315,7 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   if (ret < 0)
>   goto out_err;
>   }
> - ret = us5182d_set_opmode(data, US5182D_OPMODE_ALS);
> + ret = us5182d_als_enable(data);
>   if (ret < 0)
>   goto out_err;
>  
> @@ -278,7 +332,7 @@ static int us5182d_read_raw(struct iio_dev *indio_dev,
>   if (ret < 0)
>   goto out_err;
>   }
> - ret = us5182d_set_opmode(data, US5182D_OPMODE_PX);
> + ret = us5182d_px_enable(data);
>   if (ret < 0)
>   goto out_err;
>  
> @@ -421,6 +475,9 @@ static int us5182d_init(struct iio_dev *indio_dev)
>   return ret;
>   }
>  
> + data->als_enabled = true;
> + data->px_enabled = true;
> +
>   if (!data->default_continuous) {
>   ret = us5182d_shutdown_en(data, US5182D_CFG0_SHUTDOWN_EN);
>   if (ret < 0)
> @@ -428,7 +485,6 @@ static int us5182d_init(struct iio_dev *indio_dev)
>   data->power_mode = US5182D_ONESHOT;
>   }
>  
> -
>   return ret;
>  }
>  
> 

--
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] backlight: tps65217_bl: Add MODULE_DEVICE_TABLE.

[Enric Balletbo i Serra]

The device table is required to load modules based on modaliases.

Signed-off-by: Enric Balletbo i Serra 
---
Changes since last version:
- Use of_match_ptr (Lee Jones)

 drivers/video/backlight/tps65217_bl.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/video/backlight/tps65217_bl.c 
b/drivers/video/backlight/tps65217_bl.c
index 61d72bf..fd524ad 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -320,10 +320,19 @@ static int tps65217_bl_probe(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id tps65217_bl_of_match[] = {
+   { .compatible = "ti,tps65217-bl", },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, tps65217_bl_of_match);
+#endif
+
 static struct platform_driver tps65217_bl_driver = {
.probe  = tps65217_bl_probe,
.driver = {
.name   = "tps65217-bl",
+   .of_match_table = of_match_ptr(tps65217_bl_of_match),
},
 };
 
-- 
2.1.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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Pali Rohár]

On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > > Good. And Arnd likes the idea too. So we might be converging at
> > > last which is a good thing.
> > 
> > I disagree with the idea that there is convergence.  There might be
> > convergence towards an idea, but... Here's a mail extract, from
> > July 7th, from earlier in this very thread:
> > 
> > Pali:
> > > Me:
> > > > Are the ATAGs at a fixed address on the N900?
> > > 
> > > Yes, in board-rx51.c is:
> > > 
> > > .atag_offset= 0x100
> > > 
> > > and Nokia Bootloader (proprietary) store them to that address.
> > > 
> > > > Can that be handled in
> > > > some kind of legacy file for the N900 which calls save_atags()
> > > > on it, so we don't end up introducing yet more stuff that we
> > > > have to maintain into the distant future?  If not, what about
> > > > copying a known working atag structure into a legacy file for
> > > > the N900?
> > > 
> > > I already asked question if it is possible to read ATAGs from DT
> > > booted kernel. And somebody (do not remember who) wrote to ML,
> > > that it is not possible and it can be done in that uncompress
> > > code.
> 
> Who is that somebody? If ever it happened to be me then objection is
> withdrawn. Otherwise that somebody should come forth and speak up
> again.
> 

... do not remember ... this discussion were in more email threads and 
takes more then one year... sorry but my memory is not excellent

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

[PATCH v2 3/5] dt-bindings: rockchip-thermal: Support the RK3228/RK3399 SoCs compatible

[Caesar Wang]

This patchset attempts to new compatible for thermal founding
on RK3228/RK3399 SoCs.

Signed-off-by: Caesar Wang 
Acked-by: Rob Herring 

---

Changes in v2: None
Changes in v1:
- As Heiko comments, fix a copy incorrect name.
- Add a Acked from Rob.

 Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index 0dfa60d..08efe6b 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -2,8 +2,10 @@
 
 Required properties:
 - compatible : should be "rockchip,-tsadc"
+   "rockchip,rk3228-tsadc": found on RK3228 SoCs
"rockchip,rk3288-tsadc": found on RK3288 SoCs
"rockchip,rk3368-tsadc": found on RK3368 SoCs
+   "rockchip,rk3399-tsadc": found on RK3399 SoCs
 - reg : physical base address of the controller and length of memory mapped
region.
 - interrupts : The interrupt number to the cpu. The interrupt specifier format
-- 
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Nicolas Pitre]

On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:

> On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > Good. And Arnd likes the idea too. So we might be converging at last 
> > which is a good thing.
> 
> I disagree with the idea that there is convergence.  There might be
> convergence towards an idea, but... Here's a mail extract, from July
> 7th, from earlier in this very thread:
> 
> Pali:
> > Me:
> > > Are the ATAGs at a fixed address on the N900?
> > 
> > Yes, in board-rx51.c is:
> > 
> > .atag_offset= 0x100
> > 
> > and Nokia Bootloader (proprietary) store them to that address.
> > 
> > > Can that be handled in
> > > some kind of legacy file for the N900 which calls save_atags() on it, so
> > > we don't end up introducing yet more stuff that we have to maintain into
> > > the distant future?  If not, what about copying a known working atag
> > > structure into a legacy file for the N900?
> > >
> > 
> > I already asked question if it is possible to read ATAGs from DT booted
> > kernel. And somebody (do not remember who) wrote to ML, that it is not
> > possible and it can be done in that uncompress code.

Who is that somebody? If ever it happened to be me then objection is 
withdrawn. Otherwise that somebody should come forth and speak up again.

> So you're converging on an idea that has already been rejected.  That's
> not a good thing, IMHO.

All the alternatives are worse and being rejected as well.

In that case we should settle on the idea that satisfies the most 
people.


Nicolas
--
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 2/2] leds: rt5033: Add RT5033 Flash led device driver

[Ingi Kim]

Hi Jacek,

On 2015년 11월 26일 18:43, Jacek Anaszewski wrote:
> Hi Ingi,
> 
> On 11/26/2015 09:02 AM, Ingi Kim wrote:
> [...]
 +torch_unlock:
 +mutex_unlock(>lock);
 +return ret;
 +}
 +
 +static int rt5033_led_flash_brightness_set(struct led_classdev_flash 
 *fled_cdev,
 +   u32 brightness)
 +{
 +struct rt5033_sub_led *sub_led = flcdev_to_sub_led(fled_cdev);
 +struct rt5033_led *led = sub_led_to_led(sub_led);
 +
 +mutex_lock(>lock);
 +sub_led->flash_brightness = brightness;
 +mutex_unlock(>lock);
>>>
>>> Mutex protection is redundant in this case. You would need it if device
>>> state was also changed here.
>>
>> Okay, I'll remove it.
>>
>>>
>>> BTW why flash brightness can't be written to the device here?
>>>
>>
>> Flash brightness is only affected when FLED flashed (strobing).
>> So, I think it is better to be written in rt5033_led_flash_strobe_set 
>> function.
> 
> strobe_set op should strobe the flash ASAP, and delegating brightness
> setting there extends a delay between calling strobe_set op
> and actual flash strobe. If you set the brightness here, then you
> wouldn't have to do that in the strobe_set op, of course unless the
> the brightness is altered through the API of the other LED, in two
> separate LEDs case.
> 

The brightness may be able to change its brightness in two separate LEDs case 
as you see.
So, I think it would be better to write brightness setting in strobe_op.
In consideration of delay, of course, the brightness is set just when it would 
be changed.

 +
 +return 0;
 +}
 +
 +static int rt5033_led_flash_timeout_set(struct led_classdev_flash 
 *fled_cdev,
 +u32 timeout)
 +{
 +struct rt5033_sub_led *sub_led = flcdev_to_sub_led(fled_cdev);
 +struct rt5033_led *led = sub_led_to_led(sub_led);
 +
 +mutex_lock(>lock);
 +sub_led->flash_timeout = timeout;
 +mutex_unlock(>lock);
>>>
>>> Ditto.
>>>
> 
> Timeout should be also written here.
> 

The timeout may be able to change its flash timeout in two separate LEDs case 
as you see.
So, I think it would be better to write timeout setting in strobe_op.
In consideration of delay, of course, the timeout is set just when it would be 
changed.

> If you will add regmap_write in both ops, then mutex protection will
> have to be preserved, to assure consistency between registers state
> and sub_led->flash_brightness and sub_led->flash_timeout state.
> 

Thanks, but mutex protection is useless in this case.
so I try to remove it.

>>
 +#define RT5033_FLED_CTRL4_VTRREG_MAX0x60
>>>
>>> Rename DEF to MASK.
> 
> Hmm, here it should be: Rename MAX to MASK.
> 

Oh
Okay, 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

[PATCH v2] ARM: DTS: LS1021A: add SATA node to DTS

[Yuantian.Tang]

From: Tang Yuantian 

Added SATA node to LS1021A DTS to support SATA function.

Signed-off-by: Tang Yuantian 
---
v2:
- put reg-names right after reg property

 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 9430a99..33aae8d 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -143,6 +143,16 @@
status = "disabled";
};
 
+   sata: sata@320 {
+   compatible = "fsl,ls1021a-ahci";
+   reg = <0x0 0x320 0x0 0x1>,
+ <0x0 0x20220520 0x0 0x4>;
+   reg-names = "ahci", "sata-ecc";
+   interrupts = ;
+   clocks = <_clk 1>;
+   dma-coherent;
+   };
+
scfg: scfg@157 {
compatible = "fsl,ls1021a-scfg", "syscon";
reg = <0x0 0x157 0x0 0x1>;
-- 
2.1.0.27.g96db324

--
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 hi6220 usb node

[Zhangfei Gao]

Signed-off-by: Zhangfei Gao 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 33 +++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 0f11e2a..abb2ea0 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -209,6 +209,39 @@
clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
+
+   fixed_5v_hub: regulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed_5v_hub";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-boot-on;
+   gpio = < 7 0>;
+   regulator-always-on;
+   };
+
+   usb_phy: usbphy {
+   compatible = "hisilicon,hi6220-usb-phy";
+   #phy-cells = <0>;
+   phy-supply = <_5v_hub>;
+   hisilicon,peripheral-syscon = <_ctrl>;
+   };
+
+   usb: usb@f72c {
+   compatible = "hisilicon,hi6220-usb";
+   reg = <0x0 0xf72c 0x0 0x4>;
+   phys = <_phy>;
+   phy-names = "usb2-phy";
+   clocks = <_ctrl HI6220_USBOTG_HCLK>;
+   clock-names = "otg";
+   dr_mode = "otg";
+   g-use-dma;
+   g-rx-fifo-size = <512>;
+   g-np-tx-fifo-size = <128>;
+   g-tx-fifo-size = <128 128 128 128 128 128>;
+   interrupts = <0 77 0x4>;
+   };
+
gpio0: gpio@f8011000 {
compatible = "arm,pl061", "arm,primecell";
reg = <0x0 0xf8011000 0x0 0x1000>;
-- 
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] ravb: add R8A7791 support

[Simon Horman]

On Mon, Nov 30, 2015 at 12:14:21AM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 11/29/2015 10:26 PM, Geert Uytterhoeven wrote:
> 
> >>Add support  for yet another ARM member of the R-Car family, R-Car M2, also
> 
> >R-Car M2-W?
> 
>Right, forgot about the postfixes.
> 
> >>known as R8A7791.
> >
> >There's also R-Car M2-N, aka R8A7793, but you probably know that ;-)
> 
>Will fix.

I would prefer if we added generic gen2 and gen3 compat strings to the driver
and only documented new soc-specific compat strings.

Actually by chance I was planning to up patches to do that and add compat
strings for the missing Gen2 boards. But I won't complain if you beat me to
it.
--
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 v6 0/4] phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver

[Yoshihiro Shimoda]

This patch is based on the latest linux-phy / next branch.
(commit id = 8005c49d9aea74d382f474ce11afbbc7d7130bec)

 Changes from v5:
 - Minor modify the rcar_gen3_phy_usb2_probe() in patch 1.
 - Rebase the latest linux-phy / next branch.

 Changes from v4:
  - Modify Kconfig to "depends on OF && ARCH_SHMOBILE".
  - Modify Kconfig to "select GENERIC_PHY" instead of "depends on GENERIC_PHY".
  - Modify device tree documentation about "reg" of example.
  - Remove spinlock handling because phy-core driver calls mutex_lock().
  - Change valiable name to val instead of tmp.
  - Remove dev_set_drvdata.
  - Use dev_vdbg() instead of dev_dbg().
  - Change rcar_gen3_device_recognition()'s condition as one line.
  - Remove unnecessary value in rcar_gen3_phy_usb2_probe().
  - Modify MAINTAINERS about this driver.

 Changes from v3:
  - Shorten structure names to avoid new line if we add a long function name.
  - Add ID/VBUS pin detection for peripheral mode.

 Changes from v2:
  - Modify Kconfig to add "depends on OF" and "depends on ARCH_SHMOBILE".
  - Add more information in the dt document.
  - Change reg-names from "usb2" to "usb2_host".

 Changes from v1:
  - Revise some typos.
  - Remove using clk API to enable/disable the clocks.
(In other words, this driver expects to enable/disable the clocks by
 Runtime PM API by the phy-core driver.)
  - Remove an unnecessary header file (asm/cmpxchg.h).

Yoshihiro Shimoda (4):
  phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver
  phy: rcar-gen3-usb2: change the mode to OTG on the combined channel
  phy: rcar-gen3-usb2: add runtime ID/VBUS pin detection
  MAINTAINERS: add Renesas usb2 phy driver

 .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt |  39 +++
 MAINTAINERS|   6 +
 drivers/phy/Kconfig|   7 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-rcar-gen3-usb2.c   | 378 +
 5 files changed, 431 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
 create mode 100644 drivers/phy/phy-rcar-gen3-usb2.c

-- 
1.9.1

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

[PATCH v6 3/4] phy: rcar-gen3-usb2: add runtime ID/VBUS pin detection

[Yoshihiro Shimoda]

This patch adds support for runtime ID/VBUS pin detection if
the channel 0 of R-Car gen3 is used. So, we are able to use
the channel as both host and peripheral.

Signed-off-by: Yoshihiro Shimoda 
---
 .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt |  2 +
 drivers/phy/phy-rcar-gen3-usb2.c   | 43 +-
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index affa0f7..2390e4e 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -18,6 +18,7 @@ properties. This is because HSUSB has registers to select USB 
2.0 host or
 peripheral at that channel:
 - reg: offset and length of the partial HSUSB register block.
 - reg-names: must be "hsusb".
+- interrupts: interrupt specifier for the PHY.
 
 Example (R-Car H3):
 
@@ -25,6 +26,7 @@ Example (R-Car H3):
compatible = "renesas,usb2-phy-r8a7795";
reg = <0 0xee080200 0 0x700>, <0 0xe6590100 0 0x100>;
reg-names = "usb2_host", "hsusb";
+   interrupts = ;
clocks = <_clks R8A7795_CLK_EHCI0>,
 <_clks R8A7795_CLK_HSUSB>;
};
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index 2b5d890..ef332ef 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -12,6 +12,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -25,14 +26,18 @@
 #define USB2_SPD_RSM_TIMSET0x10c
 #define USB2_OC_TIMSET 0x110
 #define USB2_COMMCTRL  0x600
+#define USB2_OBINTSTA  0x604
+#define USB2_OBINTEN   0x608
 #define USB2_VBCTRL0x60c
 #define USB2_LINECTRL1 0x610
 #define USB2_ADPCTRL   0x630
 
 /* INT_ENABLE */
+#define USB2_INT_ENABLE_UCOM_INTEN BIT(3)
 #define USB2_INT_ENABLE_USBH_INTB_EN   BIT(2)
 #define USB2_INT_ENABLE_USBH_INTA_EN   BIT(1)
-#define USB2_INT_ENABLE_INIT   (USB2_INT_ENABLE_USBH_INTB_EN | \
+#define USB2_INT_ENABLE_INIT   (USB2_INT_ENABLE_UCOM_INTEN | \
+USB2_INT_ENABLE_USBH_INTB_EN | \
 USB2_INT_ENABLE_USBH_INTA_EN)
 
 /* USBCTR */
@@ -48,6 +53,12 @@
 /* COMMCTRL */
 #define USB2_COMMCTRL_OTG_PERI BIT(31) /* 1 = Peripheral mode */
 
+/* OBINTSTA and OBINTEN */
+#define USB2_OBINT_SESSVLDCHG  BIT(12)
+#define USB2_OBINT_IDDIGCHGBIT(11)
+#define USB2_OBINT_BITS(USB2_OBINT_SESSVLDCHG | \
+USB2_OBINT_IDDIGCHG)
+
 /* VBCTRL */
 #define USB2_VBCTRL_DRVVBUSSEL BIT(8)
 
@@ -174,6 +185,9 @@ static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch)
 
val = readl(usb2_base + USB2_VBCTRL);
writel(val | USB2_VBCTRL_DRVVBUSSEL, usb2_base + USB2_VBCTRL);
+   writel(USB2_OBINT_BITS, usb2_base + USB2_OBINTSTA);
+   val = readl(usb2_base + USB2_OBINTEN);
+   writel(val | USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
val = readl(usb2_base + USB2_ADPCTRL);
writel(val | USB2_ADPCTRL_IDPULLUP, usb2_base + USB2_ADPCTRL);
val = readl(usb2_base + USB2_LINECTRL1);
@@ -270,6 +284,23 @@ static struct phy_ops rcar_gen3_phy_usb2_ops = {
.owner  = THIS_MODULE,
 };
 
+static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void *_ch)
+{
+   struct rcar_gen3_chan *ch = _ch;
+   void __iomem *usb2_base = ch->usb2.base;
+   u32 status = readl(usb2_base + USB2_OBINTSTA);
+   irqreturn_t ret = IRQ_NONE;
+
+   if (status & USB2_OBINT_BITS) {
+   dev_vdbg(>phy->dev, "%s: %08x\n", __func__, status);
+   writel(USB2_OBINT_BITS, usb2_base + USB2_OBINTSTA);
+   rcar_gen3_device_recognition(ch);
+   ret = IRQ_HANDLED;
+   }
+
+   return ret;
+}
+
 static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
{ .compatible = "renesas,usb2-phy-r8a7795" },
{ }
@@ -302,9 +333,19 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device 
*pdev)
 
/* To avoid error message by devm_ioremap_resource() */
if (res) {
+   int irq;
+
channel->hsusb.base = devm_ioremap_resource(dev, res);
if (IS_ERR(channel->hsusb.base))
channel->hsusb.base = NULL;
+   /* call request_irq for OTG */
+   irq = platform_get_irq(pdev, 0);
+   if (irq >= 0)
+   irq = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
+  IRQF_SHARED, dev_name(dev),
+  channel);
+   if (irq < 0)
+   

[PATCH v6 4/4] MAINTAINERS: add Renesas usb2 phy driver

[Yoshihiro Shimoda]

Add Renesas usb2 phy driver to maintainer entry.

Signed-off-by: Yoshihiro Shimoda 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e9caa4b..ac1e301 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8928,6 +8928,12 @@ F:   drivers/rpmsg/
 F: Documentation/rpmsg.txt
 F: include/linux/rpmsg.h
 
+RENESAS USB2 PHY DRIVER
+M: Yoshihiro Shimoda 
+L: linux...@vger.kernel.org
+S: Maintained
+F: drivers/phy/phy-rcar-gen3-usb2.c
+
 RESET CONTROLLER FRAMEWORK
 M: Philipp Zabel 
 S: Maintained
-- 
1.9.1

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

[PATCH v6 1/4] phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver

[Yoshihiro Shimoda]

This patch adds support for R-Car generation 3 USB2 PHY driver.
This SoC has 3 EHCI/OHCI channels, and the channel 0 is shared
with the HSUSB (USB2.0 peripheral) device. And each channel has
independent registers about the PHYs.

So, the purpose of this driver is:
 1) initializes some registers of SoC specific to use the
{ehci,ohci}-platform driver.

 2) detects id pin to select host or peripheral on the channel 0.

For now, this driver only supports 1) above.

Signed-off-by: Yoshihiro Shimoda 
---
 .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt |  37 
 drivers/phy/Kconfig|   7 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-rcar-gen3-usb2.c   | 217 +
 4 files changed, 262 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
 create mode 100644 drivers/phy/phy-rcar-gen3-usb2.c

diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
new file mode 100644
index 000..affa0f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -0,0 +1,37 @@
+* Renesas R-Car generation 3 USB 2.0 PHY
+
+This file provides information on what the device node for the R-Car generation
+3 USB 2.0 PHY contains.
+
+Required properties:
+- compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an R8A7795
+ SoC.
+- reg: offset and length of the partial USB 2.0 Host register block.
+- reg-names: must be "usb2_host".
+- clocks: clock phandle and specifier pair(s).
+- #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
+
+Optional properties:
+To use a USB channel where USB 2.0 Host and HSUSB (USB 2.0 Peripheral) are
+combined, the device tree node should set HSUSB properties to reg and reg-names
+properties. This is because HSUSB has registers to select USB 2.0 host or
+peripheral at that channel:
+- reg: offset and length of the partial HSUSB register block.
+- reg-names: must be "hsusb".
+
+Example (R-Car H3):
+
+   usb-phy@ee080200 {
+   compatible = "renesas,usb2-phy-r8a7795";
+   reg = <0 0xee080200 0 0x700>, <0 0xe6590100 0 0x100>;
+   reg-names = "usb2_host", "hsusb";
+   clocks = <_clks R8A7795_CLK_EHCI0>,
+<_clks R8A7795_CLK_HSUSB>;
+   };
+
+   usb-phy@ee0a0200 {
+   compatible = "renesas,usb2-phy-r8a7795";
+   reg = <0 0xee0a0200 0 0x700>;
+   reg-names = "usb2_host";
+   clocks = <_clks R8A7795_CLK_EHCI0>;
+   };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7eb5859d..e9ab088 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -118,6 +118,13 @@ config PHY_RCAR_GEN2
help
  Support for USB PHY found on Renesas R-Car generation 2 SoCs.
 
+config PHY_RCAR_GEN3_USB2
+   tristate "Renesas R-Car generation 3 USB 2.0 PHY driver"
+   depends on OF && ARCH_SHMOBILE
+   select GENERIC_PHY
+   help
+ Support for USB 2.0 PHY found on Renesas R-Car generation 3 SoCs.
+
 config OMAP_CONTROL_PHY
tristate "OMAP CONTROL PHY Driver"
depends on ARCH_OMAP2PLUS || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..91d7a62 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_PHY_MVEBU_SATA)  += phy-mvebu-sata.o
 obj-$(CONFIG_PHY_MIPHY28LP)+= phy-miphy28lp.o
 obj-$(CONFIG_PHY_MIPHY365X)+= phy-miphy365x.o
 obj-$(CONFIG_PHY_RCAR_GEN2)+= phy-rcar-gen2.o
+obj-$(CONFIG_PHY_RCAR_GEN3_USB2)   += phy-rcar-gen3-usb2.o
 obj-$(CONFIG_OMAP_CONTROL_PHY) += phy-omap-control.o
 obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
 obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
new file mode 100644
index 000..2696152
--- /dev/null
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -0,0 +1,217 @@
+/*
+ * Renesas R-Car Gen3 for USB2.0 PHY driver
+ *
+ * Copyright (C) 2015 Renesas Electronics Corporation
+ *
+ * This is based on the phy-rcar-gen2 driver:
+ * Copyright (C) 2014 Renesas Solutions Corp.
+ * Copyright (C) 2014 Cogent Embedded, 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 
+#include 
+
+/*** USB2.0 Host registers (original offset is +0x200) ***/
+#define USB2_INT_ENABLE0x000
+#define USB2_USBCTR0x00c
+#define USB2_SPD_RSM_TIMSET0x10c
+#define USB2_OC_TIMSET 0x110
+
+/* INT_ENABLE */
+#define USB2_INT_ENABLE_USBH_INTB_EN   

[PATCH v6 2/4] phy: rcar-gen3-usb2: change the mode to OTG on the combined channel

[Yoshihiro Shimoda]

To use the channel 0 of R-Car gen3 as periperal mode, This patch changes
the mode to OTG instead of HOST. Then, this driver needs to set some
registers to enable host mode and detects ID pin and VBUS pin at
phy_init() timing.

For now, the channel 0 can be used as host mode only.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/phy/phy-rcar-gen3-usb2.c | 124 ++-
 1 file changed, 122 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index 2696152..2b5d890 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -24,6 +24,10 @@
 #define USB2_USBCTR0x00c
 #define USB2_SPD_RSM_TIMSET0x10c
 #define USB2_OC_TIMSET 0x110
+#define USB2_COMMCTRL  0x600
+#define USB2_VBCTRL0x60c
+#define USB2_LINECTRL1 0x610
+#define USB2_ADPCTRL   0x630
 
 /* INT_ENABLE */
 #define USB2_INT_ENABLE_USBH_INTB_EN   BIT(2)
@@ -41,6 +45,24 @@
 /* OC_TIMSET */
 #define USB2_OC_TIMSET_INIT0x000209ab
 
+/* COMMCTRL */
+#define USB2_COMMCTRL_OTG_PERI BIT(31) /* 1 = Peripheral mode */
+
+/* VBCTRL */
+#define USB2_VBCTRL_DRVVBUSSEL BIT(8)
+
+/* LINECTRL1 */
+#define USB2_LINECTRL1_DPRPD_ENBIT(19)
+#define USB2_LINECTRL1_DP_RPD  BIT(18)
+#define USB2_LINECTRL1_DMRPD_ENBIT(17)
+#define USB2_LINECTRL1_DM_RPD  BIT(16)
+
+/* ADPCTRL */
+#define USB2_ADPCTRL_OTGSESSVLDBIT(20)
+#define USB2_ADPCTRL_IDDIG BIT(19)
+#define USB2_ADPCTRL_IDPULLUP  BIT(5)  /* 1 = ID sampling is enabled */
+#define USB2_ADPCTRL_DRVVBUS   BIT(4)
+
 /*** HSUSB registers (original offset is +0x100) ***/
 #define HSUSB_LPSTS0x02
 #define HSUSB_UGCTRL2  0x84
@@ -66,6 +88,102 @@ struct rcar_gen3_chan {
struct phy *phy;
 };
 
+static void rcar_gen3_set_host_mode(struct rcar_gen3_chan *ch, int host)
+{
+   void __iomem *usb2_base = ch->usb2.base;
+   u32 val = readl(usb2_base + USB2_COMMCTRL);
+
+   dev_vdbg(>phy->dev, "%s: %08x, %d\n", __func__, val, host);
+   if (host)
+   val &= ~USB2_COMMCTRL_OTG_PERI;
+   else
+   val |= USB2_COMMCTRL_OTG_PERI;
+   writel(val, usb2_base + USB2_COMMCTRL);
+}
+
+static void rcar_gen3_set_linectrl(struct rcar_gen3_chan *ch, int dp, int dm)
+{
+   void __iomem *usb2_base = ch->usb2.base;
+   u32 val = readl(usb2_base + USB2_LINECTRL1);
+
+   dev_vdbg(>phy->dev, "%s: %08x, %d, %d\n", __func__, val, dp, dm);
+   val &= ~(USB2_LINECTRL1_DP_RPD | USB2_LINECTRL1_DM_RPD);
+   if (dp)
+   val |= USB2_LINECTRL1_DP_RPD;
+   if (dm)
+   val |= USB2_LINECTRL1_DM_RPD;
+   writel(val, usb2_base + USB2_LINECTRL1);
+}
+
+static void rcar_gen3_enable_vbus_ctrl(struct rcar_gen3_chan *ch, int vbus)
+{
+   void __iomem *usb2_base = ch->usb2.base;
+   u32 val = readl(usb2_base + USB2_ADPCTRL);
+
+   dev_vdbg(>phy->dev, "%s: %08x, %d\n", __func__, val, vbus);
+   if (vbus)
+   val |= USB2_ADPCTRL_DRVVBUS;
+   else
+   val &= ~USB2_ADPCTRL_DRVVBUS;
+   writel(val, usb2_base + USB2_ADPCTRL);
+}
+
+static void rcar_gen3_init_for_host(struct rcar_gen3_chan *ch)
+{
+   rcar_gen3_set_linectrl(ch, 1, 1);
+   rcar_gen3_set_host_mode(ch, 1);
+   rcar_gen3_enable_vbus_ctrl(ch, 1);
+}
+
+static void rcar_gen3_init_for_peri(struct rcar_gen3_chan *ch)
+{
+   rcar_gen3_set_linectrl(ch, 0, 1);
+   rcar_gen3_set_host_mode(ch, 0);
+   rcar_gen3_enable_vbus_ctrl(ch, 0);
+}
+
+static bool rcar_gen3_check_vbus(struct rcar_gen3_chan *ch)
+{
+   return !!(readl(ch->usb2.base + USB2_ADPCTRL) &
+ USB2_ADPCTRL_OTGSESSVLD);
+}
+
+static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
+{
+   return !!(readl(ch->usb2.base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
+}
+
+static void rcar_gen3_device_recognition(struct rcar_gen3_chan *ch)
+{
+   bool is_host = true;
+
+   /* B-device? */
+   if (rcar_gen3_check_id(ch) && rcar_gen3_check_vbus(ch))
+   is_host = false;
+
+   if (is_host)
+   rcar_gen3_init_for_host(ch);
+   else
+   rcar_gen3_init_for_peri(ch);
+}
+
+static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch)
+{
+   void __iomem *usb2_base = ch->usb2.base;
+   u32 val;
+
+   val = readl(usb2_base + USB2_VBCTRL);
+   writel(val | USB2_VBCTRL_DRVVBUSSEL, usb2_base + USB2_VBCTRL);
+   val = readl(usb2_base + USB2_ADPCTRL);
+   writel(val | USB2_ADPCTRL_IDPULLUP, usb2_base + USB2_ADPCTRL);
+   val = readl(usb2_base + USB2_LINECTRL1);
+   rcar_gen3_set_linectrl(ch, 0, 0);
+   writel(val | USB2_LINECTRL1_DPRPD_EN | USB2_LINECTRL1_DMRPD_EN,
+  usb2_base + USB2_LINECTRL1);
+
+   

Re: [PATCH v6 2/2] leds: rt5033: Add RT5033 Flash led device driver

[Ingi Kim]

Hi, Lee

Thanks to the review,
I'll carry your Ack when I reflect Jacek's comment.

On 2015년 11월 26일 18:11, Lee Jones wrote:
> On Wed, 25 Nov 2015, Ingi Kim wrote:
> 
>> This patch adds device driver of Richtek RT5033 PMIC.
>> The RT5033 Flash LED Circuit is designed for one or two LEDs driving
>> for torch and strobe applications, it provides an I2C software command
>> to trigger the torch and strobe operation.
>>
>> Each of LED outputs can contorl a separate LED sharing their setting,
>> and can be connected together for a single connected LED.
>> One LED is represented by one child node.
>>
>> Signed-off-by: Ingi Kim 
>> ---
>>  drivers/leds/Kconfig   |   8 +
>>  drivers/leds/Makefile  |   1 +
>>  drivers/leds/leds-rt5033.c | 541 
>> +
>>  include/linux/mfd/rt5033-private.h |  51 
> 
> Acked-by: Lee Jones 
> 
>>  4 files changed, 601 insertions(+)
>>  create mode 100644 drivers/leds/leds-rt5033.c
>>
>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>> index b1ab8bd..f41ac9b 100644
>> --- a/drivers/leds/Kconfig
>> +++ b/drivers/leds/Kconfig
>> @@ -345,6 +345,14 @@ config LEDS_PCA963X
>>LED driver chip accessed via the I2C bus. Supported
>>devices include PCA9633 and PCA9634
>>  
>> +config LEDS_RT5033
>> +tristate "LED support for RT5033 PMIC"
>> +depends on LEDS_CLASS_FLASH && OF
>> +depends on MFD_RT5033
>> +help
>> +  This option enables support for on-chip LED driver on
>> +  RT5033 PMIC.
>> +
>>  config LEDS_WM831X_STATUS
>>  tristate "LED support for status LEDs on WM831x PMICs"
>>  depends on LEDS_CLASS
>> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
>> index e9d53092..77cfad5 100644
>> --- a/drivers/leds/Makefile
>> +++ b/drivers/leds/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE) += 
>> leds-cobalt-qube.o
>>  obj-$(CONFIG_LEDS_COBALT_RAQ)   += leds-cobalt-raq.o
>>  obj-$(CONFIG_LEDS_SUNFIRE)  += leds-sunfire.o
>>  obj-$(CONFIG_LEDS_PCA9532)  += leds-pca9532.o
>> +obj-$(CONFIG_LEDS_RT5033)   += leds-rt5033.o
>>  obj-$(CONFIG_LEDS_GPIO_REGISTER)+= leds-gpio-register.o
>>  obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o
>>  obj-$(CONFIG_LEDS_LP3944)   += leds-lp3944.o
>> diff --git a/drivers/leds/leds-rt5033.c b/drivers/leds/leds-rt5033.c
>> new file mode 100644
>> index 000..256df74
>> --- /dev/null
>> +++ b/drivers/leds/leds-rt5033.c
>> @@ -0,0 +1,541 @@
>> +/*
>> + * led driver for RT5033
>> + *
>> + * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
>> + * Ingi Kim 
>> + *
>> + * 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 
>> +
>> +#define RT5033_LED_FLASH_TIMEOUT_MIN64000
>> +#define RT5033_LED_FLASH_TIMEOUT_STEP   32000
>> +#define RT5033_LED_FLASH_BRIGHTNESS_MIN 5
>> +#define RT5033_LED_FLASH_BRIGHTNESS_MAX_1CH 60
>> +#define RT5033_LED_FLASH_BRIGHTNESS_MAX_2CH 80
>> +#define RT5033_LED_FLASH_BRIGHTNESS_STEP25000
>> +#define RT5033_LED_TORCH_BRIGHTNESS_MIN 12500
>> +#define RT5033_LED_TORCH_BRIGHTNESS_STEP12500
>> +
>> +#define FLED1_IOUT  (BIT(0))
>> +#define FLED2_IOUT  (BIT(1))
>> +
>> +enum rt5033_fled {
>> +FLED1,
>> +FLED2,
>> +};
>> +
>> +struct rt5033_sub_led {
>> +enum rt5033_fled fled_id;
>> +struct led_classdev_flash fled_cdev;
>> +
>> +u32 flash_brightness;
>> +u32 flash_timeout;
>> +};
>> +
>> +/* RT5033 Flash led platform data */
>> +struct rt5033_led {
>> +struct device *dev;
>> +struct mutex lock;
>> +struct regmap *regmap;
>> +struct rt5033_sub_led sub_leds[2];
>> +
>> +u32 current_flash_timeout;
>> +u32 current_flash_brightness;
>> +
>> +bool iout_joint;
>> +u8 fled_mask;
>> +u8 current_iout;
>> +};
>> +
>> +struct rt5033_led_config_data {
>> +const char *label[2];
>> +u32 flash_max_microamp[2];
>> +u32 flash_max_timeout[2];
>> +u32 torch_max_microamp[2];
>> +u32 num_leds;
>> +};
>> +
>> +static u8 rt5033_torch_brightness_to_reg(u32 ua)
>> +{
>> +return (ua - RT5033_LED_TORCH_BRIGHTNESS_MIN) /
>> +RT5033_LED_TORCH_BRIGHTNESS_STEP;
>> +}
>> +
>> +static u8 rt5033_flash_brightness_to_reg(u32 ua)
>> +{
>> +return (ua - RT5033_LED_FLASH_BRIGHTNESS_MIN) /
>> +RT5033_LED_FLASH_BRIGHTNESS_STEP;
>> +}
>> +
>> +static u8 rt5033_flash_timeout_to_reg(u32 us)
>> +{
>> +return (us - RT5033_LED_FLASH_TIMEOUT_MIN) /
>> +RT5033_LED_FLASH_TIMEOUT_STEP;
>> +}
>> +
>> +static struct rt5033_sub_led *flcdev_to_sub_led(
>> +

[PATCH] of/address: fix typo in comment block of of_translate_one()

[Masahiro Yamada]

Remove the "not" before "cannot".

I am fixing the comment block style while I am here.

Signed-off-by: Masahiro Yamada 
---

 drivers/of/address.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5289c80..91a469d 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -485,9 +485,10 @@ static int of_translate_one(struct device_node *parent, 
struct of_bus *bus,
int rone;
u64 offset = OF_BAD_ADDR;
 
-   /* Normally, an absence of a "ranges" property means we are
+   /*
+* Normally, an absence of a "ranges" property means we are
 * crossing a non-translatable boundary, and thus the addresses
-* below the current not cannot be converted to CPU physical ones.
+* below the current cannot be converted to CPU physical ones.
 * Unfortunately, while this is very clear in the spec, it's not
 * what Apple understood, and they do have things like /uni-n or
 * /ht nodes with no "ranges" property and a lot of perfectly
-- 
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: Re: [RFC PATCH 02/15] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[MyungJoo Ham]

> Hi Rob,
> 
> On Sat, Nov 28, 2015 at 5:30 AM, Rob Herring  wrote:
> > On Thu, Nov 26, 2015 at 10:47:26PM +0900, Chanwoo Choi wrote:
> >> This patch adds the documentation for generic exynos bus frequency
> >> driver.
> >>
> >> Signed-off-by: Chanwoo Choi 
> >> ---
> >>  .../devicetree/bindings/devfreq/exynos-bus.txt | 92 
> >> ++
> >>  1 file changed, 92 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> >> +Example2 :
> >> + The bus of DMC block in exynos3250.dtsi are listed below:
> >
> > What is DMC?
> 
> DMC (DRAM Memory Controller)

It's Dynamic Memory Controller. (DRAM =~ Dynamic Memory)

You may need to write the full name with the first reference of DMC there
in the documentation as "DMC" may confuse a lot of people.



Cheers,
MyungJoo

Re: [PATCH v2 03/10] drm/hisilicon: Add hisilicon DRM master driver

[Daniel Vetter]

On Sat, Nov 28, 2015 at 03:25:35PM +, Emil Velikov wrote:
> Hi Xinliang,
> 
> On 28 November 2015 at 10:38, Xinliang Liu  wrote:
> > Add DRM master driver for hi6220 SoC which used in HiKey board.
> > Add dumb buffer feature.
> > Add prime dmabuf feature.
> >
> > Signed-off-by: Xinliang Liu 
> > Signed-off-by: Xinwei Kong 
> > Signed-off-by: Andy Green 
> Your s-o-b should be the bottom of the list. There was a presentation
> (ages ago) from Greg KH, who nicely described the order as a "chain of
> command" or "guilt path". Looks like the rest of the series could use
> this tweak.
> 
> > ---
> >  drivers/gpu/drm/Kconfig  |   2 +
> >  drivers/gpu/drm/Makefile |   1 +
> >  drivers/gpu/drm/hisilicon/Kconfig|   9 ++
> >  drivers/gpu/drm/hisilicon/Makefile   |   3 +
> >  drivers/gpu/drm/hisilicon/hisi_drm_drv.c | 214 
> > +++
> >  5 files changed, 229 insertions(+)
> >  create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
> >  create mode 100644 drivers/gpu/drm/hisilicon/Makefile
> >  create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_drv.c
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 8773fad..038aae8 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -274,3 +274,5 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig"
> >  source "drivers/gpu/drm/imx/Kconfig"
> >
> >  source "drivers/gpu/drm/vc4/Kconfig"
> > +
> > +source "drivers/gpu/drm/hisilicon/Kconfig"
> I could swear that we can a patch that sorts these alphabetically,
> although it doesn't seem to have made it upstream yet :-(
> 
> > --- /dev/null
> > +++ b/drivers/gpu/drm/hisilicon/hisi_drm_drv.c
> 
> > +static int hisi_drm_load(struct drm_device *dev, unsigned long flags)
> > +{
> The use of .load (and .unload?) callbacks is not recommended. Take a
> look at Laurent Pinchart's patch [1] about the whys and hows on the
> topic
> 
> > +static struct dma_buf *hisi_gem_prime_export(struct drm_device *dev,
> > +struct drm_gem_object *obj,
> > +int flags)
> > +{
> > +   /* we want to be able to write in mmapped buffer */
> > +   flags |= O_RDWR;
> Erm... something feels fishy here. Out of the existing 15 drivers
> setting up the prime callbacks only one (sti) does a similar thing. So
> either everyone else is missing something obvious or hisilicon and sti
> can rework their inner working to remove this (dare I say it) hack.

Mmap on drm dma-bufs doesn't work, and fairly intentionally. There's been
some rfc patch series to address this:

http://lists.freedesktop.org/archives/dri-devel/2015-August/089263.html

Unfortunately it seems stuck with getting the userspace piece in shape.
Might be best to ping Tiago for an update.

Meanwhile please don't do this in drivers ;-)

> > +static int hisi_gem_cma_dumb_create(struct drm_file *file,
> > +   struct drm_device *dev,
> > +   struct drm_mode_create_dumb *args)
> > +{
> > +   int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> > +
> > +   /* mali gpu need pitch 8 bytes alignment for 32bpp */
> > +   args->pitch = roundup(min_pitch, 8);
> > +
> I'm not sure you want this kind of dependency of an out of tree driver
> upstream. If this is some limitation on the display engine so be it,
> but tailoring things for an external module seems like a very bad
> idea.

Yup, nacked. dumb_create is for dumb buffers, not rendering. Mali needs to
go upstream to fix this ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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, am335x: add support for the bosch shc board

[Heiko Schocher]

Hello all,

Am 18.11.2015 um 09:24 schrieb Heiko Schocher:

Hello Dave,

Am 17.11.2015 um 22:29 schrieb Dave Gerlach:

Hi,
On 11/17/2015 02:24 AM, Heiko Schocher wrote:

add support for the am335x based shc board.

UART: 0-2 and 4
DRAM: 512 MiB
MMC:  OMAP SD/MMC: 0 @ 26 MHz
   OMAP SD/MMC: 1 @ 26 MHz
I2C:  at24 eeprom, pcf8563
USB:  USB1 (host)

Signed-off-by: Heiko Schocher 
---
The following patches are needed to get all working
for the shc board:
- disable clkout on pcf8563
   accepted.
   http://www.spinics.net/lists/devicetree/msg98542.html

- leds: leds-gpio: add shutdown function
   accepted.
   https://lkml.org/lkml/2015/10/13/169

- net: phy: smsc: disable energy detect mode
   accepted
   [PATCH v2 2/2] net: phy: smsc: disable energy detect mode
   https://lkml.org/lkml/2015/10/17/2
   [PATCH v2 1/2] drivers: net: cpsw: add phy-handle parsing
   https://lkml.org/lkml/2015/10/17/4

- ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328204.html
   @Dave: What is the current state of this patch?
   I have the same problem here on this am335x based board



A different approach is being taken for resolving the issue of rtc hwmod on 
am43x epos evm [1],
which is what I was attempting to solve with the patch you have linked. We 
decided to avoid changing
omap_hwmod code and I haven't been pursuing the ti,no-init flag anymore.


Maybe I overlook something, but I cannot see, how [1] solves the RTC
hwmod problem on am335x SoC based boards. Not all boards have this problem,
so the RTC hwmod cannot be disabled for all am335x boards ...

It must be somehow configurable for boards ... I have am335x boards
which use the rtc from the SoC


gentle ping ...

No more comments on this patch? Is it Ok for mainline or are
there more issues?

bye,
Heiko



Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg121987.html


bye,
Heiko


--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/5] spi: introduce accelerated read support for spi flash devices

[Vignesh R]

In addition to providing direct access to SPI bus, some spi controller
hardwares (like ti-qspi) provide special port (like memory mapped port)
that are optimized to improve SPI flash read performance.
This means the controller can automatically send the SPI signals
required to read data from the SPI flash device.
For this, SPI controller needs to know flash specific information like
read command to use, dummy bytes and address width.

Introduce spi_flash_read() interface to support accelerated read
over SPI flash devices. SPI master drivers can implement this callback to
support interfaces such as memory mapped read etc. m25p80 flash driver
and other flash drivers can call this make use of such interfaces. The
interface should only be used with SPI flashes and cannot be used with
other SPI devices.

Signed-off-by: Vignesh R 
---
 drivers/spi/spi.c   | 45 +
 include/linux/spi/spi.h | 41 +
 2 files changed, 86 insertions(+)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index e2415be209d5..cc2b54139352 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1134,6 +1134,7 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
}
}
 
+   mutex_lock(>bus_lock_mutex);
trace_spi_message_start(master->cur_msg);
 
if (master->prepare_message) {
@@ -1143,6 +1144,7 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
"failed to prepare message: %d\n", ret);
master->cur_msg->status = ret;
spi_finalize_current_message(master);
+   mutex_unlock(>bus_lock_mutex);
return;
}
master->cur_msg_prepared = true;
@@ -1152,6 +1154,7 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
if (ret) {
master->cur_msg->status = ret;
spi_finalize_current_message(master);
+   mutex_unlock(>bus_lock_mutex);
return;
}
 
@@ -1159,8 +1162,10 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
if (ret) {
dev_err(>dev,
"failed to transfer one message from queue\n");
+   mutex_unlock(>bus_lock_mutex);
return;
}
+   mutex_unlock(>bus_lock_mutex);
 }
 
 /**
@@ -2327,6 +2332,46 @@ int spi_async_locked(struct spi_device *spi, struct 
spi_message *message)
 EXPORT_SYMBOL_GPL(spi_async_locked);
 
 
+int spi_flash_read(struct spi_device *spi,
+  struct spi_flash_read_message *msg)
+
+{
+   struct spi_master *master = spi->master;
+   int ret;
+
+   if ((msg->opcode_nbits == SPI_NBITS_DUAL ||
+msg->addr_nbits == SPI_NBITS_DUAL) &&
+   !(spi->mode & (SPI_TX_DUAL | SPI_TX_QUAD)))
+   return -EINVAL;
+   if ((msg->opcode_nbits == SPI_NBITS_QUAD ||
+msg->addr_nbits == SPI_NBITS_QUAD) &&
+   !(spi->mode & SPI_TX_QUAD))
+   return -EINVAL;
+   if (msg->data_nbits == SPI_NBITS_DUAL &&
+   !(spi->mode & (SPI_RX_DUAL | SPI_RX_QUAD)))
+   return -EINVAL;
+   if (msg->data_nbits == SPI_NBITS_QUAD &&
+   !(spi->mode &  SPI_RX_QUAD))
+   return -EINVAL;
+
+   if (master->auto_runtime_pm) {
+   ret = pm_runtime_get_sync(master->dev.parent);
+   if (ret < 0) {
+   dev_err(>dev, "Failed to power device: %d\n",
+   ret);
+   return ret;
+   }
+   }
+   mutex_lock(>bus_lock_mutex);
+   ret = master->spi_flash_read(spi, msg);
+   mutex_unlock(>bus_lock_mutex);
+   if (master->auto_runtime_pm)
+   pm_runtime_put(master->dev.parent);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(spi_flash_read);
+
 /*-*/
 
 /* Utility methods for SPI master protocol drivers, layered on
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index cce80e6dc7d1..246d7d519f3f 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -25,6 +25,7 @@
 struct dma_chan;
 struct spi_master;
 struct spi_transfer;
+struct spi_flash_read_message;
 
 /*
  * INTERFACES between SPI master-side drivers and SPI infrastructure.
@@ -361,6 +362,8 @@ static inline void spi_unregister_driver(struct spi_driver 
*sdrv)
  * @handle_err: the subsystem calls the driver to handle an error that occurs
  * in the generic implementation of transfer_one_message().
  * @unprepare_message: undo any work done by prepare_message().
+ * @spi_flash_read: to support spi-controller hardwares that provide
+ *  accelerated interface to read from flash devices.
  * 

[PATCH v4 3/5] mtd: devices: m25p80: add support for mmap read request

[Vignesh R]

Certain spi controllers may provide accelerated interface to read from
m25p80 type flash devices. This interface provides better read
performance than regular SPI interface.
Call spi_flash_read(), if supported, to make use of such interface.

Signed-off-by: Vignesh R 
---

v4: 
 * Use spi_flash_read_message struct to pass args.
 * support passing of opcode/addr/data nbits.

 drivers/mtd/devices/m25p80.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index fe9ceb7b5405..00094a668c62 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -131,6 +131,26 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, 
size_t len,
/* convert the dummy cycles to the number of bytes */
dummy /= 8;
 
+   if (spi_flash_read_supported(spi)) {
+   struct spi_flash_read_message msg;
+   int ret;
+
+   msg.buf = buf;
+   msg.from = from;
+   msg.len = len;
+   msg.read_opcode = nor->read_opcode;
+   msg.addr_width = nor->addr_width;
+   msg.dummy_bytes = dummy;
+   /* TODO: Support other combinations */
+   msg.opcode_nbits = SPI_NBITS_SINGLE;
+   msg.addr_nbits = SPI_NBITS_SINGLE;
+   msg.data_nbits = m25p80_rx_nbits(nor);
+
+   ret = spi_flash_read(spi, );
+   *retlen = msg.retlen;
+   return ret;
+   }
+
spi_message_init();
memset(t, 0, (sizeof t));
 
-- 
2.6.3

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

[PATCH v4 0/5] Add memory mapped read support for ti-qspi

[Vignesh R]

Changes since v3:
Rework to introduce spi_flash_read_message struct.
Support different opcode/addr/data formats as per Brian's suggestion
here: https://lkml.org/lkml/2015/11/11/454

Changes since v2:
Remove mmap_lock_mutex.
Optimize enable/disable of mmap mode.

Changes since v1:
Introduce API in SPI core that MTD flash driver can call for mmap read
instead of directly calling spi-master driver callback. This API makes
sure that SPI core msg queue is locked during mmap transfers.
v1: https://lkml.org/lkml/2015/9/4/103


Cover letter:

This patch series adds support for memory mapped read port of ti-qspi.
ti-qspi has a special memory mapped port through which SPI flash
memories can be accessed directly via SoC specific memory region.

First patch adds a method to pass flash specific information like read
opcode, dummy bytes etc and to request mmap read. Second patch
implements mmap read method in ti-qspi driver. Patch 3 adapts m25p80 to
use mmap read method before trying normal SPI transfer. Patch 4 and 5
add memory map region DT entries for DRA7xx and AM43xx SoCs.

This patch series is based on the discussions here:
http://www.spinics.net/lists/linux-spi/msg04796.html

Tested on DRA74 EVM and AM437x-SK.
Read performance increases from ~100kB/s to ~2.5MB/s.


Vignesh R (5):
  spi: introduce accelerated read support for spi flash devices
  spi: spi-ti-qspi: add mmap mode read support
  mtd: devices: m25p80: add support for mmap read request
  ARM: dts: DRA7: add entry for qspi mmap region
  ARM: dts: AM4372: add entry for qspi mmap region

 Documentation/devicetree/bindings/spi/ti_qspi.txt |  19 +++-
 arch/arm/boot/dts/am4372.dtsi |   4 +-
 arch/arm/boot/dts/dra7.dtsi   |   7 +-
 drivers/mtd/devices/m25p80.c  |  20 +
 drivers/spi/spi-ti-qspi.c | 101 --
 drivers/spi/spi.c |  45 ++
 include/linux/spi/spi.h   |  41 +
 7 files changed, 225 insertions(+), 12 deletions(-)

-- 
2.6.3

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

Re: [PATCH v4 3/3] thermal: mediatek: Add cpu dynamic power cooling model.

[Viresh Kumar]

On 27-11-15, 17:32, Dawei Chien wrote:
> MT8173 cpufreq driver use of_cpufreq_power_cooling_register registering
> cooling devices with dynamic power coefficient.
> 
> Signed-off-by: Dawei Chien 
> ---
> This patch is base on patchset:
> https://lkml.org/lkml/2015/11/17/251
> ---
>  drivers/cpufreq/mt8173-cpufreq.c |   28 
>  1 file changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/cpufreq/mt8173-cpufreq.c 
> b/drivers/cpufreq/mt8173-cpufreq.c
> index 83001dc..4d39468 100644
> --- a/drivers/cpufreq/mt8173-cpufreq.c
> +++ b/drivers/cpufreq/mt8173-cpufreq.c
> @@ -263,24 +263,34 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy 
> *policy,
>   return 0;
>  }
>  
> +#define DYNAMIC_POWER "dynamic-power-coefficient"
> +
>  static void mtk_cpufreq_ready(struct cpufreq_policy *policy)
>  {
>   struct mtk_cpu_dvfs_info *info = policy->driver_data;
>   struct device_node *np = of_node_get(info->cpu_dev->of_node);
> + u32 capacitance;
>  
>   if (WARN_ON(!np))
>   return;
>  
>   if (of_find_property(np, "#cooling-cells", NULL)) {
> - info->cdev = of_cpufreq_cooling_register(np,
> -  policy->related_cpus);
> + if (!info->cdev) {

Why will info->cdev be non-NULL here ?

> + of_property_read_u32(np, DYNAMIC_POWER, );

This can fail, in which case capacitance will be used uninitialized.
Fix that by initializing it with 0 at the beginning of this routine.

> + info->cdev = of_cpufreq_power_cooling_register(np,
> + policy->related_cpus,
> + capacitance,
> + NULL);
>  
> - if (IS_ERR(info->cdev)) {
> - dev_err(info->cpu_dev,
> - "running cpufreq without cooling device: %ld\n",
> - PTR_ERR(info->cdev));
> + if (IS_ERR(info->cdev)) {
> + dev_err(info->cpu_dev,
> + "running cpufreq without cooling 
> device: %ld\n",
> + PTR_ERR(info->cdev));
>  
> - info->cdev = NULL;
> + info->cdev = NULL;
> + }
>   }
>   }
>  
> @@ -460,7 +470,9 @@ static int mtk_cpufreq_exit(struct cpufreq_policy *policy)
>  {
>   struct mtk_cpu_dvfs_info *info = policy->driver_data;
>  
> - cpufreq_cooling_unregister(info->cdev);
> + if (info->cdev)
> + cpufreq_cooling_unregister(info->cdev);
> +

Why do you need to update this?

>   dev_pm_opp_free_cpufreq_table(info->cpu_dev, >freq_table);
>   mtk_cpu_dvfs_info_release(info);
>   kfree(info);
> -- 
> 1.7.9.5

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

Re: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3

[Krzysztof Kozlowski]

On 27.11.2015 15:42, Anand Moon wrote:
> hi Krzysztof,
> 
> On 22 October 2015 at 18:34, Anand Moon  wrote:
>> hi Krzysztof,
>>
>> On 22 October 2015 at 06:31, Krzysztof Kozlowski
>>  wrote:
>>> On 20.10.2015 21:56, Anand Moon wrote:
 Changes need for host controller to detect UHS-I highspeed cards.
 Changes in VDDQ_MMC2 voltage range help scale
 the required voltage to detect and load the microSD cards.
>>>
>>> Thanks for updating description of commit.
>>>

 Signed-off-by: Anand Moon 
 ---
 Changes based on 
 git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
 v4.4-next/dt-samsung branch

 Changes:
 Drop the ranp_delay for LDO9.

 Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
 me out figure out the mmc core requirement.

 Also drop the previous changes:
 use cd-gpio method to detect sd-card.
 Added UHS-I bus speed support.

 [4.713553] random: nonblocking pool is initialized
 [4.718423] 1453.hdmi supply hdmi-en not found, using dummy 
 regulator
 [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops 
 fimd_component_ops)
 [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops 
 mixer_component_ops)
 [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops 
 hdmi_component_ops)
 [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
 [4.753428] [drm] No driver support for vblank timestamp query.
 [4.940794] Console: switching to colour frame buffer device 274x77
 [4.995344] exynos-drm exynos-drm: fb0:  frame buffer device
 [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
 [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
 [5.054571] usb 2-1: new full-speed USB device number 2 using 
 exynos-ohci
 [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
 [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 
 0x0 status 0x0)
 ---
  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
 b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
 index 1af5bdc..a4be3e0 100644
 --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
 +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
 @@ -182,9 +182,10 @@

   ldo13_reg: LDO13 {
   regulator-name = "vdd_ldo13";
 - regulator-min-microvolt = <280>;
 + regulator-min-microvolt = <180>;
>>>
>>> You did not convinced me in previous discussion about the change to
>>> 1.8V. I said that:
 On the same diagram few lines below:
 VDDQ_MMC2: 2.8V 250mA
>>>
>>> You responded:
 You are correct.
>>>
>>> So I am confused. Are you sure that this SD card block can/should
>>> operate on 1.8V? Have you actually tried this?
>>>
>>
>> Look like I missed this point. Here is the link I would like to share.
>>
>> http://www.hjreggel.net/cardspeed/cs_sdxc.html
>> Section: Summary of SD modes
>>
>> https://en.wikipedia.org/wiki/Secure_Digital
>> Section: Power consumption
>>
>> Their different requirement for voltage requirement for UHS-I, the max
>> value is around 3.3V
> 
> Do you have any comment on this voltage selection for UHS-I card (1.8V).

I asked whether you tried this, whether setting real 1.8V works fine.
You did not respond. As you can see on Odroid schematics, the VDDQ for
MMC[01] operates under 1.8V.

The VDDQ for MMC2 - under 2.8V.

In commit description you mentioned that this voltage "helps scale the
required voltage to detect and load the microSD cards". What does it
mean "help"? I would expect that detecting and loading of microSD cards
either works or does not work. I am not sure how does it help.

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

[PATCH] of/address: replace printk(KERN_ERR ...) with pr_err(...)

[Masahiro Yamada]

A trivial change suggested by checkpatch.pl.

Signed-off-by: Masahiro Yamada 
---

 drivers/of/address.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index cd53fe4..5289c80 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -596,7 +596,7 @@ static u64 __of_translate_address(struct device_node *dev,
pbus = of_match_bus(parent);
pbus->count_cells(dev, , );
if (!OF_CHECK_COUNTS(pna, pns)) {
-   printk(KERN_ERR "prom_parse: Bad cell count for %s\n",
+   pr_err("prom_parse: Bad cell count for %s\n",
   of_node_full_name(dev));
break;
}
-- 
1.9.1

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

[PATCH v4 5/5] ARM: dts: AM4372: add entry for qspi mmap region

[Vignesh R]

Add qspi memory mapped region entries for AM43xx based SoCs. Also,
update the binding documents for the controller to document this change.

Acked-by: Rob Herring 
Signed-off-by: Vignesh R 
---

v4: No changes.

 Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--
 arch/arm/boot/dts/am4372.dtsi | 4 +++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index 334aa3f32cbc..5a1542eda387 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -17,9 +17,10 @@ Recommended properties:
 
 Example:
 
+For am4372:
 qspi: qspi@4b30 {
-   compatible = "ti,dra7xxx-qspi";
-   reg = <0x4790 0x100>, <0x3000 0x3ff>;
+   compatible = "ti,am4372-qspi";
+   reg = <0x4790 0x100>, <0x3000 0x400>;
reg-names = "qspi_base", "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c9701e..e32d164102d1 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -963,7 +963,9 @@
 
qspi: qspi@4790 {
compatible = "ti,am4372-qspi";
-   reg = <0x4790 0x100>;
+   reg = <0x4790 0x100>,
+ <0x3000 0x400>;
+   reg-names = "qspi_base", "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "qspi";
-- 
2.6.3

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

[PATCH v4 2/5] spi: spi-ti-qspi: add mmap mode read support

[Vignesh R]

ti-qspi controller provides mmap port to read data from SPI flashes.
mmap port is enabled in QSPI_SPI_SWITCH_REG. ctrl module register may
also need to be accessed for some SoCs. The QSPI_SPI_SETUP_REGx needs to
be populated with flash specific information like read opcode, read
mode(quad, dual, normal), address width and dummy bytes. Once,
controller is in mmap mode, the whole flash memory is available as a
memory region at SoC specific address. This region can be accessed using
normal memcpy() (or mem-to-mem dma copy). The ti-qspi controller hardware
will internally communicate with SPI flash over SPI bus and get the
requested data.

Implement spi_flash_read() callback to support mmap read over SPI
flash devices. With this, the read throughput increases from ~100kB/s to
~2.5 MB/s.

Signed-off-by: Vignesh R 
---

 drivers/spi/spi-ti-qspi.c | 101 ++
 1 file changed, 94 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 64318fcfacf2..cd4e63f45e65 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -56,6 +56,7 @@ struct ti_qspi {
u32 dc;
 
bool ctrl_mod;
+   bool mmap_enabled;
 };
 
 #define QSPI_PID   (0x0)
@@ -65,11 +66,8 @@ struct ti_qspi {
 #define QSPI_SPI_CMD_REG   (0x48)
 #define QSPI_SPI_STATUS_REG(0x4c)
 #define QSPI_SPI_DATA_REG  (0x50)
-#define QSPI_SPI_SETUP0_REG(0x54)
+#define QSPI_SPI_SETUP_REG(n)  ((0x54 + 4 * n))
 #define QSPI_SPI_SWITCH_REG(0x64)
-#define QSPI_SPI_SETUP1_REG(0x58)
-#define QSPI_SPI_SETUP2_REG(0x5c)
-#define QSPI_SPI_SETUP3_REG(0x60)
 #define QSPI_SPI_DATA_REG_1(0x68)
 #define QSPI_SPI_DATA_REG_2(0x6c)
 #define QSPI_SPI_DATA_REG_3(0x70)
@@ -109,6 +107,16 @@ struct ti_qspi {
 
 #define QSPI_AUTOSUSPEND_TIMEOUT 2000
 
+#define MEM_CS_EN(n)   ((n + 1) << 8)
+
+#define MM_SWITCH  0x1
+
+#define QSPI_SETUP_RD_NORMAL   (0x0 << 12)
+#define QSPI_SETUP_RD_DUAL (0x1 << 12)
+#define QSPI_SETUP_RD_QUAD (0x3 << 12)
+#define QSPI_SETUP_ADDR_SHIFT  8
+#define QSPI_SETUP_DUMMY_SHIFT 10
+
 static inline unsigned long ti_qspi_read(struct ti_qspi *qspi,
unsigned long reg)
 {
@@ -366,6 +374,78 @@ static int qspi_transfer_msg(struct ti_qspi *qspi, struct 
spi_transfer *t)
return 0;
 }
 
+static void ti_qspi_enable_memory_map(struct spi_device *spi)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 val;
+
+   ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
+   if (qspi->ctrl_mod) {
+   val = readl(qspi->ctrl_base);
+   val |= MEM_CS_EN(spi->chip_select);
+   writel(val, qspi->ctrl_base);
+   /* dummy readl to ensure bus sync */
+   readl(qspi->ctrl_base);
+   }
+   qspi->mmap_enabled = true;
+}
+
+static void ti_qspi_disable_memory_map(struct spi_device *spi)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 val;
+
+   ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
+   if (qspi->ctrl_mod) {
+   val = readl(qspi->ctrl_base);
+   val &= ~MEM_CS_EN(spi->chip_select);
+   writel(val, qspi->ctrl_base);
+   }
+   qspi->mmap_enabled = false;
+}
+
+static void ti_qspi_setup_mmap_read(struct spi_device *spi,
+   struct spi_flash_read_message *msg)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 memval = msg->read_opcode;
+
+   switch (msg->data_nbits) {
+   case SPI_NBITS_QUAD:
+   memval |= QSPI_SETUP_RD_QUAD;
+   break;
+   case SPI_NBITS_DUAL:
+   memval |= QSPI_SETUP_RD_DUAL;
+   break;
+   default:
+   memval |= QSPI_SETUP_RD_NORMAL;
+   break;
+   }
+   memval |= ((msg->addr_width - 1) << QSPI_SETUP_ADDR_SHIFT |
+  msg->dummy_bytes << QSPI_SETUP_DUMMY_SHIFT);
+   ti_qspi_write(qspi, memval,
+ QSPI_SPI_SETUP_REG(spi->chip_select));
+}
+
+static int ti_qspi_spi_flash_read(struct  spi_device *spi,
+ struct spi_flash_read_message *msg)
+{
+   struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
+   int ret = 0;
+
+   mutex_lock(>list_lock);
+
+   if (!qspi->mmap_enabled)
+   ti_qspi_enable_memory_map(spi);
+   ti_qspi_setup_mmap_read(spi, msg);
+   memcpy_fromio(msg->buf, qspi->mmap_base + msg->from, msg->len);
+   msg->retlen = msg->len;
+
+   mutex_unlock(>list_lock);
+
+   return ret;
+}
+
 static int ti_qspi_start_transfer_one(struct spi_master *master,
struct spi_message *m)
 {

[PATCH v4 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Vignesh R]

Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
update the binding documents for the controller to document this change.

Acked-by: Rob Herring 
Signed-off-by: Vignesh R 
---

v4: No changes.

 Documentation/devicetree/bindings/spi/ti_qspi.txt | 14 ++
 arch/arm/boot/dts/dra7.dtsi   |  7 +--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index 601a360531a5..334aa3f32cbc 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -26,3 +26,17 @@ qspi: qspi@4b30 {
spi-max-frequency = <2500>;
ti,hwmods = "qspi";
 };
+
+For dra7xx:
+qspi: qspi@4b30 {
+   compatible = "ti,dra7xxx-qspi";
+   reg = <0x4b30 0x100>,
+ <0x5c00 0x400>,
+ <0x4a002558 0x4>;
+   reg-names = "qspi_base", "qspi_mmap",
+   "qspi_ctrlmod";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   spi-max-frequency = <4800>;
+   ti,hwmods = "qspi";
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231cbde5..debe7523643d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1153,8 +1153,11 @@
 
qspi: qspi@4b30 {
compatible = "ti,dra7xxx-qspi";
-   reg = <0x4b30 0x100>;
-   reg-names = "qspi_base";
+   reg = <0x4b30 0x100>,
+ <0x5c00 0x400>,
+ <0x4a002558 0x4>;
+   reg-names = "qspi_base", "qspi_mmap",
+   "qspi_ctrlmod";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "qspi";
-- 
2.6.3

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

Re: [PATCH v2 06/10] drm/hisilicon: Add vblank feature

[Daniel Vetter]

On Sat, Nov 28, 2015 at 06:39:01PM +0800, Xinliang Liu wrote:
> Add vblank handle for ADE.
> 
> Signed-off-by: Xinliang Liu 
> Signed-off-by: Xinwei Kong 
> Signed-off-by: Andy Green 
> ---
>  drivers/gpu/drm/hisilicon/hisi_drm_ade.c | 78 
> 
>  drivers/gpu/drm/hisilicon/hisi_drm_ade.h | 16 +++
>  drivers/gpu/drm/hisilicon/hisi_drm_drv.c | 19 +++-
>  3 files changed, 112 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_ade.h
> 
> diff --git a/drivers/gpu/drm/hisilicon/hisi_drm_ade.c 
> b/drivers/gpu/drm/hisilicon/hisi_drm_ade.c
> index b0976c3..acb11e7 100644
> --- a/drivers/gpu/drm/hisilicon/hisi_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/hisi_drm_ade.c
> @@ -267,7 +267,79 @@ static void ade_power_down(struct ade_hw_ctx *ctx)
>   ctx->power_on = false;
>  }
>  
> +static struct drm_crtc *hisi_get_crtc_from_index(struct drm_device *dev,
> +  unsigned int index)

Ugly that you had to add this, but unfortunately necessary :( Fixing up
the drm vblank hooks so that they deal with struct drm_crtc directly is
somewhere on my todo. But drm_irq.c is still a bit a mess, so this is some
ways off still.

What might be possible as a follow-up cleanup though is to add
vblank_enable and vblank_disable functions to struct
drm_crtc_helper_funcs. And then provide this code here to map from int
index to struct drm_crtc * as helpers in a new drm_vblank_helper.c file.
That might be a good intermediate step.

But nothing that needs to be done before merging hisilicon, that's for
sure.

One more comment below.

> +{
> + unsigned int index_tmp = 0;
> + struct drm_crtc *crtc;
> +
> + list_for_each_entry(crtc, >mode_config.crtc_list, head) {
> + if (index_tmp == index)
> + return crtc;
> +
> + index_tmp++;
> + }
> +
> + WARN_ON(true);
> +}
> +
> +int ade_enable_vblank(struct drm_device *dev, int crtc_index)
> +{
> + struct drm_crtc *crtc = hisi_get_crtc_from_index(dev, crtc_index);
> + struct ade_crtc *acrtc = to_ade_crtc(crtc);
> + struct ade_hw_ctx *ctx = acrtc->ctx;
> + void __iomem *base = ctx->base;
> + u32 intr_en;
> +
> + DRM_INFO("enable_vblank enter.\n");
> + if (!ctx->power_on)
> + (void)ade_power_up(ctx);
> +
> + intr_en = readl(base + LDI_INT_EN);
> + intr_en |= LDI_ISR_FRAME_END_INT;
> + writel(intr_en, base + LDI_INT_EN);
>  
> + return 0;
> +}
> +
> +void ade_disable_vblank(struct drm_device *dev, int crtc_index)
> +{
> + struct drm_crtc *crtc = hisi_get_crtc_from_index(dev, crtc_index);
> + struct ade_crtc *acrtc = to_ade_crtc(crtc);
> + struct ade_hw_ctx *ctx = acrtc->ctx;
> + void __iomem *base = ctx->base;
> + u32 intr_en;
> +
> + DRM_INFO("disable_vblank enter.\n");
> + if (!ctx->power_on) {
> + DRM_ERROR("power is down! vblank disable fail\n");
> + return;
> + }
> + intr_en = readl(base + LDI_INT_EN);
> + intr_en &= ~LDI_ISR_FRAME_END_INT;
> + writel(intr_en, base + LDI_INT_EN);
> +}
> +
> +static irqreturn_t ade_irq_handler(int irq, void *data)
> +{
> + struct ade_crtc *acrtc = data;
> + struct ade_hw_ctx *ctx = acrtc->ctx;
> + struct drm_crtc *crtc = >base;
> + struct drm_device *dev = crtc->dev;
> + void __iomem *base = ctx->base;
> + u32 status;
> +
> + status = readl(base + LDI_MSK_INT);
> + /* DRM_INFO("LDI IRQ: status=0x%X\n",status); */
> +
> + /* vblank irq */
> + if (status & LDI_ISR_FRAME_END_INT) {
> + writel(LDI_ISR_FRAME_END_INT, base + LDI_INT_CLR);
> + drm_handle_vblank(dev, drm_crtc_index(crtc));

drm_crtc_handle_vblank please. At least when calling into the vblank code
drivers don't have to do the struct drm_crtc -> int index conversion any
more. Please make sure you do that everywhere, in case I've missed one.

Cheers, Daniel

> + }
> +
> + return IRQ_HANDLED;
> +}
>  
>  /*
>   * set modules' reset mode: by software or hardware
> @@ -858,6 +930,12 @@ static int ade_bind(struct device *dev, struct device 
> *master, void *data)
>   if (ret)
>   return ret;
>  
> + /* vblank irq init */
> + ret = request_irq(ctx->irq, ade_irq_handler, DRIVER_IRQ_SHARED,
> +   drm_dev->driver->name, acrtc);
> + if (ret)
> + return ret;
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/hisilicon/hisi_drm_ade.h 
> b/drivers/gpu/drm/hisilicon/hisi_drm_ade.h
> new file mode 100644
> index 000..d1d7b5d
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/hisi_drm_ade.h
> @@ -0,0 +1,16 @@
> +/*
> + * Copyright (c) 2014-2015 Hisilicon Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 

[PATCH v2 0/5] Fix a trivial typo and support rk3228/rk3399 SoCs for thermal driver.

[Caesar Wang]

This series pacthes to support the next soc for this thermal driver.
I don't add the dts thermal data since these SoCs have *_not_* land
in this mainline. I believe these SoCs dts will land in this mainline
lately,
then I will add the thermal data for Heiko.

This series patches can apply into Eduardo branch.
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git

Also, this series pacthes have built on github branch.
https://github.com/rockchip-linux/kernel/commits/develop4.4

PATCH[1/5]:
That's bit ugly typo, sorry for sending again :(.

PATCH[2/5]:
To fix a build warning came from Dan Carpenter report smatch check,
Thanks. :)

PATCH[3/5]:
Add the rk3228/rk3399 SoCs compatible for dt-bindings.

PATCH[4/5]:
Add the rk3228 SoCs for thermal driver.

PATCH[5/5]:
Add the rk3399 SoCs for thermal driver based on PATCH[4/5].


Changes in v2:
- As Heiko comments, move to documenting the fields in the header
  instead of inside the table.

Changes in v1:
- Search more trivial typo for me.
- As Heiko comments, fix a copy incorrect name.
- Add a Acked from Rob.
- fix a irq ack is similar with RK3228 SoCs.

Caesar Wang (5):
  thermal: rockchip: fix a trivial typo
  thermal: rockchip: fix a impossible condition caused by the warning
  dt-bindings: rockchip-thermal: Support the RK3228/RK3399 SoCs
compatible
  thermal: rockchip: Support the RK3228 SoCs in thermal driver
  thermal: rockchip: Support the RK3399 SoCs in thermal driver

 .../bindings/thermal/rockchip-thermal.txt  |   2 +
 drivers/thermal/rockchip_thermal.c | 174 +++--
 2 files changed, 163 insertions(+), 13 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 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support

[Nishanth Menon]

On 11/29/2015 06:10 AM, Dmitry Lifshitz wrote:
[...]
>>> +};
>>> +
>>> +leds {
>>> +compatible = "gpio-leds";
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <_pins_default>;
>>> +
>>> +led@0 {
>>> +label = "cl-som-am57x:green";
>>> +gpios = < 5 GPIO_ACTIVE_HIGH>;
>>> +linux,default-trigger = "heartbeat";
>>> +default-state = "off";
>>> +};
>>> +};
>>> +};
>>> +
>>> +_pmx_core {
>>> +leds_pins_default: leds_pins_default {
>>> +pinctrl-single,pins = <
>>> +DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)/*
>>> gpmc_a15.gpio2_5 */
>>> +>;
>>> +};
>>> +
>>> +i2c1_pins_default: i2c1_pins_default {
>>> +pinctrl-single,pins = <
>>> +DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP |
>>> MUX_MODE0)/* i2c1_sda.sda */
>>> +DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP |
>>> MUX_MODE0)/* i2c1_scl.scl */
>>> +>;
>>> +};
>>> +
>>> +tps659038_pins_default: tps659038_pins_default {
>>> +pinctrl-single,pins = <
>>> +DRA7XX_CORE_IOPAD(0x3818, PIN_INPUT_PULLUP | MUX_MODE14)
>>> /* wakeup0.gpio1_0 */
>>> +>;
>>> +};
>>
>> Generic comment: As per requirements of the SoC -> all pinctrl must be
>> done in bootloader. this was a recommendation that came in too late
>> for TI platforms that got introduced in upstream, but that cleanup
>> should eventually take place as well.
>>
> 
> Please, could you provide a reference to those recommendations.
> Do you mean pinctrl for PMIC pins only?

You might want to ask your TI support contact for IODelay
recommendations. TRM mentions that pinmuxing must be performed under IO
isolation. There are silicon constraints in DRA7/AM57xx family, which
were not present previously.

>>> +tps659038: tps659038@58 {
>>> +compatible = "ti,tps659038";
>>> +reg = <0x58>;
>>> +interrupt-parent = <>;
>>> +interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>>
>> Also See: https://patchwork.kernel.org/patch/7596541/ ->
>> Documentation/devicetree/bindings/i2c/i2c.txt -> since you seem to
>> have a PMIC with power button, you might be able to get wakeup source
>> also there.
>>
> 
> Do you mean just adding "wakeup-source" property?
> 
> According to Documentation/devicetree/bindings/i2c/i2c.txt the primary
> interrupt will be used as wakeup interrupt.

I think you might have to describe a "wakeup" interrupt -> which will be
similar in description to the one you used to describe uart wakeup
capability.

[..]

>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <_pins_default>;
>>> +
>>> +#interrupt-cells = <2>;
>>> +interrupt-controller;
>>> +
>>> +ti,system-power-controller;
>>
>> Assuming powerhold signal and BOOT0,1 is proper here, else poweroff
>> will never work.
>>
> 
> Please, could you provide more details regarding this issue.

well,  if poweroff command does not completely power off your board, you
may want to investigate further. overall, the better circuit
configuration is the X15 configuration:
https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2.pdf
Pay close attention to the PMIC GPIO_&/POWERHOLD signal. Also notice the
extra reset circuit involved.

Again, a topic that you should probably discuss with your TI support
contact person.

[...]

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