[RESEND PATCH v3] mtd: hisilicon: add device tree node for NAND controller
This patch adds dts support for NAND flash controller of Hisilicon Soc Hip04.
Now it is based on v4.0-rc5
Changes in v3:
- Change E-mail address in signed-off-by to "wangzh...@hisilicon.com"
Changes in v2:
- Base on v3.19-rc1
- Use nand-ecc-strength, nand-ecc-step-size to replace hisi,nand-ecc-bits
Changes in v1:
- Move partition and other board related information into board dts file:
hip04-d01.dts
Signed-off-by: Zhou Wang
---
arch/arm/boot/dts/hip04-d01.dts | 27 +++
arch/arm/boot/dts/hip04.dtsi| 7 +++
2 files changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/hip04-d01.dts b/arch/arm/boot/dts/hip04-d01.dts
index 40a9e33..ba04dd5 100644
--- a/arch/arm/boot/dts/hip04-d01.dts
+++ b/arch/arm/boot/dts/hip04-d01.dts
@@ -28,5 +28,32 @@
uart0: uart@4007000 {
status = "ok";
};
+
+ nand: nand@402 {
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <16>;
+ nand-ecc-step-size = <1024>;
+
+ partition@0 {
+ label = "nand_text";
+ reg = <0x 0x0040>;
+ };
+
+ partition@0040 {
+ label = "nand_monitor";
+ reg = <0x0040 0x0040>;
+ };
+
+ partition@0080 {
+ label = "nand_kernel";
+ reg = <0x0080 0x0080>;
+ };
+
+ partition@0100 {
+ label = "nand_fs";
+ reg = <0x0100 0x1f00>;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi
index 2388145..ac32fce 100644
--- a/arch/arm/boot/dts/hip04.dtsi
+++ b/arch/arm/boot/dts/hip04.dtsi
@@ -269,6 +269,13 @@
interrupts = <0 372 4>;
};
+ nand: nand@402 {
+ compatible = "hisilicon,504-nfc";
+ reg = <0x402 0x1>, <0x500 0x1000>;
+ interrupts = <0 379 4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
};
etb@0,e3c42000 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] of: Allow selection of OF_DYNAMIC and OF_OVERLAY if OF_UNITTEST
On Fri, 20 Mar 2015 08:32:12 -0500 , Rob Herring wrote: > On Fri, Mar 20, 2015 at 7:25 AM, Grant Likely wrote: > > On Fri, 23 Jan 2015 17:10:04 +0100 > > , Geert Uytterhoeven > > wrote: > >> Currently OF_DYNAMIC and OF_OVERLAY are not visible to the user, and are > >> selected automatically only when needed. > >> > >> Allow them to be enabled manually to improve device tree unit test > >> coverage. > >> > >> Signed-off-by: Geert Uytterhoeven > > > > I like the change. Merged, thanks. > > Making OF_OVERLAY visible is already in 4.0-rc4. Yes, I modified the patch to fit. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v6 2/2] ARM: dts: hip04: add GPIO pieces
From: Zhou Wang
Hisilicon Soc hip04 has four GPIO controllers, each one has 32
GPIOs and can be configured to be an interrupt controller.The GPIO
controllers are compatible with the snps,dw-apb-gpio driver.
This patch add the corresponding device tree nodes.
Acked-by: Linus Walleij
Signed-off-by: Zhou Wang
---
arch/arm/boot/dts/hip04.dtsi | 75
1 file changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi
index 2388145..267942a 100644
--- a/arch/arm/boot/dts/hip04.dtsi
+++ b/arch/arm/boot/dts/hip04.dtsi
@@ -269,6 +269,81 @@
interrupts = <0 372 4>;
};
+ gpio@4003000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dw-apb-gpio";
+ reg = <0x4003000 0x1000>;
+
+ gpio3: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ snps,nr-gpios = <32>;
+ reg = <0>;
+ interrupt-parent = <&gic>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 392 4>;
+ };
+ };
+
+ gpio@4002000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dw-apb-gpio";
+ reg = <0x4002000 0x1000>;
+
+ gpio2: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ snps,nr-gpios = <32>;
+ reg = <0>;
+ interrupt-parent = <&gic>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 391 4>;
+ };
+ };
+
+ gpio@4001000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dw-apb-gpio";
+ reg = <0x4001000 0x1000>;
+
+ gpio1: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ snps,nr-gpios = <32>;
+ reg = <0>;
+ interrupt-parent = <&gic>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 390 4>;
+ };
+ };
+
+ gpio@400 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dw-apb-gpio";
+ reg = <0x400 0x1000>;
+
+ gpio0: gpio-controller@0 {
+ compatible = "snps,dw-apb-gpio-port";
+ gpio-controller;
+ #gpio-cells = <2>;
+ snps,nr-gpios = <32>;
+ reg = <0>;
+ interrupt-parent = <&gic>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 389 4>;
+ };
+ };
};
etb@0,e3c42000 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v6 1/2] ARM: hip04: add GPIO configure in hisi_defconfig
From: Zhou Wang The GPIO controller of Hisilicon hip04 Soc uses the IP from Sysnopsis, gpio-dwapb.c can be reused to support this GPIO controller. This patch adds related configure item in hisi_defconfig. Acked-by: Linus Walleij Signed-off-by: Zhou Wang --- arch/arm/configs/hisi_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig index c34da58..e7bf486 100644 --- a/arch/arm/configs/hisi_defconfig +++ b/arch/arm/configs/hisi_defconfig @@ -51,6 +51,7 @@ CONFIG_GPIO_SYSFS=y CONFIG_GPIOLIB=y CONFIG_GPIO_GENERIC_PLATFORM=y CONFIG_REGULATOR_GPIO=y +CONFIG_GPIO_DWAPB=y CONFIG_MFD_SYSCON=y CONFIG_POWER_RESET_SYSCON=y CONFIG_DRM=y -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v6 0/2] ARM: hip04: add GPIO support
This series add the support for the GPIOs of Hisilicon Soc hip04. Hip04 uses synopsis' GPIO IP, and we use the dwapb GPIO driver here. This series add the corresponding dts. The default value of ARCH_NR_GPIOS is used to find gpio base here. Now this patchset is based on v4.0-rc5 Change in v6: - Change E-mail address in signed-off-by to "wangzh...@hisilicon.com" Change in v5: - Base on v3.19-rc1 - Just use default value of ARCH_NR_GPIOS to find gpio base. Remove the new added patch(3/4) in v4. Change in v4: - Delete "default 128 if ARCH_HIP04" in arch/arm/Kconfig - add a new patch to support find GPIO base number in increasing order - add gpio-number-forward property in snps gpio binding doc Change in v3: - Move CONFIG_GPIO_DWAPB to hisi_defconfig - Add CONFIG_GPIOLIB, CONFIG_GPIO_SYSFS in hisi_defconfig Change in v2: - Add select GPIO_DWAPB in arch/arm/mach-hisi/Kconfig Link for v4: - http://www.spinics.net/lists/arm-kernel/msg383883.html Link for v3: - http://www.spinics.net/lists/devicetree/msg60324.html Zhou Wang (2): ARM: hip04: add GPIO configure in hisi_defconfig ARM: dts: hip04: add GPIO pieces arch/arm/boot/dts/hip04.dtsi| 75 + arch/arm/configs/hisi_defconfig | 1 + 2 files changed, 76 insertions(+) -- 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 v4] dt-bindings: brcm: rationalize Broadcom documentation naming
Hi Rob,
On 15-03-22 06:20 PM, Rob Herring wrote:
On 03/20/2015 08:06 PM, Scott Branden wrote:
This patchset attempts to standardize the naming of dt-bindings
documents based on the Broadcom vendor prefix of brcm.
Although there are no guidelines currently present for how to name
the dt-bindings document the "vendor,binding.txt" style is in use by
some of the other vendors.
Acked-by: Lee Jones
Acked-by: Florian Fainelli
Acked-by: Gregory Fong
Acked-by: Stephen Warren
Signed-off-by: Scott Branden
Version history would be nice...
Yes, I should have added a cover letter but didn't. The difference
between versions was minimal: a spelling correction in the commit
message text and a few additional binding files were found that were
added between the versions, along with the Ack's.
Who did you want to apply this? I can, but I'm worried about merge
conflicts here. Hopefully, you're not also doing lots of changes to
existing bindings.
Yes, it would be great for you to take care of applying this. There
shouldn't be any merge conflicts as none of these bindings are currently
being updated. I left a clock binding document out of this patchset at
Ray Jui is updating/renaming the documentation for that binding in a
different patch already.
Thanks,
Scott
Rob
---
.../arm/bcm/{brcm,bcm11351-cpu-method => brcm,bcm11351-cpu-method.txt}| 0
.../devicetree/bindings/arm/bcm/{bcm11351.txt => brcm,bcm11351.txt} | 0
.../devicetree/bindings/arm/bcm/{bcm21664.txt => brcm,bcm21664.txt} | 0
.../devicetree/bindings/arm/{bcm2835.txt => bcm/brcm,bcm2835.txt} | 0
.../devicetree/bindings/arm/{bcm4708.txt => bcm/brcm,bcm4708.txt} | 0
.../devicetree/bindings/arm/bcm/{bcm63138.txt => brcm,bcm63138.txt} | 0
.../devicetree/bindings/arm/{brcm-brcmstb.txt => bcm/brcm,brcmstb.txt}| 0
Documentation/devicetree/bindings/arm/bcm/{cygnus.txt => brcm,cygnus.txt} | 0
Documentation/devicetree/bindings/bus/{bcma.txt => brcm,bus-axi.txt} | 0
.../devicetree/bindings/clock/{bcm-kona-clock.txt => brcm,kona-ccu.txt} | 0
.../devicetree/bindings/dma/{bcm2835-dma.txt => brcm,bcm2835-dma.txt} | 0
.../devicetree/bindings/gpio/{gpio-bcm-kona.txt => brcm,kona-gpio.txt}| 0
.../devicetree/bindings/i2c/{i2c-bcm-kona.txt => brcm,kona-i2c.txt} | 0
Documentation/devicetree/bindings/mfd/{bcm590xx.txt => brcm,bcm59056.txt} | 0
.../bindings/mips/brcm/{bcm3384-intc.txt => brcm,bcm3384-intc.txt}| 0
Documentation/devicetree/bindings/mips/brcm/{bmips.txt => brcm,bmips.txt} | 0
.../devicetree/bindings/mips/brcm/{cm-dsl.txt => brcm,cm-dsl.txt} | 0
Documentation/devicetree/bindings/misc/{smc.txt => brcm,kona-smc.txt} | 0
.../devicetree/bindings/mmc/{kona-sdhci.txt => brcm,kona-sdhci.txt} | 0
.../bindings/net/{broadcom-sf2.txt => brcm,bcm7445-switch-v4.0.txt} | 0
.../devicetree/bindings/net/{broadcom-bcmgenet.txt => brcm,bcmgenet.txt} | 0
.../bindings/net/{broadcom-systemport.txt => brcm,systemport.txt} | 0
.../bindings/net/{broadcom-mdio-unimac.txt => brcm,unimac-mdio.txt} | 0
.../devicetree/bindings/phy/{bcm-phy.txt => brcm,kona-usb2-phy.txt} | 0
.../devicetree/bindings/pwm/{bcm-kona-pwm.txt => brcm,kona-pwm.txt} | 0
.../{arm/bcm/kona-resetmgr.txt => reset/brcm,bcm21664-resetmgr.txt} | 0
.../bindings/serial/{bcm63xx-uart.txt => brcm,bcm6345-uart.txt} | 0
.../devicetree/bindings/sound/{bcm2835-i2s.txt => brcm,bcm2835-i2s.txt} | 0
.../bindings/{arm/bcm/kona-timer.txt => timer/brcm,kona-timer.txt}| 0
.../devicetree/bindings/{mips/brcm/usb.txt => usb/brcm,bcm3384-usb.txt} | 0
.../bindings/{arm/bcm/kona-wdt.txt => watchdog/brcm,kona-wdt.txt} | 0
31 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/arm/bcm/{brcm,bcm11351-cpu-method =>
brcm,bcm11351-cpu-method.txt} (100%)
rename Documentation/devicetree/bindings/arm/bcm/{bcm11351.txt =>
brcm,bcm11351.txt} (100%)
rename Documentation/devicetree/bindings/arm/bcm/{bcm21664.txt =>
brcm,bcm21664.txt} (100%)
rename Documentation/devicetree/bindings/arm/{bcm2835.txt =>
bcm/brcm,bcm2835.txt} (100%)
rename Documentation/devicetree/bindings/arm/{bcm4708.txt =>
bcm/brcm,bcm4708.txt} (100%)
rename Documentation/devicetree/bindings/arm/bcm/{bcm63138.txt =>
brcm,bcm63138.txt} (100%)
rename Documentation/devicetree/bindings/arm/{brcm-brcmstb.txt =>
bcm/brcm,brcmstb.txt} (100%)
rename Documentation/devicetree/bindings/arm/bcm/{cygnus.txt =>
brcm,cygnus.txt} (100%)
rename Documentation/devicetree/bindings/bus/{bcma.txt => brcm,bus-axi.txt}
(100%)
rename Documentation/devicetree/bindings/clock/{bcm-kona-clock.txt =>
brcm,kona-ccu.txt} (100%)
rename Documentation/devicetree/bindings/dma/{bcm2835-dma.txt =>
brcm,bcm2835-dma.txt} (100%)
rename Documentation/devicetree/bindings/gpio/{gpio-bcm-kona.txt =>
brcm,kona-gpio.txt} (100%)
ren
[PATCH v2] powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s)
From: Igal Liberman
Describe the PHY topology for all configurations supported by each board
Based on prior work by Andy Fleming
Signed-off-by: Igal Liberman
Signed-off-by: Shruti Kanetkar
Signed-off-by: Emil Medve
---
v2: Remove 'Change-Id'
arch/powerpc/boot/dts/b4860qds.dts| 60 -
arch/powerpc/boot/dts/b4qds.dtsi | 51 -
arch/powerpc/boot/dts/p1023rdb.dts| 24 +-
arch/powerpc/boot/dts/p2041rdb.dts| 92 +++-
arch/powerpc/boot/dts/p3041ds.dts | 112 +-
arch/powerpc/boot/dts/p4080ds.dts | 184 +++-
arch/powerpc/boot/dts/p5020ds.dts | 112 +-
arch/powerpc/boot/dts/p5040ds.dts | 234 +++-
arch/powerpc/boot/dts/t1040rdb.dts| 32 ++-
arch/powerpc/boot/dts/t1042rdb.dts| 30 ++-
arch/powerpc/boot/dts/t1042rdb_pi.dts | 18 +-
arch/powerpc/boot/dts/t104xqds.dtsi | 178 ++-
arch/powerpc/boot/dts/t104xrdb.dtsi | 33 ++-
arch/powerpc/boot/dts/t2080qds.dts| 158 +-
arch/powerpc/boot/dts/t2080rdb.dts| 67 +-
arch/powerpc/boot/dts/t2081qds.dts| 221 ++-
arch/powerpc/boot/dts/t4240qds.dts| 400 +-
arch/powerpc/boot/dts/t4240rdb.dts| 149 -
18 files changed, 2135 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/boot/dts/b4860qds.dts
b/arch/powerpc/boot/dts/b4860qds.dts
index 6bb3707..98b1ef4 100644
--- a/arch/powerpc/boot/dts/b4860qds.dts
+++ b/arch/powerpc/boot/dts/b4860qds.dts
@@ -1,7 +1,7 @@
/*
* B4860DS Device Tree Source
*
- * Copyright 2012 Freescale Semiconductor Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -39,12 +39,69 @@
model = "fsl,B4860QDS";
compatible = "fsl,B4860QDS";
+ aliases {
+ phy_sgmii_1e = &phy_sgmii_1e;
+ phy_sgmii_1f = &phy_sgmii_1f;
+ phy_xaui_slot1 = &phy_xaui_slot1;
+ phy_xaui_slot2 = &phy_xaui_slot2;
+ };
+
ifc: localbus@ffe124000 {
board-control@3,0 {
compatible = "fsl,b4860qds-fpga", "fsl,fpga-qixis";
};
};
+ soc@ffe00 {
+ fman@40 {
+ ethernet@e8000 {
+ phy-handle = <&phy_sgmii_1e>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@ea000 {
+ phy-handle = <&phy_sgmii_1f>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@f {
+ phy-handle = <&phy_xaui_slot1>;
+ phy-connection-type = "xgmii";
+ };
+
+ ethernet@f2000 {
+ phy-handle = <&phy_xaui_slot2>;
+ phy-connection-type = "xgmii";
+ };
+
+ mdio@fc000 {
+ phy_sgmii_1e: ethernet-phy@1e {
+ reg = <0x1e>;
+ status = "disabled";
+ };
+
+ phy_sgmii_1f: ethernet-phy@1f {
+ reg = <0x1f>;
+ status = "disabled";
+ };
+ };
+
+ mdio@fd000 {
+ phy_xaui_slot1: xaui-phy@slot1 {
+ compatible =
"ethernet-phy-ieee802.3-c45";
+ reg = <0x7>;
+ status = "disabled";
+ };
+
+ phy_xaui_slot2: xaui-phy@slot2 {
+ compatible =
"ethernet-phy-ieee802.3-c45";
+ reg = <0x6>;
+ status = "disabled";
+ };
+ };
+ };
+ };
+
rio: rapidio@ffe0c {
reg = <0xf 0xfe0c 0 0x11000>;
@@ -55,7 +112,6 @@
ranges = <0 0 0xc 0x3000 0 0x1000>;
};
};
-
};
/include/ "fsl/b4860si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index 559d006..af49456 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -1,7 +1,7 @@
/*
* B4420DS Device Tree Source
*
- * Copyright 2012 - 2014 Freescale Semiconductor, Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor, Inc.
*
* Redistribution and use in sourc
Re: [PATCH 5/5] MAINTAINERS: Pantelis Antoniou device tree overlay maintainer
On Tue, Mar 17, 2015 at 3:30 PM, Pantelis Antoniou wrote: > Add me as the device tree overlays maintainer. > > Signed-off-by: Pantelis Antoniou Applied. Thanks. Rob > --- > MAINTAINERS | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 0e1abe8..24aa339 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7187,6 +7187,15 @@ F: Documentation/devicetree/ > F: arch/*/boot/dts/ > F: include/dt-bindings/ > > +OPEN FIRMWARE AND DEVICE TREE OVERLAYS > +M: Pantelis Antoniou > +L: devicetree@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree/dynamic-resolution-notes.txt > +F: Documentation/devicetree/overlay-notes.txt > +F: drivers/of/overlay.c > +F: drivers/of/resolver.c > + > OPENRISC ARCHITECTURE > M: Jonas Bonn > W: http://openrisc.net > -- > 1.7.12 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] of: overlay: Master enable switch
On Tue, Mar 17, 2015 at 3:30 PM, Pantelis Antoniou
wrote:
> Implement a throw once master enable switch to protect against any
> further overlay applications if the administrator desires so.
sysfs documentation?
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/of/overlay.c | 66
> +++-
> 1 file changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index f17f5ef..6688797 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> #include "of_private.h"
>
> @@ -55,6 +56,9 @@ struct of_overlay {
> struct kobject kobj;
> };
>
> +/* master enable switch; once set to 0 can't be re-enabled */
> +static atomic_t ov_enable = ATOMIC_INIT(1);
> +
> static int of_overlay_apply_one(struct of_overlay *ov,
> struct device_node *target, const struct device_node
> *overlay);
>
> @@ -345,6 +349,60 @@ static struct kobj_type of_overlay_ktype = {
>
> static struct kset *ov_kset;
>
> +static ssize_t enable_read(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf,
> + loff_t offset, size_t count)
> +{
> + char tbuf[3];
> +
> + if (offset < 0)
> + return -EINVAL;
> +
> + if (offset >= sizeof(tbuf))
> + return 0;
> +
> + if (count > sizeof(tbuf) - offset)
> + count = sizeof(tbuf) - offset;
> +
> + /* fill in temp */
> + tbuf[0] = '0' + atomic_read(&ov_enable);
> + tbuf[1] = '\n';
> + tbuf[2] = '\0';
> +
> + /* copy to buffer */
> + memcpy(buf, tbuf + offset, count);
> +
> + return count;
> +}
> +
> +static ssize_t enable_write(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf,
> + loff_t off, size_t count)
> +{
> + int new_enable;
> +
> + if (off != 0 || (buf[0] != '0' && buf[1] != '1'))
Is buf[1] correct here?
> + return -EINVAL;
> +
> + new_enable = buf[0] - '0';
> + if (new_enable != 0 && new_enable != 1)
Make unsigned just "if (new_enable > 1)".
> + return -EINVAL;
> +
> + /* NOP for same value */
> + if (new_enable == atomic_read(&ov_enable))
> + return count;
> +
> + /* if we've disabled it, no going back */
> + if (atomic_read(&ov_enable) == 0)
> + return -EPERM;
> +
> + atomic_set(&ov_enable, new_enable);
> + return count;
> +}
> +
> +/* just a single char + '\n' + '\0' */
> +static BIN_ATTR_RW(enable, 3);
> +
> /**
> * of_overlay_create() - Create and apply an overlay
> * @tree: Device node containing all the overlays
> @@ -360,6 +418,10 @@ int of_overlay_create(struct device_node *tree)
> struct of_overlay *ov;
> int err, id;
>
> + /* administratively disabled */
> + if (!atomic_read(&ov_enable))
> + return -EPERM;
> +
> /* allocate the overlay structure */
> ov = kzalloc(sizeof(*ov), GFP_KERNEL);
> if (ov == NULL)
> @@ -596,5 +658,7 @@ int of_overlay_init(void)
> if (!ov_kset)
> return -ENOMEM;
>
> - return 0;
> + rc = sysfs_create_bin_file(&ov_kset->kobj, &bin_attr_enable);
> + WARN(rc, "%s: error adding enable attribute\n", __func__);
> + return rc;
> }
> --
> 1.7.12
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v3 1/2] dma: Add Xilinx Central DMA DT Binding Documentation
Device-tree binding documentation of Xilinx Central DMA Engine.
Signed-off-by: Srikanth Thokala
Signed-off-by: Kedareswara rao Appana
---
Changes in v3:
- Used proper alignment for all the properties.
Changes in v2:
- Change property 'xlnx,data-width' to 'xlnx,datawidth' in the description
to match the implementation.
.../devicetree/bindings/dma/xilinx/xilinx_cdma.txt | 54 ++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/xilinx/xilinx_cdma.txt
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_cdma.txt
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_cdma.txt
new file mode 100644
index 000..aba3b10
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_cdma.txt
@@ -0,0 +1,54 @@
+Xilinx AXI CDMA engine, it does transfers between memory-mapped source
+address and a memory-mapped destination address.
+
+Required properties:
+- compatible : Should be "xlnx,axi-cdma-1.00.a"
+- #dma-cells : Should be <1>, see "dmas" property below
+- reg : Should contain cdma registers location and length.
+- dma-channel child node: Should have only one channel
+
+Optional properties:
+- xlnx,include-sg : Tells whether configured for Scatter-mode in
+ the hardware.
+
+Required child node properties:
+- compatible : It should be "xlnx,axi-cdma-channel".
+- interrupts : Should contain per channel CDMA interrupts.
+- xlnx,datawidth : Should contain the stream data width, take values
+ {32,64...1024}.
+
+Option child node properties:
+- xlnx,include-dre : Tells whether hardware is configured for Data
+ Realignment Engine.
+
+Example:
+
+
+axi_cdma_0: axicdma@7e20 {
+ compatible = "xlnx,axi-cdma-1.00.a";
+ #dma_cells = <1>;
+ reg = < 0x7e20 0x1 >;
+ dma-channel@7e20 {
+ compatible = "xlnx,axi-cdma-channel";
+ interrupts = < 0 55 4 >;
+ xlnx,datawidth = <0x40>;
+ } ;
+} ;
+
+
+* DMA client
+
+Required properties:
+- dmas : a list of <[Central DMA device phandle] [Channel ID]> pairs,
+ where Channel ID is '0' for write/tx and '1' for read/rx
+ channel.
+- dma-names: a list of DMA channel names, one per "dmas" entry
+
+Example:
+
+
+cdmatest_0: cdmatest@0 {
+ compatible ="xlnx,axi-cdma-test-1.00.a";
+ dmas = <&axi_cdma_0 0>;
+ dma-names = "cdma0";
+} ;
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] of: unittest: overlay: Keep track of created overlays
On Tue, Mar 17, 2015 at 3:30 PM, Pantelis Antoniou
wrote:
> During the course of the overlay selftests some of them remain
> applied. While this does not pose a real problem, make sure you track
> them and destroy them at the end of the test.
This is going to need to be rebased on my tree as there has been some
selftest->unitest renaming.
Rob
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/of/unittest.c | 62
> +++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 4e60682..c711534 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -23,6 +23,8 @@
> #include
> #include
>
> +#include
> +
> #include "of_private.h"
>
> static struct selftest_results {
> @@ -1115,6 +1117,59 @@ static const char *overlay_path(int nr)
>
> static const char *bus_path = "/testcase-data/overlay-node/test-bus";
>
> +/* it is guaranteed that overlay ids are assigned in sequence */
> +#define MAX_SELFTEST_OVERLAYS 256
> +static unsigned long overlay_id_bits[BITS_TO_LONGS(MAX_SELFTEST_OVERLAYS)];
> +static int overlay_first_id = -1;
> +
> +static void of_selftest_track_overlay(int id)
> +{
> + if (overlay_first_id < 0)
> + overlay_first_id = id;
> + id -= overlay_first_id;
> +
> + /* we shouldn't need that many */
> + BUG_ON(id >= MAX_SELFTEST_OVERLAYS);
> + overlay_id_bits[BIT_WORD(id)] |= BIT_MASK(id);
> +}
> +
> +static void of_selftest_untrack_overlay(int id)
> +{
> + if (overlay_first_id < 0)
> + return;
> + id -= overlay_first_id;
> + BUG_ON(id >= MAX_SELFTEST_OVERLAYS);
> + overlay_id_bits[BIT_WORD(id)] &= ~BIT_MASK(id);
> +}
> +
> +static void of_selftest_destroy_tracked_overlays(void)
> +{
> + int id, ret, defers;
> +
> + if (overlay_first_id < 0)
> + return;
> +
> + /* try until no defers */
> + do {
> + defers = 0;
> + /* remove in reverse order */
> + for (id = MAX_SELFTEST_OVERLAYS - 1; id >= 0; id--) {
> + if (!(overlay_id_bits[BIT_WORD(id)] & BIT_MASK(id)))
> + continue;
> +
> + ret = of_overlay_destroy(id + overlay_first_id);
> + if (ret != 0) {
> + defers++;
> + pr_warn("%s: overlay destroy failed for
> #%d\n",
> + __func__, id + overlay_first_id);
> + continue;
> + }
> +
> + overlay_id_bits[BIT_WORD(id)] &= ~BIT_MASK(id);
> + }
> + } while (defers > 0);
> +}
> +
> static int of_selftest_apply_overlay(int selftest_nr, int overlay_nr,
> int *overlay_id)
> {
> @@ -1136,6 +1191,7 @@ static int of_selftest_apply_overlay(int selftest_nr,
> int overlay_nr,
> goto out;
> }
> id = ret;
> + of_selftest_track_overlay(id);
>
> ret = 0;
>
> @@ -1349,6 +1405,7 @@ static void of_selftest_overlay_6(void)
> return;
> }
> ov_id[i] = ret;
> + of_selftest_track_overlay(ov_id[i]);
> }
>
> for (i = 0; i < 2; i++) {
> @@ -1373,6 +1430,7 @@ static void of_selftest_overlay_6(void)
> PDEV_OVERLAY));
> return;
> }
> + of_selftest_untrack_overlay(ov_id[i]);
> }
>
> for (i = 0; i < 2; i++) {
> @@ -1417,6 +1475,7 @@ static void of_selftest_overlay_8(void)
> return;
> }
> ov_id[i] = ret;
> + of_selftest_track_overlay(ov_id[i]);
> }
>
> /* now try to remove first overlay (it should fail) */
> @@ -1439,6 +1498,7 @@ static void of_selftest_overlay_8(void)
> PDEV_OVERLAY));
> return;
> }
> + of_selftest_untrack_overlay(ov_id[i]);
> }
>
> selftest(1, "overlay test %d passed\n", 8);
> @@ -1861,6 +1921,8 @@ static void __init of_selftest_overlay(void)
> of_selftest_overlay_i2c_cleanup();
> #endif
>
> + of_selftest_destroy_tracked_overlays();
> +
> out:
> of_node_put(bus_np);
> }
> --
> 1.7.12
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: base: improve of_get_next_child() kernel-doc
On Thu, Mar 19, 2015 at 7:03 AM, Baruch Siach wrote: > Add two new facts to of_get_next_child() documentation: > >* of_get_next_child() returns NULL when there is not next child > >* of_get_next_child() decrements the refcount of prev > > Signed-off-by: Baruch Siach Applied. Thanks. Rob > --- > drivers/of/base.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/of/base.c b/drivers/of/base.c > index adb8764861c0..5ca5f900de9c 100644 > --- a/drivers/of/base.c > +++ b/drivers/of/base.c > @@ -640,8 +640,9 @@ static struct device_node *__of_get_next_child(const > struct device_node *node, > * @node: parent node > * @prev: previous child of the parent node, or NULL to get first > * > - * Returns a node pointer with refcount incremented, use > - * of_node_put() on it when done. > + * Returns a node pointer with refcount incremented, use of_node_put() on > + * it when done. Returns NULL when prev is the last child. Decrements the > + * refcount of prev. > */ > struct device_node *of_get_next_child(const struct device_node *node, > struct device_node *prev) > -- > 2.1.4 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Update the OF unittest and some small fix
On Wed, Mar 11, 2015 at 3:36 AM, Wang Long wrote:
> This series patches do some small fixes in drivers/of/unittest.c,
> and update the Documenttion.
>
> At last, replace selftest with unittest in the c, dtsi
> and binding files.
>
> * v2 <- v1:
> - According to Gaurav's advice. make the rename
> file patch correctly.
>
> Wang Long (5):
> of/unittest: remove the duplicate of_changeset_init
> of/unittest: Fix the wrong expected value in
> of_selftest_property_string
> Documentation: update the of_selftest.txt
> Documentation: rename of_selftest.txt to of_unittest.txt
> of/unittest: replace 'selftest' with 'unittest'
I've applied the series. Thanks.
Rob
>
> Documentation/devicetree/bindings/unittest.txt | 44 +-
> .../{of_selftest.txt => of_unittest.txt} | 35 +-
> drivers/of/unittest-data/tests-overlay.dtsi| 108 ++--
> drivers/of/unittest.c | 703
> ++---
> 4 files changed, 445 insertions(+), 445 deletions(-)
> rename Documentation/devicetree/{of_selftest.txt => of_unittest.txt} (87%)
>
> --
> 1.8.3.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch] dt: OF_UNITTEST make dependency broken
On Fri, Mar 13, 2015 at 2:21 PM, Frank Rowand wrote: > From: Frank Rowand > > If CONFIG_OF_UNITTEST=y then a kernel image make will always cause .version to > be incremented, even if there are not source changes. This is caused by > a lack of dependency tracking and checking for > drivers/of/unittest-data/testcases.dtb.o. > > > Signed-off-by: Frank Rowand Applied. Thanks. Rob > > --- > > > drivers/of/Makefile |5 +++-- > drivers/of/unittest-data/.gitignore |2 ++ > drivers/of/unittest-data/Makefile |7 +++ > 3 files changed, 12 insertions(+), 2 deletions(-) > > Index: b/drivers/of/Makefile > === > --- a/drivers/of/Makefile > +++ b/drivers/of/Makefile > @@ -6,8 +6,7 @@ obj-$(CONFIG_OF_PROMTREE) += pdt.o > obj-$(CONFIG_OF_ADDRESS) += address.o > obj-$(CONFIG_OF_IRQ)+= irq.o > obj-$(CONFIG_OF_NET) += of_net.o > -obj-$(CONFIG_OF_UNITTEST) += of_unittest.o > -of_unittest-objs := unittest.o unittest-data/testcases.dtb.o > +obj-$(CONFIG_OF_UNITTEST) += unittest.o > obj-$(CONFIG_OF_MDIO) += of_mdio.o > obj-$(CONFIG_OF_PCI) += of_pci.o > obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o > @@ -16,5 +15,7 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_rese > obj-$(CONFIG_OF_RESOLVE) += resolver.o > obj-$(CONFIG_OF_OVERLAY) += overlay.o > > +obj-$(CONFIG_OF_UNITTEST) += unittest-data/ > + > CFLAGS_fdt.o = -I$(src)/../../scripts/dtc/libfdt > CFLAGS_fdt_address.o = -I$(src)/../../scripts/dtc/libfdt > Index: b/drivers/of/unittest-data/Makefile > === > --- /dev/null > +++ b/drivers/of/unittest-data/Makefile > @@ -0,0 +1,7 @@ > +obj-y += testcases.dtb.o > + > +targets += testcases.dtb testcases.dtb.S > + > +.SECONDARY: \ > + $(obj)/testcases.dtb.S \ > + $(obj)/testcases.dtb > Index: b/drivers/of/unittest-data/.gitignore > === > --- /dev/null > +++ b/drivers/of/unittest-data/.gitignore > @@ -0,0 +1,2 @@ > +testcases.dtb > +testcases.dtb.S -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] clk: st: New always-on clock domain
Hi Lee,
On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote:
> On Fri, 06 Mar 2015, Mike Turquette wrote:
>> Quoting Lee Jones (2015-03-04 04:00:03)
>> > Mike,
>> >
>> > Do you want me to resend this set with Robert's Reviewed-by applied,
>> > or are you happy to apply it yourself?
>>
>> No need for the resend. I am hoping for a final review from a DT human.
>>
>> This approach looks fine to me. In practice I think it is restricted to
>> hardware blocks that don't exist in DT yet (e.g. no driver, in the case
>> of your interconnect) and that restriction is probably for the best.
>
> Agreed.
I think this restriction should be documented in the DT binding more clearly,
as adding a "clk-always-on" node prohibits you from handling the clock
correctly in
the future.
Still, for simple devices where you don't have a driver, but have "predictable"
bindings (e.g. a bus like "simple-pm-bus"), I think it's better to add
a device node
for that simple device now, incl. a reference to the clock, and have a simple
driver that binds to the device, or platform code that looks for a
compatible node,
and enables the clock. That way you don't have to make any chances to the DTS
later, when you'll have a real driver.
>> > > v2 => v3:
>> > > - Ensure DT actually reflects h/w
>> > > - i.e. Nodes should not contain a mishmash of different IP
>> > > blocks, but should identify related h/w. In the current
>> > > example we use interconnects
>> > > - Change naming from clkdomain to clk-always-on
>> > > - Place "do not abuse" warning in documentation
>> > >
>> > > v1 => v2:
>> > > - Turned the ST specific driver into a generic one
>> > >
>> > > Hardware can have a bunch of clocks which must not be turned off.
>> > > If drivers a) fail to obtain a reference to any of these or b) give
>> > > up a previously obtained reference during suspend, the common clk
>> > > framework will attempt to turn them off and the hardware will
>> > > subsequently die. The only way to recover from this failure is to
>> > > restart.
>> > >
>> > > To avoid either of these two scenarios from catastrophically
>> > > disabling the running system we have implemented a clock domain
>> > > where clocks are consumed and references are taken, thus preventing
>> > > them from being shut down by the framework.
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 v4] dt-bindings: brcm: rationalize Broadcom documentation naming
On 03/20/2015 08:06 PM, Scott Branden wrote:
> This patchset attempts to standardize the naming of dt-bindings
> documents based on the Broadcom vendor prefix of brcm.
>
> Although there are no guidelines currently present for how to name
> the dt-bindings document the "vendor,binding.txt" style is in use by
> some of the other vendors.
>
> Acked-by: Lee Jones
> Acked-by: Florian Fainelli
> Acked-by: Gregory Fong
> Acked-by: Stephen Warren
> Signed-off-by: Scott Branden
Version history would be nice...
Who did you want to apply this? I can, but I'm worried about merge
conflicts here. Hopefully, you're not also doing lots of changes to
existing bindings.
Rob
> ---
> .../arm/bcm/{brcm,bcm11351-cpu-method => brcm,bcm11351-cpu-method.txt}| 0
> .../devicetree/bindings/arm/bcm/{bcm11351.txt => brcm,bcm11351.txt} | 0
> .../devicetree/bindings/arm/bcm/{bcm21664.txt => brcm,bcm21664.txt} | 0
> .../devicetree/bindings/arm/{bcm2835.txt => bcm/brcm,bcm2835.txt} | 0
> .../devicetree/bindings/arm/{bcm4708.txt => bcm/brcm,bcm4708.txt} | 0
> .../devicetree/bindings/arm/bcm/{bcm63138.txt => brcm,bcm63138.txt} | 0
> .../devicetree/bindings/arm/{brcm-brcmstb.txt => bcm/brcm,brcmstb.txt}| 0
> Documentation/devicetree/bindings/arm/bcm/{cygnus.txt => brcm,cygnus.txt} | 0
> Documentation/devicetree/bindings/bus/{bcma.txt => brcm,bus-axi.txt} | 0
> .../devicetree/bindings/clock/{bcm-kona-clock.txt => brcm,kona-ccu.txt} | 0
> .../devicetree/bindings/dma/{bcm2835-dma.txt => brcm,bcm2835-dma.txt} | 0
> .../devicetree/bindings/gpio/{gpio-bcm-kona.txt => brcm,kona-gpio.txt}| 0
> .../devicetree/bindings/i2c/{i2c-bcm-kona.txt => brcm,kona-i2c.txt} | 0
> Documentation/devicetree/bindings/mfd/{bcm590xx.txt => brcm,bcm59056.txt} | 0
> .../bindings/mips/brcm/{bcm3384-intc.txt => brcm,bcm3384-intc.txt}| 0
> Documentation/devicetree/bindings/mips/brcm/{bmips.txt => brcm,bmips.txt} | 0
> .../devicetree/bindings/mips/brcm/{cm-dsl.txt => brcm,cm-dsl.txt} | 0
> Documentation/devicetree/bindings/misc/{smc.txt => brcm,kona-smc.txt} | 0
> .../devicetree/bindings/mmc/{kona-sdhci.txt => brcm,kona-sdhci.txt} | 0
> .../bindings/net/{broadcom-sf2.txt => brcm,bcm7445-switch-v4.0.txt} | 0
> .../devicetree/bindings/net/{broadcom-bcmgenet.txt => brcm,bcmgenet.txt} | 0
> .../bindings/net/{broadcom-systemport.txt => brcm,systemport.txt} | 0
> .../bindings/net/{broadcom-mdio-unimac.txt => brcm,unimac-mdio.txt} | 0
> .../devicetree/bindings/phy/{bcm-phy.txt => brcm,kona-usb2-phy.txt} | 0
> .../devicetree/bindings/pwm/{bcm-kona-pwm.txt => brcm,kona-pwm.txt} | 0
> .../{arm/bcm/kona-resetmgr.txt => reset/brcm,bcm21664-resetmgr.txt} | 0
> .../bindings/serial/{bcm63xx-uart.txt => brcm,bcm6345-uart.txt} | 0
> .../devicetree/bindings/sound/{bcm2835-i2s.txt => brcm,bcm2835-i2s.txt} | 0
> .../bindings/{arm/bcm/kona-timer.txt => timer/brcm,kona-timer.txt}| 0
> .../devicetree/bindings/{mips/brcm/usb.txt => usb/brcm,bcm3384-usb.txt} | 0
> .../bindings/{arm/bcm/kona-wdt.txt => watchdog/brcm,kona-wdt.txt} | 0
> 31 files changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/devicetree/bindings/arm/bcm/{brcm,bcm11351-cpu-method
> => brcm,bcm11351-cpu-method.txt} (100%)
> rename Documentation/devicetree/bindings/arm/bcm/{bcm11351.txt =>
> brcm,bcm11351.txt} (100%)
> rename Documentation/devicetree/bindings/arm/bcm/{bcm21664.txt =>
> brcm,bcm21664.txt} (100%)
> rename Documentation/devicetree/bindings/arm/{bcm2835.txt =>
> bcm/brcm,bcm2835.txt} (100%)
> rename Documentation/devicetree/bindings/arm/{bcm4708.txt =>
> bcm/brcm,bcm4708.txt} (100%)
> rename Documentation/devicetree/bindings/arm/bcm/{bcm63138.txt =>
> brcm,bcm63138.txt} (100%)
> rename Documentation/devicetree/bindings/arm/{brcm-brcmstb.txt =>
> bcm/brcm,brcmstb.txt} (100%)
> rename Documentation/devicetree/bindings/arm/bcm/{cygnus.txt =>
> brcm,cygnus.txt} (100%)
> rename Documentation/devicetree/bindings/bus/{bcma.txt => brcm,bus-axi.txt}
> (100%)
> rename Documentation/devicetree/bindings/clock/{bcm-kona-clock.txt =>
> brcm,kona-ccu.txt} (100%)
> rename Documentation/devicetree/bindings/dma/{bcm2835-dma.txt =>
> brcm,bcm2835-dma.txt} (100%)
> rename Documentation/devicetree/bindings/gpio/{gpio-bcm-kona.txt =>
> brcm,kona-gpio.txt} (100%)
> rename Documentation/devicetree/bindings/i2c/{i2c-bcm-kona.txt =>
> brcm,kona-i2c.txt} (100%)
> rename Documentation/devicetree/bindings/mfd/{bcm590xx.txt =>
> brcm,bcm59056.txt} (100%)
> rename Documentation/devicetree/bindings/mips/brcm/{bcm3384-intc.txt =>
> brcm,bcm3384-intc.txt} (100%)
> rename Documentation/devicetree/bindings/mips/brcm/{bmips.txt =>
> brcm,bmips.txt} (100%)
> rename Documentation/devicetree/bindings/mips/brcm/{cm-dsl.txt =>
> brcm,cm-dsl.txt} (100%)
> rename Documentation/devicetree/bindings/misc/{smc.txt => brcm,ko
Re: [PATCH v4 2/3] leds: ktd2692: add device tree bindings for ktd2692
On 03/25/2015 07:00 AM, Ingi Kim wrote:
This patch adds the device tree bindings for ktd2692 flash LEDs.
Add optional properties 'flash-timeout-us' to control flash timeout
and 'vin-supply' for flash-led regulator
Signed-off-by: Ingi Kim
---
.../devicetree/bindings/leds/leds-ktd2692.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
new file mode 100644
index 000..f78512f
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
@@ -0,0 +1,33 @@
+* Kinetic Technologies - KTD2692 Flash LED Driver
+
+KTD2692 is the ideal power solution for high-power flash LEDs.
+It uses ExpressWire single-wire programming for maximum flexibility.
+
+The ExpressWire interface through CTRL pin can control LED on/off and
+enable/disable the IC, Movie(max 1/3 of Flash current) / Flash mode current,
+Flash timeout, LVP(low voltage protection).
+
+Also, When the AUX pin is pulled high while CTRL pin is high,
+LED current will be ramped up to the flash-mode current level.
+
+Required properties:
+ - compatible: "kinetic,ktd2692"
+ - ctrl-gpio, aux-gpio : gpio pins in order control ktd2692 flash led.
+ There is an internal 300kOhm pull-down resistor at each pin
+ - vin-supply : "vin" LED supply (2.7V to 5.5V)
+ See Documentation/devicetree/bindings/regulator/regulator.txt
+
Above bindings are not that readable to me. Remove the tab spaces before
properties.
+Optional property:
+ - flash-timeout-us : Maximum flash timeout in microseconds.
+ flash timeout ranges from 0 to 1835000us and
+ default is 1049000us.
+
+Example:
+
+flash-led {
+ compatible = "kinetic,ktd2692";
+ ctrl-gpio = <&gpc0 1 0>;
+ aux-gpio = <&gpc0 2 0>;
+ flash-timeout-us = <1835000>;
+ vin-supply = <&vbat>;
+};
--
Varka Bhadram
--
To unsubscribe from this list: send the line "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] leds: Add ktd2692 flash LED driver
On 03/25/2015 07:00 AM, Ingi Kim wrote:
This patch adds a driver to support the ktd2692 flash LEDs.
ktd2692 can control flash current by ExpressWire interface.
Signed-off-by: Ingi Kim
---
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-ktd2692.c | 412
3 files changed, 422 insertions(+)
create mode 100644 drivers/leds/leds-ktd2692.c
(...)
+static int ktd2692_parse_dt(struct ktd2692_context *led, struct device *dev,
+ u32 *flash_timeout_us)
+{
+ struct device_node *np = dev->of_node;
+
Unnecessary one line space..
+ int ret;
+
+ led->ctrl_gpio = of_get_named_gpio(np, "ctrl-gpio", 0);
+ if (!gpio_is_valid(led->ctrl_gpio)) {
+ dev_err(dev, "no ctrl-gpio property found\n");
+ return -EINVAL;
+ }
+
+ led->aux_gpio = of_get_named_gpio(np, "aux-gpio", 0);
+ if (!gpio_is_valid(led->aux_gpio)) {
+ dev_err(dev, "no aux-gpio property found\n");
+ return -EINVAL;
+ }
+
+ ret = devm_gpio_request_one(dev, led->ctrl_gpio,
+ GPIOF_OPEN_SOURCE, "ctrl-gpio");
+ if (ret) {
+ dev_err(dev, "failed to request ctrl-gpio %d error %d\n",
+ led->ctrl_gpio, ret);
+ return ret;
+ }
+
+ ret = devm_gpio_request_one(dev, led->aux_gpio,
+ GPIOF_OPEN_SOURCE, "aux-gpio");
+ if (ret) {
+ dev_err(dev, "failed to request aux-gpio %d error %d\n",
+ led->aux_gpio, ret);
+ return ret;
+ }
+
+ ret = of_property_read_u32(np, "flash-timeout-us", flash_timeout_us);
+ /* default setting */
+ if (ret)
+ *flash_timeout_us = KTD2692_FLASH_MODE_TIMEOUT_DEFAULT_US;
+
+ return 0;
+}
+
+static const struct led_flash_ops flash_ops = {
+ .strobe_set = ktd2692_led_flash_strobe_set,
+ .timeout_set = ktd2692_led_flash_timeout_set,
+};
+
+static int ktd2692_probe(struct platform_device *pdev)
+{
+ struct ktd2692_context *led;
+ struct led_classdev *led_cdev;
+ struct led_classdev_flash *fled_cdev;
+ struct led_flash_setting flash_timeout;
+ u32 flash_timeout_us;
+ int ret;
+
+ led = devm_kzalloc(&pdev->dev, sizeof(*led), GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ if (!pdev->dev.of_node)
+ return -ENXIO;
+
Above operation dt related. So if you do that in ktd2692_parse_dt(), it will be
good
+ fled_cdev = &led->fled_cdev;
+ led_cdev = &fled_cdev->led_cdev;
+
+ ret = ktd2692_parse_dt(led, &pdev->dev, &flash_timeout_us);
+ if (ret)
+ return ret;
+
+ led->regulator = devm_regulator_get(&pdev->dev, "vin");
+ if (IS_ERR(led->regulator)) {
+ dev_err(&pdev->dev, "regulator get failed\n");
+ return PTR_ERR(led->regulator);
+ }
+
+ ktd2692_init_flash_timeout(flash_timeout_us, &flash_timeout);
+
+ fled_cdev->timeout = flash_timeout;
+ fled_cdev->ops = &flash_ops;
+
+ led_cdev->name = KTD2692_DEFAULT_NAME;
+ led_cdev->brightness_set = ktd2692_led_brightness_set;
+ led_cdev->brightness_set_sync = ktd2692_led_brightness_set_sync;
+ led_cdev->flags |= LED_CORE_SUSPENDRESUME;
+ led_cdev->flags |= LED_DEV_CAP_FLASH;
+
+ mutex_init(&led->lock);
+ INIT_WORK(&led->work_brightness_set, ktd2692_brightness_set_work);
+
+ platform_set_drvdata(pdev, led);
+
+ ret = led_classdev_flash_register(&pdev->dev, fled_cdev);
+ if (ret) {
+ dev_err(&pdev->dev, "can't register LED %s\n", led_cdev->name);
+ cancel_work_sync(&led->work_brightness_set);
Is the above API is correct to use in this place.?
cancel_work_sync — cancel a work and wait for it to finish...
Work is not yet scheduled..?
What about mutex destroy..?
+ return ret;
+ }
+
+ ktd2692_setup(led);
+ ktd2692_led_regulator_enable(led);
+
+ return 0;
+}
+
+static int ktd2692_remove(struct platform_device *pdev)
+{
+ struct ktd2692_context *led = platform_get_drvdata(pdev);
+
+ ktd2692_led_regulator_disable(led);
+ led_classdev_flash_unregister(&led->fled_cdev);
+ cancel_work_sync(&led->work_brightness_set);
+
+ mutex_destroy(&led->lock);
+
+ return 0;
+}
+
+static const struct of_device_id ktd2692_match[] = {
+ { .compatible = "kinetic,ktd2692", },
+ { /* sentinel */ },
+};
+
+static struct platform_driver ktd2692_driver = {
+ .driver = {
+ .name = "leds-ktd2692",
+ .of_match_table = ktd2692_match,
+ },
+ .probe = ktd2692_probe,
+ .remove = ktd2692_remove,
+};
+
+module_platform_driver(ktd2692_driver);
+
+MODULE
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi, On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote: > So you propose that the parent->child relationship is “control”? I.e. some > channel which allows to address some bus client (through ) and > control that devices. > > Makes sense. This is how i2c and spi clients are specified. > > > > > In the case of our GPS, it receives control over the serial connection from > > the UART, > > Ahem - does it? > > AFAIK the chip simply starts to emit NMEA records if powered on. > There is no command going over the serial interface to address it > or control it. Right, since GPS basically doesn't need any configuration/control. That's not true for other UART attached devices, though. > > also receives control via a GPIO to the on/off pin, and also needs > > a regulator to power the antenna. > > > > So should the parent be the uart, the on/off GPIO, or the regulator? > > > > I would much rather there wasn't a parent, and that each of these were > > listed > > as ad-hoc attribute assignments. But device-tree says there must be a > > parent > > (where possible), and the parent is the thing that is “primarily" in > > control. > > Well, IMHO the “parent” could also be the root. Representing the > whole board. > > Nevertheless, I doubt your rule that “ability to control” defines > the parent>child relation (see below). > > > > > I think the GPS is “primarily" a uart-attached device. > > But not in the same way as an I2C device. > > Especially the serial interface is not a bus and not used for > signalling and power control. It is payload data (only). Actually many I2C devices are also powered on/off via a GPIO and even use additional GPIOs for sending interrupts. Nevertheless they are normally identified as an I2C device. Also for non-GPS device the serial connection is used for controlling and configuring the device. > > So I propose a device-node which describes the GPS, which is a child of the > > UART, and explicitly identifies the GPIO it uses to power on/off, the > > regulator it uses to power the antenna, and how it receives "on or off" > > status indications from the GPS. > > The more I think about that, you have given good arguments *not* > to use the parent->child relationship for the UART interface of > the GPS. > > Let me give another example. The 3G Modem has 3 (or 4) interfaces: > 1. an USB-Interface for AT signalling and payload > 2. some GPIOs for power control. > 3. a PCM interface for digital voice. > 4. it might also have a serial interface as alternate AT command and (GPRS > low speed) payload. > > So which one is the most prominent or most important to make it a child of? > > If you use “control” you must make it a child of the USB phy and the serial > interface > which requires multiple inheritance… > > So I am not sure at all. None is IMHO prominent and unique enough to make it > a parent>child relation. > > Threrefore, I would be happy to see it as multiple children of /. For example > a > MFD with subnodes. This scenario has already been seen before and can happen for non-UART based devices (e.g. SPI + I2C). So far the decision was to postpone the discussion about this kind of devices until one of them appears. > > It is arguable that the "antenna" should be treated as a separate device - a > > child of the GPS - which controls the regulator and also provides a 'extcon' > > which reports whether an external GPS antenna is attached, or whether the > > internal on is in use. I haven't made the time to properly explore that > > issue yet. > > If you assume that parent>child relationship is about control (only). But if > it > is about data flow, there is a different concept in DT. For example the > CSI/DSI > (OMAP DSS) use the “port” concept. Yes, this is about data not going to the cpu / system memory. > This means that indeed parent>child is used for control, e.g. I2C > or SPI to tell the panel controller to switch on. well parent > child is not about power control, but about "primary" control. Some I2C/SPI devices have additional gpios for power control. > For example we have the GTA04 panel as a subnode of SPI (because SPI is a > bus and the panel is controlled through SPI). Other panels need no control > interface and are simply a child of /. Yes, some devices do not have an interface worth of being called "primary control" :) > The video stream and its connections are arranged through such ports. > For the video out management we have added our OPA362 video amplifier into > that video pipeline which starts at the VENC (Video encode) in the SoC, > goes through the OPA362 and ends in the connector (which has its own > node). All this is connected by references. The opa362 node itself is a child > of /: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98 > > So to summarize I now see exactly two cases where parent>child is used: > a) for componen
[PATCH v4 0/3] Add ktd2692 Flash LED driver using LED Flash class
This patch adds ktd2692 Flash LED driver with LED Flash class Change in v4: - Clean up the code - Modify binding documentation of ktd2692 Change in v3: - Clean up the code - Add aux gpio pin to control Flash LED Change in v2: - Introduction of LED Flash class as Jacek's comment - Supplement of binding documentation - Rename gpio control pin and remove unused pin - Add regulator for the Flash LED Ingi Kim (3): of: Add vendor prefix for Kinetic technologies leds: ktd2692: add device tree bindings for ktd2692 leds: Add ktd2692 flash LED driver .../devicetree/bindings/leds/leds-ktd2692.txt | 33 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/leds/Kconfig | 9 + drivers/leds/Makefile | 1 + drivers/leds/leds-ktd2692.c| 412 + 5 files changed, 456 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt create mode 100644 drivers/leds/leds-ktd2692.c -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] leds: ktd2692: add device tree bindings for ktd2692
This patch adds the device tree bindings for ktd2692 flash LEDs.
Add optional properties 'flash-timeout-us' to control flash timeout
and 'vin-supply' for flash-led regulator
Signed-off-by: Ingi Kim
---
.../devicetree/bindings/leds/leds-ktd2692.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
new file mode 100644
index 000..f78512f
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
@@ -0,0 +1,33 @@
+* Kinetic Technologies - KTD2692 Flash LED Driver
+
+KTD2692 is the ideal power solution for high-power flash LEDs.
+It uses ExpressWire single-wire programming for maximum flexibility.
+
+The ExpressWire interface through CTRL pin can control LED on/off and
+enable/disable the IC, Movie(max 1/3 of Flash current) / Flash mode current,
+Flash timeout, LVP(low voltage protection).
+
+Also, When the AUX pin is pulled high while CTRL pin is high,
+LED current will be ramped up to the flash-mode current level.
+
+Required properties:
+ - compatible: "kinetic,ktd2692"
+ - ctrl-gpio, aux-gpio : gpio pins in order control ktd2692 flash led.
+ There is an internal 300kOhm pull-down resistor at each pin
+ - vin-supply : "vin" LED supply (2.7V to 5.5V)
+ See Documentation/devicetree/bindings/regulator/regulator.txt
+
+Optional property:
+ - flash-timeout-us : Maximum flash timeout in microseconds.
+ flash timeout ranges from 0 to 1835000us and
+ default is 1049000us.
+
+Example:
+
+flash-led {
+ compatible = "kinetic,ktd2692";
+ ctrl-gpio = <&gpc0 1 0>;
+ aux-gpio = <&gpc0 2 0>;
+ flash-timeout-us = <1835000>;
+ vin-supply = <&vbat>;
+};
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] of: Add vendor prefix for Kinetic technologies
This patch adds vendor prefix for Kinetic technologies Signed-off-by: Ingi Kim Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389ca13..de9e126 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -98,6 +98,7 @@ isee ISEE 2007 S.L. isil Intersil karo Ka-Ro electronics GmbH keymileKeymile GmbH +kinetic Kinetic Technologies lacie LaCie lantiq Lantiq Semiconductor lenovo Lenovo Group Ltd. -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] leds: Add ktd2692 flash LED driver
This patch adds a driver to support the ktd2692 flash LEDs.
ktd2692 can control flash current by ExpressWire interface.
Signed-off-by: Ingi Kim
---
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-ktd2692.c | 412
3 files changed, 422 insertions(+)
create mode 100644 drivers/leds/leds-ktd2692.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 25b320d..9311cfc4 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -498,6 +498,15 @@ config LEDS_MENF21BMC
This driver can also be built as a module. If so the module
will be called leds-menf21bmc.
+config LEDS_KTD2692
+ tristate "Flash LED support for the KTD2692 Driver"
+ depends on LEDS_CLASS_FLASH && GPIOLIB
+ help
+ This option enables support for the KTD2692 connected through
+ ExpressWire Interface. Say Y to enabled these.
+ It depends on LEDS_CLASS_FLASH for using flash led (strobe) and
+ GPIOLIB for using gpio pin to control Expresswire interface
+
comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
(HID_THINGM)"
config LEDS_BLINKM
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index cbba921..289513b 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
+obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-ktd2692.c b/drivers/leds/leds-ktd2692.c
new file mode 100644
index 000..c31ec9d
--- /dev/null
+++ b/drivers/leds/leds-ktd2692.c
@@ -0,0 +1,412 @@
+/*
+ * LED driver : leds-ktd2692.c
+ *
+ * Copyright (C) 2015 Samsung Electronics
+ * 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
+#include
+#include
+#include
+
+#define GET_BIT(bit, val) (((val) >> (bit)) & 0x01)
+
+/* Value related the flash mode */
+#define KTD2692_FLASH_MODE_TIMEOUT_LEVELS 8
+#define KTD2692_FLASH_MODE_TIMEOUT_DISABLE 0
+#define KTD2692_FLASH_MODE_TIMEOUT_DEFAULT_US 1049000
+#define KTD2692_FLASH_MODE_TIMEOUT_MAX_US 1835000
+#define KTD2692_FLASH_MODE_CURR_PERCENT(x) (((x) * 16) / 100)
+
+/* Macro for getting offset of flash timeout */
+#define GET_TIMEOUT_OFFSET(timeout, step) ((timeout) / (step))
+
+/* Adjust a multiple of brightness */
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_16(x) (((x) >> 4) & 0x0F)
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_8(x) (((x) >> 5) & 0x0F)
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_4(x) (((x) >> 6) & 0x0F)
+
+/* Base register address */
+#define KTD2692_REG_LVP_BASE 0x00
+#define KTD2692_REG_FLASH_TIMEOUT_BASE 0x20
+#define KTD2692_REG_MIN_CURRENT_SET_BASE 0x40
+#define KTD2692_REG_MOVIE_CURRENT_BASE 0x60
+#define KTD2692_REG_FLASH_CURRENT_BASE 0x80
+#define KTD2692_REG_MODE_BASE 0xA0
+
+/* Set bit coding time for expresswire interface */
+#define KTD2692_TIME_RESET_US 700
+#define KTD2692_TIME_DATA_START_TIME_US10
+#define KTD2692_TIME_HIGH_END_OF_DATA_US 350
+#define KTD2692_TIME_LOW_END_OF_DATA_US10
+#define KTD2692_TIME_SHORT_BITSET_US 4
+#define KTD2692_TIME_LONG_BITSET_US12
+
+/* KTD2692 default length of name */
+#define KTD2692_NAME_LENGTH20
+
+/* KTD2692 default name */
+#define KTD2692_DEFAULT_NAME "ktd2692"
+
+enum ktd2692_bitset {
+ KTD2692_LOW = 0,
+ KTD2692_HIGH,
+};
+
+/* Movie / Flash Mode Control */
+enum ktd2692_led_mode {
+ KTD2692_MODE_DISABLE = 0, /* default */
+ KTD2692_MODE_MOVIE,
+ KTD2692_MODE_FLASH,
+};
+
+struct ktd2692_context {
+ /* Related LED Flash class device */
+ struct led_classdev_flash fled_cdev;
+
+ struct mutex lock;
+ struct regulator *regulator;
+ struct work_struct work_brightness_set;
+
+ int aux_gpio;
+ int ctrl_gpio;
+
+ enum ktd2692_led_mode mode;
+ enum led_brightness torch_brightness;
+};
+
+static struct ktd2692_context *fled_cdev_to_led(
+ struct led_classdev_flash *fled_cdev)
+{
+ return container_of(fled_cdev, struct ktd2692_context, fled_cdev);
+}
+
+static void ktd2692_led_regulator_enable(struct ktd2692_context *led)
+{
+ struct led_classdev_flash *fled_cdev = &led->fled_cdev;
+ struct led_classdev *led_cdev = &fled_
Re: [PATCH v1 09/11] DT: Add documentation for exynos4-is 'flashes' property
Hi Jacek, On Fri, Mar 20, 2015 at 04:03:29PM +0100, Jacek Anaszewski wrote: > This patch adds a description of 'flashes' property > to the samsung-fimc.txt. > > Signed-off-by: Jacek Anaszewski > Acked-by: Kyungmin Park > Cc: Sylwester Nawrocki > --- > .../devicetree/bindings/media/samsung-fimc.txt |8 > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt > b/Documentation/devicetree/bindings/media/samsung-fimc.txt > index 922d6f8..cb0e263 100644 > --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt > +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt > @@ -40,6 +40,13 @@ should be inactive. For the "active-a" state the camera > port A must be activated > and the port B deactivated and for the state "active-b" it should be the > other > way around. > > +Optional properties: > + > +- flashes - Array of phandles to the flash LEDs that can be controlled by the > + sub-devices contained in this media device. Flash LED is > + represented by a child node of a flash LED device This should be in Documentation/devicetree/bindings/media/video-interfaces.txt. Should flash devices be associated with sensors somehow rather than ISPs? That's how they commonly are arranged, however that doesn't limit placing them in silly places. I'm not necessarily saying the flashes-property should be present in sensor's DT nodes, but it'd be good to be able to make the association if it's there. > + (see Documentation/devicetree/bindings/leds/common.txt). > + > The 'camera' node must include at least one 'fimc' child node. > > > @@ -166,6 +173,7 @@ Example: > clock-output-names = "cam_a_clkout", "cam_b_clkout"; > pinctrl-names = "default"; > pinctrl-0 = <&cam_port_a_clk_active>; > + flashes = <&camera_flash>, <&system_torch>; > status = "okay"; > #address-cells = <1>; > #size-cells = <1>; There will be other kind of devices that have somewhat similar relationship. They just haven't been defined yet. Lens controllers or EEPROM for instance. The two are an integral part of a module, something which is not modelled in DT in any way, but perhaps should be. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/5] clk: shmobile: rcar-gen2: Add CPG Clock Domain support
Hi Mike, On Tue, Mar 24, 2015 at 04:00:36PM -0700, Michael Turquette wrote: > Quoting Geert Uytterhoeven (2015-03-18 12:46:53) > > Add Clock Domain support to the R-Car Gen2 Clock Pulse Generator (CPG) > > driver using the generic PM Domain. This allows to power-manage the > > module clocks of SoC devices that are part of the CPG Clock Domain using > > Runtime PM, or for system suspend/resume. > > > > SoC devices that are part of the CPG Clock Domain and can be > > power-managed through their primary clock should be tagged in DT with a > > proper "power-domains" property. > > > > Signed-off-by: Geert Uytterhoeven > > Looks good to me. Which tree do you want this patch to go through? My tree seems reasonable from my point of view. Though at this point it would be targeted at v4.2. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7] ARM: dts: Add HS400 support for exynos5420 and exynos5800
Alim Akhtar wrote:
>
> Gentle Ping !!
>
Thanks ;-)
>
> On Wed, Mar 18, 2015 at 4:50 PM, Alim Akhtar wrote:
> > From: Seungwon Jeon
> >
> > HS400 timing values are added for SMDK5420, exynos5420-peach-pit
> > and exynos5800-peach-pi boards.
> > This also adds RCLK GPIO line, this gpio should be in pull-down
> > state.
> > This also enables HS400 on peach-pi and this updates the clock frequency
> > to 800MHz to be set as input clock to controller.
> >
> > Signed-off-by: Seungwon Jeon
> > Signed-off-by: Alim Akhtar
> > [Alim: addressed review comments]
> > Acked-by: Jaehoon Chung
> > ---
> > Changes in V7:
> > Add back bus1 pin, which was removed during rebase in v6
> > as rightly pointed out by Javier[1].
> >
> > Changes in V6:
> > Rebased on kukjin's for-next branch[0]
> > (commit: 77105c8 Merge branch 'v4.0-samsung-fixes-2' into for-next)
> >
> > [0]: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> > [1]: http://www.spinics.net/lists/arm-kernel/msg406618.html
> >
> > arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 +++-
> > arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 7 +++
> > arch/arm/boot/dts/exynos5420-smdk5420.dts | 5 -
> > arch/arm/boot/dts/exynos5800-peach-pi.dts | 7 +--
> > 4 files changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> > b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> > index 3f4e2fe..0788d08 100644
> > --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> > +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> > @@ -699,8 +699,10 @@
> > samsung,dw-mshc-ciu-div = <3>;
> > samsung,dw-mshc-sdr-timing = <0 4>;
> > samsung,dw-mshc-ddr-timing = <0 2>;
> > + samsung,dw-mshc-hs400-timing = <0 2>;
> > + samsung,read-strobe-delay = <90>;
> > pinctrl-names = "default";
> > - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8>;
> > + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
> > &sd0_rclk>;
> > bus-width = <8>;
> > };
> >
> > diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> > b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> > index ba686e4..8b15316 100644
> > --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> > +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> > @@ -201,6 +201,13 @@
> > samsung,pin-drv = <3>;
> > };
> >
> > + sd0_rclk: sd0-rclk {
> > + samsung,pins = "gpc0-7";
> > + samsung,pin-function = <2>;
> > + samsung,pin-pud = <1>;
> > + samsung,pin-drv = <3>;
> > + };
> > +
> > sd1_cmd: sd1-cmd {
> > samsung,pins = "gpc1-1";
> > samsung,pin-function = <2>;
> > diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> > b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> > index 7a56852..9103f23 100644
> > --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> > +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> > @@ -80,8 +80,11 @@
> > samsung,dw-mshc-ciu-div = <3>;
> > samsung,dw-mshc-sdr-timing = <0 4>;
> > samsung,dw-mshc-ddr-timing = <0 2>;
> > + samsung,dw-mshc-hs400-timing = <0 2>;
> > + samsung,read-strobe-delay = <90>;
> > pinctrl-names = "default";
> > - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4
> > &sd0_bus8>;
> > + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
> > +&sd0_rclk>;
> > bus-width = <8>;
> > cap-mmc-highspeed;
> > };
> > diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> > b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> > index c833bac..412f41d 100644
> > --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> > +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> > @@ -654,15 +654,18 @@
> > num-slots = <1>;
> > broken-cd;
> > mmc-hs200-1_8v;
> > + mmc-hs400-1_8v;
> > cap-mmc-highspeed;
> > non-removable;
> > card-detect-delay = <200>;
> > - clock-frequency = <4>;
> > + clock-frequency = <8>;
> > samsung,dw-mshc-ciu-div = <3>;
> > samsung,dw-mshc-sdr-timing = <0 4>;
> > samsung,dw-mshc-ddr-timing = <0 2>;
> > + samsung,dw-mshc-hs400-timing = <0 2>;
> > + samsung,read-strobe-delay = <90>;
> > pinctrl-names = "default";
> > - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8>;
> > + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
> > &sd0_rclk>;
> > bus-width = <8>;
> > };
> >
> > --
Applied.
- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vge
Re: [PATCH v1 07/11] media: Add registration helpers for V4L2 flash sub-devices
Hi Jacek, On Tue, Mar 24, 2015 at 09:35:05AM +0100, Jacek Anaszewski wrote: ... > diff --git a/drivers/media/v4l2-core/v4l2-flash.c > b/drivers/media/v4l2-core/v4l2-flash.c > new file mode 100644 > index 000..804c2e4 > --- /dev/null > +++ b/drivers/media/v4l2-core/v4l2-flash.c > @@ -0,0 +1,607 @@ > +/* > + * V4L2 Flash LED sub-device registration helpers. > + * > + * Copyright (C) 2015 Samsung Electronics Co., Ltd > + * Author: Jacek Anaszewski > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "../../leds/leds.h" > >>> > >>>What do you need from leds.h? Shouldn't this be e.g. under include/linux > >>>instead? > > I need led_trigger_remove function. It's exported but defined in what is obviously a private header file to the framework. Could it be moved to include/linux/leds.h instead? -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 02/11] DT: Add documentation for the mfd Maxim max77693
Hi Jacek, On Mon, Mar 23, 2015 at 10:54:11AM +0100, Jacek Anaszewski wrote: > Hi Sakari, > > On 03/21/2015 11:49 PM, Sakari Ailus wrote: > >Hi Jacek, > > > >On Fri, Mar 20, 2015 at 04:03:22PM +0100, Jacek Anaszewski wrote: > >>+Optional properties of the LED child node: > >>+- label : see Documentation/devicetree/bindings/leds/common.txt > > > >I'm still not comfortable using the label field as-is as the entity name in > >the later patches, there's one important problem: it is not guaranteed to be > >unique in the system. > > I don't use it as-is in my patches. For max77603-led the i2c adapter id > and client address is added to it, and for aat1290 there is '_n' suffix > added. Nonetheless I didn't notice that the patch [1] was already > merged. It checks if a LED class device with given name isn't already > registered and adds a '_n" suffix if there was any. If it was exported > I could use it in the leds-aat1290 driver and avoid depending on the > static variable. > > Whereas for I2C devices the problem doesn't exist (it is guaranteed that > no more than one I2C client with an address can be present on the > same bus), for devices driven through GPIOs we haven't stable unique > identifier. > > I thought that we agreed on #v4l about adding numerical postfixes > in case of such devices. > > >Do you think this could be added to > >Documentation/devicetree/bindings/leds/common.txt, with perhaps enforcing it > >in the LED framework? Bryan, what do you think? > > The patch [1] seems to address the issue. Replied to that, you're cc'd. For this patch: Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Documentation: devicetree: m25p80: add "nor-jedec" binding
On Sun, Mar 22, 2015 at 12:30:05AM +0100, Rafał Miłecki wrote: > On 20 March 2015 at 20:12, Brian Norris wrote: > > Yes, and that is an eventual goal I suppose, but the current list is > > excessive and is most likely not currently relied on by any one. So I > > don't just want to C&P the entire list into this binding immediately. > > > > I guess my plan looks like this: > > > > 1. add "nor-jedec" binding, to provide lowest common denominator binding > > (this series) > > > > 2. stop adding to the m25p_ids[] table unless necessary (enabled by this > > series) > > > > 3. gauge whether we can remove certain entries from m25p_ids[] (e.g., if > > they were only used in platform_data, not DT; or if they were very > > recently added just to synchronize with spi-nor.c) > > Why we can't remove (slowly) all entries from m25p_ids that don't need > any extra handling? > > If we'll have DT with > "spansion,m25p80", "nor-jedec" > and then m25p80.c will handle both: "m25p80" and "nor-jedec" without > any difference, what's the point of keeping "m25p80" entry? ABI stability. A lot of DTBs might be using m25p80 already, and they aren't supposed to have to update just because SW decided to drop them. But see [1] for the official word on ABI stability. I think that leaves room for removing most/all of these eventually. Brian [1] Documentation/devicetree/bindings/ABI.txt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 07/11] media: Add registration helpers for V4L2 flash sub-devices
Hi Jacek,
One more comment on this one:
On Fri, Mar 20, 2015 at 04:03:27PM +0100, Jacek Anaszewski wrote:
...
> +struct v4l2_flash *v4l2_flash_init(struct led_classdev_flash *fled_cdev,
> +const struct v4l2_flash_ops *ops,
> +struct v4l2_flash_ctrl_config *config)
> +{
> + struct v4l2_flash *v4l2_flash;
> + struct led_classdev *led_cdev = &fled_cdev->led_cdev;
> + struct v4l2_subdev *sd;
> + int ret;
> +
> + if (!fled_cdev || !ops || !config)
> + return ERR_PTR(-EINVAL);
> +
> + v4l2_flash = devm_kzalloc(led_cdev->dev, sizeof(*v4l2_flash),
> + GFP_KERNEL);
> + if (!v4l2_flash)
> + return ERR_PTR(-ENOMEM);
> +
> + sd = &v4l2_flash->sd;
> + v4l2_flash->fled_cdev = fled_cdev;
> + v4l2_flash->ops = ops;
> + sd->dev = led_cdev->dev;
> + v4l2_subdev_init(sd, &v4l2_flash_subdev_ops);
> + sd->internal_ops = &v4l2_flash_subdev_internal_ops;
> + sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> + strlcpy(sd->name, config->dev_name, sizeof(sd->name));
> +
> + ret = media_entity_init(&sd->entity, 0, NULL, 0);
> + if (ret < 0)
> + return ERR_PTR(ret);
> +
> + sd->entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
> +
> + ret = v4l2_flash_init_controls(v4l2_flash, config);
> + if (ret < 0)
> + return ERR_PTR(ret);
> +
> + of_node_get(led_cdev->dev->of_node);
> +
> + ret = v4l2_async_register_subdev(sd);
> + if (ret < 0)
> + goto err_async_register_sd;
> +
> + return v4l2_flash;
> +
> +err_async_register_sd:
> + of_node_put(led_cdev->dev->of_node);
> + v4l2_ctrl_handler_free(sd->ctrl_handler);
> + media_entity_cleanup(&sd->entity);
> +
> + return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(v4l2_flash_init);
> +
> +void v4l2_flash_release(struct v4l2_flash *v4l2_flash)
> +{
> + struct v4l2_subdev *sd = &v4l2_flash->sd;
> + struct led_classdev *led_cdev = &v4l2_flash->fled_cdev->led_cdev;
> +
> + v4l2_async_unregister_subdev(sd);
> + of_node_put(led_cdev->dev->of_node);
> + v4l2_ctrl_handler_free(sd->ctrl_handler);
> + media_entity_cleanup(&sd->entity);
> +}
> +EXPORT_SYMBOL_GPL(v4l2_flash_release);
It'd be very nice if v4l2_flash_release() could graciously behave with NULL
or negative error code as an argument, such as those produced by
v4l2_flash_init(). This makes error handling a lot easier in drivers.
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/5] power: max77843_charger: Add Max77843 charger device driver
On 03/24/2015 05:38 PM, Krzysztof Kozlowski wrote: > 2015-03-24 9:01 GMT+01:00 Beomho Seo : >> On 03/10/2015 10:44 PM, Beomho Seo wrote: >>> On 03/09/2015 09:13 PM, Krzysztof Kozlowski wrote: On pon, 2015-03-09 at 20:46 +0900, Beomho Seo wrote: > On 03/09/2015 08:02 PM, Krzysztof Kozlowski wrote: >> 2015-03-09 1:35 GMT+01:00 Beomho Seo : >>> On 03/08/2015 05:13 AM, Sebastian Reichel wrote: On Mon, Mar 02, 2015 at 07:10:35PM +0900, Jaewon Kim wrote: > From: Beomho Seo > > This patch adds device driver of max77843 charger. This driver provide > initialize each charging mode(e.g. fast charge, top-off mode and > constant > charging mode so on.). Additionally, control charging paramters to use > i2c interface. > > Cc: Sebastian Reichel > Signed-off-by: Beomho Seo Reviewed-By: Sebastian Reichel I can't take it as is, since it depends on the private header file of PATCHv1. -- Sebastian >>> >>> This patch reviewed by Sebastian. >>> Could you Please merge that your git tree ? >> >> Hi, >> >> ... and again we are adding a new driver for very similar chipset to >> already supported. I looked at spec and the charger's registers are >> almost the same as for max77693. Their layout and addresses are the >> same. I see some minor differences, probably the most important would >> be different values current (fast-charge, top-off). But still 90% of >> registers are the same... Do we really have to add new driver? >> >> Best regards, >> Krzysztof >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-input" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > Hi, > > Thank you for your comment. As you say, both chip set are similar. > But new driver need for support max77843. It is support different below > - Provide Battery presence information. Another set of power supply properties could be added for that chip. This way the get_property() function would be the same but actually the POWER_SUPPLY_PROP_PRESENT won't be called for max77693. > - Can OTG FET control. Where the OTG FET feature is it enabled in your driver? I couldn't find it. >>> >>> Sorry. This driver don't control OTG FET feature. >>> > - Bigger Fast charge current, Top Off current Threshold selection. > - Various and bigger OTG current limitation. > - Bigger primary charger termination voltage setting. > - Different maximum input current limit selection(Different step). Yes, I mentioned some of these differences (the Fast/top-off differences). These are differences in values so it does not require new driver. There is need to develop new driver just to support different current (3.0 A instead of 2.1 A) or voltage threshold. >>> >>> They are different charging current, OTG current limitation, top off >>> current, >>> charging limitation value. In case OTG current limitation different not >>> limitation value but using register bit(max77843 use[7:6] max77693 use[7] >>> bit only). Even if this driver not support all feature, some register >>> different with max77693(support value, use register bit). >>> >>> If this driver will combined with max77693 may even be beneficial for >>> new Maxim driver. But the present, this driver is related with >>> max77843 core driver and max77843-regulator. So I hope this driver >>> merge first. And then will extend two driver(max77843 charger and max77693 >>> charger). > > I still prefer merging common drivers into one instead of creating > some more of them. > However I understand your point and I am not entirely opposed against. > Especially that you invested quite a bit of time for developing this > and my feedback was quite late. To summarize I am fine with your > approach. > > Best regards, > Krzysztof > Then, Can I request merge this patch ? Best regards, Beomho -- To unsubscribe from this list: send the line "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 8/9] eeprom: qfprom: Add bindings for qfprom
On Tue, Mar 24, 2015 at 11:31 PM, Srinivas Kandagatla
wrote:
> This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
> is based on simple eeprom framework.
>
> Signed-off-by: Srinivas Kandagatla
> ---
> .../devicetree/bindings/eeprom/qfprom.txt | 23
> ++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/eeprom/qfprom.txt
>
> diff --git a/Documentation/devicetree/bindings/eeprom/qfprom.txt
> b/Documentation/devicetree/bindings/eeprom/qfprom.txt
> new file mode 100644
> index 000..d5baed6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/eeprom/qfprom.txt
> @@ -0,0 +1,23 @@
> += Qualcomm QFPROM device tree bindings =
> +
> +This binding is intended to represent QFPROM which is found in most QCOM
> SOCs.
> +
> +Required properties:
> +- compatible: should be "qcom,qfprom"
> +- reg: Should contain registers location and length
> +
> += Data cells =
> +Are child nodes of qfprom, bindings of which as described in
> +bindings/eeprom/eeprom.txt
> +
> +Example:
> +
> + qfprom: qfprom@0070 {
> + compatible = "qcom,qfprom";
> + reg = <0x0070 0x1000>;
The qfprom block starts at 0x70 and is 0x8000 long.
The registers at the beginning of this block are raw R/W fuse bits and
should not be read directly. Instead there is an ecc corrected shadow
copy of these registers at 0x4000.
> + ...
> + /* Data cells */
> + tsens_calibration: calib@404 {
> + reg = <0x404 0x10>;
> + };
> + };
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/9] arm64: Add the support for new Exynos5433 SoC
Dear Kukjin,
On 03/24/2015 05:09 PM, Kukjin Kim wrote:
> Chanwoo Choi wrote:
>>
>> Dear Kukjin,
>>
> Hi,
>
>> Could you please pick or review this patch-set?
>>
> Sorry for late response and honestly I was looking at the review in ml ;-)
>
> Anyway I have no objection on this series except using ARCH_EXYNOS for clock
> stuff in other series for exynos5433 but I agree we don't have other solution
> at this moment.
>
> I'll queue this series.
Thanks for your apply.
Best Regards,
Chanwoo Choi
>
> Thanks,
> Kukjin
>
>> Best Regards,
>> Chanwoo Choi
>>
>> On Wed, Mar 18, 2015 at 9:17 AM, Chanwoo Choi wrote:
>>> This patchset adds new 64-bit Exynos5433 Samsung SoC which contains quad
>>> Cortex-A57 and quad Cortex-A53. It is desigend with the 20nm low power
>>> process.
>>>
>>> Depends on:
>>> - This patch-set has the dependency on Exynos5433 clock driver[1] and
>>> pinctrl driver[2].
>>> The Exynos5433 clock controller patch-set[1] was merged by Michael
>>> Turquette.
>>> and Exynos5433's pinctrl patch[2] was merged by Linus Walleij. Exynos5433's
>>> TMU patch[3]
>>> will be refactoring without feature update.
>>>
>>> [1]
>> http://git.linaro.org/people/mike.turquette/linux.git/commit/cc91909b9683c834485fd0627708c81d9398bf02
>>> [2]
>>> https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-
>> next&id=3c5ecc9ed3537846fd95e8f288d6d6968075879f
>>> [3] [PATCH 0/3] thermal: exynos: Add support for Exynos5433 TMU
>>> - https://lkml.org/lkml/2015/2/26/234
>>>
>>> Changelog:
>>>
>>> Changes fromv v6:
>>> (https://lkml.org/lkml/2015/3/9/1036)
>>> - Fix wrong base address of CMU_MSCL dt node (0x105d -> 0x150d)
>>> - Adjust the length of memory mapped region for all clock domains
>>>
>>> Changes from v5:
>>> (https://lkml.org/lkml/2015/3/5/27)
>>> - Move 'timer' dt node under root node by Mark Rutland's comment
>>>
>>> Changes from v4:
>>> (https://lkml.org/lkml/2015/2/24/2)
>>> - Rebased it on Linux 4.0-rc2
>>> - Remove CONFIG_ARCH_EXYNOS5433 configuration by Arnd Bergmann's comment
>>> - Move 'aliases' dt node from SoC dtsi to board dts file by Arnd Bergmann's
>>> comment
>>> - Add Exynos5433 TMU patches which got the Lukasz Majewski's reviewed
>>> message
>>>
>>> Changes from v3:
>>> (https://lkml.org/lkml/2015/2/12/65)
>>> - Rebased it on Linux 4.0-rc1.
>>> - Remove ARM_GIC and ARM_AMBA dependency because CONFIG_ARM64 already
>>> included them.
>>>
>>> Changes from v2:
>>> (https://lkml.org/lkml/2014/12/2/134)
>>> : Fix the range of GICC memory map (0x1000 -> 0x2000)
>>> : Fix address space of 'range' property under 'soc' node
>>> : Add ADMA / I2S dt node for sound playback/capture
>>> - Select ARM_AMBA/ARM_GIC/HAVE_S3C_RTC for Exynos5433 in arch/arm64/Kconfig
>>> - Send separate patch-set for Exynos5433 clock controller[1][2] and
>>> pinctrl[3]
>>>
>>> Changes from v1:
>>> (https://lkml.org/lkml/2014/11/27/92)
>>> - Merge two patches (patch2, patch3) to solve incomplete description
>>> - Exynos5433 Clock driver
>>> : Fix wrong register and code clean by using space instead of tab
>>> : Add CLK_IGNORE_UNUSED flag to pclk_sysreg_* clock for accessing system
>>> control register
>>> : Remove duplicate definition on the patch for CMU_BUS{0|1|2} domain
>>> - Exynos5433 SoC DTS
>>> : Remove un-supported properties of arch_timer
>>> : Remove 'clock-frequency' property from 'cpus' dt node
>>> : Fix interrupt type from edge rising triggering to level high triggering
>>>because Cortex-A53/A57 use level triggering.
>>> : Fix defult address-size/size-celss from 1 to 2 because Exynos5433 is
>>> 64-bit SoC
>>> : Modify 'fin_pll' dt node to remove un-needed and ugly code
>>> : Move 'chipid' dt node under 'soc'
>>> : Use lowercase on all case in exynos5433.dtsi
>>> : Add PSCI dt node for secondary cpu boot
>>> : Add 'samsung,exynos5433' compatible to MCT dt node
>>> - Divide pinctrl patch from this patchset
>>> - Add new following patches:
>>> : clocksource: exynos_mct: Add the support for Exynos 64bit SoC
>>> : arm64: Enable Exynos5433 SoC in the defconfig
>>> -
>>>
>>> Chanwoo Choi (6):
>>> arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
>>> arm64: dts: exynos: Add SPI/PDMA dt node for Exynos5433
>>> arm64: dts: exynos: Add PMU dt node for Exynos5433
>>> arm64: dts: exynos: Add RTC and ADC dt node for Exynos5433 SoC
>>> arm64: dts: exynos: Add TMU sensor dt node for Exynos5433 SoC
>>> arm64: dts: exynos: Add thermal-zones dt node for Exynos5433 SoC
>>>
>>> Inha Song (2):
>>> arm64: dts: exynos: Add ADMA dt node for Exynos5433 SoC
>>> arm64: dts: exynos: Add I2S dt node for Exynos5433 SoC
>>>
>>> Jaehoon Chung (1):
>>> arm64: dts: exynos: Add MSHC dt node for Exynos5433
>>>
>>> .../devicetree/bindings/arm/samsung/pmu.txt| 1 +
>>> arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698 +++
>>> .../dts/exynos/exynos5433-tmu-sensor-conf.dtsi
Re: [PATCH v3 1/9] regmap: Introduce regmap_get_max_register.
On Tue, 2015-03-24 at 23:05 +, Srinivas Kandagatla wrote:
> On 24/03/15 22:36, Mark Brown wrote:
> >> +int regmap_get_max_register(struct regmap *map)
> >> +{
> >> + return map->max_register ? : -EINVAL;
> >> +}
> >
> > Please write the logic out properly, don't abuse the ternery operator.
> Am happy to change it to your preference in next version, but this GNU
> extensions widely used in the kernel
>
> $ grep -rR "return.*? :" ./linux | wc -l
> 115
Double that when you add the ?: variants
$ git grep -E "return.*\?\s*:" | wc -l
253
There are ~530 uses like:
return ? :
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/9] regmap: Introduce regmap_get_reg_stride.
On 24/03/15 22:37, Mark Brown wrote: On Tue, Mar 24, 2015 at 10:30:00PM +, Srinivas Kandagatla wrote: + /* regmap_get_reg_stride(): Report the register address stride + * + * Report the register address stride, mainly intended to for use by + * generic infrastructure built on top of regmap. + */ +int regmap_get_reg_stride(struct regmap *map) Please fix the indentation for the comment block and add kerneldoc for the argument. This is an exported function so it should also be /** not /* My bad.. I will fix it in next version. -- To unsubscribe from this list: send the line "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/9] regmap: Introduce regmap_get_max_register.
On 24/03/15 22:36, Mark Brown wrote:
On Tue, Mar 24, 2015 at 10:29:39PM +, Srinivas Kandagatla wrote:
This patch introduces regmap_get_max_register() function which would be
used by the infrastructures like eeprom framework built on top of
regmap.
In what way would it be used?
Its used in 2 purposes
1> It is used for sanity check purposes of the register ranges provided
via DT/non-DT eeprom data cells.
2> To stop user reading when eeprom binary from /sys/class/eeprom/*/eeprom
+int regmap_get_max_register(struct regmap *map)
+{
+ return map->max_register ? : -EINVAL;
+}
Please write the logic out properly, don't abuse the ternery operator.
Am happy to change it to your preference in next version, but this GNU
extensions widely used in the kernel
$ grep -rR "return.*? :" ./linux | wc -l
115
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/5] clk: shmobile: rcar-gen2: Add CPG Clock Domain support
Quoting Geert Uytterhoeven (2015-03-18 12:46:53)
> Add Clock Domain support to the R-Car Gen2 Clock Pulse Generator (CPG)
> driver using the generic PM Domain. This allows to power-manage the
> module clocks of SoC devices that are part of the CPG Clock Domain using
> Runtime PM, or for system suspend/resume.
>
> SoC devices that are part of the CPG Clock Domain and can be
> power-managed through their primary clock should be tagged in DT with a
> proper "power-domains" property.
>
> Signed-off-by: Geert Uytterhoeven
Looks good to me. Which tree do you want this patch to go through?
Regards,
Mike
> ---
> .../clock/renesas,rcar-gen2-cpg-clocks.txt | 26 -
> arch/arm/mach-shmobile/Kconfig | 1 +
> drivers/clk/shmobile/clk-rcar-gen2.c | 63
> ++
> 3 files changed, 88 insertions(+), 2 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> b/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> index b02944fba9de4f86..fc013f225a348929 100644
> --- a/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> +++ b/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> @@ -2,6 +2,8 @@
>
> The CPG generates core clocks for the R-Car Gen2 SoCs. It includes three PLLs
> and several fixed ratio dividers.
> +The CPG also provides a Clock Domain for SoC devices, in combination with the
> +CPG Module Stop (MSTP) Clocks.
>
> Required Properties:
>
> @@ -20,10 +22,18 @@ Required Properties:
>- clock-output-names: The names of the clocks. Supported clocks are "main",
> "pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1", "z", "rcan",
> and
> "adsp"
> + - #power-domain-cells: Must be 0
>
> +SoC devices that are part of the CPG Clock Domain and can be power-managed
> +through their primary clock should refer to the CPG device node in their
> +"power-domains" property, as documented by the generic PM domain bindings in
> +Documentation/devicetree/bindings/power/power_domain.txt.
>
> -Example
>
> +
> +Examples
> +
> +
> + - CPG device node:
>
> cpg_clocks: cpg_clocks@e615 {
> compatible = "renesas,r8a7790-cpg-clocks",
> @@ -34,4 +44,16 @@ Example
> clock-output-names = "main", "pll0, "pll1", "pll3",
> "lb", "qspi", "sdh", "sd0", "sd1", "z",
> "rcan", "adsp";
> + #power-domain-cells = <0>;
> + };
> +
> +
> + - CPG Clock Domain member node:
> +
> + thermal@e61f {
> + compatible = "renesas,thermal-r8a7790",
> "renesas,rcar-thermal";
> + reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
> + interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&mstp5_clks R8A7790_CLK_THERMAL>;
> + power-domains = <&cpg_clocks>;
> };
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 0fb484221c90e0eb..048101a3253c52de 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -4,6 +4,7 @@ config ARCH_SHMOBILE
>
> config PM_RCAR
> bool
> + select PM_GENERIC_DOMAINS
>
> config PM_RMOBILE
> bool
> diff --git a/drivers/clk/shmobile/clk-rcar-gen2.c
> b/drivers/clk/shmobile/clk-rcar-gen2.c
> index acfb6d7dbd6bc049..b54439d3722a13ad 100644
> --- a/drivers/clk/shmobile/clk-rcar-gen2.c
> +++ b/drivers/clk/shmobile/clk-rcar-gen2.c
> @@ -18,6 +18,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
>
> struct rcar_gen2_cpg {
> @@ -364,6 +366,65 @@ rcar_gen2_cpg_register_clock(struct device_node *np,
> struct rcar_gen2_cpg *cpg,
> 4, 0, table, &cpg->lock);
> }
>
> +#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
> +static int cpg_pd_attach_dev(struct generic_pm_domain *domain,
> +struct device *dev)
> +{
> + int error;
> +
> + error = pm_clk_create(dev);
> + if (error) {
> + dev_err(dev, "pm_clk_create failed %d\n", error);
> + return error;
> + }
> +
> + error = pm_clk_add(dev, NULL);
> + if (error) {
> + dev_err(dev, "pm_clk_add failed %d\n", error);
> + goto fail;
> + }
> +
> + return 0;
> +
> +fail:
> + pm_clk_destroy(dev);
> + return error;
> +}
> +
> +static void cpg_pd_detach_dev(struct generic_pm_domain *domain,
> + struct device *dev)
> +{
> + pm_clk_destroy(dev);
> +}
> +
> +static void __init rcar_gen2_cpg_add_pm_domain(struct device_node *np)
> +{
> + struct generic_pm_domain *pd;
> + u32 ncells;
> +
> + if (of_property_read_u32(np, "#power-domain-cells", &ncells)) {
> + pr_warn("%s lacks #power-domain-cell
Re: [PATCH v3 3/9] eeprom: Add a simple EEPROM framework for eeprom providers
On Tue, Mar 24, 2015 at 10:30:08PM +, Srinivas Kandagatla wrote:
> +static ssize_t bin_attr_eeprom_write(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *attr,
> + char *buf, loff_t offset, size_t count)
> +{
> + struct device *dev = container_of(kobj, struct device, kobj);
> + struct eeprom_device *eeprom = to_eeprom(dev);
> + int rc;
> +
> + if (offset > eeprom->size)
> + return -EINVAL;
> +
> + if (offset + count > eeprom->size)
> + count = eeprom->size - offset;
> +
> + rc = regmap_bulk_write(eeprom->regmap, offset,
> +buf, count/eeprom->stride);
Are you sure that this and the read interface should be using the bulk
interface and not the raw interface - do we want the byte swapping that
the bulk interface provides?
I'm also not entirely able to convince myself that the above error
checks and code line up with what I'd expect the userspace ABI to be, we
seem to be treating offset as both a byte offset into the data (which is
what I'd expect the userspace ABI to do) and a word based index into the
data (which is what the regmap API is doing). For example with 16 bit
words offset 2 will start at the 5th byte of data but if userspace seeks
to offset 5 it will get the 11th byte and onwards.
The stride and the word size are separate, they will frequently line up
for memory mapped devices but typically won't for other devices. I
think you need more data mangling to handle this robustly.
signature.asc
Description: Digital signature
Re: [PATCH V6 00/25] Generic BMIPS kernel
On 25/12/14 09:48, Kevin Cernekee wrote: > V5->V6: Incorporate several fixes/enhancements from Jaedon Shin: > > - Fix register read/modify/write in RAC flush code. > > - Fix use of "SYS_HAS_CPU_BMIPS32_3300" Kconfig symbol. > > - Add base platform support for 7358 and 7362. > > The DTS files follow Andrew Bresticker's new per-vendor directory layout. > > This series applies on top of Linus' current head of tree. > > Patch 01 (Fix outdated use of mips_cpu_intc_init()) is REQUIRED for 3.19 > to fix a build failure seen in 3.19-rc. The other patches can > be queued for 3.20 or later. Jason, can you merge the irqchip patches through your tree? They still apply cleanly to your irqchip/core branch as of today, except the last one which has a small hunk to be fixed in drivers/irqchip/Makefile. Thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/9] regmap: Introduce regmap_get_reg_stride.
On Tue, Mar 24, 2015 at 10:30:00PM +, Srinivas Kandagatla wrote: > + /* regmap_get_reg_stride(): Report the register address stride > + * > + * Report the register address stride, mainly intended to for use by > + * generic infrastructure built on top of regmap. > + */ > +int regmap_get_reg_stride(struct regmap *map) Please fix the indentation for the comment block and add kerneldoc for the argument. This is an exported function so it should also be /** not /* signature.asc Description: Digital signature
Re: [PATCH v3 1/9] regmap: Introduce regmap_get_max_register.
On Tue, Mar 24, 2015 at 10:29:39PM +, Srinivas Kandagatla wrote:
> This patch introduces regmap_get_max_register() function which would be
> used by the infrastructures like eeprom framework built on top of
> regmap.
In what way would it be used?
> +int regmap_get_max_register(struct regmap *map)
> +{
> + return map->max_register ? : -EINVAL;
> +}
Please write the logic out properly, don't abuse the ternery operator.
signature.asc
Description: Digital signature
[PATCH v3 3/9] eeprom: Add a simple EEPROM framework for eeprom providers
This patch adds just providers part of the framework just to enable easy
review.
Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were driving, etc.
This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.
This introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.
Having regmap interface to this framework would give much better
abstraction for eeproms on different buses.
Signed-off-by: Maxime Ripard
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla
---
drivers/Kconfig | 2 +
drivers/Makefile| 1 +
drivers/eeprom/Kconfig | 11 ++
drivers/eeprom/Makefile | 6 ++
drivers/eeprom/core.c | 227
include/linux/eeprom-provider.h | 42
6 files changed, 289 insertions(+)
create mode 100644 drivers/eeprom/Kconfig
create mode 100644 drivers/eeprom/Makefile
create mode 100644 drivers/eeprom/core.c
create mode 100644 include/linux/eeprom-provider.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index c70d6e4..d7afc82 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -184,4 +184,6 @@ source "drivers/thunderbolt/Kconfig"
source "drivers/android/Kconfig"
+source "drivers/eeprom/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 527a6da..57eb5b0 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -165,3 +165,4 @@ obj-$(CONFIG_RAS) += ras/
obj-$(CONFIG_THUNDERBOLT) += thunderbolt/
obj-$(CONFIG_CORESIGHT)+= coresight/
obj-$(CONFIG_ANDROID) += android/
+obj-$(CONFIG_EEPROM) += eeprom/
diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
new file mode 100644
index 000..21e1847
--- /dev/null
+++ b/drivers/eeprom/Kconfig
@@ -0,0 +1,11 @@
+menuconfig EEPROM
+ tristate "EEPROM Support"
+ depends on OF
+ select REGMAP
+ help
+ Support for EEPROM alike devices.
+
+ This framework is designed to provide a generic interface to EEPROM
+ from both the Linux Kernel and the userspace.
+
+ If unsure, say no.
diff --git a/drivers/eeprom/Makefile b/drivers/eeprom/Makefile
new file mode 100644
index 000..51a727f
--- /dev/null
+++ b/drivers/eeprom/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for eeprom drivers.
+#
+
+obj-$(CONFIG_EEPROM) += eeprom_core.o
+eeprom_core-y := core.o
diff --git a/drivers/eeprom/core.c b/drivers/eeprom/core.c
new file mode 100644
index 000..9fd556c
--- /dev/null
+++ b/drivers/eeprom/core.c
@@ -0,0 +1,227 @@
+/*
+ * EEPROM framework core.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla
+ * Copyright (C) 2013 Maxime Ripard
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct eeprom_device {
+ struct regmap *regmap;
+ int stride;
+ size_t size;
+
+ struct module *owner;
+ struct device dev;
+ int id;
+ int users;
+};
+
+static DEFINE_MUTEX(eeprom_mutex);
+static DEFINE_IDA(eeprom_ida);
+
+#define to_eeprom(d) container_of(d, struct eeprom_device, dev)
+
+static ssize_t bin_attr_eeprom_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t offset, size_t count)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct eeprom_device *eeprom = to_eeprom(dev);
+ int rc;
+
+ if (offset > eeprom->size)
+ return -EINVAL;
+
+ if (offset + count > eeprom->size)
+ count = eeprom->size - offset;
+
+ rc = regmap_bulk_read(eeprom->regmap, offset,
+ buf, count/eeprom->stride);
+
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ return count - count % eeprom->stride;
+}
+
+static ssize_t bin_attr_eeprom_write(struct file
[PATCH v3 1/9] regmap: Introduce regmap_get_max_register.
This patch introduces regmap_get_max_register() function which would be
used by the infrastructures like eeprom framework built on top of
regmap.
Signed-off-by: Srinivas Kandagatla
---
drivers/base/regmap/regmap.c | 12
include/linux/regmap.h | 7 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index d2f8a81..6fd234b 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2616,6 +2616,18 @@ int regmap_get_val_bytes(struct regmap *map)
}
EXPORT_SYMBOL_GPL(regmap_get_val_bytes);
+/*
+ * regmap_get_max_register(): Report the max register value
+ *
+ * Report the max register value, mainly intended to for use by
+ * generic infrastructure built on top of regmap.
+ */
+int regmap_get_max_register(struct regmap *map)
+{
+ return map->max_register ? : -EINVAL;
+}
+EXPORT_SYMBOL_GPL(regmap_get_max_register);
+
int regmap_parse_val(struct regmap *map, const void *buf,
unsigned int *val)
{
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 4419b99..c46dbf3 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -433,6 +433,7 @@ int regmap_update_bits_check_async(struct regmap *map,
unsigned int reg,
unsigned int mask, unsigned int val,
bool *change);
int regmap_get_val_bytes(struct regmap *map);
+int regmap_get_max_register(struct regmap *map);
int regmap_async_complete(struct regmap *map);
bool regmap_can_raw_write(struct regmap *map);
@@ -676,6 +677,12 @@ static inline int regmap_get_val_bytes(struct regmap *map)
return -EINVAL;
}
+static inline int regmap_get_max_register(struct regmap *map)
+{
+ WARN_ONCE(1, "regmap API is disabled");
+ return -EINVAL;
+}
+
static inline int regcache_sync(struct regmap *map)
{
WARN_ONCE(1, "regmap API is disabled");
--
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 v3 7/9] eeprom: qfprom: Add Qualcomm QFPROM support.
This patch adds QFPROM support driver which is used by other drivers
like thermal sensor and cpufreq.
On MSM parts there are some efuses (called qfprom) these fuses store things like
calibration data, speed bins.. etc. Drivers like cpufreq, thermal sensors would
read out this data for configuring the driver.
Signed-off-by: Srinivas Kandagatla
---
drivers/eeprom/Kconfig | 11 +++
drivers/eeprom/Makefile | 2 ++
drivers/eeprom/qfprom.c | 87 +
3 files changed, 100 insertions(+)
create mode 100644 drivers/eeprom/qfprom.c
diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
index ad396c1..8fc14d3 100644
--- a/drivers/eeprom/Kconfig
+++ b/drivers/eeprom/Kconfig
@@ -23,4 +23,15 @@ config EEPROM_SUNXI_SID
This driver can also be built as a module. If so, the module
will be called eeprom-sunxi-sid.
+config QCOM_QFPROM
+ tristate "QCOM QFPROM Support"
+ depends on ARCH_QCOM
+ select REGMAP_MMIO
+ help
+ Say y here to enable QFPROM support. The QFPROM provides access
+ functions for QFPROM data to rest of the drivers via eeprom interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called eeprom-qfprom.
+
endif
diff --git a/drivers/eeprom/Makefile b/drivers/eeprom/Makefile
index 184aa53..4ac437e 100644
--- a/drivers/eeprom/Makefile
+++ b/drivers/eeprom/Makefile
@@ -8,3 +8,5 @@ eeprom_core-y := core.o
# Devices
obj-$(CONFIG_EEPROM_SUNXI_SID) += eeprom-sunxi-sid.o
eeprom-sunxi-sid-y := sunxi-sid.o
+obj-$(CONFIG_QCOM_QFPROM) += eeprom_qfprom.o
+eeprom_qfprom-y:= qfprom.o
diff --git a/drivers/eeprom/qfprom.c b/drivers/eeprom/qfprom.c
new file mode 100644
index 000..8d5d4d8
--- /dev/null
+++ b/drivers/eeprom/qfprom.c
@@ -0,0 +1,87 @@
+/*
+ * Copyright (C) 2015 Srinivas Kandagatla
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct regmap_config qfprom_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 8,
+ .reg_stride = 1,
+};
+
+static struct eeprom_config econfig = {
+ .name = "qfprom",
+};
+
+static int qfprom_remove(struct platform_device *pdev)
+{
+ struct eeprom_device *eeprom = platform_get_drvdata(pdev);
+
+ return eeprom_unregister(eeprom);
+}
+
+static int qfprom_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ void __iomem *base;
+ struct device *dev = &pdev->dev;
+ struct eeprom_device *eeprom;
+ struct regmap *regmap;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ qfprom_regmap_config.max_register = resource_size(res) - 1;
+
+ regmap = devm_regmap_init_mmio(dev, base,
+ &qfprom_regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(dev, "regmap init failed\n");
+ return PTR_ERR(regmap);
+ }
+ econfig.owner = THIS_MODULE;
+ econfig.dev = dev;
+ eeprom = eeprom_register(&econfig);
+ if (IS_ERR(eeprom))
+ return PTR_ERR(eeprom);
+
+ platform_set_drvdata(pdev, eeprom);
+ return 0;
+}
+
+static const struct of_device_id qfprom_of_match[] = {
+ { .compatible = "qcom,qfprom"},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, qfprom_of_match);
+
+static struct platform_driver qfprom_driver = {
+ .probe = qfprom_probe,
+ .remove = qfprom_remove,
+ .driver = {
+ .name = "qcom,qfprom",
+ .of_match_table = qfprom_of_match,
+ },
+};
+module_platform_driver(qfprom_driver);
+MODULE_AUTHOR("Srinivas Kandagatla ");
+MODULE_DESCRIPTION("Qualcomm QFPROM driver");
+MODULE_LICENSE("GPL v2");
--
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 v3 9/9] eeprom: Add to MAINTAINERS for eeprom framework
This patch adds MAINTAINERS to eeprom framework. Signed-off-by: Srinivas Kandagatla --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d66a97d..ee7ba92 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3657,6 +3657,15 @@ T: git git://git.alsa-project.org/alsa-kernel.git S: Maintained F: sound/usb/misc/ua101.c +EEPROM FRAMEWORK +M: Srinivas Kandagatla +M: Maxime Ripard +S: Maintained +F: drivers/eeprom/ +F: Documentation/devicetree/bindings/eeprom/ +F: include/linux/eeprom-provider.h +F: include/linux/eeprom-consumer.h + EXTENSIBLE FIRMWARE INTERFACE (EFI) M: Matt Fleming L: linux-...@vger.kernel.org -- 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 v3 8/9] eeprom: qfprom: Add bindings for qfprom
This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
is based on simple eeprom framework.
Signed-off-by: Srinivas Kandagatla
---
.../devicetree/bindings/eeprom/qfprom.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/eeprom/qfprom.txt
diff --git a/Documentation/devicetree/bindings/eeprom/qfprom.txt
b/Documentation/devicetree/bindings/eeprom/qfprom.txt
new file mode 100644
index 000..d5baed6
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/qfprom.txt
@@ -0,0 +1,23 @@
+= Qualcomm QFPROM device tree bindings =
+
+This binding is intended to represent QFPROM which is found in most QCOM SOCs.
+
+Required properties:
+- compatible: should be "qcom,qfprom"
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/eeprom/eeprom.txt
+
+Example:
+
+ qfprom: qfprom@0070 {
+ compatible = "qcom,qfprom";
+ reg = <0x0070 0x1000>;
+ ...
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x404 0x10>;
+ };
+ };
--
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 v3 5/9] eeprom: Add bindings for simple eeprom framework
This patch adds bindings for simple eeprom framework which allows eeprom
consumers to talk to eeprom providers to get access to eeprom cell data.
Signed-off-by: Maxime Ripard
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla
---
.../devicetree/bindings/eeprom/eeprom.txt | 70 ++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt
b/Documentation/devicetree/bindings/eeprom/eeprom.txt
new file mode 100644
index 000..8348d18
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -0,0 +1,70 @@
+= EEPROM Data Device Tree Bindings =
+
+This binding is intended to represent the location of hardware
+configuration data stored in EEPROMs.
+
+On a significant proportion of boards, the manufacturer has stored
+some data on an EEPROM-like device, for the OS to be able to retrieve
+these information and act upon it. Obviously, the OS has to know
+about where to retrieve these data from, and where they are stored on
+the storage device.
+
+This document is here to document this.
+
+= Data providers =
+Contains bindings specific to provider drivers and data cells as children
+to this node.
+
+= Data cells =
+These are the child nodes of the provider which contain data cell
+information like offset and size in eeprom provider.
+
+Required properties:
+reg: specifies the offset in byte within that storage device, and the length
+ in bytes of the data we care about.
+ There could be more then one offset-length pairs in this property.
+
+Optional properties:
+As required by specific data parsers/interpreters.
+
+For example:
+
+ /* Provider */
+ qfprom: qfprom@0070 {
+ compatible = "qcom,qfprom";
+ reg = <0x0070 0x1000>;
+ ...
+
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x404 0x10>;
+ };
+
+ serial_number: sn {
+ reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>;
+
+ };
+ ...
+ };
+
+= Data consumers =
+Are device nodes which consume eeprom data cells.
+
+Required properties:
+
+eeproms: List of phandle and data cell the device might be interested in.
+
+Optional properties:
+
+eeprom-names: List of data cell name strings sorted in the same order
+ as the eeproms property. Consumers drivers will use
+ eeprom-names to differentiate between multiple cells,
+ and hence being able to know what these cells are for.
+
+For example:
+
+ tsens {
+ ...
+ eeproms = <&tsens_calibration>;
+ eeprom-names = "calibration";
+ };
--
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 v3 6/9] eeprom: sunxi: Move the SID driver to the eeprom framework
From: Maxime Ripard
Now that we have the EEPROM framework, we can consolidate the common driver
code. Move the driver to the framework, and hopefully, it will fix the sysfs
file creation race.
Signed-off-by: Maxime Ripard
[srinivas.kandagatla: Moved to regmap based EEPROM framework]
Signed-off-by: Srinivas Kandagatla
---
Documentation/ABI/testing/sysfs-driver-sunxi-sid | 22 ---
.../bindings/eeprom/allwinner,sunxi-sid.txt| 21 +++
.../bindings/misc/allwinner,sunxi-sid.txt | 17 ---
drivers/eeprom/Kconfig | 15 ++
drivers/eeprom/Makefile| 4 +
drivers/eeprom/sunxi-sid.c | 136 ++
drivers/misc/eeprom/Kconfig| 13 --
drivers/misc/eeprom/Makefile | 1 -
drivers/misc/eeprom/sunxi_sid.c| 156 -
9 files changed, 176 insertions(+), 209 deletions(-)
delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
create mode 100644
Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt
delete mode 100644
Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
create mode 100644 drivers/eeprom/sunxi-sid.c
delete mode 100644 drivers/misc/eeprom/sunxi_sid.c
diff --git a/Documentation/ABI/testing/sysfs-driver-sunxi-sid
b/Documentation/ABI/testing/sysfs-driver-sunxi-sid
deleted file mode 100644
index ffb9536..000
--- a/Documentation/ABI/testing/sysfs-driver-sunxi-sid
+++ /dev/null
@@ -1,22 +0,0 @@
-What: /sys/devices/*//eeprom
-Date: August 2013
-Contact: Oliver Schinagl
-Description: read-only access to the SID (Security-ID) on current
- A-series SoC's from Allwinner. Currently supports A10, A10s, A13
- and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
- whereas the newer A20 SoC exposes 512 bytes split into sections.
- Besides the 16 bytes of SID, there's also an SJTAG area,
- HDMI-HDCP key and some custom keys. Below a quick overview, for
- details see the user manual:
- 0x000 128 bit root-key (sun[457]i)
- 0x010 128 bit boot-key (sun7i)
- 0x020 64 bit security-jtag-key (sun7i)
- 0x028 16 bit key configuration (sun7i)
- 0x02b 16 bit custom-vendor-key (sun7i)
- 0x02c 320 bit low general key (sun7i)
- 0x040 32 bit read-control access (sun7i)
- 0x064 224 bit low general key (sun7i)
- 0x080 2304 bit HDCP-key (sun7i)
- 0x1a0 768 bit high general key (sun7i)
-Users: any user space application which wants to read the SID on
- Allwinner's A-series of CPU's.
diff --git a/Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt
b/Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt
new file mode 100644
index 000..cceaaf6
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt
@@ -0,0 +1,21 @@
+Allwinner sunxi-sid
+
+Required properties:
+- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/eeprom/eeprom.txt
+
+Example for sun4i:
+ sid@01c23800 {
+ compatible = "allwinner,sun4i-a10-sid";
+ reg = <0x01c23800 0x10>
+ };
+
+Example for sun7i:
+ sid@01c23800 {
+ compatible = "allwinner,sun7i-a20-sid";
+ reg = <0x01c23800 0x200>
+ };
diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
deleted file mode 100644
index fabdf64..000
--- a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Allwinner sunxi-sid
-
-Required properties:
-- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
-- reg: Should contain registers location and length
-
-Example for sun4i:
- sid@01c23800 {
- compatible = "allwinner,sun4i-a10-sid";
- reg = <0x01c23800 0x10>
- };
-
-Example for sun7i:
- sid@01c23800 {
- compatible = "allwinner,sun7i-a20-sid";
- reg = <0x01c23800 0x200>
- };
diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
index 21e1847..ad396c1 100644
--- a/drivers/eeprom/Kconfig
+++ b/drivers/eeprom/Kconfig
@@ -9,3 +9,18 @@ menuconfig EEPROM
from both the Linux Kernel and the userspace.
If unsure, say no.
+
+if EEPROM
+
+config EEPROM_SUNXI_SID
+ tristate "Allwinner SoCs SID support"
+ depends on ARCH_SUNXI
+ select REGMAP_MMIO
+ help
+ This is a driver for the 'security ID' available on various Allwinner
+ devices.
+
+
[PATCH v3 4/9] eeprom: Add a simple EEPROM framework for eeprom consumers
This patch adds just consumers part of the framework just to enable easy
review.
Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were driving, etc.
This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.
This introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.
Having regmap interface to this framework would give much better
abstraction for eeproms on different buses.
Signed-off-by: Maxime Ripard
[Maxime Ripard: intial version of the framework]
Signed-off-by: Srinivas Kandagatla
---
drivers/eeprom/core.c | 304
include/linux/eeprom-consumer.h | 67 +
2 files changed, 371 insertions(+)
create mode 100644 include/linux/eeprom-consumer.h
diff --git a/drivers/eeprom/core.c b/drivers/eeprom/core.c
index 9fd556c..43d03ef 100644
--- a/drivers/eeprom/core.c
+++ b/drivers/eeprom/core.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -37,6 +38,13 @@ struct eeprom_device {
int users;
};
+struct eeprom_cell {
+ struct eeprom_device*eeprom;
+ int nblocks;
+ int size;
+ struct eeprom_block blocks[0];
+};
+
static DEFINE_MUTEX(eeprom_mutex);
static DEFINE_IDA(eeprom_ida);
@@ -125,6 +133,37 @@ static struct class eeprom_class = {
.dev_release= eeprom_release,
};
+static int of_eeprom_match(struct device *dev, const void *eeprom_np)
+{
+ return dev->of_node == eeprom_np;
+}
+
+static struct eeprom_device *of_eeprom_find(struct device_node *eeprom_np)
+{
+ struct device *d;
+
+ if (!eeprom_np)
+ return NULL;
+
+ d = class_find_device(&eeprom_class, NULL, eeprom_np, of_eeprom_match);
+
+ return d ? to_eeprom(d) : NULL;
+}
+
+static int eeprom_match(struct device *dev, const void *data)
+{
+ return !strcmp(dev_name(dev), (const char *)data);
+}
+
+static struct eeprom_device *eeprom_find(const char *name)
+{
+ struct device *d;
+
+ d = class_find_device(&eeprom_class, NULL, (void *)name, eeprom_match);
+
+ return d ? to_eeprom(d) : NULL;
+}
+
/**
* eeprom_register(): Register a eeprom device for given eeprom.
* Also creates an binary entry in /sys/class/eeprom/name-id/eeprom
@@ -208,6 +247,271 @@ int eeprom_unregister(struct eeprom_device *eeprom)
}
EXPORT_SYMBOL_GPL(eeprom_unregister);
+static int eeprom_cell_sanity_check(struct eeprom_cell *cell)
+{
+ struct eeprom_device *eeprom = cell->eeprom;
+ int i;
+
+ /* byte aligned, no need to check for stride sanity */
+ if (eeprom->stride == 1)
+ return 0;
+
+ for (i = 0; i < cell->nblocks; i++) {
+ if (!IS_ALIGNED(cell->blocks[i].offset, eeprom->stride) ||
+ !IS_ALIGNED(cell->blocks[i].count, eeprom->stride)) {
+ dev_err(&eeprom->dev,
+ "cell unaligned to eeprom stride %d\n",
+ eeprom->stride);
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+static struct eeprom_cell *__eeprom_cell_get(struct device_node *cell_np,
+const char *ename,
+struct eeprom_block *blocks,
+int nblocks)
+{
+ struct eeprom_cell *cell;
+ struct eeprom_device *eeprom = NULL;
+ struct property *prop;
+ const __be32 *vp;
+ u32 pv;
+ int i, rval;
+
+ mutex_lock(&eeprom_mutex);
+
+ eeprom = cell_np ? of_eeprom_find(cell_np->parent) : eeprom_find(ename);
+ if (!eeprom) {
+ mutex_unlock(&eeprom_mutex);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ eeprom->users++;
+ mutex_unlock(&eeprom_mutex);
+
+ if (!try_module_get(eeprom->owner)) {
+ dev_err(&eeprom->dev,
+ "could not increase module refcount for cell %s\n",
+ ename);
+ rval = -EINVAL;
+ goto err_mod;
+ }
+
+ if (cell_np)
+ nblocks = of_property_count_u32_elems(cell_np, "reg") / 2;
+
+ cell = kzalloc(sizeof(*cell) + nblocks * sizeof(*blocks), GFP_KERNEL);
+ if (!cell) {
+ rval = -ENOMEM;
+ goto err_mem;
+ }
+
+ cell->nblocks = nblocks;
+ cell->eeprom = eeprom;
+ cell->size = 0;
+ i = 0;
+
+ if
[PATCH v3 0/9] Add simple EEPROM Framework via regmap.
Thankyou all for providing inputs and comments on previous versions of this
patchset.
Here is the v3 of the patchset addressing all the issues raised as
part of previous versions review.
This patchset adds a new simple EEPROM framework to kernel.
Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were driving, etc.
This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.
This introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.
Having regmap interface to this framework would give much better
abstraction for eeproms on different buses.
patch 1-2 Introduces two regmap helper functions.
patch 3-5 Introduces the EEPROM framework.
Patch 6 migrates an existing driver to eeprom framework.
Patch 7-8 Adds Qualcomm specific qfprom driver.
Patch 9 adds entry in MAINTAINERS.
Its also possible to migrate other eeprom drivers to this framework.
Patch 6 can also be made a generic mmio-eeprom driver.
Providers APIs:
eeprom_register/unregister();
Consumers APIs:
eeprom_cell_get()/of_eeprom_cell_get()/of_eeprom_cell_get_byname();
eeprom_cell_put();
eeprom_cell_read()/eeprom_cell_write();
Device Tree:
/* Provider */
qfprom: qfprom@0070 {
compatible = "qcom,qfprom";
reg = <0x0070 0x1000>;
...
/* Data cells */
tsens_calibration: calib@404 {
reg = <0x404 0x10>;
};
serial_number: sn {
reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>;
};
...
};
/* Consumer node */
tsens: tsens {
...
eeproms = <&tsens_calibration>;
eeprom-names = "calib";
...
};
userspace interface:
hexdump /sys/class/eeprom/qfprom0/eeprom
000
*
0a0 db10 2240 e000 0c00 0c00 0c00
000
...
*
0001000
Changes since v2(https://lkml.org/lkml/2015/3/13/168)
* Fixed error handling in eeprom_register spotted by Mark Brown
* Added new regmap_get_max_register() and regmap_get_reg_stride().
* Fixed module build errors reported by kbuild robot.
* recycle the ids when eeprom provider is released.
Changes since v1(https://lkml.org/lkml/2015/3/5/153)
* Fix various Licencing issues spotted by Paul Bolle and Mark Brown
* Allow eeprom core to build as module spotted by Paul Bolle.
* Fix various kconfig issues spotted by Paul Bolle.
* remove unessary atomic varible spotted by Mark Brown.
* Few cleanups and common up some of the code in core.
* Add qfprom bindings.
Changes since RFC(https://lkml.org/lkml/2015/2/19/307)
* Fix documentation and error checks in read/write spotted by Andrew Lunn
* Kconfig fix suggested by Stephen Boyd.
* Add module owner suggested by Stephen Boyd and others.
* Fix unsafe handling of eeprom in unregister spotted by Russell and Mark
Brown.
* seperate bindings patch as suggested by Rob.
* Add MAINTAINERS as suggested by Rob.
* Added support to allow reading eeprom for things like serial number which
* canbe scatters across.
* Added eeprom data using reg property suggested by Sascha and Stephen.
* Added non-DT support.
* Move kerneldoc to the src files spotted by Mark Brown.
* Remove local list and do eeprom lookup by using class_find_device()
Thanks,
srini
Maxime Ripard (1):
eeprom: sunxi: Move the SID driver to the eeprom framework
Srinivas Kandagatla (8):
regmap: Introduce regmap_get_max_register.
regmap: Introduce regmap_get_reg_stride.
eeprom: Add a simple EEPROM framework for eeprom providers
eeprom: Add a simple EEPROM framework for eeprom consumers
eeprom: Add bindings for simple eeprom framework
eeprom: qfprom: Add Qualcomm QFPROM support.
eeprom: qfprom: Add bindings for qfprom
eeprom: Add to MAINTAINERS for eeprom framework
Documentation/ABI/testing/sysfs-driver-sunxi-sid | 22 -
.../bindings/eeprom/allwinner,sunxi-sid.txt| 21 +
.../devicetree/bindings/eeprom/eeprom.txt | 70 +++
.../devicetree/bindings/eeprom/qfprom.txt | 23 +
.../bindings/misc/allwinner,sunxi-sid.txt | 17 -
MAINTAINERS
[PATCH v3 2/9] regmap: Introduce regmap_get_reg_stride.
This patch introduces regmap_get_reg_stride() function which would
be used by the infrastructures like eeprom framework built on top of
regmap. Mostly this function would be used for sanity checks on inputs
within such infrastructure.
Signed-off-by: Srinivas Kandagatla
---
drivers/base/regmap/regmap.c | 11 +++
include/linux/regmap.h | 7 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 6fd234b..44d3d94 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2628,6 +2628,17 @@ int regmap_get_max_register(struct regmap *map)
}
EXPORT_SYMBOL_GPL(regmap_get_max_register);
+ /* regmap_get_reg_stride(): Report the register address stride
+ *
+ * Report the register address stride, mainly intended to for use by
+ * generic infrastructure built on top of regmap.
+ */
+int regmap_get_reg_stride(struct regmap *map)
+{
+ return map->reg_stride;
+}
+EXPORT_SYMBOL_GPL(regmap_get_reg_stride);
+
int regmap_parse_val(struct regmap *map, const void *buf,
unsigned int *val)
{
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index c46dbf3..b58067c 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -434,6 +434,7 @@ int regmap_update_bits_check_async(struct regmap *map,
unsigned int reg,
bool *change);
int regmap_get_val_bytes(struct regmap *map);
int regmap_get_max_register(struct regmap *map);
+int regmap_get_reg_stride(struct regmap *map);
int regmap_async_complete(struct regmap *map);
bool regmap_can_raw_write(struct regmap *map);
@@ -683,6 +684,12 @@ static inline int regmap_get_max_register(struct regmap
*map)
return -EINVAL;
}
+static inline int regmap_get_reg_stride(struct regmap *map)
+{
+ WARN_ONCE(1, "regmap API is disabled");
+ return -EINVAL;
+}
+
static inline int regcache_sync(struct regmap *map)
{
WARN_ONCE(1, "regmap API is disabled");
--
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 7/7] ARM: dts: add OPPs for i.MX23/i.MX28
Stefan Wahren wrote:
> [...]
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 98c1be6..21c1921 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -38,12 +38,23 @@
> };
>
> cpus {
> - #address-cells = <0>;
> + #address-cells = <1>;
> #size-cells = <0>;
>
> - cpu {
> + cpu@0 {
> compatible = "arm,arm926ej-s";
> device_type = "cpu";
> + reg = <0x0>;
> + operating-points = <
> + /* kHz uV */
> + 261819 135
> + 36 135
> + 392728 145
> + 454737 155
> + >;
> + clocks = <&clks 4>;
> + clock-latency = <61036>; /* two CLK32 periods */
> + cpu-supply = <®_vddd>;
> };
> };
Maybe you should take into account not to reduce VDD below 1.55 V if the SDRAM
controller runs above 196 MHz. The i.MX28 datasheet[1] lists these
restrictions. VDD powers the SDRAM controller as well. From the datasheet the
table "Frequency versus Voltage for EMICLK" shows:
EMICLK Fmax (MHz)
VDDD (V) DDR2 mDDR
1.550 205.71 205.71
1.450 196.36 196.36
1.350 196.36 196.36
jbe
[1]
i.MX28 Applications
Processors for Consumer
Products
Silicon Version 1.2
Document Number: IMX28CEC
Rev. 3, 07/2012
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers
On Tue, Mar 24, 2015 at 07:26:45PM +, Srinivas Kandagatla wrote: > On 24/03/15 19:02, Mark Brown wrote: > >On Tue, Mar 24, 2015 at 06:34:32PM +, Srinivas Kandagatla wrote: > >>>On 24/03/15 17:23, Mark Brown wrote: > > >>regmap_get_size(regmap) > >This is already there. > >>>Sorry, I can't see any such api atleast in v4.0-rc5 and linux-next? Are you > >>>referring to another api which does the same job? > >regmap_get_val_bytes() > This would return value bytes, but I wanted is the regmap->max_register > value which would be used for sanity checks in eeprom-core. Then you *really* want to pick a better name then, I'd never have inferred that meaning from "size" (consider sparse register maps for example). Like I said, send patches (preferrably showing the users as well). signature.asc Description: Digital signature
Re: [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers
On 24/03/15 19:02, Mark Brown wrote: On Tue, Mar 24, 2015 at 06:34:32PM +, Srinivas Kandagatla wrote: >On 24/03/15 17:23, Mark Brown wrote: > >>regmap_get_size(regmap) > >This is already there. >Sorry, I can't see any such api atleast in v4.0-rc5 and linux-next? Are you >referring to another api which does the same job? regmap_get_val_bytes() This would return value bytes, but I wanted is the regmap->max_register value which would be used for sanity checks in eeprom-core. --srini -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/6] wlcore: add device-tree support
hi Nikita, On Tue, Mar 24, 2015 at 1:37 PM, Nikita Kiryanov wrote: > Hi Eliad, > > On 03/18/2015 06:38 PM, Eliad Peller wrote: >> >> Add device-tree support to the wlcore (wl12xx/wl18xx) >> driver. >> >> Update the current users to use the bindings instead >> of pdata-quirks. >> >> Finally, remove the deprecated wl12xx_platform_data >> struct (along with the da850 board file code that >> still uses it) > > > Tested-by: Nikita Kiryanov > Tested on am437x-gp-evm with WL1835MODCOM8B > thanks for testing it! Eliad. -- To unsubscribe from this list: send the line "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] ARM: cpuidle: Document the code
On Tue, Mar 24, 2015 at 06:51:44PM +, Lorenzo Pieralisi wrote: > On Tue, Mar 24, 2015 at 09:54:02AM +, Daniel Lezcano wrote: [...] > > +/* > > + * arm_cpuidle_init() - Initialize cpuidle_ops for a specific cpu > > + * @cpu: the cpu to be initialized > > + * > > + * Initialize the cpuidle ops with the device for the cpu and then call > > + * the cpu's idle initialization callback. This may fail if the underlying > > HW > > + * is not operational. > > + * > > + * Returns: > > + * 0 on success, > > + * -ENODEV if it fails to find the cpu node in the device tree, > > + * -EOPNOTSUPP if it does not find a registered cpuidle_ops for this cpu, > > + * -ENOENT if it fails to find a enabled-method property, > > Ultra-nit: "an enabled-method" Bah, I cannot see the wood for the trees anymore. "an enable-method". Lorenzo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers
On Tue, Mar 24, 2015 at 06:34:32PM +, Srinivas Kandagatla wrote: > On 24/03/15 17:23, Mark Brown wrote: > >>regmap_get_size(regmap) > >This is already there. > Sorry, I can't see any such api atleast in v4.0-rc5 and linux-next? Are you > referring to another api which does the same job? regmap_get_val_bytes() > >>Which would be give eeprom-core the size and stride info, doing this way > >>would cut down regmap related things from eeprom_config structure to minimal > >>and also the source of information would come from just regmap apis. > >Documentation/SubmittingPatches... > Am not sure what you meant here, Am guessing that you asked me to keep the > respective maintainers in the loop and follow the guide, when I resend the > patch? I'm saying that you should send patches if you want to add features. signature.asc Description: Digital signature
Re: [PATCH 2/2] ARM: cpuidle: Document the code
On Tue, Mar 24, 2015 at 09:54:02AM +, Daniel Lezcano wrote:
> Add kernel-doc format documentation in the code.
>
> Signed-off-by: Daniel Lezcano
> ---
> arch/arm/kernel/cpuidle.c | 58
> +++
> 1 file changed, 58 insertions(+)
>
> diff --git a/arch/arm/kernel/cpuidle.c b/arch/arm/kernel/cpuidle.c
> index 2b0dae3..9219613 100644
> --- a/arch/arm/kernel/cpuidle.c
> +++ b/arch/arm/kernel/cpuidle.c
> @@ -21,6 +21,17 @@ static const struct of_cpuidle_method
> __cpuidle_method_of_table_sentinel
>
> static struct cpuidle_ops cpuidle_ops[NR_CPUS];
>
> +/*
You miss a star here to comply with kernel-doc (comment valid throughout
the patch for all functions).
> + * arm_cpuidle_simple_enter() - a wrapper to cpu_do_idle()
> + * @dev: not used
> + * @drv: not used
> + * @index: not used
> + *
> + * A trivial wrapper to allow the cpu_do_idle function to be assigned as a
> + * cpuidle callback by matching the function signature.
> + *
> + * Returns the index passed as parameter
> + */
> int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int index)
> {
> @@ -29,6 +40,16 @@ int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
> return index;
> }
>
> +/*
> + * arm_cpuidle_suspend() - function to enter low power idle states
> + * @index: an integer used as an identifier for the low level PM callbacks
> + *
> + * This function calls the underlying arch specific low level PM code as
> + * registered at the init time.
> + *
> + * Returns -EOPNOTSUPP if no suspend callback is defined, the result of the
> + * callback otherwise.
> + */
> int arm_cpuidle_suspend(int index)
> {
> int ret = -EOPNOTSUPP;
> @@ -40,6 +61,15 @@ int arm_cpuidle_suspend(int index)
> return ret;
> }
>
> +/*
> + * arm_cpuidle_get_ops() - find a registered cpuidle_ops by name
> + * @method: the method name
> + *
> + * Search in the __cpuidle_method_of_table array the cpuidle ops matching the
> + * method name.
> + *
> + * Returns a struct cpuidle_ops pointer, NULL if not found.
> + */
> static struct cpuidle_ops *__init arm_cpuidle_get_ops(const char *method)
> {
> struct of_cpuidle_method *m = __cpuidle_method_of_table;
> @@ -51,6 +81,19 @@ static struct cpuidle_ops *__init
> arm_cpuidle_get_ops(const char *method)
> return NULL;
> }
>
> +/*
> + * arm_cpuidle_read_ops() - Initialize the cpuidle ops with the device tree
> + * @dn: a struct device node corresponding to a cpu node
It is a pointer, not a struct.
> + * @cpu: the cpu identifier
> + *
> + * Get the method name defined in the 'enabled-method' property, retrieve the
> + * associated cpuidle_ops and do a struct copy. This copy is needed because
> all
> + * cpuidle_ops are tagged __initdata and will be unloaded after the init
> + * process.
> + *
> + * Return 0 on sucess, -ENOENT if no enabled-method is defined, -EOPNOTSUPP
> if
> + * no cpuidle_ops is registered for the enabled-method.
> + */
> static int __init arm_cpuidle_read_ops(struct device_node *dn, int cpu)
> {
> const char *enable_method;
> @@ -75,6 +118,21 @@ static int __init arm_cpuidle_read_ops(struct device_node
> *dn, int cpu)
> return 0;
> }
>
> +/*
> + * arm_cpuidle_init() - Initialize cpuidle_ops for a specific cpu
> + * @cpu: the cpu to be initialized
> + *
> + * Initialize the cpuidle ops with the device for the cpu and then call
> + * the cpu's idle initialization callback. This may fail if the underlying HW
> + * is not operational.
> + *
> + * Returns:
> + * 0 on success,
> + * -ENODEV if it fails to find the cpu node in the device tree,
> + * -EOPNOTSUPP if it does not find a registered cpuidle_ops for this cpu,
> + * -ENOENT if it fails to find a enabled-method property,
Ultra-nit: "an enabled-method"
> + * -ENXIO if the HW reports a failure or a misconfiguration
-ENOMEM is missing.
Apart from these ultraminor changes (and thanks for putting it
together):
Acked-by: Lorenzo Pieralisi
> + */
> int __init arm_cpuidle_init(int cpu)
> {
> struct device_node *cpu_node = of_cpu_device_node_get(cpu);
> --
> 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 v2 0/2] Qualcomm PM8941 power key driver
On Fri, Mar 20, 2015 at 02:54:33AM +0100, Bjorn Andersson wrote: > On Mon, Feb 16, 2015 at 10:55 AM, Ivan T. Ivanov wrote: > > > > On Fri, 2015-01-23 at 16:19 -0800, Bjorn Andersson wrote: > >> These patches add dt bindings and a device driver for the power key block > >> in > >> the Qualcomm PM8941 pmic. > >> > >> Changes since v1: > >> * Use a reboot_notifier to set power off/reboot mode > >> * Use irq flags from devicetree > >> * Some style fixes > >> > >> Courtney Cavin (2): > >> input: Add Qualcomm PM8941 power key driver > >> input: pm8941-pwrkey: Add DT binding documentation > > > > Tested-by: Ivan T. Ivanov > > > > Thanks for your testing Ivan. > > Dmitry, can you apply this? (It still applies cleanly to linux-next) > Queued for 4.1, thank you. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers
On 24/03/15 17:23, Mark Brown wrote: On Tue, Mar 24, 2015 at 09:18:14AM +, Srinivas Kandagatla wrote: I did try your suggestion, by which I could remove the regmap from config. One thing I did not like was eeprom-core getting size/stride info directly from providers and regmap from regmap apis. I was wondering if we could take a step further and introduce new regmap helpers like regmap_get_size(regmap) This is already there. Sorry, I can't see any such api atleast in v4.0-rc5 and linux-next? Are you referring to another api which does the same job? regmap_get_stride(regmap) Which would be give eeprom-core the size and stride info, doing this way would cut down regmap related things from eeprom_config structure to minimal and also the source of information would come from just regmap apis. Documentation/SubmittingPatches... Am not sure what you meant here, Am guessing that you asked me to keep the respective maintainers in the loop and follow the guide, when I resend the patch? --srini -- To unsubscribe from this list: send the line "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] input: Add support for ChipOne icn8318 based touchscreens
On Tue, Mar 24, 2015 at 06:45:03PM +0100, Hans de Goede wrote: > Hi, > > On 03/22/2015 11:42 PM, Dmitry Torokhov wrote: > >On Sun, Mar 22, 2015 at 12:00:55PM +0100, Hans de Goede wrote: > >>Hi, > >> > >>On 22-03-15 05:03, Dmitry Torokhov wrote: > >>>Hi Hans, > >>> > >>>On Tue, Mar 10, 2015 at 06:05:33PM +0100, Hans de Goede wrote: > + error = devm_request_threaded_irq(dev, client->irq, NULL, icn8318_irq, > + IRQF_TRIGGER_FALLING | IRQF_ONESHOT, > >>> > >>>Shouldn't we let DT data tell us what trigger to use? I.e. just leave > >>>IRQF_ONESHOT here? > >> > >>That is an interesting question, that new data is available is signalled by > >>the irq pin of the chip going low is a property of the chip, not the board > >>layout, so I believe it is best to leave this as is. > > > >My concern is that even if pin behavior is property of chip maybe on > >some boards we want to use level-triggered interrupts instead of edge? > >And if we indeed want to hard-code the trigger then shouldn't the > >binding document use onecell mapping (so that users do not attempt to > >configure triggers from DT)? > > The number of irq cells is specified by the interrupt controller driver > rather then by the device binding. > > > > >> > >>Also note that if we want to get this from devicetree, that simply leaving > >>out the > >>flag is not enough, we must specifically get the data from devicetree and > >>pass > >>it into request_irq AFAICT. So the above would change to: > >> > >>irqflags = irqd_get_trigger_type(irq_get_irq_data(client->irq)) | > >> IRQF_ONESHOT, > >>error = devm_request_threaded_irq(dev, client->irq, NULL, icn8318_irq, > >> irqflags, > > > >No, of_irq_get() that i2c core calls before probing driver should > >already set the trigger type for us. There is no need for the individual > >drivers to do that. > > Ah I see, ok I've just tested removing the IRQF_TRIGGER_FALLING flag and > indeed > things still work fine, so feel free to merge this patch with that flagged > dropped. OK, thanks, queued for 4.1. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
Hi Maxime, On 03/12/2015 05:55 PM, Maxime Coquelin wrote: > From: Maxime Coquelin > > This drivers adds support to the STM32 USART controller, which is a > standard serial driver. Comments below. > Signed-off-by: Maxime Coquelin > --- > drivers/tty/serial/Kconfig | 17 + > drivers/tty/serial/Makefile | 1 + > drivers/tty/serial/stm32-usart.c | 695 > +++ > include/uapi/linux/serial_core.h | 3 + > 4 files changed, 716 insertions(+) > create mode 100644 drivers/tty/serial/stm32-usart.c > > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > index d2501f0..880cb4f 100644 > --- a/drivers/tty/serial/Kconfig > +++ b/drivers/tty/serial/Kconfig > @@ -1611,6 +1611,23 @@ config SERIAL_SPRD_CONSOLE > with "earlycon" on the kernel command line. The console is > enabled when early_param is processed. > > +config SERIAL_STM32 > + tristate "STMicroelectronics STM32 serial port support" > + select SERIAL_CORE > + depends on ARM || COMPILE_TEST > + help > + This driver is for the on-chip Serial Controller on > + STMicroelectronics STM32 MCUs. > + USART supports Rx & Tx functionality. > + It support all industry standard baud rates. > + > + If unsure, say N. > + > +config SERIAL_STM32_CONSOLE > + bool "Support for console on STM32" > + depends on SERIAL_STM32=y > + select SERIAL_CORE_CONSOLE > + > endmenu > > config SERIAL_MCTRL_GPIO > diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile > index 599be4b..67c5023 100644 > --- a/drivers/tty/serial/Makefile > +++ b/drivers/tty/serial/Makefile > @@ -95,6 +95,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART) += fsl_lpuart.o > obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR) += digicolor-usart.o > obj-$(CONFIG_SERIAL_MEN_Z135)+= men_z135_uart.o > obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o > +obj-$(CONFIG_SERIAL_STM32) += stm32-usart.o > > # GPIOLIB helpers for modem control lines > obj-$(CONFIG_SERIAL_MCTRL_GPIO) += serial_mctrl_gpio.o > diff --git a/drivers/tty/serial/stm32-usart.c > b/drivers/tty/serial/stm32-usart.c > new file mode 100644 > index 000..61bb065 > --- /dev/null > +++ b/drivers/tty/serial/stm32-usart.c > @@ -0,0 +1,695 @@ > +/* > + * Copyright (C) Maxime Coquelin 2015 > + * Author: Maxime Coquelin > + * License terms: GNU General Public License (GPL), version 2 > + * > + * Inspired by st-asc.c from STMicroelectronics (c) > + */ > + > +#if defined(CONFIG_SERIAL_STM32_USART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) > +#define SUPPORT_SYSRQ > +#endif > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DRIVER_NAME "stm32-usart" > + > +/* Register offsets */ > +#define USART_SR 0x00 > +#define USART_DR 0x04 > +#define USART_BRR0x08 > +#define USART_CR10x0c > +#define USART_CR20x10 > +#define USART_CR30x14 > +#define USART_GTPR 0x18 > + > +/* USART_SR */ > +#define USART_SR_PE BIT(0) > +#define USART_SR_FE BIT(1) > +#define USART_SR_NF BIT(2) > +#define USART_SR_ORE BIT(3) > +#define USART_SR_IDLEBIT(4) > +#define USART_SR_RXNEBIT(5) > +#define USART_SR_TC BIT(6) > +#define USART_SR_TXE BIT(7) > +#define USART_SR_LBD BIT(8) > +#define USART_SR_CTS BIT(9) > +#define USART_SR_ERR_MASK(USART_SR_LBD | USART_SR_ORE | \ > + USART_SR_FE | USART_SR_PE) > +/* Dummy bits */ > +#define USART_SR_DUMMY_RXBIT(16) > + > +/* USART_DR */ > +#define USART_DR_MASKGENMASK(8, 0) > + > +/* USART_BRR */ > +#define USART_BRR_DIV_F_MASK GENMASK(3, 0) > +#define USART_BRR_DIV_M_MASK GENMASK(15, 4) > +#define USART_BRR_DIV_M_SHIFT4 > + > +/* USART_CR1 */ > +#define USART_CR1_SBKBIT(0) > +#define USART_CR1_RWUBIT(1) > +#define USART_CR1_RE BIT(2) > +#define USART_CR1_TE BIT(3) > +#define USART_CR1_IDLEIE BIT(4) > +#define USART_CR1_RXNEIE BIT(5) > +#define USART_CR1_TCIE BIT(6) > +#define USART_CR1_TXEIE BIT(7) > +#define USART_CR1_PEIE BIT(8) > +#define USART_CR1_PS BIT(9) > +#define USART_CR1_PCEBIT(10) > +#define USART_CR1_WAKE BIT(11) > +#define USART_CR1_M BIT(12) > +#define USART_CR1_UE BIT(13) > +#define USART_CR1_OVER8 BIT(15) > +#define USART_CR1_IE_MASKGENMASK(8, 4) > + > +/* USART_CR2 */ > +#define USART_CR2_ADD_MASK GENMASK(3, 0) > +#define USART_CR2_LBDL BIT(5) > +#define USART_CR2_LBDIE BIT(6) > +#define USART_CR2_LBCL BIT(8) > +#define USART_CR2_CPHA BIT(9) >
Re: [PATCH V5 1/2] ARM: cpuidle: Register per cpuidle device
On Tue, Mar 24, 2015 at 09:54:01AM +, Daniel Lezcano wrote:
> If the cpuidle init cpu operation returns -ENXIO, therefore reporting HW
> failure or misconfiguration, the CPUidle driver skips the respective
> cpuidle device initialization because the associated platform back-end HW
> is not operational.
>
> That prevents the system to crash and allows to handle the error gracefully.
>
> For example, on Qcom's platform, each core has a SPM. The device associated
> with this SPM is initialized before the cpuidle framework. If there is an
> error
> in the initialization (eg. error in the DT), the system continues to boot but
> in degraded mode as some SPM may not be correctly initialized.
>
> Signed-off-by: Daniel Lezcano
Acked-by: Lorenzo Pieralisi
> ---
> drivers/cpuidle/cpuidle-arm.c | 45
> +--
> 1 file changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
> index 1c94b88..545069d 100644
> --- a/drivers/cpuidle/cpuidle-arm.c
> +++ b/drivers/cpuidle/cpuidle-arm.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -94,6 +95,7 @@ static int __init arm_idle_init(void)
> {
> int cpu, ret;
> struct cpuidle_driver *drv = &arm_idle_driver;
> + struct cpuidle_device *dev;
>
> /*
>* Initialize idle states data, starting at index 1.
> @@ -105,18 +107,57 @@ static int __init arm_idle_init(void)
> if (ret <= 0)
> return ret ? : -ENODEV;
>
> + ret = cpuidle_register_driver(drv);
> + if (ret) {
> + pr_err("Failed to register cpuidle driver\n");
> + return ret;
> + }
> +
> /*
>* Call arch CPU operations in order to initialize
>* idle states suspend back-end specific data
>*/
> for_each_possible_cpu(cpu) {
> ret = arm_cpuidle_init(cpu);
> +
> + /*
> + * Skip the cpuidle device initialization if the reported
> + * failure is a HW misconfiguration/breakage (-ENXIO).
> + */
> + if (ret == -ENXIO)
> + continue;
> +
> if (ret) {
> pr_err("CPU %d failed to init idle CPU ops\n", cpu);
> - return ret;
> + goto out_fail;
> + }
> +
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> + if (!dev) {
> + pr_err("Failed to allocate cpuidle device\n");
> + goto out_fail;
> + }
> + dev->cpu = cpu;
> +
> + ret = cpuidle_register_device(dev);
> + if (ret) {
> + pr_err("Failed to register cpuidle device for CPU %d\n",
> +cpu);
> + kfree(dev);
> + goto out_fail;
> }
> }
>
> - return cpuidle_register(drv, NULL);
> + return 0;
> +out_fail:
> + while (--cpu >= 0) {
> + dev = per_cpu(cpuidle_devices, cpu);
> + cpuidle_unregister_device(dev);
> + kfree(dev);
> + }
> +
> + cpuidle_unregister_driver(drv);
> +
> + return ret;
> }
> device_initcall(arm_idle_init);
> --
> 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: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi,
Am 21.03.2015 um 00:31 schrieb NeilBrown :
> On Fri, 20 Mar 2015 10:34:18 +0100 "Dr. H. Nikolaus Schaller"
> wrote:
>
>>
>> Am 20.03.2015 um 09:54 schrieb NeilBrown :
>
>>> There needs to be one device-node for each device, and that device-node
>>> needs
>>> to be a child of the device-node for the device which is the primary
>>> connection to the child device.
>>
>> Then please explain to me nodes like
>>
>> / {
>> compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";
>>
>> cpus {
>> cpu@0 {
>> cpu0-supply = <&vcc>;
>> };
>> };
>>
>> According to the rule you apply here it should be something like
>>
>> cpu@0 {
>> regulator {
>> …
>> }
>>
>>
>
> This exactly highlight one of the big problems with device tree as I see it.
>
> Each device can potentially have relationships with a number of other
> devices, for the supply of power, reset signalling, interrupt handled, data
> transfer, command transfer etc etc etc.
Yes. The network is a mesh.
>
> devicetree provides two ways to indicated a relationship between devices.
> One way is a parent/child arrangement. The other way is ad-hoc
> attribute = <&devicename>
> assignments.
Yes.
>
> Each device can only have one parent, but can have multiple arbitrary
> assignments.
>
> I would much rather that the parent/child relationship didn't exist at all.
> Each device should stand alone, and list all relationships explicitly. But
> that is not the way devicetree works, and we need to live with that.
Is it not how the device tree works or how we use it? Or how you think it
should better be?
What stops us from using it in arbitrary assignments like clocks and
regulators?
GPIOs are also a nice example: you just specify the gpio controller
and the gpio number to use it. There is no parent/child connection.
Why for tty / serial and serial consumers but not for GPIOs?
I have tried to find out the rules when parent>child is used (see below).
>
> So we need a clear understanding of what the 'parent' of a given device
> should be.
> I don't know what the specifications say, if anything, but what I see is that
> the parent is in practive a device which can ‘address' the child.
I think this holds only for “bus” devices - where it is really a good and
standard way of structuring the bus and it’s masters/slaves. One child
node per client.
> i.e.
> control signalling is the key parent->child relationship.
> This is consistent with the fact that many device nodes have a
> reg=
> attribute which gives the address of the node as seen by it's parent.
>
> Given that understanding, a regulator must be a child of the device which can
> control it - which can turn it on or off. Not a child of the device which
> receives power from it.
So you propose that the parent->child relationship is “control”? I.e. some
channel which allows to address some bus client (through ) and
control that devices.
Makes sense. This is how i2c and spi clients are specified.
>
> In the case of our GPS, it receives control over the serial connection from
> the UART,
Ahem - does it?
AFAIK the chip simply starts to emit NMEA records if powered on. There is no
command going over the serial interface to address it or control it.
> also receives control via a GPIO to the on/off pin, and also needs
> a regulator to power the antenna.
>
> So should the parent be the uart, the on/off GPIO, or the regulator?
>
> I would much rather there wasn't a parent, and that each of these were listed
> as ad-hoc attribute assignments. But device-tree says there must be a parent
> (where possible), and the parent is the thing that is “primarily" in control.
Well, IMHO the “parent” could also be the root. Representing the whole board.
Nevertheless, I doubt your rule that “ability to control” defines the
parent>child
relation (see below).
>
> I think the GPS is “primarily" a uart-attached device.
But not in the same way as an I2C device.
Especially the serial interface is not a bus and not used for signalling and
power control. It is payload data (only).
> So I propose a device-node which describes the GPS, which is a child of the
> UART, and explicitly identifies the GPIO it uses to power on/off, the
> regulator it uses to power the antenna, and how it receives "on or off"
> status indications from the GPS.
The more I think about that, you have given good arguments *not* to use the
parent->child relationship for the UART interface of the GPS.
Let me give another example. The 3G Modem has 3 (or 4) interfaces:
1. an USB-Interface for AT signalling and payload
2. some GPIOs for power control.
3. a PCM interface for digital voice.
4. it might also have a serial interface as alternate AT command and (GPRS
low speed) payload.
So which one is the most prominent or most important to make it a child of?
If you use “control” you must make it a chi
Re: [PATCH] [RFC] OF: probe order dependency aware of_platform_populate
Hi Geert,
> On Mar 24, 2015, at 07:50 , Geert Uytterhoeven wrote:
>
> Hi Pantelis, Grant,
>
> On Fri, Mar 20, 2015 at 12:39 PM, Pantelis Antoniou
> wrote:
>>> On Mar 19, 2015, at 21:18 , Grant Likely wrote:
>>>
>>> On Tue, 16 Dec 2014 14:11:31 +0200
>>> , Pantelis Antoniou
>>> wrote:
A nice side-effect of the changes in DTC for supporting overlays
is that it is now possible to do dependency tracking of platform
devices automatically.
This patch implements dependency aware probe order for users
of of_platform_populate.
There are no changes in the syntax of the DTS bindings, the
dependency is generated automatically by the use of phandle
references.
>>>
>>> Do you have measurements showing improvement? Conceptually, I don't have
>>> a problem with having a small scale solution like this, but I want proof
>>> that it actively makes things better, and is worth the extra complexity.
>>> It's not an easy block of code to understand.
>>>
>>
>> I will be the first to admit that the code it’s a bit hard to follow, but
>> that’s the nature of trees and recursion.
>>
>> FWIW I’ve been booting with this applied for a month with no adverse effects,
>> besides the fact that there dependency cycles which I would file as a bug.
>
> IIUC, this would fix the issue I worked around in "ARM: shmobile: r8a73a4:
> Move pfc node to work around probe ordering bug"?
> https://git.kernel.org/cgit/linux/kernel/git/horms/renesas.git/commit/?h=r8a73a4-ccf-and-multiplatform-for-v4.1&id=e4ba0a9bddff3ba52cec100414d2f178440efc91
>
A victim^Wtester! Yeah, it’s supposed to do that, but no guarantees, this is an
RFC.
I would be happy to know if it solves your problem or not, please keep me in
the loop.
> I'll give it a try when I'm back from ELC...
>
> Gr{oetje,eeting}s,
>
>Geert
>
Regards
— Pantelis
> --
> 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
--
To unsubscribe from this list: send the line "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/7] ARM: dts: enable regulator support for i.MX23/i.MX28
On Tue, Mar 24, 2015 at 07:45:39AM +0100, Stefan Wahren wrote: > Am 23.03.2015 um 19:37 schrieb Mark Brown: > > This might be the sort of thing normally handled by a system controller, > > I have to say I had assumed this had all been discussed in the previous > > iterations of this seriee. > sorry, but i missed this important fact. > If you speak of system controller, do you mean the usage of > drivers/mfd/syscon.c ? Yes. signature.asc Description: Digital signature
[PATCH v8 2/2] powerpc/mpc85xx: Add FSL QorIQ DPAA QMan support to device tree(s)
From: Kumar Gala
Signed-off-by: Kumar Gala
Signed-off-by: Geoff Thorpe
Signed-off-by: Hai-Ying Wang
Signed-off-by: Chunhe Lan
Signed-off-by: Poonam Aggrwal
[Emil Medve: Sync with the upstream binding]
Signed-off-by: Emil Medve
---
v8: Fix indentation/whitespaces
v7: Remove 'Change-Id'
v6: Rebase
arch/powerpc/boot/dts/b4qds.dtsi| 12 ++
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 69 ++
arch/powerpc/boot/dts/fsl/b4si-post.dtsi| 106 ++
arch/powerpc/boot/dts/fsl/p1023si-post.dtsi | 43
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 13 ++
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 13 ++
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 13 ++
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 13 ++
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 13 ++
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 78 +++
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 126 +++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 318
arch/powerpc/boot/dts/kmcoge4.dts | 12 ++
arch/powerpc/boot/dts/oca4080.dts | 12 ++
arch/powerpc/boot/dts/p1023rdb.dts | 12 ++
arch/powerpc/boot/dts/p2041rdb.dts | 12 ++
arch/powerpc/boot/dts/p3041ds.dts | 12 ++
arch/powerpc/boot/dts/p4080ds.dts | 12 ++
arch/powerpc/boot/dts/p5020ds.dts | 12 ++
arch/powerpc/boot/dts/p5040ds.dts | 12 ++
arch/powerpc/boot/dts/t104xqds.dtsi | 12 ++
arch/powerpc/boot/dts/t104xrdb.dtsi | 12 ++
arch/powerpc/boot/dts/t208xqds.dtsi | 12 ++
arch/powerpc/boot/dts/t208xrdb.dtsi | 12 ++
arch/powerpc/boot/dts/t4240qds.dts | 12 ++
arch/powerpc/boot/dts/t4240rdb.dts | 12 ++
26 files changed, 985 insertions(+)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index 24ed80d..559d006 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -106,6 +106,14 @@
size = <0 0x100>;
alignment = <0 0x100>;
};
+ qman_fqd: qman-fqd {
+ size = <0 0x40>;
+ alignment = <0 0x40>;
+ };
+ qman_pfdr: qman-pfdr {
+ size = <0 0x200>;
+ alignment = <0 0x200>;
+ };
};
dcsr: dcsr@f {
@@ -116,6 +124,10 @@
ranges = <0x0 0xf 0xf400 0x200>;
};
+ qportals: qman-portals@ff600 {
+ ranges = <0x0 0xf 0xf600 0x200>;
+ };
+
soc: soc@ffe00 {
ranges = <0x 0xf 0xfe00 0x100>;
reg = <0xf 0xfe00 0 0x1000>;
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index f35e9e0..f26e736 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -167,6 +167,75 @@
};
};
+&qportals {
+ qportal14: qman-portal@38000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x38000 0x4000>, <0x100e000 0x1000>;
+ interrupts = <132 0x2 0 0>;
+ fsl,qman-channel-id = <0xe>;
+ };
+ qportal15: qman-portal@3c000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x3c000 0x4000>, <0x100f000 0x1000>;
+ interrupts = <134 0x2 0 0>;
+ fsl,qman-channel-id = <0xf>;
+ };
+ qportal16: qman-portal@4 {
+ compatible = "fsl,qman-portal";
+ reg = <0x4 0x4000>, <0x101 0x1000>;
+ interrupts = <136 0x2 0 0>;
+ fsl,qman-channel-id = <0x10>;
+ };
+ qportal17: qman-portal@44000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x44000 0x4000>, <0x1011000 0x1000>;
+ interrupts = <138 0x2 0 0>;
+ fsl,qman-channel-id = <0x11>;
+ };
+ qportal18: qman-portal@48000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x48000 0x4000>, <0x1012000 0x1000>;
+ interrupts = <140 0x2 0 0>;
+ fsl,qman-channel-id = <0x12>;
+ };
+ qportal19: qman-portal@4c000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x4c000 0x4000>, <0x1013000 0x1000>;
+ interrupts = <142 0x2 0 0>;
+ fsl,qman-channel-id = <0x13>;
+ };
+ qportal20: qman-portal@5 {
+ compatible = "fsl,qman-portal";
+ reg = <0x5 0x4000>, <0x1014000 0x1000>;
+ interrupts = <144 0x2 0 0>;
+ fsl,qman-channel-id = <0x14>;
+ };
+ qportal21: qman-portal@54000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x54000 0x4000>, <0x1015000
Re: [PATCH v3] input: Add support for ChipOne icn8318 based touchscreens
Hi, On 03/22/2015 11:42 PM, Dmitry Torokhov wrote: On Sun, Mar 22, 2015 at 12:00:55PM +0100, Hans de Goede wrote: Hi, On 22-03-15 05:03, Dmitry Torokhov wrote: Hi Hans, On Tue, Mar 10, 2015 at 06:05:33PM +0100, Hans de Goede wrote: + error = devm_request_threaded_irq(dev, client->irq, NULL, icn8318_irq, + IRQF_TRIGGER_FALLING | IRQF_ONESHOT, Shouldn't we let DT data tell us what trigger to use? I.e. just leave IRQF_ONESHOT here? That is an interesting question, that new data is available is signalled by the irq pin of the chip going low is a property of the chip, not the board layout, so I believe it is best to leave this as is. My concern is that even if pin behavior is property of chip maybe on some boards we want to use level-triggered interrupts instead of edge? And if we indeed want to hard-code the trigger then shouldn't the binding document use onecell mapping (so that users do not attempt to configure triggers from DT)? The number of irq cells is specified by the interrupt controller driver rather then by the device binding. Also note that if we want to get this from devicetree, that simply leaving out the flag is not enough, we must specifically get the data from devicetree and pass it into request_irq AFAICT. So the above would change to: irqflags = irqd_get_trigger_type(irq_get_irq_data(client->irq)) | IRQF_ONESHOT, error = devm_request_threaded_irq(dev, client->irq, NULL, icn8318_irq, irqflags, No, of_irq_get() that i2c core calls before probing driver should already set the trigger type for us. There is no need for the individual drivers to do that. Ah I see, ok I've just tested removing the IRQF_TRIGGER_FALLING flag and indeed things still work fine, so feel free to merge this patch with that flagged dropped. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
Hi Maxime,
On 03/24/2015 01:21 PM, Maxime Coquelin wrote:
> Hi Peter,
>
> 2015-03-19 18:35 GMT+01:00 Maxime Coquelin :
>> 2015-03-19 15:58 GMT+01:00 Peter Hurley :
>>> On 03/19/2015 09:55 AM, Maxime Coquelin wrote:
+static void stm32_set_termios(struct uart_port *port, struct ktermios
*termios,
+ struct ktermios *old)
>>> [...]
+ usardiv = (port->uartclk * 25) / (baud * 4);
+ mantissa = (usardiv / 100) << USART_BRR_DIV_M_SHIFT;
+ fraction = DIV_ROUND_CLOSEST((usardiv % 100) * 16, 100);
+ if (fraction & ~USART_BRR_DIV_F_MASK) {
+ fraction = 0;
+ mantissa += (1 << USART_BRR_DIV_M_SHIFT);
+ }
>>> [...]
Really, I would prefer keeping this fractional divider as it is
implemented today.
>>>
>>> You have to admit that's basically an unintelligible mess;
>>> how would anyone ever be able to refactor and replace that with a
>>> common divider implementation?
>>>
>>> At the very least, please comment on the formula and format.
>>
>> Ok, I will refactor the implementation, and comment it.
>
> The implementation was indeed a mess.
> I found some time to refactor the code, and also added support for 8
> times oversampling (16 by default).
> It will allow to achieve higher speeds, with the side effect of being
> less tolerant to clock deviations.
>
> What do you think about the code below?
>
>
> usartdiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
>
> /*
> * The USART supports 16 or 8 times oversampling.
> * By default we prefer 16 times oversampling, so that the receiver
> * has a better tolerance to clock deviations.
> * 8 times oversampling is only used to achieve higher speeds.
> */
> if (usartdiv < 16) {
> oversampling = 8;
> stm32_set_bits(port, USART_CR1, USART_CR1_OVER8);
> } else {
> oversampling = 16;
> stm32_clr_bits(port, USART_CR1, USART_CR1_OVER8);
> }
>
> mantissa = (usartdiv / oversampling) << USART_BRR_DIV_M_SHIFT;
> fraction = usartdiv % oversampling;
> writel_relaxed(mantissa | fraction, port->membase + USART_BRR)
Thanks! Way better :)
Much more obvious this is a fixed-point divisor.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers
On Tue, Mar 24, 2015 at 09:18:14AM +, Srinivas Kandagatla wrote: > I did try your suggestion, by which I could remove the regmap from config. > One thing I did not like was eeprom-core getting size/stride info directly > from providers and regmap from regmap apis. I was wondering if we could take > a step further and introduce new regmap helpers like > regmap_get_size(regmap) This is already there. > regmap_get_stride(regmap) > Which would be give eeprom-core the size and stride info, doing this way > would cut down regmap related things from eeprom_config structure to minimal > and also the source of information would come from just regmap apis. Documentation/SubmittingPatches... signature.asc Description: Digital signature
Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
Hi Peter,
2015-03-19 18:35 GMT+01:00 Maxime Coquelin :
> 2015-03-19 15:58 GMT+01:00 Peter Hurley :
>> On 03/19/2015 09:55 AM, Maxime Coquelin wrote:
>>> +static void stm32_set_termios(struct uart_port *port, struct ktermios
>>> *termios,
>>> + struct ktermios *old)
>> [...]
>>> + usardiv = (port->uartclk * 25) / (baud * 4);
>>> + mantissa = (usardiv / 100) << USART_BRR_DIV_M_SHIFT;
>>> + fraction = DIV_ROUND_CLOSEST((usardiv % 100) * 16, 100);
>>> + if (fraction & ~USART_BRR_DIV_F_MASK) {
>>> + fraction = 0;
>>> + mantissa += (1 << USART_BRR_DIV_M_SHIFT);
>>> + }
>> [...]
>>> Really, I would prefer keeping this fractional divider as it is
>>> implemented today.
>>
>> You have to admit that's basically an unintelligible mess;
>> how would anyone ever be able to refactor and replace that with a
>> common divider implementation?
>>
>> At the very least, please comment on the formula and format.
>
> Ok, I will refactor the implementation, and comment it.
The implementation was indeed a mess.
I found some time to refactor the code, and also added support for 8
times oversampling (16 by default).
It will allow to achieve higher speeds, with the side effect of being
less tolerant to clock deviations.
What do you think about the code below?
usartdiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
/*
* The USART supports 16 or 8 times oversampling.
* By default we prefer 16 times oversampling, so that the receiver
* has a better tolerance to clock deviations.
* 8 times oversampling is only used to achieve higher speeds.
*/
if (usartdiv < 16) {
oversampling = 8;
stm32_set_bits(port, USART_CR1, USART_CR1_OVER8);
} else {
oversampling = 16;
stm32_clr_bits(port, USART_CR1, USART_CR1_OVER8);
}
mantissa = (usartdiv / oversampling) << USART_BRR_DIV_M_SHIFT;
fraction = usartdiv % oversampling;
writel_relaxed(mantissa | fraction, port->membase + USART_BRR)
Thanks,
Maxime
>
> Regards,
> Maxime
>
>>
>> Regards,
>> Peter Hurley
--
To unsubscribe from this list: send the line "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 v8 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex
Add binding documentation for the Qualcomm Hardware Mutex.
Reviewed-by: Andy Gross
Reviewed-by: Jeffrey Hugo
Signed-off-by: Bjorn Andersson
---
Changes since v7:
- Corrected address, compatible and naming of the tcsr block
Changes since v6:
- Corrected indentation error in example
Changes since v5:
- Extracted the dt binding documentation into a separate patch
- Moved the driver to consume a syscon
- Dropped previously suggested generic hwlock dt bindings
.../devicetree/bindings/hwlock/qcom-hwspinlock.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
new file mode 100644
index 000..4563f52
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
@@ -0,0 +1,39 @@
+Qualcomm Hardware Mutex Block:
+
+The hardware block provides mutexes utilized between different processors on
+the SoC as part of the communication protocol used by these processors.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,sfpb-mutex",
+ "qcom,tcsr-mutex"
+
+- syscon:
+ Usage: required
+ Value type:
+ Definition: one cell containing:
+ syscon phandle
+ offset of the hwmutex block within the syscon
+ stride of the hwmutex registers
+
+- #hwlock-cells:
+ Usage: required
+ Value type:
+ Definition: must be 1, the specified cell represent the lock id
+ (hwlock standard property, see hwlock.txt)
+
+Example:
+
+ tcsr_mutex_block: syscon@fd484000 {
+ compatible = "syscon";
+ reg = <0xfd484000 0x2000>;
+ };
+
+ hwlock@fd484000 {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_block 0 0x80>;
+
+ #hwlock-cells = <1>;
+ };
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/1] dts: cubox: Map gpio-keys to gpio3 8
Rebased the patch on rmk's relicensing patch... "ARM: dts: Re-license SolidRun iMX6 platform DT GPL v2/X11" George Joseph (1): dts: cubox: Map gpio-keys to gpio3 8 arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 20 1 file changed, 20 insertions(+) -- 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
[PATCH v3 1/1] dts: cubox: Map gpio-keys to gpio3 8
The Cubox has a recessed button between the HDMI and RJ-45 connectors
that wasn't mapped in the device tree, so I've mapped it to gpio-keys
BTN_0.
Signed-off-by: George Joseph
Tested-by: George Joseph
---
arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
index 4303bc0..d033bb1 100644
--- a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
@@ -41,6 +41,8 @@
*/
#include "imx6qdl-microsom.dtsi"
#include "imx6qdl-microsom-ar8035.dtsi"
+#include
+#include
/ {
ir_recv: ir-receiver {
@@ -104,6 +106,18 @@
spdif-controller = <&spdif>;
spdif-out;
};
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&pinctrl_gpio_key>;
+ pinctrl-names = "default";
+
+ button_0 {
+ label = "Button 0";
+ gpios = <&gpio3 8 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
};
&hdmi {
@@ -208,6 +222,12 @@
MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x13059
>;
};
+
+ pinctrl_gpio_key: gpio-key {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_DA8__GPIO3_IO08 0x17059
+ >;
+ };
};
};
--
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 1/5] drivers: soc: sunxi: Introduce SoC driver to map SRAMs
Hi,
On Fri, Mar 20, 2015 at 07:52:45PM +0100, Hans de Goede wrote:
> From: Maxime Ripard
>
> The Allwinner SoCs have a handful of SRAM that can be either mapped to be
> accessible by devices or the CPU.
>
> That mapping is controlled by an SRAM controller, and that mapping might not
> be
> set by the bootloader, for example if the device wasn't used at all, or if
> we're using solutions like the U-Boot's Falcon Boot.
>
> We could also imagine changing this at runtime for example to change the
> mapping of these SRAMs to use them for suspend/resume or runtime memory rate
> change, if that ever happens.
>
> These use cases require some API in the kernel to control that mapping,
> exported through a drivers/soc driver.
>
> This driver also implement a debugfs file that shows the SRAM found in the
> system, the current mapping and the SRAM that have been claimed by some
> drivers
> in the kernel.
>
> Signed-off-by: Maxime Ripard
> [hdego...@redhat.com: Changed compat string to sun4i-a10-sram-controller, as
> the sram controller is identical on sun4i, sun5i & sun7i, added devicetree
> binding documentation, fixed some checkpatch warnings]
> Signed-off-by: Hans de Goede
> ---
> .../devicetree/bindings/soc/sunxi/sram.txt | 64 ++
> drivers/soc/Kconfig| 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/sunxi/Kconfig | 12 ++
> drivers/soc/sunxi/Makefile | 1 +
> drivers/soc/sunxi/sunxi_sram.c | 235
> +
> include/linux/soc/sunxi/sunxi_sram.h | 24 +++
> 7 files changed, 338 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/sunxi/sram.txt
> create mode 100644 drivers/soc/sunxi/Kconfig
> create mode 100644 drivers/soc/sunxi/Makefile
> create mode 100644 drivers/soc/sunxi/sunxi_sram.c
> create mode 100644 include/linux/soc/sunxi/sunxi_sram.h
>
> diff --git a/Documentation/devicetree/bindings/soc/sunxi/sram.txt
> b/Documentation/devicetree/bindings/soc/sunxi/sram.txt
> new file mode 100644
> index 000..6e1bc80
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/sunxi/sram.txt
> @@ -0,0 +1,64 @@
> +Allwinnner sun4i / sun5i / sun7i SoC SRAM controllers
> +-
> +
> +Required properties:
> +- compatible : "allwinner,sun4i-a10-sram-controller"
> +- reg : sram controller register offset + length
> +
> +SRAM nodes
> +--
> +
> +Besides a node for the SRAM controller the devicetree must also contain a
> +node for each SRAM block controlled by the controller.
> +
> +Required sram node properties:
> +- compatible : "allwinner,sun4i-a10-sram"
> +- allwinner,sram-name : should be one of
> + * "A1"
> + * "A2"
> + * "A3-A4"
> + * "D"
> +
> +Example
> +---
> +
> +/*
> + * Note we use the address were mmio register start, not where
^ where
> + * the SRAM blocks starts, this cannot be changed because doing
^ start
> + * doing so would be a devicetree ABI change.
One doing too many ? :)
> + */
> +soc@01c0 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + sram@ {
> + compatible = "allwinner,sun4i-a10-sram";
> + reg = <0x 0x4000>;
> + allwinner,sram-name = "A1";
> + };
> +
> + sram@4000 {
> + compatible = "allwinner,sun4i-a10-sram";
> + reg = <0x4000 0x4000>;
> + allwinner,sram-name = "A2";
> + };
> +
> + sram@8000 {
> + compatible = "allwinner,sun4i-a10-sram";
> + reg = <0x8000 0x4000>;
> + allwinner,sram-name = "A3-A4";
> + };
> +
> + sram@0001 {
> + compatible = "allwinner,sun4i-a10-sram";
> + reg = <0x0001 0x1000>;
> + allwinner,sram-name = "D";
> + };
> +
> + sram-controller@01c0 {
> + compatible = "allwinner,sun4i-a10-sram-controller";
> + reg = <0x01c0 0x30>;
> + };
> +};
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 76d6bd4..5d0f55d 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -1,6 +1,7 @@
> menu "SOC (System On Chip) specific Drivers"
>
> source "drivers/soc/qcom/Kconfig"
> +source "drivers/soc/sunxi/Kconfig"
> source "drivers/soc/ti/Kconfig"
> source "drivers/soc/versatile/Kconfig"
>
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 063113d..170bba3 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -3,6 +3,7 @@
> #
>
> obj-$(CONFIG_ARCH_QCOM) += qcom/
> +obj-$(CONFIG_ARCH_SUNXI) += sunxi/
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_SOC_TI) += ti/
> obj-$(CONFIG_PLAT_VERSATILE) += versatile/
> diff --git a/drivers/soc/
Re: [PATCH v7 3/8] ARM: dt: Binding documentation for imx25 touchscreen controller
On Sat, Mar 07, 2015 at 05:37:04PM +, Jonathan Cameron wrote: > On 03/03/15 07:58, Markus Pargmann wrote: > > This is the touchscreen conversion queue binding documentation. It uses > > the shared imx25 ADC. > > > > Signed-off-by: Markus Pargmann > Looks fine, one more general binding approach comment though. > A lot of the vendor specific elements in here are awfully generic. > Does it not make sense to have them as standard attributes for > touch screen drivers? > > --- > > > > Notes: > > Changes in v5: > > - Fix signed/unsigned comparison > > - Fix unused variable settling_time by putting it in the correct > > argument list > > - Use continous conversion queue with the repeat feature and a proper > >repeat-wait. Previously the touchscreen caused massive number of > > interrupts. > > > > .../bindings/input/touchscreen/fsl-mx25-tcq.txt| 29 > > ++ > > 1 file changed, 29 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt > > > > diff --git > > a/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt > > b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt > > new file mode 100644 > > index ..4214a99d197a > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt > > @@ -0,0 +1,29 @@ > > +Freescale mx25 TS conversion queue module > > + > > +mx25 touchscreen conversion queue module which controls the ADC unit of the > > +mx25 for attached touchscreens. > > + > > +Required properties: > > + - compatible: Should be "fsl,imx25-tcq". > > + - reg: Memory range of the device. > > + - interrupts: Should be the interrupt number associated with this module > > within > > + the tscadc unit (<0>). > > + - interrupt-parent: Should be a phandle to the tscadc unit. > > + - fsl,wires: Should be '<4>' or '<5>' > > + > > +Optional properties: > > + - fsl,pen-debounce: Pen debounce time. > > + - fsl,pen-threshold: Pen-down threshold for the touchscreen. > > + - fsl,settling-time: Settling time in nanoseconds. > Obviously it's up to Dmitry etc, but are these not standard enough attributes > to > not be vendor specific? I'd expect say touch-pen-debouce and > touch-pen-threshold > etc to be standard binding elements for touch screens. Seems like a good idea. I just discovered that there is a 'touchscreen-fuzz-pressure' which seems to be the same as fsl,pen-threshold. So this should be replaced in my patches. The other properties do not exist. Dmitry, what do you think about some standard properties for the remaining? Best Regards, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
Re: [PATCH 5/5] net: allwinner: emac: Claim our SRAM
On Fri, Mar 20, 2015 at 07:52:49PM +0100, Hans de Goede wrote:
> From: Maxime Ripard
>
> The SRAM the EMAC is using might not have been mapped accordingly by the
> bootloader, preventing the EMAC to work properly.
>
> Ask for that SRAM to be mapped at probe time to make sure that this never
> happens.
>
> Signed-off-by: Maxime Ripard
> [hdego...@redhat.com: Make sure SUNXI_SRAM gets enabled in Kconfig]
> Signed-off-by: Hans de Goede
> ---
> drivers/net/ethernet/allwinner/sun4i-emac.c | 13 +++--
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 1 +
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c
> b/drivers/net/ethernet/allwinner/sun4i-emac.c
> index f3470d9..9d0136b 100644
> --- a/drivers/net/ethernet/allwinner/sun4i-emac.c
> +++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
> @@ -29,6 +29,8 @@
> #include
> #include
>
> +#include
> +
> #include "sun4i-emac.h"
>
> #define DRV_NAME "sun4i-emac"
> @@ -857,11 +859,15 @@ static int emac_probe(struct platform_device *pdev)
>
> clk_prepare_enable(db->clk);
>
> + ret = sunxi_sram_claim(SUNXI_SRAM_EMAC, "emac");
> + if (ret)
> + dev_warn(&pdev->dev, "Couldn't map SRAM to device\n");
> +
> db->phy_node = of_parse_phandle(np, "phy", 0);
> if (!db->phy_node) {
> dev_err(&pdev->dev, "no associated PHY\n");
> ret = -ENODEV;
> - goto out;
> + goto out_release_sram;
> }
>
> /* Read MAC-address from DT */
> @@ -893,7 +899,7 @@ static int emac_probe(struct platform_device *pdev)
> if (ret) {
> dev_err(&pdev->dev, "Registering netdev failed!\n");
> ret = -ENODEV;
> - goto out;
> + goto out_release_sram;
> }
>
> dev_info(&pdev->dev, "%s: at %p, IRQ %d MAC: %pM\n",
> @@ -901,6 +907,8 @@ static int emac_probe(struct platform_device *pdev)
>
> return 0;
>
> +out_release_sram:
> + sunxi_sram_release(SUNXI_SRAM_EMAC);
> out:
> dev_err(db->dev, "not found (%d).\n", ret);
>
> @@ -914,6 +922,7 @@ static int emac_remove(struct platform_device *pdev)
> struct net_device *ndev = platform_get_drvdata(pdev);
>
> unregister_netdev(ndev);
> + sunxi_sram_release(SUNXI_SRAM_EMAC);
> free_netdev(ndev);
>
> dev_dbg(&pdev->dev, "released and freed device\n");
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index 7d3af19..785ca22 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -16,6 +16,7 @@ if STMMAC_ETH
> config STMMAC_PLATFORM
> tristate "STMMAC Platform bus support"
> depends on STMMAC_ETH
> + select SUNXI_SRAM if ARCH_SUNXI
> default y
> ---help---
> This selects the platform specific bus support for the stmmac driver.
Shouldn't that be in emac's Kconfig option instead?
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH 2/5] ARM: dts: sun4i: Add A10 SRAM and SRAM controller
On Fri, Mar 20, 2015 at 07:52:46PM +0100, Hans de Goede wrote:
> The A10 has a few SRAM that can be mapped either to a device or to the CPU,
> with the mapping being controlled by a SRAM controller.
>
> Since most of the time these SRAM won't be accessible by the CPU,
> we can't use the mmio-sram driver and compatible.
>
> Signed-off-by: Hans de Goede
> ---
> arch/arm/boot/dts/sun4i-a10.dtsi | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi
> b/arch/arm/boot/dts/sun4i-a10.dtsi
> index b66ebb3..88f57b4 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -451,12 +451,46 @@
> };
> };
>
> + /*
> + * Note we use the address were mmio registers start, not where the
^ where
> + * SRAM blocks start, this cannot be changed because that would be
> + * a devicetree ABI change.
> + */
> soc@01c0 {
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> + sram@ {
> + compatible = "allwinner,sun4i-a10-sram";
> + reg = <0x 0x4000>;
> + allwinner,sram-name = "A1";
> + };
> +
> + sram@4000 {
> + compatible = "allwinner,sun4i-a10-sram";
> + reg = <0x4000 0x4000>;
> + allwinner,sram-name = "A2";
> + };
> +
> + sram@8000 {
> + compatible = "allwinner,sun4i-a10-sram";
> + reg = <0x8000 0x4000>;
> + allwinner,sram-name = "A3-A4";
> + };
> +
> + sram@0001 {
> + compatible = "allwinner,sun4i-a10-sram";
> + reg = <0x0001 0x1000>;
> + allwinner,sram-name = "D";
> + };
> +
> + sram-controller@01c0 {
> + compatible = "allwinner,sun4i-a10-sram-controller";
> + reg = <0x01c0 0x30>;
> + };
> +
> dma: dma-controller@01c02000 {
> compatible = "allwinner,sun4i-a10-dma";
> reg = <0x01c02000 0x1000>;
> --
> 2.3.3
>
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[PATCH] devicetree: Add vendor prefix for Shelly, Inc.
Signed-off-by: Nicolas Ferre --- Thierry, Here it is ;-) Bye, Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index a9eeaa0c5867..1b0f5b797cd5 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -165,6 +165,7 @@ sbs Smart Battery System schindler Schindler seagateSeagate Technology PLC semtechSemtech Corporation +shelly Shelly, Inc. silSilicon Image silabs Silicon Laboratories siliconmitus Silicon Mitus, Inc. -- 2.1.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] devicetree: Add vendor prefix for Foxlink Group
Signed-off-by: Nicolas Ferre --- Thierry, Boris added the support for a Foxlink panel in this commit: 102932b0e474 (drm/panel: add support for Foxlink FL500WVR00-A0T panel). Here is the vendor prefix. Bye, Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1b0f5b797cd5..e9fca088ba1a 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -73,6 +73,7 @@ everspin Everspin Technologies, Inc. excito Excito fcsFairchild Semiconductor fireflyFirefly +foxlinkFoxlink Group fslFreescale Semiconductor GEFanucGE Fanuc Intelligent Platforms Embedded Systems, Inc. gefGE Fanuc Intelligent Platforms Embedded Systems, Inc. -- 2.1.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
Master-aware devices and sideband ID data
Hi all,
For some devices, identification of particular masters is critical to
their operation (e.g. IOMMUs, MSI controllers). The identity of masters
is determined from sideband signals on the bus, and it may or may not be
possible to probe and/or configure this information. Worse still, these
information may be rewritten by intermediate buses, so the
information for a given master may differ at different points in the bus
hierarchy.
We currently describe this master information for devices attached to
IOMMUs, with a master ID being encoded in the iommu-cells. However this
only covers the ID between the master and its IOMMU(s), and we don't
currently have a mechanism to describe the master IDs as they are seen
by devices beyond the IOMMU(s), or in the absence of any IOMMU(s).
The following are example of master IDs:
* PCIe Requester IDs (RIDs) (bus:device.function AKA BDF)
* SMMU Stream IDs (SIDs)
* GICv3 ITS Device IDs (DIDs)
In the case of a system with PCIe, SMMU and GICv3, the master IDs are
rewritten in a chain of RID=>SID=>DID, as in the following diagram:
+-+
| PCIe master |
+-+
||
|| Requester ID (RID)
|| Probeable from RC.
\/
+---+
| PCIe Root Complex |
+---+
||
|| SMMU Stream ID (SID)
|| Derived from RID, static non-probeable mapping.
\/
+--+
| SMMU (IOMMU) |
+--+
||
|| ITS Device ID (DID)
|| Derived from SID, static non-probeable mapping.
\/
++
| GICv3 ITS (MSI controller) |
++
In simpler cases, you might have a simpler set of master ID
translations, e.g. just a DID:
+-+
| Platform device |
+-+
||
|| ITS Device ID (DID)
|| Hard-wired on the bus.
\/
++
| GICv3 ITS (MSI controller) |
++
Ignoring current bindings for the moment, I can see how we can describe
this with a generic master id-binding, with master-id-map along the
lines of interrupt-map, with a tuple format like:
For the PCIe example, this would look something like the following (with
properties omitted for brevity):
PCI: pci@af00 {
...
/* Requester ID of PCIe endpoints, implicit at runtime */
master-id-cells = <1>;
/* RIDS idmapped to SIDS @ SMMU */
master-id-map = <0 0x1 &SMMU 0>;
}
SMMU: iommu@bf00 {
...
/* SID, derived from RID */
master-id-cells = <1>;
/*
* For some reason the high bit of the ID was negated.
*/
master-id-map = <0x 0x8000 &ITS 0x0 0x8000>,
<0x8000 0x8000 &ITS 0x0 0x>;
};
ITS: its@cf00 {
...
/* DID, derived from SID */
master-id-cells = <2>;
/*
* Master traffic not propagated beyond this point, so no
* master-id-ranges
*/
};
For the simpler case, this would look something like:
DEV: device@af00 {
master-id-cells = <1>;
master-ids = <0xf>, <0xb>;
master-id-map = <0 0xf &ITS 0 0>;
};
ITS: its@cf00 {
...
/* DID */
master-id-cells = <2>;
};
However, this conflicts/overlaps with existing bindings (at least iommus
and msi-parent), and I'm not sure how to reconcile them. Am I missing a
neat way of describing this that works with the existing bindings?
It's also not clear to me if it's sufficient to have a generic
"master-ids" property (with the relevant type being implicit from
context), or if each type of ID needs each type of ID (RID, SID, DID,
etc) needs its own.
Which other devices out there which require side-band master
information, and what do they require?
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] iio: mlx90614 enhancements
This series follows up on the first series sent on February 25. I have dropped the filter configuration for now, as I am still trying to figure out how to do that properly. This set of patches adds the following additional features to the mlx90614 temperature sensor driver. * Support for the dual IR sensor model (patch 3) * Emissivity setting (patches 4 and 5) * Power management (patch 6) * Handle errors in temperature reading (patch 7) The changes have been split into 7 patches to ease code review. Patches 1 and 2 contain mandatory symbol definitions, which have already been applied to the togreg branch of iio.git. Patches 3, 5-7 implement the additional features and are mostly independent from each other. Patch 4 introduces IIO_CHAN_INFO_EMISSIVITY in iio core and is a prerequisite of patch 5. Patch 6 introduces device tree bindings and is the only one sent to the devicetree list. Patch set history: v2: * Drop processed temperature output (v1 patch 3) * Drop raw IR values for now (v1 patch 7) * Drop iir, fir, and gain attributes for now (v1 patch 5) * Introduce standard attribute for emissivity (patches 4 and 5) * Add patch 7, fixing wrong readings * Return -EINTR when wake-up is interrupted during read (patch 6) * Make adding vendor prefix explicit in commit message of patch 6 Vianney le Clément de Saint-Marcq (7): iio: mlx90614: Refactor register symbols iio: mlx90614: Add symbols for accessible registers iio: mlx90614: Support devices with dual IR sensor iio: core: Introduce IIO_CHAN_INFO_EMISSIVITY iio: mlx90614: Add emissivity setting iio: mlx90614: Add power management iio: mlx90614: Check for errors in read values Documentation/ABI/testing/sysfs-bus-iio| 11 + .../bindings/iio/temperature/mlx90614.txt | 24 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/industrialio-core.c| 1 + drivers/iio/temperature/mlx90614.c | 450 - include/linux/iio/iio.h| 1 + 6 files changed, 472 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/iio/temperature/mlx90614.txt -- 2.3.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] iio: mlx90614: Add power management
Add support for system sleep and runtime power management.
To wake up the device, the SDA line should be held low for at least 33ms
while SCL is high. As this is not possible using the i2c API (and not
supported by all i2c adapters), a GPIO connected to the SDA line is
needed. The GPIO is named "wakeup" and can be specified in a device
tree with the "wakeup-gpios" binding.
If the wake-up GPIO is not given, disable power management for the
device. Entering sleep requires an SMBus byte access, hence power
management is also disabled if byte access is not supported by the
adapter.
Introduce "melexis" as a vendor prefix for device tree bindings.
Signed-off-by: Vianney le Clément de Saint-Marcq
Cc: Arnout Vandecappelle (Essensium/Mind)
---
The default autosleep delay (5s) is chosen arbitrarily, trying to take
into account the long startup time (250ms). Feel free to change it to
another value if you think it is saner.
v2: return -EINTR when the startup delay is interrupted
---
.../bindings/iio/temperature/mlx90614.txt | 24 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
drivers/iio/temperature/mlx90614.c | 246 -
3 files changed, 269 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/iio/temperature/mlx90614.txt
diff --git a/Documentation/devicetree/bindings/iio/temperature/mlx90614.txt
b/Documentation/devicetree/bindings/iio/temperature/mlx90614.txt
new file mode 100644
index 000..9be57b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/mlx90614.txt
@@ -0,0 +1,24 @@
+* Melexis MLX90614 contactless IR temperature sensor
+
+http://melexis.com/Infrared-Thermometer-Sensors/Infrared-Thermometer-Sensors/MLX90614-615.aspx
+
+Required properties:
+
+ - compatible: should be "melexis,mlx90614"
+ - reg: the I2C address of the sensor
+
+Optional properties:
+
+ - wakeup-gpios: device tree identifier of the GPIO connected to the SDA line
+ to hold low in order to wake up the device. In normal operation, the
+ GPIO is set as input and will not interfere in I2C communication. There
+ is no need for a GPIO driving the SCL line. If no GPIO is given, power
+ management is disabled.
+
+Example:
+
+mlx90614@5a {
+ compatible = "melexis,mlx90614";
+ reg = <0x5a>;
+ wakeup-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index fae26d0..c8db30c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -110,6 +110,7 @@ lltcLinear Technology Corporation
marvellMarvell Technology Group Ltd.
maxim Maxim Integrated Products
mediatek MediaTek Inc.
+melexisMelexis N.V.
merrii Merrii Technology Co., Ltd.
micrel Micrel Inc.
microchip Microchip Technology Inc.
diff --git a/drivers/iio/temperature/mlx90614.c
b/drivers/iio/temperature/mlx90614.c
index b981d1e..6b9bfcd 100644
--- a/drivers/iio/temperature/mlx90614.c
+++ b/drivers/iio/temperature/mlx90614.c
@@ -12,13 +12,24 @@
*
* (7-bit I2C slave address 0x5a, 100KHz bus speed only!)
*
- * TODO: sleep mode, filter configuration
+ * To wake up from sleep mode, the SDA line must be held low while SCL is high
+ * for at least 33ms. This is achieved with an extra GPIO that can be
connected
+ * directly to the SDA line. In normal operation, the GPIO is set as input and
+ * will not interfere in I2C communication. While the GPIO is driven low, the
+ * i2c adapter is locked since it cannot be used by other clients. The SCL
line
+ * always has a pull-up so we do not need an extra GPIO to drive it high. If
+ * the "wakeup" GPIO is not given, power management will be disabled.
+ *
+ * TODO: filter configuration
*/
#include
#include
#include
#include
+#include
+#include
+#include
#include
@@ -52,9 +63,13 @@
#define MLX90614_TIMING_WAKEUP 34 /* time to hold SDA low for wake-up */
#define MLX90614_TIMING_STARTUP 250 /* time before first data after wake-up */
+#define MLX90614_AUTOSLEEP_DELAY 5000 /* default autosleep delay */
+
struct mlx90614_data {
struct i2c_client *client;
struct mutex lock; /* for EEPROM access only */
+ struct gpio_desc *wakeup_gpio; /* NULL to disable sleep/wake-up */
+ unsigned long ready_timestamp; /* in jiffies */
};
/*
@@ -95,6 +110,54 @@ static s32 mlx90614_write_word(const struct i2c_client
*client, u8 command,
return ret;
}
+#ifdef CONFIG_PM
+/*
+ * If @startup is true, make sure MLX90614_TIMING_STARTUP ms have elapsed since
+ * the last wake-up. This is normally only needed to get a valid temperature
+ * reading. EEPROM access does not need such delay.
+ * Return 0 on success, <0 on error.
+ */
+static int mlx90614_power_get(struct mlx90614_data *data, bool startup)
+{
+ unsigned lo
Re: [PATCH v3 0/7] Use DRM component API in tilcdc to connect to tda998x
On 03/24/15 17:16, Tomi Valkeinen wrote: On 24/03/15 16:28, Jyri Sarha wrote: I tried first with 3.19 and then with 4.0-rc5, checked the boot and then the modetest, but I could not reproduce the trace above. In my config I just have CONFIG_DRM=m and CONFIG_DRM_I2C_NXP_TDA998X=m on top of plain omap2plus_defconfig. Should I take something else? Anyway, I doubt this has anything to do with my patches. Could you give it one more try without my patches? 4.0-rc3 works ok for me without your patches. I can run modetest and I get a picture on the monitor. Well, not 100% ok. If I run my test app, I get "BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:949". With your patches I get the warnings and I don't get anything on the screen. I've attached my kernel config. Hmm. The warning comes if tilcdc_crtc_mode_valid() fails (I think). My monitor is not a HDMI monitor. It has native mode 1920x1200@60, which cannot be produced by tilcdc, and on -rc3 the mode picked is 1280x960@60. Oh-o. That is the reason then. My HDMI TV also - wrongly - advertises having 1920x1200@60 mode. When that mode produced the error I did not think much of it and tested with other modes. Maybe this is somehow related? You're using a HDMI TV? What mode does it pick? Is it the native mode? Hmm, yes, I think it's related. Enabling debug prints shows: [ 32.361924] [drm:tilcdc_crtc_mode_valid] Processing mode 1920x1080@60 with pixel clock 148500 [ 32.370850] [drm:tilcdc_crtc_mode_valid] Pruning mode: pixel clock too high [ 32.378143] [ cut here ] [ 32.382993] WARNING: CPU: 0 PID: 50 at drivers/gpu/drm/tilcdc/tilcdc_crtc.c:269 tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]() [ 32.394641] Modules linked in: tilcdc tda998x drm_kms_helper drm [ 32.400964] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 4.0.0-rc3-7-g944a1f8a79f1 #16 [ 32.409617] Hardware name: Generic AM33XX (Flattened Device Tree) So maybe your series removes some filtering somewhere, and illegal modes get passed forward? It indeed looks like that. The actual tilcdc_slave code does not have much much logic in it, but is sounds like the DRM slave encoder API and the DRM external encoder API are not entirely entirely "compatible". I'll try to track this further. Thanks, Jyri -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] ARM: dts: am57xx-beagle-x15: Add thermal map to include fan and tmp102
On Mon, Mar 23, 2015 at 02:39:39PM -0500, Nishanth Menon wrote:
> BeagleBoard-X15 has capability for a fan and has an onboard TMP102
> temperature sensor as well. This allows us to create a new thermal
> zone (called, un-imaginatively "board"), and allows us to use some
> active cooling as temperatures start edge upward in the system by
> creating a new alert temperature (emperically 50C) for cpu.
>
> NOTE: Fan is NOT mounted by default on the platform, in such a case,
> all we end up doing is switch on a regulator and leak very minimal
> current.
>
> Signed-off-by: Nishanth Menon
Acked-by: Eduardo Valentin
> ---
> Changes since V1:
> - slight change in omap4-cpu-thermal for usage in am57xx-dtsi
> - Not carrying forward ack due to change
>
> V1: http://marc.info/?t=14268810274&r=1&w=2
>
> arch/arm/boot/dts/am57xx-beagle-x15.dts | 49
> ++
> arch/arm/boot/dts/omap4-cpu-thermal.dtsi |4 +--
> 2 files changed, 51 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 41642fe770a1..6a3621c23017 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -86,6 +86,7 @@
> gpios = <&tps659038_gpio 1 GPIO_ACTIVE_HIGH>;
> gpio-fan,speed-map = <0 0>,
><13000 1>;
> + #cooling-cells = <2>;
> };
>
> extcon_usb1: extcon_usb1 {
> @@ -441,6 +442,7 @@
> pinctrl-0 = <&tmp102_pins_default>;
> interrupt-parent = <&gpio7>;
> interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
> + #thermal-sensor-cells = <1>;
> };
> };
>
> @@ -559,3 +561,50 @@
> &usb2 {
> dr_mode = "peripheral";
> };
> +
> +&cpu_trips {
> + cpu_alert1: cpu_alert1 {
> + temperature = <5>; /* millicelsius */
> + hysteresis = <2000>; /* millicelsius */
> + type = "active";
> + };
> +};
> +
> +&cpu_cooling_maps {
> + map1 {
> + trip = <&cpu_alert1>;
> + cooling-device = <&gpio_fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> +};
> +
> +&thermal_zones {
> + board_thermal: board_thermal {
> + polling-delay-passive = <1250>; /* milliseconds */
> + polling-delay = <1500>; /* milliseconds */
> +
> + /* sensor ID */
> + thermal-sensors = <&tmp102 0>;
> +
> + board_trips: trips {
> + board_alert0: board_alert {
> + temperature = <4>; /* millicelsius */
> + hysteresis = <2000>; /* millicelsius */
> + type = "active";
> + };
> +
> + board_crit: board_crit {
> + temperature = <105000>; /* millicelsius */
> + hysteresis = <0>; /* millicelsius */
> + type = "critical";
> + };
> + };
> +
> + board_cooling_maps: cooling-maps {
> + map0 {
> + trip = <&board_alert0>;
> + cooling-device =
> + <&gpio_fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
> b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
> index cb9458feb2e3..ab7f87ae96f0 100644
> --- a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
> +++ b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
> @@ -18,7 +18,7 @@ cpu_thermal: cpu_thermal {
> /* sensor ID */
> thermal-sensors = <&bandgap 0>;
>
> -trips {
> + cpu_trips: trips {
> cpu_alert0: cpu_alert {
> temperature = <10>; /* millicelsius */
> hysteresis = <2000>; /* millicelsius */
> @@ -31,7 +31,7 @@ cpu_thermal: cpu_thermal {
> };
> };
>
> - cooling-maps {
> + cpu_cooling_maps: cooling-maps {
> map0 {
> trip = <&cpu_alert0>;
> cooling-device =
> --
> 1.7.9.5
>
signature.asc
Description: Digital signature
Re: [PATCH v3 0/7] Use DRM component API in tilcdc to connect to tda998x
On 24/03/15 16:28, Jyri Sarha wrote: > I tried first with 3.19 and then with 4.0-rc5, checked the boot and then > the modetest, but I could not reproduce the trace above. > > In my config I just have CONFIG_DRM=m and CONFIG_DRM_I2C_NXP_TDA998X=m > on top of plain omap2plus_defconfig. Should I take something else? > > Anyway, I doubt this has anything to do with my patches. Could you give > it one more try without my patches? 4.0-rc3 works ok for me without your patches. I can run modetest and I get a picture on the monitor. Well, not 100% ok. If I run my test app, I get "BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:949". With your patches I get the warnings and I don't get anything on the screen. I've attached my kernel config. Hmm. The warning comes if tilcdc_crtc_mode_valid() fails (I think). My monitor is not a HDMI monitor. It has native mode 1920x1200@60, which cannot be produced by tilcdc, and on -rc3 the mode picked is 1280x960@60. Maybe this is somehow related? You're using a HDMI TV? What mode does it pick? Is it the native mode? Hmm, yes, I think it's related. Enabling debug prints shows: [ 32.361924] [drm:tilcdc_crtc_mode_valid] Processing mode 1920x1080@60 with pixel clock 148500 [ 32.370850] [drm:tilcdc_crtc_mode_valid] Pruning mode: pixel clock too high [ 32.378143] [ cut here ] [ 32.382993] WARNING: CPU: 0 PID: 50 at drivers/gpu/drm/tilcdc/tilcdc_crtc.c:269 tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]() [ 32.394641] Modules linked in: tilcdc tda998x drm_kms_helper drm [ 32.400964] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 4.0.0-rc3-7-g944a1f8a79f1 #16 [ 32.409617] Hardware name: Generic AM33XX (Flattened Device Tree) So maybe your series removes some filtering somewhere, and illegal modes get passed forward? Tomi # # Automatically generated file; DO NOT EDIT. # Linux/arm 4.0.0-rc3 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # CONFIG_AUDITSYSCALL is not set # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_HANDLE_DOMAIN_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_RCU_USER_QS is not set CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_RCU_FAST_NO_HZ is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_KTHREAD_PRIO=0 # CONFIG_RCU_NOCB_CPU is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_SWAP_ENABLED=y CONFIG_MEMCG_KMEM=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y CONFIG_BLK_CGRO
Re: [PATCH] coresight: adding basic support for Spreadtrum SC9836
On 23 March 2015 at 23:48, Chunyan Zhang wrote:
> Support only for ETB, FUNNEL, STM are included currently.
> Support for ETM, TPIU and the replicator linked to it are not included in
> this version patch.
>
> Signed-off-by: Chunyan Zhang
> ---
> arch/arm64/boot/dts/sprd/sc9836.dtsi | 57
>
> 1 file changed, 57 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/sprd/sc9836.dtsi
> b/arch/arm64/boot/dts/sprd/sc9836.dtsi
> index f92f1b4..2ca80f3 100644
> --- a/arch/arm64/boot/dts/sprd/sc9836.dtsi
> +++ b/arch/arm64/boot/dts/sprd/sc9836.dtsi
> @@ -45,6 +45,63 @@
> };
> };
>
> + etb@10003000 {
> + compatible = "arm,coresight-etb10", "arm,primecell";
> + reg = <0 0x10003000 0 0x1000>;
> + arm,primecell-periphid = <0x0003b907>;
Specifying the primecell id in the device tree like this is usually to
avoid probing of the memory space by the AMBA mechanic when bus
components are discovered. As such components are probed and
initialised when their drivers are registered with the diver core
later in the boot process.
Is there a good reason why this is done here? Especially when the
funnel and STM don't specify their cell IDs in the DT.
> + coresight-default-sink;
Please remove the above - this feature no longer exists.
> + clocks = <&clk26mhz>;
> + clock-names = "apb_pclk";
> + port {
> + etb_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&funnel_out_port0>;
> + };
> + };
> + };
> +
> + funnel@10001000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0x10001000 0 0x1000>;
> + clocks = <&clk26mhz>;
> + clock-names = "apb_pclk";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* funnel output port */
> + port@0 {
> + reg = <0>;
> + funnel_out_port0: endpoint {
> + remote-endpoint = <&etb_in>;
> + };
> + };
> +
> + /* funnel input port 0~3 is reserved for ETMs */
> + port@1 {
> + reg = <4>;
> + funnel_in_port4: endpoint {
> + slave-mode;
> + remote-endpoint = <&stm_out>;
> + };
> + };
> + };
> + };
> +
> + stm@10006000 {
> + compatible = "arm,coresight-stm", "arm,primecell";
> + reg = <0 0x10006000 0 0x1000>,
> + <0 0x0100 0 0x18>;
> + reg-names = "stm-base", "stm-stimulus-base";
> + clocks = <&clk26mhz>;
> + clock-names = "apb_pclk";
> + port {
> + stm_out: endpoint {
> + remote-endpoint = <&funnel_in_port4>;
> + };
> + };
> + };
> +
> gic: interrupt-controller@12001000 {
> compatible = "arm,gic-400";
> reg = <0 0x12001000 0 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
[PATCHv2 07/10] arm/dts: dra72-evm.dts: add HDMI
DRA72 EVM has a HDMI output. This patch adds the device tree nodes
required for HDMI.
Signed-off-by: Tomi Valkeinen
Cc: devicetree@vger.kernel.org
---
arch/arm/boot/dts/dra72-evm.dts | 110
1 file changed, 110 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 4d8711713610..c752d7aa302d 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -19,6 +19,10 @@
reg = <0x8000 0x4000>; /* 1024 MB */
};
+ aliases {
+ display0 = &hdmi0;
+ };
+
evm_3v3: fixedregulator-evm_3v3 {
compatible = "regulator-fixed";
regulator-name = "evm_3v3";
@@ -35,6 +39,51 @@
compatible = "linux,extcon-usb-gpio";
id-gpio = <&pcf_gpio_21 2 GPIO_ACTIVE_HIGH>;
};
+
+ hdmi0: connector {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = "ti,tpd12s015";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tpd12s015_pins>;
+
+ gpios = <&pcf_hdmi 4 GPIO_ACTIVE_HIGH>, /* P4, CT CP HPD */
+ <&pcf_hdmi 5 GPIO_ACTIVE_HIGH>, /* P5, LS OE */
+ <&gpio7 12 GPIO_ACTIVE_HIGH>; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
};
&dra7_pmx_core {
@@ -45,6 +94,13 @@
>;
};
+ i2c5_pins: pinmux_i2c5_pins {
+ pinctrl-single,pins = <
+ 0x2b4 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr0.i2c5_sda
*/
+ 0x2b8 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr1.i2c5_scl
*/
+ >;
+ };
+
nand_default: nand_default {
pinctrl-single,pins = <
0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0 */
@@ -144,6 +200,19 @@
0xb8 (PIN_OUTPUT | MUX_MODE1) /* gpmc_cs2.qspi1_cs0 */
>;
};
+
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins = <
+ 0x408 (PIN_INPUT | MUX_MODE1) /* i2c2_sda.hdmi1_ddc_scl
*/
+ 0x40c (PIN_INPUT | MUX_MODE1) /* i2c2_scl.hdmi1_ddc_sda
*/
+ >;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins = <
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ >;
+ };
};
&i2c1 {
@@ -280,6 +349,27 @@
};
};
+&i2c5 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c5_pins>;
+ clock-frequency = <40>;
+
+ pcf_hdmi: pcf8575@26 {
+ compatible = "nxp,pcf8575";
+ reg = <0x26>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ /*
+* initial state is used here to keep the mdio interface
+* selected on RU89 through SEL_VIN4_MUX_S0, VIN2_S1 and
+* VIN2_S0 driven high otherwise Ethernet stops working
+* VIN6_SEL_S0 is low, thus selecting McASP3 over VIN6
+*/
+ lines-initial-states = <0x0f2b>;
+ };
+};
+
&uart1 {
status = "okay";
};
@@ -569,3 +659,23 @@
};
};
};
+
+&dss {
+ status = "ok";
+
+ vdda_video-supply = <&ldo5_reg>;
+};
+
+&hdmi {
+ status = "ok";
+ vdda-supply = <&ldo3_reg>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pins>;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+ };
+};
--
2.3.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
[PATCHv2 01/10] arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk
We need set-rate-parent flags for the display's clock path so that the
DSS driver can change the clock rate of the PLL.
This patchs adds the ti,set-rate-parent flag to 'dss_dss_clk' clock
node, which is only a gate clock, allowing the setting of the clock rate
to propagate to the PLL.
Signed-off-by: Tomi Valkeinen
Cc: devicetree@vger.kernel.org
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 4bdcbd61ce47..0d76233840e6 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1451,6 +1451,7 @@
clocks = <&dpll_per_h12x2_ck>;
ti,bit-shift = <8>;
reg = <0x1120>;
+ ti,set-rate-parent;
};
dss_hdmi_clk: dss_hdmi_clk {
--
2.3.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
[PATCHv2 08/10] arm/dts: am57xx-beagle-x15.dts: add HDMI
AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
nodes required for HDMI.
Signed-off-by: Tomi Valkeinen
Cc: devicetree@vger.kernel.org
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 +
1 file changed, 81 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 03750af3b49a..7184fc16d31e 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -19,6 +19,7 @@
aliases {
rtc0 = &mcp_rtc;
rtc1 = &tps659038_rtc;
+ display0 = &hdmi0;
};
memory {
@@ -102,6 +103,51 @@
pinctrl-names = "default";
pinctrl-0 = <&extcon_usb2_pins>;
};
+
+ hdmi0: connector {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = "ti,tpd12s015";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tpd12s015_pins>;
+
+ gpios = <&gpio7 10 GPIO_ACTIVE_HIGH>, /* gpio7_10, CT CP HPD
*/
+ <&gpio6 28 GPIO_ACTIVE_HIGH>, /* gpio6_28, LS OE */
+ <&gpio7 12 GPIO_ACTIVE_HIGH>; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
};
&dra7_pmx_core {
@@ -121,6 +167,13 @@
>;
};
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins = <
+ 0x408 (PIN_INPUT | MUX_MODE1) /*
i2c2_sda.hdmi1_ddc_scl */
+ 0x40c (PIN_INPUT | MUX_MODE1) /*
i2c2_scl.hdmi1_ddc_sda */
+ >;
+ };
+
i2c3_pins_default: i2c3_pins_default {
pinctrl-single,pins = <
0x2a4 (PIN_INPUT| MUX_MODE10) /*
mcasp1_aclkx.i2c3_sda */
@@ -277,6 +330,14 @@
0x3e8 (PIN_INPUT_PULLUP | MUX_MODE14) /*
uart1_ctsn.gpio7_24 */
>;
};
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins = <
+ 0x3b0 (PIN_OUTPUT | MUX_MODE14) /* gpio7_10
CT_CP_HPD */
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ 0x370 (PIN_OUTPUT | MUX_MODE14) /* gpio6_28
LS_OE */
+ >;
+ };
};
&i2c1 {
@@ -560,3 +621,23 @@
&usb2 {
dr_mode = "peripheral";
};
+
+&dss {
+ status = "ok";
+
+ vdda_video-supply = <&ldoln_reg>;
+};
+
+&hdmi {
+ status = "ok";
+ vdda-supply = <&ldo3_reg>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pins>;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+ };
+};
--
2.3.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
[PATCHv2 06/10] arm/dts: dra7.dtsi: add DSS support
DRA7xxx contains a very similar DSS to OMAP5. The main differences are:
* no DSI or RFBI support.
* 1 or 2 dedicated video PLLs.
* need to do additional configuration to the DRA7 CONTROL module.
DRA72xx has only one video PLL, and DRA74xx has two.
Signed-off-by: Tomi Valkeinen
Cc: devicetree@vger.kernel.org
---
arch/arm/boot/dts/dra7.dtsi | 38 ++
arch/arm/boot/dts/dra72x.dtsi | 11 +++
arch/arm/boot/dts/dra74x.dtsi | 15 +++
3 files changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8e50ca3fc102..312ede660b23 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1445,6 +1445,44 @@
clocks = <&sys_clkin1>;
status = "disabled";
};
+
+ dss: dss@5800 {
+ compatible = "ti,dra7-dss";
+ /* 'reg' defined in dra72x.dtsi and dra74x.dtsi */
+ /* 'clocks' defined in dra72x.dtsi and dra74x.dtsi */
+ status = "disabled";
+ ti,hwmods = "dss_core";
+ /* CTRL_CORE_DSS_PLL_CONTROL */
+ syscon-pll-ctrl = <&scm_conf 0x538>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@58001000 {
+ compatible = "ti,dra7-dispc";
+ reg = <0x58001000 0x1000>;
+ interrupts = ;
+ ti,hwmods = "dss_dispc";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ /* CTRL_CORE_SMA_SW_1 */
+ syscon-pol = <&scm_conf 0x534>;
+ };
+
+ hdmi: encoder@5806 {
+ compatible = "ti,dra7-hdmi";
+ reg = <0x5804 0x200>,
+ <0x58040200 0x80>,
+ <0x58040300 0x80>,
+ <0x5806 0x19000>;
+ reg-names = "wp", "pll", "phy", "core";
+ interrupts = ;
+ status = "disabled";
+ ti,hwmods = "dss_hdmi";
+ clocks = <&dss_48mhz_clk>, <&dss_hdmi_clk>;
+ clock-names = "fck", "sys_clk";
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index e5a3d23a3df1..0866866c8e94 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -28,3 +28,14 @@
interrupts = ;
};
};
+
+&dss {
+ reg = <0x5800 0x80>,
+ <0x58004054 0x4>,
+ <0x58004300 0x20>;
+ reg-names = "dss", "pll1_clkctrl", "pll1";
+
+ clocks = <&dss_dss_clk>,
+<&dss_video1_clk>;
+ clock-names = "fck", "video1_clk";
+};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 10173fab1a15..1a4f4970aaad 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -67,3 +67,18 @@
};
};
};
+
+&dss {
+ reg = <0x5800 0x80>,
+ <0x58004054 0x4>,
+ <0x58004300 0x20>,
+ <0x58005054 0x4>,
+ <0x58005300 0x20>;
+ reg-names = "dss", "pll1_clkctrl", "pll1",
+ "pll2_clkctrl", "pll2";
+
+ clocks = <&dss_dss_clk>,
+<&dss_video1_clk>,
+<&dss_video2_clk>;
+ clock-names = "fck", "video1_clk", "video2_clk";
+};
--
2.3.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] [RFC] OF: probe order dependency aware of_platform_populate
Hi Pantelis, Grant,
On Fri, Mar 20, 2015 at 12:39 PM, Pantelis Antoniou
wrote:
>> On Mar 19, 2015, at 21:18 , Grant Likely wrote:
>>
>> On Tue, 16 Dec 2014 14:11:31 +0200
>> , Pantelis Antoniou
>> wrote:
>>> A nice side-effect of the changes in DTC for supporting overlays
>>> is that it is now possible to do dependency tracking of platform
>>> devices automatically.
>>>
>>> This patch implements dependency aware probe order for users
>>> of of_platform_populate.
>>>
>>> There are no changes in the syntax of the DTS bindings, the
>>> dependency is generated automatically by the use of phandle
>>> references.
>>
>> Do you have measurements showing improvement? Conceptually, I don't have
>> a problem with having a small scale solution like this, but I want proof
>> that it actively makes things better, and is worth the extra complexity.
>> It's not an easy block of code to understand.
>>
>
> I will be the first to admit that the code it’s a bit hard to follow, but
> that’s the nature of trees and recursion.
>
> FWIW I’ve been booting with this applied for a month with no adverse effects,
> besides the fact that there dependency cycles which I would file as a bug.
IIUC, this would fix the issue I worked around in "ARM: shmobile: r8a73a4:
Move pfc node to work around probe ordering bug"?
https://git.kernel.org/cgit/linux/kernel/git/horms/renesas.git/commit/?h=r8a73a4-ccf-and-multiplatform-for-v4.1&id=e4ba0a9bddff3ba52cec100414d2f178440efc91
I'll give it a try when I'm back from ELC...
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 v7 4/8] mfd: fsl imx25 Touchscreen ADC driver
Hi,
Sorry for the late reply,
On Mon, Mar 09, 2015 at 09:27:10AM +, Lee Jones wrote:
> On Tue, 03 Mar 2015, Markus Pargmann wrote:
>
> > This is the core driver for imx25 touchscreen/adc driver. The module
> > has one shared ADC and two different conversion queues which use the
> > ADC. The two queues are identical. Both can be used for general purpose
> > ADC but one is meant to be used for touchscreens.
> >
> > This driver is the core which manages the central components and
> > registers of the TSC/ADC unit. It manages the IRQs and forwards them to
> > the correct components.
> >
> > Signed-off-by: Markus Pargmann
> > Signed-off-by: Denis Carikli
> > Acked-by: Jonathan Cameron
> > ---
> >
> > Notes:
> > Changes in v7:
> > - Cleanup bit defines in header files to be more readable
> > - Fix irq check to return with an error for irq <= 0
> > - Add COMPILE_TEST in Kconfig file
> >
> > Changes in v5:
> > - Remove ifdef CONFIG_OF as this driver is only for DT usage
> > - Remove module owner
> > - Add Kconfig dependencies ARCH_MX25 and OF
> >
> > @Jonathan Cameron:
> > I left your acked-by on the patch as these were small changes. If it
> > should be
> > removed, please say so. Thanks
> >
> > drivers/mfd/Kconfig | 10 +++
> > drivers/mfd/Makefile| 2 +
> > drivers/mfd/fsl-imx25-tsadc.c | 164
> >
> > include/linux/mfd/imx25-tsadc.h | 141 ++
> > 4 files changed, 317 insertions(+)
> > create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
> > create mode 100644 include/linux/mfd/imx25-tsadc.h
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index 38356e39adba..c0036aef61d7 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -244,6 +244,16 @@ config MFD_MC13XXX_I2C
> > help
> > Select this if your MC13xxx is connected via an I2C bus.
> >
> > +config MFD_MX25_TSADC
> > + tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
> > + select REGMAP_MMIO
> > + depends on SOC_IMX25 || COMPILE_TEST
> > + depends on OF
>
> Are you sure you can't compile test with OF disabled?
>
> depends on (SOC_IMX25 && OF) || COMPILE_TEST
Yes, should be possible without OF.
>
> > + help
> > + Enable support for the integrated Touchscreen and ADC unit of the
> > + i.MX25 processors. They consist of a conversion queue for general
> > + purpose ADC and a queue for Touchscreens.
> > +
> > config MFD_HI6421_PMIC
> > tristate "HiSilicon Hi6421 PMU/Codec IC"
> > depends on OF
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 19f3d744e3bd..acfe639e147c 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -78,6 +78,8 @@ obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
> > obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o
> > obj-$(CONFIG_TWL6040_CORE) += twl6040.o
> >
> > +obj-$(CONFIG_MFD_MX25_TSADC) += fsl-imx25-tsadc.o
> > +
> > obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
> > obj-$(CONFIG_MFD_MC13XXX_SPI) += mc13xxx-spi.o
> > obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
> > diff --git a/drivers/mfd/fsl-imx25-tsadc.c b/drivers/mfd/fsl-imx25-tsadc.c
> > new file mode 100644
> > index ..c4a3e15001ea
> > --- /dev/null
> > +++ b/drivers/mfd/fsl-imx25-tsadc.c
> > @@ -0,0 +1,164 @@
> > +/*
> > + * Copyright (C) 2014-2015 Pengutronix, Markus Pargmann
> >
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > under
> > + * the terms of the GNU General Public License version 2 as published by
> > the
> > + * Free Software Foundation.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static struct regmap_config mx25_tsadc_regmap_config = {
> > + .fast_io = true,
> > + .max_register = 8,
> > + .reg_bits = 32,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > +};
> > +
> > +static void mx25_tsadc_irq_handler(u32 irq, struct irq_desc *desc)
> > +{
> > + struct mx25_tsadc *tsadc = irq_desc_get_handler_data(desc);
> > + struct irq_chip *chip = irq_get_chip(irq);
> > + u32 status;
> > +
> > + chained_irq_enter(chip, desc);
> > +
> > + regmap_read(tsadc->regs, MX25_TSC_TGSR, &status);
> > +
> > + if (status & MX25_TGSR_GCQ_INT)
> > + generic_handle_irq(irq_find_mapping(tsadc->domain, 1));
> > +
> > + if (status & MX25_TGSR_TCQ_INT)
> > + generic_handle_irq(irq_find_mapping(tsadc->domain, 0));
> > +
> > + chained_irq_exit(chip, desc);
> > +}
> > +
> > +static int mx25_tsadc_domain_map(struct irq_domain *d, unsigned int irq,
> > +irq_hw_number_t hwirq)
> > +{
> > + struct mx25_tsadc *tsadc = d->host_data;
> > +
> > + irq_set_chip_dat
Re: [PATCH v3 0/7] Use DRM component API in tilcdc to connect to tda998x
On 03/24/15 14:50, Tomi Valkeinen wrote: Hi, On 18/03/15 11:06, Jyri Sarha wrote: I think the patches 1-5 are ready for merging. See the details below. I applied these on top of v4.0-rc3, booted up BBB, and loaded the modules. After doing that and waiting a few secs: # ./s-bbb.sh [ 15.237139] sysrq: SysRq : Changing Loglevel [ 15.241646] sysrq: Loglevel set to 9 [ 15.319762] [drm] Initialized drm 1.1.0 20060810 [ 15.588122] tda998x 0-0070: found TDA19988 [ 15.594824] tilcdc 4830e000.lcdc: bound 0-0070 (ops tda998x_ops [tda998x]) [ 15.602034] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 15.609011] [drm] No driver support for vblank timestamp query. [ 15.700798] tilcdc 4830e000.lcdc: fb0: frame buffer device [ 15.706757] tilcdc 4830e000.lcdc: registered panic notifier [ 15.712659] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0 # # [ 25.789364] [ cut here ] [ 25.794315] WARNING: CPU: 0 PID: 50 at drivers/gpu/drm/tilcdc/tilcdc_crtc.c:269 tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]() [ 25.805999] Modules linked in: tilcdc tda998x drm_kms_helper drm [ 25.812325] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 4.0.0-rc3-7-g5fbf26ebaf12 #7 [ 25.820893] Hardware name: Generic AM33XX (Flattened Device Tree) [ 25.827359] Workqueue: events output_poll_execute [drm_kms_helper] [ 25.833819] Backtrace: [ 25.836439] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 25.844380] r6:c09d4228 r5:c09d4228 r4: r3:dd3604c0 [ 25.850338] [] (show_stack) from [] (dump_stack+0xa4/0xd4) [ 25.857927] [] (dump_stack) from [] (warn_slowpath_common+0x84/0xc0) [ 25.866401] r6:010d r5:bf0a010c r4: r3:dd3604c0 [ 25.872348] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x24/0x2c) [ 25.881543] r8:dd50 r7:000f r6:bf0a25f0 r5:dd6b1400 r4:dd4e6800 [ 25.888617] [] (warn_slowpath_null) from [] (tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]) [ 25.898849] [] (tilcdc_crtc_mode_set [tilcdc]) from [] (drm_crtc_helper_set_mode+0x2b0/0x4f0 [drm_kms_helper]) [ 25.911132] r10:dd4e6bf0 r9:dd4e6800 r8:dd4e2e80 r7:dd6b1400 r6:0001 r5:dd50 [ 25.919372] r4:bf09fb20 [ 25.922061] [] (drm_crtc_helper_set_mode [drm_kms_helper]) from [] (drm_crtc_helper_set_config+0x768/0x9c8 [drm_kms_helper]) [ 25.935612] r10: r9:dd73d980 r8:dd4e6bf0 r7:bf031808 r6:dd4e6be4 r5:dd4e6bd8 [ 25.943827] r4:dd50 [ 25.946758] [] (drm_crtc_helper_set_config [drm_kms_helper]) from [] (drm_mode_set_config_internal+0x6c/0xf4 [drm]) [ 25.959518] r10:0001 r9: r8:dd4b4b40 r7:dd50 r6:0001 r5:0028 [ 25.967767] r4:dd4b46c0 [ 25.970558] [] (drm_mode_set_config_internal [drm]) from [] (restore_fbdev_mode+0xe0/0x100 [drm_kms_helper]) [ 25.982672] r7:dd73d980 r6:0001 r5:0028 r4: [ 25.988698] [] (restore_fbdev_mode [drm_kms_helper]) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x64 [drm_kms_helper]) [ 26.002884] r9:dd4e6be4 r8:bf031808 r7:dd4e6800 r6:dd4e6800 r5:dd4b46c0 r4:dd4b4b40 [ 26.011104] [] (drm_fb_helper_restore_fb> Tomi dev_mode_unlocked [drm_kms_helper]) from [] (drm_fb_helper_set_par+0x20/0x3c [drm_kms_helper]) [ 26.025562] r6:dd4e6800 r5:dd4b46c0 r4: r3: [ 26.031556] [] (drm_fb_helper_set_par [drm_kms_helper]) from [] (drm_fb_helper_hotplug_event+0x90/0xd0 [drm_kms_helper]) [ 26.044753] r4:dd4b4b40 r3: [ 26.048557] [] (drm_fb_helper_hotplug_event [drm_kms_helper]) from [] (drm_fbdev_cma_hotplug_event+0x18/0x1c [drm_kms_helper]) [ 26.062289] r7:dd4e6a40 r6:0001 r5:dd4e6c38 r4:dd4e6800 [ 26.068300] [] (drm_fbdev_cma_hotplug_event [drm_kms_helper]) from [] (tilcdc_fb_output_poll_changed+0x18/0x1c [tilcdc]) [ 26.081521] [] (tilcdc_fb_output_poll_changed [tilcdc]) from [] (drm_kms_helper_hotplug_event+0x2c/0x30 [drm_kms_helper]) [ 26.094840] [] (drm_kms_helper_hotplug_event [drm_kms_helper]) from [] (output_poll_execute+0x6c/0x18c [drm_kms_helper]) [ 26.108027] r4:dd4e6bd8 r3: [ 26.111809] [] (output_poll_execute [drm_kms_helper]) from [] (process_one_work+0x1e8/0x560) [ 26.122456] r10:dfa1b700 r9: r8:c0a0c0b8 r> Tomi 7:dd51deb0 r6:dfa157c0 r5:dd4b4d40 [ 26.130696] r4:dd4e6c38 [ 26.133353] [] (process_one_work) from [] (worker_thread+0x160/0x4c4) [ 26.141914] r10:dfa157c0 r9:0008 r8:dd4b4d58 r7:dd4b4d40 r6:c005d304 r5:dfa157f0 [ 26.150153] r4:dfa157c0 [ 26.152812] [] (worker_thread) from [] (kthread+0xf0/0x110) [ 26.160465] r10: r9: r8: r7:c005d2cc r6:dd4b4d40 r5:dd509cc0 [ 26.168704] r4: [ 26.171362] [] (kthread) from [] (ret_from_fork+0x14/0x24) [ 26.178925] r7: r6: r5:c0061d48 r4:dd509cc0 [ 26.184898] ---[ end trace e86278b011364fe4 ]--- [ 26.189766] [drm:drm_crtc_helper_set_config [drm_kms_helper]] *ERROR* failed to set mode on [CRTC:18] Also running modetest
Re: [PATCH v7] ARM: dts: Add HS400 support for exynos5420 and exynos5800
Gentle Ping !!
On Wed, Mar 18, 2015 at 4:50 PM, Alim Akhtar wrote:
> From: Seungwon Jeon
>
> HS400 timing values are added for SMDK5420, exynos5420-peach-pit
> and exynos5800-peach-pi boards.
> This also adds RCLK GPIO line, this gpio should be in pull-down
> state.
> This also enables HS400 on peach-pi and this updates the clock frequency
> to 800MHz to be set as input clock to controller.
>
> Signed-off-by: Seungwon Jeon
> Signed-off-by: Alim Akhtar
> [Alim: addressed review comments]
> Acked-by: Jaehoon Chung
> ---
> Changes in V7:
> Add back bus1 pin, which was removed during rebase in v6
> as rightly pointed out by Javier[1].
>
> Changes in V6:
> Rebased on kukjin's for-next branch[0]
> (commit: 77105c8 Merge branch 'v4.0-samsung-fixes-2' into for-next)
>
> [0]: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> [1]: http://www.spinics.net/lists/arm-kernel/msg406618.html
>
> arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 +++-
> arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 7 +++
> arch/arm/boot/dts/exynos5420-smdk5420.dts | 5 -
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 7 +--
> 4 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 3f4e2fe..0788d08 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -699,8 +699,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + samsung,dw-mshc-hs400-timing = <0 2>;
> + samsung,read-strobe-delay = <90>;
> pinctrl-names = "default";
> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8>;
> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
> &sd0_rclk>;
> bus-width = <8>;
> };
>
> diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> index ba686e4..8b15316 100644
> --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> @@ -201,6 +201,13 @@
> samsung,pin-drv = <3>;
> };
>
> + sd0_rclk: sd0-rclk {
> + samsung,pins = "gpc0-7";
> + samsung,pin-function = <2>;
> + samsung,pin-pud = <1>;
> + samsung,pin-drv = <3>;
> + };
> +
> sd1_cmd: sd1-cmd {
> samsung,pins = "gpc1-1";
> samsung,pin-function = <2>;
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index 7a56852..9103f23 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -80,8 +80,11 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + samsung,dw-mshc-hs400-timing = <0 2>;
> + samsung,read-strobe-delay = <90>;
> pinctrl-names = "default";
> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8>;
> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
> +&sd0_rclk>;
> bus-width = <8>;
> cap-mmc-highspeed;
> };
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index c833bac..412f41d 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -654,15 +654,18 @@
> num-slots = <1>;
> broken-cd;
> mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> cap-mmc-highspeed;
> non-removable;
> card-detect-delay = <200>;
> - clock-frequency = <4>;
> + clock-frequency = <8>;
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + samsung,dw-mshc-hs400-timing = <0 2>;
> + samsung,read-strobe-delay = <90>;
> pinctrl-names = "default";
> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8>;
> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8
> &sd0_rclk>;
> bus-width = <8>;
> };
>
> --
> 1.9.1
>
--
Regards,
Alim
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Re-license SolidRun iMX6 platform DT GPL v2/X11
On Mon, Mar 02, 2015 at 08:00:50PM +, Russell King wrote: > Update SolidRun iMX6 platforms DT descriptions to be dual-licensed. > > Cc: Sascha Hauer > Cc: Rabeeh Khoury > Signed-off-by: Russell King Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: Exynos5420: dt: Fixed the checkpatch.pl WARNING misspelled
Anand Moon wrote: > > Changes fixes the misspelled of #interrups-cell. > > arch/arm/boot/dts/exynos5420.dtsi:224: WARNING: 'interrups' >may be misspelled - perhaps 'interrupts'? > > Tested on OdroidXU3 board. > > Signed-off-by: Anand Moon > --- > arch/arm/boot/dts/exynos5420.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/exynos5420.dtsi > b/arch/arm/boot/dts/exynos5420.dtsi > index c0e98cf..a78ac1f 100644 > --- a/arch/arm/boot/dts/exynos5420.dtsi > +++ b/arch/arm/boot/dts/exynos5420.dtsi > @@ -221,7 +221,7 @@ > compatible = "samsung,exynos4210-mct"; > reg = <0x101C 0x800>; > interrupt-controller; > - #interrups-cells = <1>; > + #interrupt-cells = <1>; Oops, what's happened :( I'm seeing the typo in exynos5250.dtsi as well... arch/arm/boot/dts/exynos5250.dtsi:146: #interrups-cells = <2>; I'll apply with above fix. Thanks, Kukjin > interrupt-parent = <&mct_map>; > interrupts = <0>, <1>, <2>, <3>, <4>, <5>, <6>, <7>, > <8>, <9>, <10>, <11>; > -- > 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] ARM: dts: Re-license SolidRun iMX6 platform DT GPL v2/X11
On 03/24/2015 02:11 PM, Shawn Guo wrote: On Mon, Mar 02, 2015 at 08:00:50PM +, Russell King wrote: Update SolidRun iMX6 platforms DT descriptions to be dual-licensed. Cc: Sascha Hauer Cc: Rabeeh Khoury Signed-off-by: Russell King --- Sascha, Rabeeh, I need an ack from you for this change we have changes from both of you in the mainline kernel. Thanks. Rabeeh, Sascha has ACK-ed the patch, and what about you? Acked-by: Rabeeh Khoury Thanks, Rabeeh Shawn arch/arm/boot/dts/imx6dl-cubox-i.dts | 38 ++ arch/arm/boot/dts/imx6dl-hummingboard.dts | 38 ++ arch/arm/boot/dts/imx6q-cubox-i.dts| 38 ++ arch/arm/boot/dts/imx6q-hummingboard.dts | 38 ++ arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 38 ++ arch/arm/boot/dts/imx6qdl-hummingboard.dtsi| 38 ++ arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 38 ++ arch/arm/boot/dts/imx6qdl-microsom.dtsi| 38 ++ 8 files changed, 304 insertions(+) diff --git a/arch/arm/boot/dts/imx6dl-cubox-i.dts b/arch/arm/boot/dts/imx6dl-cubox-i.dts index 58aa8f2b0f26..e0b7fe8e18f8 100644 --- a/arch/arm/boot/dts/imx6dl-cubox-i.dts +++ b/arch/arm/boot/dts/imx6dl-cubox-i.dts @@ -1,5 +1,43 @@ /* * Copyright (C) 2014 Russell King + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License. + * + * This file is distributed in the hope that it will be useful + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. */ /dts-v1/; diff --git a/arch/arm/boot/dts/imx6dl-hummingboard.dts b/arch/arm/boot/dts/imx6dl-hummingboard.dts index 44a0e6736bb1..7369d2d7da3e 100644 --- a/arch/arm/boot/dts/imx6dl-hummingboard.dts +++ b/arch/arm/boot/dts/imx6dl-hummingboard.dts @@ -1,6 +1,44 @@ /* * Copyright (C) 2014 Rabeeh Khoury (rab...@solid-run.com) * Based on dt work by Russell King + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License. + * + * This file is distributed in the hope that it will be useful + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The a
RE: [alsa-devel] [PATCH RESEND] ARM: dts: Support audio on Exynos5422-odroidxu3 using simple-audio-card
Sylwester Nawrocki wrote:
>
> On 23/03/15 03:51, Inha Song wrote:
> > Add MAX98090 audio codec, I2S interface and the sound nodes to support
> > audio on Exynos5422 SoC Based Odroid-XU3 board. Now we can support audio
> > in Odroid-XU3 board using simple-audio-card DT binding.
> >
> > Signed-off-by: Inha Song
> > ---
> > arch/arm/boot/dts/exynos5420.dtsi | 9 +
> > arch/arm/boot/dts/exynos5422-odroidxu3.dts | 57
> > ++
> > 2 files changed, 66 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> > b/arch/arm/boot/dts/exynos5420.dtsi
> > index 4eaeabe..e459c1d 100644
> > --- a/arch/arm/boot/dts/exynos5420.dtsi
> > +++ b/arch/arm/boot/dts/exynos5420.dtsi
> > @@ -415,6 +415,9 @@
> > <&clock_audss EXYNOS_I2S_BUS>,
> > <&clock_audss EXYNOS_SCLK_I2S>;
> > clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
> > + #clock-cells = <1>;
> > + clock-output-names = "i2s_cdclk0";
> > + #sound-dai-cells = <1>;
> > samsung,idma-addr = <0x0300>;
> > pinctrl-names = "default";
> > pinctrl-0 = <&i2s0_bus>;
> > @@ -429,6 +432,9 @@
> > dma-names = "tx", "rx";
> > clocks = <&clock CLK_I2S1>, <&clock CLK_SCLK_I2S1>;
> > clock-names = "iis", "i2s_opclk0";
> > + #clock-cells = <1>;
> > + clock-output-names = "i2s_cdclk1";
> > + #sound-dai-cells = <1>;
> > pinctrl-names = "default";
> > pinctrl-0 = <&i2s1_bus>;
> > status = "disabled";
> > @@ -442,6 +448,9 @@
> > dma-names = "tx", "rx";
> > clocks = <&clock CLK_I2S2>, <&clock CLK_SCLK_I2S2>;
> > clock-names = "iis", "i2s_opclk0";
> > + #clock-cells = <1>;
> > + clock-output-names = "i2s_cdclk2";
> > + #sound-dai-cells = <1>;
> > pinctrl-names = "default";
> > pinctrl-0 = <&i2s2_bus>;
> > status = "disabled";
> > diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> > b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> > index edc25cf..9275ad6 100644
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> > @@ -11,6 +11,7 @@
> > */
> >
> > /dts-v1/;
> > +#include
> > #include "exynos5800.dtsi"
> >
> > / {
> > @@ -285,6 +286,62 @@
> > rtc@101E {
> > status = "okay";
> > };
> > +
> > + sound: sound {
> > + compatible = "simple-audio-card";
> > + assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
> > + <&clock_audss EXYNOS_MOUT_I2S>,
> > + <&clock_audss EXYNOS_DOUT_AUD_BUS>;
> > + assigned-clock-parents = <&clock CLK_FIN_PLL>,
> > + <&clock_audss EXYNOS_MOUT_AUDSS>;
> > + assigned-clock-rates = <0>,
> > + <0>,
> > + <1920>;
>
> The patch looks good, except it would be more appropriate to move the
> above properties to &clock_audss { }; node in this file.
> With that change feel free to add:
> Reviewed-by: Sylwester Nawrocki
>
> As a side note, this is a dts patch and of course Kukjin maintains that.
> You would likely get it applied sooner if you would have addressed it
> directly to Kukjin, rather than Mark or me.
>
Yes, please. I'll apply this once you address comments per Sylwester's
suggestion.
Thanks,
Kukjin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] Use DRM component API in tilcdc to connect to tda998x
Hi, On 18/03/15 11:06, Jyri Sarha wrote: > I think the patches 1-5 are ready for merging. See the details below. I applied these on top of v4.0-rc3, booted up BBB, and loaded the modules. After doing that and waiting a few secs: # ./s-bbb.sh [ 15.237139] sysrq: SysRq : Changing Loglevel [ 15.241646] sysrq: Loglevel set to 9 [ 15.319762] [drm] Initialized drm 1.1.0 20060810 [ 15.588122] tda998x 0-0070: found TDA19988 [ 15.594824] tilcdc 4830e000.lcdc: bound 0-0070 (ops tda998x_ops [tda998x]) [ 15.602034] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 15.609011] [drm] No driver support for vblank timestamp query. [ 15.700798] tilcdc 4830e000.lcdc: fb0: frame buffer device [ 15.706757] tilcdc 4830e000.lcdc: registered panic notifier [ 15.712659] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0 # # [ 25.789364] [ cut here ] [ 25.794315] WARNING: CPU: 0 PID: 50 at drivers/gpu/drm/tilcdc/tilcdc_crtc.c:269 tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]() [ 25.805999] Modules linked in: tilcdc tda998x drm_kms_helper drm [ 25.812325] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 4.0.0-rc3-7-g5fbf26ebaf12 #7 [ 25.820893] Hardware name: Generic AM33XX (Flattened Device Tree) [ 25.827359] Workqueue: events output_poll_execute [drm_kms_helper] [ 25.833819] Backtrace: [ 25.836439] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 25.844380] r6:c09d4228 r5:c09d4228 r4: r3:dd3604c0 [ 25.850338] [] (show_stack) from [] (dump_stack+0xa4/0xd4) [ 25.857927] [] (dump_stack) from [] (warn_slowpath_common+0x84/0xc0) [ 25.866401] r6:010d r5:bf0a010c r4: r3:dd3604c0 [ 25.872348] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x24/0x2c) [ 25.881543] r8:dd50 r7:000f r6:bf0a25f0 r5:dd6b1400 r4:dd4e6800 [ 25.888617] [] (warn_slowpath_null) from [] (tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]) [ 25.898849] [] (tilcdc_crtc_mode_set [tilcdc]) from [] (drm_crtc_helper_set_mode+0x2b0/0x4f0 [drm_kms_helper]) [ 25.911132] r10:dd4e6bf0 r9:dd4e6800 r8:dd4e2e80 r7:dd6b1400 r6:0001 r5:dd50 [ 25.919372] r4:bf09fb20 [ 25.922061] [] (drm_crtc_helper_set_mode [drm_kms_helper]) from [] (drm_crtc_helper_set_config+0x768/0x9c8 [drm_kms_helper]) [ 25.935612] r10: r9:dd73d980 r8:dd4e6bf0 r7:bf031808 r6:dd4e6be4 r5:dd4e6bd8 [ 25.943827] r4:dd50 [ 25.946758] [] (drm_crtc_helper_set_config [drm_kms_helper]) from [] (drm_mode_set_config_internal+0x6c/0xf4 [drm]) [ 25.959518] r10:0001 r9: r8:dd4b4b40 r7:dd50 r6:0001 r5:0028 [ 25.967767] r4:dd4b46c0 [ 25.970558] [] (drm_mode_set_config_internal [drm]) from [] (restore_fbdev_mode+0xe0/0x100 [drm_kms_helper]) [ 25.982672] r7:dd73d980 r6:0001 r5:0028 r4: [ 25.988698] [] (restore_fbdev_mode [drm_kms_helper]) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x64 [drm_kms_helper]) [ 26.002884] r9:dd4e6be4 r8:bf031808 r7:dd4e6800 r6:dd4e6800 r5:dd4b46c0 r4:dd4b4b40 [ 26.011104] [] (drm_fb_helper_restore_fbdev_mode_unlocked [drm_kms_helper]) from [] (drm_fb_helper_set_par+0x20/0x3c [drm_kms_helper]) [ 26.025562] r6:dd4e6800 r5:dd4b46c0 r4: r3: [ 26.031556] [] (drm_fb_helper_set_par [drm_kms_helper]) from [] (drm_fb_helper_hotplug_event+0x90/0xd0 [drm_kms_helper]) [ 26.044753] r4:dd4b4b40 r3: [ 26.048557] [] (drm_fb_helper_hotplug_event [drm_kms_helper]) from [] (drm_fbdev_cma_hotplug_event+0x18/0x1c [drm_kms_helper]) [ 26.062289] r7:dd4e6a40 r6:0001 r5:dd4e6c38 r4:dd4e6800 [ 26.068300] [] (drm_fbdev_cma_hotplug_event [drm_kms_helper]) from [] (tilcdc_fb_output_poll_changed+0x18/0x1c [tilcdc]) [ 26.081521] [] (tilcdc_fb_output_poll_changed [tilcdc]) from [] (drm_kms_helper_hotplug_event+0x2c/0x30 [drm_kms_helper]) [ 26.094840] [] (drm_kms_helper_hotplug_event [drm_kms_helper]) from [] (output_poll_execute+0x6c/0x18c [drm_kms_helper]) [ 26.108027] r4:dd4e6bd8 r3: [ 26.111809] [] (output_poll_execute [drm_kms_helper]) from [] (process_one_work+0x1e8/0x560) [ 26.122456] r10:dfa1b700 r9: r8:c0a0c0b8 r7:dd51deb0 r6:dfa157c0 r5:dd4b4d40 [ 26.130696] r4:dd4e6c38 [ 26.133353] [] (process_one_work) from [] (worker_thread+0x160/0x4c4) [ 26.141914] r10:dfa157c0 r9:0008 r8:dd4b4d58 r7:dd4b4d40 r6:c005d304 r5:dfa157f0 [ 26.150153] r4:dfa157c0 [ 26.152812] [] (worker_thread) from [] (kthread+0xf0/0x110) [ 26.160465] r10: r9: r8: r7:c005d2cc r6:dd4b4d40 r5:dd509cc0 [ 26.168704] r4: [ 26.171362] [] (kthread) from [] (ret_from_fork+0x14/0x24) [ 26.178925] r7: r6: r5:c0061d48 r4:dd509cc0 [ 26.184898] ---[ end trace e86278b011364fe4 ]--- [ 26.189766] [drm:drm_crtc_helper_set_config [drm_kms_helper]] *ERROR* failed to set mode on [CRTC:18] Also running modetest spams with similar warnings. Tomi signature.asc Descript
