Re: [PATCH] ARM: shmobile: porter: add DU DT support
Hello. On 12/28/2015 08:29 AM, Simon Horman wrote: Define the Porter board dependent part of the DU device node. Add the device node for Analog Devices ADV7511W HDMI transmitter to I2C2 bus and the HDMI connector. Add the necessary subnodes to interconnect DU and HDMI devices. Signed-off-by: Sergei Shtylyov --- This patch is against 'renesas-devel-20151221-v4.4-rc6' tag of Simon Horman's 'renesas.git' repo. Thanks, I have queued this up for v4.6. Actually, I was going to check this patch WRT the DU channels used, given Laurent's remark. OK, I will just send an incremental patch if needed. MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] arm64: renesas: r8a7795: add USB2.0 Host (EHCI/OHCI) device nodes
Hello.
On 12/25/2015 1:03 PM, Yoshihiro Shimoda wrote:
Signed-off-by: Yoshihiro Shimoda
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 66
1 file changed, 66 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 89393ea..e26073c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -809,5 +809,71 @@
#phy-cells = <0>;
status = "disabled";
};
+
+ ehci0: usb@ee080100 {
+ compatible = "renesas,ehci-r8a7795", "generic-ehci";
+ reg = <0 0xee080100 0 0xff>;
s/0xff/0x100? This is size, not limit.
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 703>;
+ phys = <&usb2_phy0>;
+ phy-names = "usb";
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ ehci1: usb@ee0a0100 {
+ compatible = "renesas,ehci-r8a7795", "generic-ehci";
+ reg = <0 0xee0a0100 0 0xff>;
Likewise?
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 702>;
+ phys = <&usb2_phy1>;
+ phy-names = "usb";
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ ehci2: usb@ee0c0100 {
+ compatible = "renesas,ehci-r8a7795", "generic-ehci";
+ reg = <0 0xee0c0100 0 0xff>;
Likewise?
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 701>;
+ phys = <&usb2_phy2>;
+ phy-names = "usb";
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ ohci0: usb@ee08 {
+ compatible = "renesas,ohci-r8a7795", "generic-ohci";
+ reg = <0 0xee08 0 0xff>;
Likewise?
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 703>;
+ phys = <&usb2_phy0>;
+ phy-names = "usb";
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ ohci1: usb@ee0a {
+ compatible = "renesas,ohci-r8a7795", "generic-ohci";
+ reg = <0 0xee0a 0 0xff>;
Likewise?
+ interrupts = ;
+ clocks = <&cpg CPG_MOD 702>;
+ phys = <&usb2_phy1>;
+ phy-names = "usb";
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ ohci2: usb@ee0c {
+ compatible = "renesas,ohci-r8a7795", "generic-ohci";
+ reg = <0 0xee0c 0 0xff>;
Likewise?
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: porter: add DU DT support
Define the Porter board dependent part of the DU device node.
Add the device node for Analog Devices ADV7511W HDMI transmitter to I2C2
bus and the HDMI connector. Add the necessary subnodes to interconnect DU
and HDMI devices.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151221-v4.4-rc6' tag of Simon Horman's
'renesas.git' repo.
arch/arm/boot/dts/r8a7791-porter.dts | 81 +++
1 file changed, 81 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -78,6 +78,29 @@
states = <330 1
180 0>;
};
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ x3_clk: x3-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <14850>;
+ };
+
+ x16_clk: x16-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <7425>;
+ };
};
&extal_clk {
@@ -139,6 +162,11 @@
renesas,groups = "can0_data";
renesas,function = "can0";
};
+
+ du_pins: du {
+ renesas,groups = "du_rgb888", "du_sync", "du_disp",
"du_clk_out_0";
+ renesas,function = "du";
+ };
};
&scif0 {
@@ -240,6 +268,38 @@
};
};
};
+
+ hdmi@39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&du_out_rgb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
};
&sata0 {
@@ -303,3 +363,24 @@
status = "okay";
};
+
+&du {
+ pinctrl-0 = <&du_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ clocks = <&mstp7_clks R8A7791_CLK_DU0>,
+<&mstp7_clks R8A7791_CLK_DU1>,
+<&mstp7_clks R8A7791_CLK_LVDS0>,
+<&x3_clk>, <&x16_clk>;
+ clock-names = "du.0", "du.1", "lvds.0",
+ "dclkin.0", "dclkin.1";
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] extcon: add Maxim MAX3355 driver
Hello. On 12/23/2015 05:17 AM, Chanwoo Choi wrote: This patch depend on GPIOLIB configuration as following: I modified it with following diff and applied it. diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index ba4db7d..3d89e60 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -54,6 +54,7 @@ config EXTCON_MAX14577 config EXTCON_MAX3355 tristate "Maxim MAX3355 USB OTG EXTCON Support" + depends on GPIOLIB || COMPILE_TEST If it won't compile w/o gpiolib, what's the use of COMIPLE_TEST? And no, it shouldn't depend on gpiolib. It has empty stubs for the case of CONFIG_GPIOLIB=n. Obviously something is wrong with the GPIO headers, I'll look into it. Yes. When GPIOLIB is disabled, the build issue don't happen. What? It surely does happen! hmm Sure. you need to check the include/linux/gpio/consumer.h. Because of build error happen, you miss to include the "linux/gpio/consumer.h" header file in extcon-max3355.c. Please test it for enough time. Yes, with this file #include'd, it build fine now. because include/linux/gpio/consumer.h implement the dummy function for all gpio functions if CONFIG_GPIOLIB is disabled. Linus W. advised to #include this header explicitly -- I'll try and post. Don't necessary. I already updated it including the "include/linux/gpio/consumer.h". I saw that, yes. For correct operation of max3355, you should add the dependency to the extcon-max3355.c driver. This driver use the GPIO library certainly. I disagree. The driver will just cease to load in this case. I don't see why we need such dependency. Only compilation time dependencies should be specified, I think. This driver have to depend on GPIOLIB. Why are you disagreeing the COMPILE_TEST dependency? It is just compile test without anything. I agree now. I still disagree about the gpiolib dependency though. If gpiolib is disabled, extcon-max3355.c might not operate it correctly. It'll just fail the probe, that's all. Just this driver could be built without operation because gpiolib function will not do the any behavior. devm_gpiod_get() will just fail with -ENOSYS. I think that it is not too much problem. I should send the pull request within this week. If you want to need more discussion of extcon-max3355.c, I will not include it on pull request for v4.5 because there is issue. No, please include it into the pull request. MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] extcon: add Maxim MAX3355 driver
Hello. On 12/22/2015 4:13 AM, Chanwoo Choi wrote: This patch depend on GPIOLIB configuration as following: I modified it with following diff and applied it. diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index ba4db7d..3d89e60 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -54,6 +54,7 @@ config EXTCON_MAX14577 config EXTCON_MAX3355 tristate "Maxim MAX3355 USB OTG EXTCON Support" + depends on GPIOLIB || COMPILE_TEST If it won't compile w/o gpiolib, what's the use of COMIPLE_TEST? And no, it shouldn't depend on gpiolib. It has empty stubs for the case of CONFIG_GPIOLIB=n. Obviously something is wrong with the GPIO headers, I'll look into it. Yes. When GPIOLIB is disabled, the build issue don't happen. What? It surely does happen! hmm Sure. you need to check the include/linux/gpio/consumer.h. Because of build error happen, you miss to include the "linux/gpio/consumer.h" header file in extcon-max3355.c. Please test it for enough time. Yes, with this file #include'd, it build fine now. because include/linux/gpio/consumer.h implement the dummy function for all gpio functions if CONFIG_GPIOLIB is disabled. Linus W. advised to #include this header explicitly -- I'll try and post. Don't necessary. I already updated it including the "include/linux/gpio/consumer.h". I saw that, yes. For correct operation of max3355, you should add the dependency to the extcon-max3355.c driver. This driver use the GPIO library certainly. I disagree. The driver will just cease to load in this case. I don't see why we need such dependency. Only compilation time dependencies should be specified, I think. This driver have to depend on GPIOLIB. Why are you disagreeing the COMPILE_TEST dependency? It is just compile test without anything. I agree now. I still disagree about the gpiolib dependency though. MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] extcon: add Maxim MAX3355 driver
Hello. On 12/21/2015 02:01 PM, Sergei Shtylyov wrote: This patch depend on GPIOLIB configuration as following: I modified it with following diff and applied it. diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index ba4db7d..3d89e60 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -54,6 +54,7 @@ config EXTCON_MAX14577 config EXTCON_MAX3355 tristate "Maxim MAX3355 USB OTG EXTCON Support" + depends on GPIOLIB || COMPILE_TEST If it won't compile w/o gpiolib, what's the use of COMIPLE_TEST? And no, it shouldn't depend on gpiolib. It has empty stubs for the case of CONFIG_GPIOLIB=n. Obviously something is wrong with the GPIO headers, I'll look into it. Yes. When GPIOLIB is disabled, the build issue don't happen. What? It surely does happen! because include/linux/gpio/consumer.h implement the dummy function for all gpio functions if CONFIG_GPIOLIB is disabled. Linus W. advised to #include this header explicitly -- I'll try and post. I see you already #include'd it, thanks. But in that case, doesn't seem necessary. Thanks, Chanwoo Choi MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] arm: dts: phy3250: add SD fixed regulator
On 12/21/2015 07:58 PM, Vladimir Zapolskiy wrote:
The change adds fixed voltage regulator for SD controller, ARM MMCI
controller driver uses it to control card power management.
Signed-off-by: Vladimir Zapolskiy
---
arch/arm/boot/dts/phy3250.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/phy3250.dts b/arch/arm/boot/dts/phy3250.dts
index 34e15fd..5465b9e 100644
--- a/arch/arm/boot/dts/phy3250.dts
+++ b/arch/arm/boot/dts/phy3250.dts
@@ -45,6 +45,15 @@
enable-active-high;
regulator-boot-on;
};
+
+ sd_reg: fixed-regulator@2 {
Please just "regulator@2", to comply with the ePAPR standard.
thanks for review, just for my information, do I understand correctly
that you reference to "Generic Names Recommendation" ?
Sure, AKA 2.2.2. :-)
I have no objection to generalize device tree node name as you
suggested, will do it.
TIA.
With best wishes,
Vladimir
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] arm: dts: phy3250: add SD fixed regulator
Hello.
On 12/20/2015 2:32 AM, Vladimir Zapolskiy wrote:
The change adds fixed voltage regulator for SD controller, ARM MMCI
controller driver uses it to control card power management.
Signed-off-by: Vladimir Zapolskiy
---
arch/arm/boot/dts/phy3250.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/phy3250.dts b/arch/arm/boot/dts/phy3250.dts
index 34e15fd..5465b9e 100644
--- a/arch/arm/boot/dts/phy3250.dts
+++ b/arch/arm/boot/dts/phy3250.dts
@@ -45,6 +45,15 @@
enable-active-high;
regulator-boot-on;
};
+
+ sd_reg: fixed-regulator@2 {
Please just "regulator@2", to comply with the ePAPR standard.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] extcon: add Maxim MAX3355 driver
Hello. On 12/21/2015 5:38 AM, Chanwoo Choi wrote: This patch depend on GPIOLIB configuration as following: I modified it with following diff and applied it. diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index ba4db7d..3d89e60 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -54,6 +54,7 @@ config EXTCON_MAX14577 config EXTCON_MAX3355 tristate "Maxim MAX3355 USB OTG EXTCON Support" + depends on GPIOLIB || COMPILE_TEST If it won't compile w/o gpiolib, what's the use of COMIPLE_TEST? And no, it shouldn't depend on gpiolib. It has empty stubs for the case of CONFIG_GPIOLIB=n. Obviously something is wrong with the GPIO headers, I'll look into it. Yes. When GPIOLIB is disabled, the build issue don't happen. What? It surely does happen! because include/linux/gpio/consumer.h implement the dummy function for all gpio functions if CONFIG_GPIOLIB is disabled. Linus W. advised to #include this header explicitly -- I'll try and post. For correct operation of max3355, you should add the dependency to the extcon-max3355.c driver. This driver use the GPIO library certainly. I disagree. The driver will just cease to load in this case. I don't see why we need such dependency. Only compilation time dependencies should be specified, I think. COMPILE_TEST is used for just build test. You can see the detailed data[1]. [1] https://lkml.org/lkml/2013/5/22/155 I know. Re-read my question please. Thanks, Chanwoo Choi MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] extcon: add Maxim MAX3355 driver
Hello. On 12/20/2015 05:31 PM, Chanwoo Choi wrote: This patch depend on GPIOLIB configuration as following: I modified it with following diff and applied it. diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index ba4db7d..3d89e60 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -54,6 +54,7 @@ config EXTCON_MAX14577 config EXTCON_MAX3355 tristate "Maxim MAX3355 USB OTG EXTCON Support" + depends on GPIOLIB || COMPILE_TEST If it won't compile w/o gpiolib, what's the use of COMIPLE_TEST? And no, it shouldn't depend on gpiolib. It has empty stubs for the case of CONFIG_GPIOLIB=n. Obviously something is wrong with the GPIO headers, I'll look into it. [...] Thanks, Chanwoo Choi MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] extcon: add Maxim MAX3355 driver
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
Acked-by: Chanwoo Choi
---
Changes in version 5:
- removed unused variable in the probe() method;
- removed reference to the Koelsch board from the binding document;
- added Chanwoo Choi's ACK.
Changes in version 4:
- stopped calling kstrdup() for the device name;
- removed unneeded 'owner' field initializer;
- moved devm_extcon_allocate() call further down in the probe() method;
- extended the driver copyright;
- indented the continuation lines in the binding document.
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 150
4 files changed, 180 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+Maxim Integrated MAX3355 USB OTG chip
+-
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's SHDN# pin;
+- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example:
+
+ usb-otg {
+ compatible = "maxim,max3355";
+ maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+ id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+ };
Index: extcon/drivers/extcon/Kconfig
===
--- extcon.orig/drivers/extcon/Kconfig
+++ extcon/drivers/extcon/Kconfig
@@ -52,6 +52,14 @@ config EXTCON_MAX14577
Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
detector and switch.
+config EXTCON_MAX3355
+ tristate "Maxim MAX3355 USB OTG EXTCON Support"
+ help
+ If you say yes here you get support for the USB OTG role detection by
+ MAX3355. The MAX3355 chip integrates a charge pump and comparators to
+ enable a system with an integrated USB OTG dual-role transceiver to
+ function as an USB OTG dual-role device.
+
config EXTCON_MAX77693
tristate "Maxim MAX77693 EXTCON Support"
depends on MFD_MAX77693 && INPUT
Index: extcon/drivers/extcon/Makefile
===
--- extcon.orig/drivers/extcon/Makefile
+++ extcon/drivers/extcon/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
+obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
obj-$(CONFIG_EXTC
Re: [PATCH 1/3] ARM: dts: bcm5301x: Add TWD WD Support to DT
Hello.
On 12/19/2015 12:37 AM, Jon Mason wrote:
Add support for the ARM TWD Watchdog to the bcm5301x device tree. The
ARM TWD timer allocated the register space for the WDT, so this patch
necessitated shrinking that. Also, the GIC masks were added for these.
Signed-off-by: Jon Mason
---
arch/arm/boot/dts/bcm5301x.dtsi | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index 65a1309..c31fafe 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -66,10 +66,19 @@
clocks = <&periph_clk>;
};
- local-timer@20600 {
+ twd-timer@20600 {
Please just "timer". The node names should be very generic, according to
the ePAPR standard.
compatible = "arm,cortex-a9-twd-timer";
- reg = <0x20600 0x100>;
- interrupts = ;
+ reg = <0x20600 0x20>;
+ interrupts = ;
+ clocks = <&periph_clk>;
+ };
+
+ twd-watchdog@20620 {
Please, just "watchdog".
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] extcon: add Maxim MAX3355 driver
Hello. On 12/18/2015 4:14 AM, Chanwoo Choi wrote: Except for just one comment below, Looks good to me. Acked-by: Chanwoo Choi I'll wait for a few days to get the review from DT maintainer before applying it on extcon-next branch. On 2015년 12월 18일 07:47, Sergei Shtylyov wrote: Maxim Integrated MAX3355E chip integrates a charge pump and comparators to enable a system with an integrated USB OTG dual-role transceiver to function as an USB OTG dual-role device. In addition to sensing/controlling Vbus, the chip also passes thru the ID signal from the USB OTG connector. On some Renesas boards, this signal is just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only host and gadget USB controllers sharing the same USB bus; however, we'd like to allow host or gadget drivers to be loaded depending on the cable type, hence the need for the MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs (however, we aren't currently interested in them), the OFFVBUS# signal is controlled by the host controllers, there's also the SHDN# signal wired to a GPIO, it should be driven high for the normal operation. Signed-off-by: Sergei Shtylyov --- The patch is against the 'extcon-next' branch of the 'extcon.git' repo. Changes in version 4: - stopped calling kstrdup() for the device name; - removed unneeded 'owner' field initializer; - moved devm_extcon_allocate() call further down in the probe() method; - extended the driver copyright; - indented the continuation lines in the binding document. Changes in version 3: - reformatted the change log. Changes in version 2: - added the USB gadget cable support; - added the remove() driver method which drives SHDN# GPIO low to save power; - dropped vendor prefix from the ID GPIO property name; - changed the GPIO property name suffix to "-gpios"; - switched to usign extcon_set_cable_state_() API; - switched to using the gpiod/sleeping 'gpiolib' APIs; - addded error messages to max3355_probe(); - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call; - renamed 'ret' variable to 'err' in max3355_probe(); - expanded the Kconfig entry help text; - added vendor name to the patch summary, the bindings document, the Kconfig entry, the driver heading comment, the module description, and the change log; - fixed up and reformatted the change log. Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 + drivers/extcon/Kconfig |8 drivers/extcon/Makefile |1 drivers/extcon/extcon-max3355.c | 151 4 files changed, 181 insertions(+) Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt === --- /dev/null +++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt @@ -0,0 +1,21 @@ +Maxim Integrated MAX3355 USB OTG chip +- + +MAX3355 integrates a charge pump and comparators to enable a system with an +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role +device. + +Required properties: +- compatible: should be "maxim,max3355"; +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO pin + connected to the MAX3355's SHDN# pin; +- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin + connected to the MAX3355's ID_OUT pin. + +Example (Koelsch board): You mean that "koelsch" board might be arch/arm/boot/dts/r8a7791-koelsch.dts. But, the max3355 dt node isn't really included in r8a7791-koelsch.dts. Of course, I couldn't post the device tree patch before the binding was accepted. I recommend that you add the accurate information because the wrong info causes the confusion. So, I'd like you to change it as following: "Example (Koelsch board):" -> "Example:" After adding the max3355 dt node to Koelsch board on separate patch, you modify this documentation for real usage case of max3355 dt node. No dire need to modify the documentation then. Should I still repost? [...] Thanks, Chanwoo Choi MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
Hello. On 12/18/2015 3:19 AM, Krzysztof Kozlowski wrote: [...] Please pass the source through recent coccicheck and fix the findings. Has it been included in the kernel source somewhere already? The rules detecting the unnecessary owner should be there for some time (sice 4.2 or 4.1?). The coccicheck is in kernel - scripts/coccicheck. It Found it already. uses coccinelle/spatch. Installed it. You can run it just like other code-checker tools - sparse and smatch. I tried but couldn't figure out how to confine 'make coccicheck'only to the files I need. Best regards, Krzysztof MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] ARM: dts: dra7: Add dt node for the sycon pcie
Hello.
On 12/18/2015 1:21 PM, Kishon Vijay Abraham I wrote:
Add new device tree node for the control module register space where
PCIe registers are present.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231..e38f63f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -155,6 +155,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
+
+scm_conf_pcie: tisyscon@1c24 {
Please use the generic node names as the ePAPR standard says.
something like scm_conf_pcie: syscon@1c24??
Yes, though "system-controller" would be probably more in line with what
ePAPR has standardized.
Thanks
Kishon
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] extcon: add Maxim MAX3355 driver
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
Changes in version 4:
- stopped calling kstrdup() for the device name;
- removed unneeded 'owner' field initializer;
- moved devm_extcon_allocate() call further down in the probe() method;
- extended the driver copyright;
- indented the continuation lines in the binding document.
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 151
4 files changed, 181 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+Maxim Integrated MAX3355 USB OTG chip
+-
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's SHDN# pin;
+- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+ usb-otg {
+ compatible = "maxim,max3355";
+ maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+ id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+ };
Index: extcon/drivers/extcon/Kconfig
===
--- extcon.orig/drivers/extcon/Kconfig
+++ extcon/drivers/extcon/Kconfig
@@ -52,6 +52,14 @@ config EXTCON_MAX14577
Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
detector and switch.
+config EXTCON_MAX3355
+ tristate "Maxim MAX3355 USB OTG EXTCON Support"
+ help
+ If you say yes here you get support for the USB OTG role detection by
+ MAX3355. The MAX3355 chip integrates a charge pump and comparators to
+ enable a system with an integrated USB OTG dual-role transceiver to
+ function as an USB OTG dual-role device.
+
config EXTCON_MAX77693
tristate "Maxim MAX77693 EXTCON Support"
depends on MFD_MAX77693 && INPUT
Index: extcon/drivers/extcon/Makefile
===
--- extcon.orig/drivers/extcon/Makefile
+++ extcon/drivers/extcon/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
+obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
obj-$(CONFIG_EXTCON_MAX77693) +=
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
Hello.
On 12/17/2015 05:34 AM, Chanwoo Choi wrote:
On 2015년 12월 17일 03:07, Sergei Shtylyov wrote:
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
---
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change
log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 153
4 files changed, 183 insertions(+)
[snip]
+ return 0;
+}
+
+static int max3355_remove(struct platform_device *pdev)
+{
+ struct max3355_data *data = platform_get_drvdata(pdev);
+
+ gpiod_set_value_cansleep(data->shdn_gpiod, 0);
Don't need to handle the 'shdn' gpio on resume/suspend funtcion?
But, if the interrput of id gpio is used for wakeup source,
there is no reason to handle it for suspend mode.
You told me to pass IRQF_NO_SUSPEND to devm_request_threaded_irq(), didn't
you?
[snip]
Thanks,
Chanwoo Choi
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
Hello.
On 12/17/2015 3:53 AM, Krzysztof Kozlowski wrote:
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
---
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change
log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 153
4 files changed, 183 insertions(+)
Index: renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+Maxim Integrated MAX3355 USB OTG chip
+-
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's SHDN# pin;
Could you add some indentation to the wrapped line for this property?
For readability.
If it's not indented enough, I can add more spaces/tabs.
+- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
Ditto.
Why this property lacks the vendor prefix i(n comparison to shdn-gpios
which has the prefix)?
Since the extcon-usb-gpio driver uses "id-gpio" prop already. I can add
back the vendor prefix if you insist.
[...]
Index: renesas/drivers/extcon/extcon-max3355.c
===
--- /dev/null
+++ renesas/drivers/extcon/extcon-max3355.c
@@ -0,0 +1,153 @@
[...]
+static int max3355_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct max3355_data *data;
+ struct gpio_desc *gpiod;
+ int irq, err;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(struct max3355_data),
+ GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->edev = devm_extcon_dev_allocate(&pdev->dev, max3355_cable);
+ if (IS_ERR(data->edev)) {
+ dev_err(&pdev->dev, "failed to allocate extcon device\n");
+ return PTR_ERR(data->edev);
+ }
+ data->edev->name = kstrdup(np->name, GFP_KERNEL);
I think it is not needed any more (extcon_dev_register()) will set it.
Anyway there is no checking for NULL return value and no freeing in
error/exit paths.
Oops, will fix.
[...]
+static struct platform_driver max3355_driver = {
+ .probe = max3355_probe,
+ .remove = max3355_remove,
+ .driver = {
+ .name = "extcon-max3355",
+ .of_match_table = max3355_match_table,
+ .owner = THIS_MODULE,
No need for owner.
Please pass the source through recent coccicheck and fix the findings.
Has it been included in the kernel source somewhere already?
Best regards,
Krzysztof
MBR, Sergei
[PATCH v3] extcon: add Maxim MAX3355 driver
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
---
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 153
4 files changed, 183 insertions(+)
Index: renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+Maxim Integrated MAX3355 USB OTG chip
+-
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's SHDN# pin;
+- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+ usb-otg {
+ compatible = "maxim,max3355";
+ maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+ id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+ };
Index: renesas/drivers/extcon/Kconfig
===
--- renesas.orig/drivers/extcon/Kconfig
+++ renesas/drivers/extcon/Kconfig
@@ -52,6 +52,14 @@ config EXTCON_MAX14577
Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
detector and switch.
+config EXTCON_MAX3355
+ tristate "Maxim MAX3355 USB OTG EXTCON Support"
+ help
+ If you say yes here you get support for the USB OTG role detection by
+ MAX3355. The MAX3355 chip integrates a charge pump and comparators to
+ enable a system with an integrated USB OTG dual-role transceiver to
+ function as an USB OTG dual-role device.
+
config EXTCON_MAX77693
tristate "Maxim MAX77693 EXTCON Support"
depends on MFD_MAX77693 && INPUT
Index: renesas/drivers/extcon/Makefile
===
--- renesas.orig/drivers/extcon/Makefile
+++ renesas/drivers/extcon/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
+obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX77843) += extcon-max77843.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
Index: renesas/drivers/extcon/extcon-max3355.c
===
--- /dev/null
+++ renesas/drivers/extcon/extcon-max3355.c
@@ -0,0 +1,153 @@
+/*
+ * Maxim Integrated MAX3355 USB OTG chip extcon driver
+ *
+ * Copyright (C) 2014 Cogent Embedded, Inc.
+ * Author: Sergei Shtylyov
+ *
+ * This software
Re: [PATCH v2] extcon: add Maxim MAX3355 driver
On 12/15/2015 04:20 AM, Chanwoo Choi wrote: Maxim Integrated MAX3355E chip integrates a charge pump and comparators to ^^ ^^ enable a system with an integrated USB OTG dual-role transceiver to function as an USB OTG dual-role device. In addition to sensing/controlling Vbus, ^^ ^^ ^^ ^^ the chip also passes thru the ID signal from the USB OTG connector. ^^ On some Renesas boards, this signal is just fed into the SoC thru a GPIO ^^ ^^ pin -- there's no real OTG controller, only host and gadget USB controllers ^^ ^^ sharing the same USB bus; however, we'd like to allow host or gadget drivers ^^ to be loaded depending on the cable type, hence the need for the MAX3355 ^^ extcon driver. The Vbus status signals are also wired to GPIOs (however, we aren't currently interested in them), the OFFVBUS# signal is controlled by ^^ ^^ the host controllers, there's also the SHDN# signal wired to a GPIO, it ^^ should be driven high for the normal operation. ^^ As above '^' expression, you used the double space between words. You should fix it. OK, since so many people seem to be offended by that, I'll fix it. Meanwhile, please comment on the patch itself. Thanks, Chanwoo Choi [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: add Maxim MAX3355 driver
Hello. On 12/15/2015 09:51 PM, Greg KH wrote: Maxim Integrated MAX3355E chip integrates a charge pump and comparators to enable a system with an integrated USB OTG dual-role transceiver to function as an USB OTG dual-role device. In addition to sensing/controlling Vbus, the chip also passes thru the ID signal from the USB OTG connector. On some Renesas boards, this signal is just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only host and gadget USB controllers sharing the same USB bus; however, we'd like to allow host or gadget drivers to be loaded depending on the cable type, hence the need for the MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs (however, we aren't currently interested in them), the OFFVBUS# signal is controlled by the host controllers, there's also the SHDN# signal wired to a GPIO, it should be driven high for the normal operation. As multiple people have said, fix the spacing here. You are the first to complain abou _this_ patch. If you don't have other issues with this driver in which case you should have trimmed the reply at this point), I'd like to keep my spacing as is. Thank you. Your previous version was not "extcon-usb-gpio: add enable pin support"[1] which has now been re-written to be max3355 specific? No, the MAX3355 driver pre-dates that version. First there was a driver, then I tried to re-use the existing stuff (there was no extcon-usb-gpio at the time of writing my driver), then had to return to the separate driver idea... "So what" and "I'd like to keep my spacing as is" aren't valid reasons. Fix it, then I'll look at the rest again. I'll consider doing that if you care to explain what's the problem with my spacing. TIA. You are mixing 2 and 1 spaces between words, don't do that. Care to just explain why? Because the rules of typography and grammer do not allow this. Typography? Are you serious? The books are all printed using filled up lines with arbitrary spaces between words. Grammar, maybe. Are you really arguing this? If so, it's trivial for us to just ignore your patches if you insist on this. I haven't had the opposite side's arguments so far, just "don't do it because we say so". Geert's mail was the first with such argument, and it didn't really seem a serious one, sorry. And please don't try to intimidate me with ignoring my patches. With 750+ merged patches I don't care that much... greg k-h MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] ARM: dts: dra7: Add dt node for the sycon pcie
Hello.
On 12/15/2015 12:39 PM, Kishon Vijay Abraham I wrote:
Add new device tree node for the control module register space where
PCIe registers are present.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231..e38f63f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -155,6 +155,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
+
+ scm_conf_pcie: tisyscon@1c24 {
Please use the generic node names as the ePAPR standard says.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: add Maxim MAX3355 driver
Hello. On 12/15/2015 2:28 PM, Geert Uytterhoeven wrote: "So what" and "I'd like to keep my spacing as is" aren't valid reasons. Fix it, then I'll look at the rest again. I'll consider doing that if you care to explain what's the problem with my spacing. TIA. You are mixing 2 and 1 spaces between words, don't do that. Care to just explain why? It makes the text difficult to read. Are you serious? :-) [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] usb: renesas_usbhs: add fallback compatibility strings
Hello. On 12/15/2015 9:41 AM, Simon Horman wrote: Add fallback compatibility strings for R-Car Gen2 and Gen3. This is in keeping with the fallback scheme being adopted wherever appropriate for drivers for Renesas SoCs. Signed-off-by: Simon Horman --- v3 * Moved documentation of SoC names to a separate patch * Use correct fallback compatibility string in example v2 * Add R-Car Gen2 and Gen3 fallback compatibility strings rather than a single compatibility string for all of R-Car. --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 10 +- drivers/usb/renesas_usbhs/common.c | 9 + 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index a14c0bb561d5..c55cf77006d0 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -2,10 +2,18 @@ Renesas Electronics USBHS driver Required properties: - compatible: Must contain one of the following: Really? Would "...one or more of the following" help? It would, of course. + - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device + - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device + - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device + + When compatible with the generic version, nodes must list the + SoC-specific version corresponding to the platform first followed + by the generic version. + This kinda contradicts the above claim. [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: add Maxim MAX3355 driver
Hello. On 12/15/2015 2:44 AM, Greg KH wrote: Maxim Integrated MAX3355E chip integrates a charge pump and comparators to enable a system with an integrated USB OTG dual-role transceiver to function as an USB OTG dual-role device. In addition to sensing/controlling Vbus, the chip also passes thru the ID signal from the USB OTG connector. On some Renesas boards, this signal is just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only host and gadget USB controllers sharing the same USB bus; however, we'd like to allow host or gadget drivers to be loaded depending on the cable type, hence the need for the MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs (however, we aren't currently interested in them), the OFFVBUS# signal is controlled by the host controllers, there's also the SHDN# signal wired to a GPIO, it should be driven high for the normal operation. As multiple people have said, fix the spacing here. You are the first to complain abou _this_ patch. If you don't have other issues with this driver in which case you should have trimmed the reply at this point), I'd like to keep my spacing as is. Thank you. Your previous version was not "extcon-usb-gpio: add enable pin support"[1] which has now been re-written to be max3355 specific? No, the MAX3355 driver pre-dates that version. First there was a driver, then I tried to re-use the existing stuff (there was no extcon-usb-gpio at the time of writing my driver), then had to return to the separate driver idea... "So what" and "I'd like to keep my spacing as is" aren't valid reasons. Fix it, then I'll look at the rest again. I'll consider doing that if you care to explain what's the problem with my spacing. TIA. You are mixing 2 and 1 spaces between words, don't do that. Care to just explain why? MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: add Maxim MAX3355 driver
Hello. On 12/15/2015 01:21 AM, Rob Herring wrote: Maxim Integrated MAX3355E chip integrates a charge pump and comparators to enable a system with an integrated USB OTG dual-role transceiver to function as an USB OTG dual-role device. In addition to sensing/controlling Vbus, the chip also passes thru the ID signal from the USB OTG connector. On some Renesas boards, this signal is just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only host and gadget USB controllers sharing the same USB bus; however, we'd like to allow host or gadget drivers to be loaded depending on the cable type, hence the need for the MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs (however, we aren't currently interested in them), the OFFVBUS# signal is controlled by the host controllers, there's also the SHDN# signal wired to a GPIO, it should be driven high for the normal operation. As multiple people have said, fix the spacing here. You are the first to complain abou _this_ patch. If you don't have other issues with this driver in which case you should have trimmed the reply at this point), I'd like to keep my spacing as is. Thank you. Your previous version was not "extcon-usb-gpio: add enable pin support"[1] which has now been re-written to be max3355 specific? No, the MAX3355 driver pre-dates that version. First there was a driver, then I tried to re-use the existing stuff (there was no extcon-usb-gpio at the time of writing my driver), then had to return to the separate driver idea... "So what" and "I'd like to keep my spacing as is" aren't valid reasons. Fix it, then I'll look at the rest again. I'll consider doing that if you care to explain what's the problem with my spacing. TIA. Rob MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: add Maxim MAX3355 driver
Hello. On 12/14/2015 04:24 AM, Rob Herring wrote: Maxim Integrated MAX3355E chip integrates a charge pump and comparators to enable a system with an integrated USB OTG dual-role transceiver to function as an USB OTG dual-role device. In addition to sensing/controlling Vbus, the chip also passes thru the ID signal from the USB OTG connector. On some Renesas boards, this signal is just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only host and gadget USB controllers sharing the same USB bus; however, we'd like to allow host or gadget drivers to be loaded depending on the cable type, hence the need for the MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs (however, we aren't currently interested in them), the OFFVBUS# signal is controlled by the host controllers, there's also the SHDN# signal wired to a GPIO, it should be driven high for the normal operation. As multiple people have said, fix the spacing here. You are the first to complain abou _this_ patch. If you don't have other issues with this driver in which case you should have trimmed the reply at this point), I'd like to keep my spacing as is. Thank you. MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] extcon: add Maxim MAX3355 driver
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to function
as an USB OTG dual-role device. In addition to sensing/controlling Vbus,
the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget drivers
to be loaded depending on the cable type, hence the need for the MAX3355
extcon driver. The Vbus status signals are also wired to GPIOs (however, we
aren't currently interested in them), the OFFVBUS# signal is controlled by
the host controllers, there's also the SHDN# signal wired to a GPIO, it
should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 153
4 files changed, 183 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+Maxim Integrated MAX3355 USB OTG chip
+-
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's SHDN# pin;
+- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+ usb-otg {
+ compatible = "maxim,max3355";
+ maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+ id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+ };
Index: extcon/drivers/extcon/Kconfig
===
--- extcon.orig/drivers/extcon/Kconfig
+++ extcon/drivers/extcon/Kconfig
@@ -52,6 +52,14 @@ config EXTCON_MAX14577
Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
detector and switch.
+config EXTCON_MAX3355
+ tristate "Maxim MAX3355 USB OTG EXTCON Support"
+ help
+ If you say yes here you get support for the USB OTG role detection by
+ MAX3355. The MAX3355 chip integrates a charge pump and comparators to
+ enable a system with an integrated USB OTG dual-role transceiver to
+ function as an USB OTG dual-role device.
+
config EXTCON_MAX77693
tristate "Maxim MAX77693 EXTCON Support"
depends on MFD_MAX77693 && INPUT
Index: extcon/drivers/extcon/Makefile
===
--- extcon.orig/drivers/extcon/Makefile
+++ extcon/drivers/extcon/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
+obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX77843) += extcon-max77843.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
Index: extcon/drivers/extcon/extcon-max3355.c
===
--- /dev/null
+++ extcon/drivers/extcon/extcon-max3355.c
@@ -0,0 +1,153 @@
+/*
+ * Maxim Integrated MAX3355 USB OTG chip extcon driver
+ *
+ * Copyright (C) 2014 Cogent Embedded, Inc.
+ *
Re: [PATCH] extcon-usb-gpio: add enable pin support
Hello.
On 12/11/2015 06:53 AM, Rob Herring wrote:
Sometimes there's a real OTG chip behind the USB ID signal mapped to a GPIO
pin: in my case it's Maxim Integrated MAX3355E which integrates Vbus charge
pump and comparators and passes thru the ID signal from an OTG connector.
This chip also has the SHDN# pin which should be driven high for the normal
operation and low to save power; it is connected to a GPIO pin as well on,
hence we'll have to teach the driver to parse the new optional device tree
property, "enable-gpio"...
Some wierd spacing going on here.
I like my text properly filling up the given columns. What's the problem? :-)
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt |3 +++
drivers/extcon/extcon-usb-gpio.c |5 +
2 files changed, 8 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
===
--- extcon.orig/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -7,6 +7,9 @@ Required properties:
- compatible: Should be "linux,extcon-usb-gpio"
- id-gpio: gpio for USB ID pin. See gpio binding.
+Optional properties:
+- enable-gpio: gpio for the enable pin. See gpio binding.
Use -gpios as -gpio is deprecated.
Didn't know, thanks.
[...]
Index: extcon/drivers/extcon/extcon-usb-gpio.c
===
--- extcon.orig/drivers/extcon/extcon-usb-gpio.c
+++ extcon/drivers/extcon/extcon-usb-gpio.c
[...]
@@ -99,6 +100,8 @@ static int usb_extcon_probe(struct platf
return -ENOMEM;
info->dev = dev;
+ info->enable_gpiod = devm_gpiod_get_optional(&pdev->dev, "enable",
+GPIOD_OUT_HIGH);
info->id_gpiod = devm_gpiod_get(&pdev->dev, "id", GPIOD_IN);
if (IS_ERR(info->id_gpiod)) {
dev_err(dev, "failed to get ID GPIO\n");
@@ -155,6 +158,8 @@ static int usb_extcon_remove(struct plat
cancel_delayed_work_sync(&info->wq_detcable);
+ gpiod_set_value_cansleep(info->enable_gpiod, 0);
Shouldn't you support either polarity?
The gpiolib does that for me -- devm_gpiod_get_optional() should read the
polarity from DT.
Rob
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] extcon-usb-gpio: add enable pin support
Hello. On 12/11/2015 07:05 AM, Chanwoo Choi wrote: Sometimes there's a real OTG chip behind the USB ID signal mapped to a GPIO pin: in my case it's Maxim Integrated MAX3355E which integrates Vbus charge pump and comparators and passes thru the ID signal from an OTG connector. s/thru/through ? "Thru" is valid English. This chip also has the SHDN# pin which should be driven high for the normal operation and low to save power; it is connected to a GPIO pin as well on, hence we'll have to teach the driver to parse the new optional device tree property, "enable-gpio"... This patch description includes the double space between words. Also, I think So what? you need to write the patch description again for formal style. Not sure I understand you. This patch adds the specific 'enable-gpio' pin to express the SHDN#pin for MAX3355E. I think it is not regular and standard case because maybe USB specification don't include the SHDN#pin information. Certainly, it's not a USB pin. I think it not appropriate way. Instead, you better to make the MAX3355 extcon driver to support this case. OK, just didn't want to duplicate most of this driver there... Thanks, Chanwoo MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] usb: renesas_usbhs: add fallback compatibility strings
Hello. On 12/11/2015 5:12 AM, Simon Horman wrote: Add fallback compatibility strings for R-Car Gen2 and Gen3. This is in keeping with the fallback scheme being adopted wherever appropriate for drivers for Renesas SoCs. Signed-off-by: Simon Horman --- v3 * Moved documentation of SoC names to a separate patch * Use correct fallback compatibility string in example v2 * Add R-Car Gen2 and Gen3 fallback compatibility strings rather than a single compatibility string for all of R-Car. --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 10 +- drivers/usb/renesas_usbhs/common.c | 9 + 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index a14c0bb561d5..c55cf77006d0 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -2,10 +2,18 @@ Renesas Electronics USBHS driver Required properties: - compatible: Must contain one of the following: Really? + - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device + - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device + - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device + + When compatible with the generic version, nodes must list the + SoC-specific version corresponding to the platform first followed + by the generic version. + This kinda contradicts the above claim. [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] extcon-usb-gpio: add enable pin support
Sometimes there's a real OTG chip behind the USB ID signal mapped to a GPIO
pin: in my case it's Maxim Integrated MAX3355E which integrates Vbus charge
pump and comparators and passes thru the ID signal from an OTG connector.
This chip also has the SHDN# pin which should be driven high for the normal
operation and low to save power; it is connected to a GPIO pin as well on,
hence we'll have to teach the driver to parse the new optional device tree
property, "enable-gpio"...
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt |3 +++
drivers/extcon/extcon-usb-gpio.c |5 +
2 files changed, 8 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
===
--- extcon.orig/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -7,6 +7,9 @@ Required properties:
- compatible: Should be "linux,extcon-usb-gpio"
- id-gpio: gpio for USB ID pin. See gpio binding.
+Optional properties:
+- enable-gpio: gpio for the enable pin. See gpio binding.
+
Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
extcon_usb1 {
compatible = "linux,extcon-usb-gpio";
Index: extcon/drivers/extcon/extcon-usb-gpio.c
===
--- extcon.orig/drivers/extcon/extcon-usb-gpio.c
+++ extcon/drivers/extcon/extcon-usb-gpio.c
@@ -33,6 +33,7 @@ struct usb_extcon_info {
struct device *dev;
struct extcon_dev *edev;
+ struct gpio_desc *enable_gpiod;
struct gpio_desc *id_gpiod;
int id_irq;
@@ -99,6 +100,8 @@ static int usb_extcon_probe(struct platf
return -ENOMEM;
info->dev = dev;
+ info->enable_gpiod = devm_gpiod_get_optional(&pdev->dev, "enable",
+GPIOD_OUT_HIGH);
info->id_gpiod = devm_gpiod_get(&pdev->dev, "id", GPIOD_IN);
if (IS_ERR(info->id_gpiod)) {
dev_err(dev, "failed to get ID GPIO\n");
@@ -155,6 +158,8 @@ static int usb_extcon_remove(struct plat
cancel_delayed_work_sync(&info->wq_detcable);
+ gpiod_set_value_cansleep(info->enable_gpiod, 0);
+
return 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 linux-next (v3) 1/2] reset: Add brcm,bcm6345-reset device tree binding
Hello.
On 12/11/2015 12:28 AM, Simon Arlott wrote:
Add device tree binding for the BCM6345 soft reset controller.
The BCM6345 contains a soft-reset controller activated by setting
a bit (that must previously have been cleared).
Signed-off-by: Simon Arlott
---
v3: Resend. Example has changed because usbh now has two compatible
strings and uses a power domain instead of a regulator.
v2: Renamed to bcm6345, removed "mask" property.
Acked-by: Rob Herring
.../bindings/reset/brcm,bcm6345-reset.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
new file mode 100644
index 000..0313040
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
@@ -0,0 +1,33 @@
+Broadcom BCM6345 reset controller
+
+The BCM6345 contains a basic soft reset controller in the perf register
+set which resets components using a bit in a register.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "brcm,bcm-reset", "brcm,bcm6345-reset"
+- regmap: The register map phandle
+- offset: Offset in the register map for the reset register (in bytes)
+- #reset-cells:Must be set to 1
+
+Example:
+
+periph_soft_rst: reset-controller {
+ compatible = "brcm,bcm63168-reset", "brcm,bcm6345-reset";
+ regmap = <&periph_cntl>;
+ offset = <0x10>;
+
+ #reset-cells = <1>;
+};
+
+usbh: usbphy@10002700 {
"usb-phy" please to be more in line with ePAPR standardized "ethernet-phy"
node name.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] usb: renesas_usbhs: add fallback compatibility strings
Hello.
On 12/10/2015 8:40 AM, Simon Horman wrote:
Add fallback compatibility strings for R-Car Gen2 and Gen3.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.
Also add SoC names.
Signed-off-by: Simon Horman
---
v2
* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
a single compatibility string for all of R-Car.
---
.../devicetree/bindings/usb/renesas_usbhs.txt | 18 +-
drivers/usb/renesas_usbhs/common.c | 9 +
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 7d48f63db44e..b959059826cd 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
[...]
@@ -22,7 +30,7 @@ Optional properties:
Example:
usbhs: usb@e659 {
- compatible = "renesas,usbhs-r8a7790";
+ compatible = "renesas,usbhs-r8a7790", "renesas,rcar-usbhs";
You forgot "gen2-" here.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: renesas_usbhs: add fallback compatibility string
On 12/08/2015 08:51 AM, Simon Horman wrote:
Add fallback compatibility string.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.
Signed-off-by: Simon Horman
---
Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 4 ++--
drivers/usb/renesas_usbhs/common.c | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 7d48f63db44e..8c50df8441c9 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -1,7 +1,7 @@
Renesas Electronics USBHS driver
Required properties:
- - compatible: Must contain one of the following:
+ - compatible: "renesas,usbhs-", "renesas,rcar-usbhs" as fallback.
- "renesas,usbhs-r8a7790"
- "renesas,usbhs-r8a7791"
- "renesas,usbhs-r8a7794"
[...]
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index d82fa36c3465..2a9d4f405f30 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -481,6 +481,10 @@ static const struct of_device_id usbhs_of_match[] = {
.compatible = "renesas,usbhs-r8a7795",
.data = (void *)USBHS_TYPE_RCAR_GEN2,
},
+ {
+ .compatible = "renesas,usbhs",
You just documented "renesas,rcar-usbhs".
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rcar_jpu: add fallback compatibility string
Hello. On 12/8/2015 8:42 AM, Simon Horman wrote: Add fallback compatibility string. This is in keeping with the fallback scheme being adopted wherever appropriate for drivers for Renesas SoCs. Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/media/renesas,jpu.txt | 13 +++-- drivers/media/platform/rcar_jpu.c | 1 + 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/media/renesas,jpu.txt b/Documentation/devicetree/bindings/media/renesas,jpu.txt index 0cb94201bf92..c96de75f0089 100644 --- a/Documentation/devicetree/bindings/media/renesas,jpu.txt +++ b/Documentation/devicetree/bindings/media/renesas,jpu.txt @@ -5,11 +5,12 @@ and decoding function conforming to the JPEG baseline process, so that the JPU can encode image data and decode JPEG data quickly. Required properties: - - compatible: should containg one of the following: - - "renesas,jpu-r8a7790" for R-Car H2 - - "renesas,jpu-r8a7791" for R-Car M2-W - - "renesas,jpu-r8a7792" for R-Car V2H - - "renesas,jpu-r8a7793" for R-Car M2-N +- compatible: "renesas,jpu-", "renesas,jpu" as fallback. Not "renesas,rcar[-gen2]-jpu"? [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] stmmac: socfpga: Provide dt node to config ptp clk source.
On 12/07/2015 04:38 AM, Phil Reid wrote: Signed-off-by: Phil Reid --- Documentation/devicetree/bindings/net/socfpga-dwmac.txt | 2 ++ drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 9 + 2 files changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt index 3a9d679..72d82d6 100644 --- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt +++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt @@ -11,6 +11,8 @@ Required properties: designware version numbers documented in stmmac.txt - altr,sysmgr-syscon : Should be the phandle to the system manager node that encompasses the glue register, the register offset, and the register shift. + - altr,f2h_ptp_ref_clk use f2h_ptp_ref_clk instead of default eosc1 clock + for ptp ref clk. This affects all emacs as the clock is common. Optional properties: altr,emac-splitter: Should be the phandle to the emac splitter soft IP node if diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c index 401383b..3c5bc12 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c [...] @@ -171,6 +175,11 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac) ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << reg_shift); ctrl |= val << reg_shift; + if(dwmac->f2h_ptp_ref_clk) Please run your patches thru scripts/checkpatch.pl (space needed after *if*). [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] stmmac: socfpga: Provide dt node to config ptp clk source.
Hello. On 12/07/2015 04:38 AM, Phil Reid wrote: How about change log? Signed-off-by: Phil Reid --- Documentation/devicetree/bindings/net/socfpga-dwmac.txt | 2 ++ drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 10 ++ 2 files changed, 12 insertions(+) diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt index 3a9d679..72d82d6 100644 --- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt +++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt @@ -11,6 +11,8 @@ Required properties: designware version numbers documented in stmmac.txt - altr,sysmgr-syscon : Should be the phandle to the system manager node that encompasses the glue register, the register offset, and the register shift. + - altr,f2h_ptp_ref_clk use f2h_ptp_ref_clk instead of default eosc1 clock Colon missed after the prop name. And in general, hyphens are preferred to underscores in the device tree names. + for ptp ref clk. This affects all emacs as the clock is common. Optional properties: altr,emac-splitter: Should be the phandle to the emac splitter soft IP node if diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c index 401383b..c1bab62 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c [...] @@ -116,6 +118,9 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device * return -EINVAL; } + dwmac->f2h_ptp_ref_clk = of_property_read_bool(np, "f2h_ptp_ref_clk"); Where is "altr,"? [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Add R8A7791 EtherAVB DT support
Hello. On 12/3/2015 1:19 AM, Sergei Shtylyov wrote: Here's the set of 2 patches against Simon Horman's 'renesas.git' repo, 'renesas-devel-20151201-v4.4-rc3' tag. Here we add the EtherAVB device tree support for the R8A7791 SoC. The 2nd patch depends on the Simon's recent EtherAVB driver patches in order to work... Well, not exactly "work", as the node is disabled. Anyway, Simon's patches got merged to net-next.git by Dave, so I think this series can be merged now as well... [1/2] ARM: shmobile: r8a7791: add EtherAVB clock [2/2] ARM: shmobile: r8a7791: add EtherAVB DT support MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: shmobile: r8a7791: add EtherAVB DT support
Define the generic R8A7791 part of the EtherAVB device node.
Based on the commit f25d6b977240 ("ARM: shmobile: r8a7790: add EtherAVB DT
support").
Signed-off-by: Sergei Shtylyov
---
arch/arm/boot/dts/r8a7791.dtsi | 12
1 file changed, 12 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -785,6 +785,18 @@
status = "disabled";
};
+ avb: ethernet@e680 {
+ compatible = "renesas,etheravb-r8a7791",
+"renesas,etheravb-rcar-gen2";
+ reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
+ interrupts = <0 163 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp8_clks R8A7791_CLK_ETHERAVB>;
+ power-domains = <&cpg_clocks>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
sata0: sata@ee30 {
compatible = "renesas,sata-r8a7791";
reg = <0 0xee30 0 0x2000>;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: shmobile: r8a7791: add EtherAVB clock
Add the EtherAVB clock to the R8A7791 device tree.
Based on the commit 63d2d750c902 ("ARM: shmobile: r8a7790: add EtherAVB
clocks").
Signed-off-by: Sergei Shtylyov
---
arch/arm/boot/dts/r8a7791.dtsi| 10 ++
include/dt-bindings/clock/r8a7791-clock.h |1 +
2 files changed, 7 insertions(+), 4 deletions(-)
Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -1329,16 +1329,18 @@
compatible = "renesas,r8a7791-mstp-clocks",
"renesas,cpg-mstp-clocks";
reg = <0 0xe6150990 0 4>, <0 0xe61509a0 0 4>;
clocks = <&zx_clk>, <&hp_clk>, <&zg_clk>, <&zg_clk>,
-<&zg_clk>, <&p_clk>, <&zs_clk>, <&zs_clk>;
+<&zg_clk>, <&hp_clk>, <&p_clk>, <&zs_clk>,
+<&zs_clk>;
#clock-cells = <1>;
clock-indices = <
R8A7791_CLK_IPMMU_SGX R8A7791_CLK_MLB
R8A7791_CLK_VIN2 R8A7791_CLK_VIN1
R8A7791_CLK_VIN0
- R8A7791_CLK_ETHER R8A7791_CLK_SATA1
R8A7791_CLK_SATA0
+ R8A7791_CLK_ETHERAVB R8A7791_CLK_ETHER
+ R8A7791_CLK_SATA1 R8A7791_CLK_SATA0
>;
clock-output-names =
- "ipmmu_sgx", "mlb", "vin2", "vin1", "vin0",
"ether",
- "sata1", "sata0";
+ "ipmmu_sgx", "mlb", "vin2", "vin1", "vin0",
+ "etheravb", "ether", "sata1", "sata0";
};
mstp9_clks: mstp9_clks@e6150994 {
compatible = "renesas,r8a7791-mstp-clocks",
"renesas,cpg-mstp-clocks";
Index: renesas/include/dt-bindings/clock/r8a7791-clock.h
===
--- renesas.orig/include/dt-bindings/clock/r8a7791-clock.h
+++ renesas/include/dt-bindings/clock/r8a7791-clock.h
@@ -102,6 +102,7 @@
#define R8A7791_CLK_VIN2 9
#define R8A7791_CLK_VIN1 10
#define R8A7791_CLK_VIN0 11
+#define R8A7791_CLK_ETHERAVB 12
#define R8A7791_CLK_ETHER 13
#define R8A7791_CLK_SATA1 14
#define R8A7791_CLK_SATA0 15
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add R8A7791 EtherAVB DT support
Hello. Here's the set of 2 patches against Simon Horman's 'renesas.git' repo, 'renesas-devel-20151201-v4.4-rc3' tag. Here we add the EtherAVB device tree support for the R8A7791 SoC. The 2nd patch depends on the Simon's recent EtherAVB driver patches in order to work... [1/2] ARM: shmobile: r8a7791: add EtherAVB clock [2/2] ARM: shmobile: r8a7791: add EtherAVB DT support WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 net-next 5/5] net:hns: Add the init code to disable Hip06 "Hardware VLAN assist"
Hello.
On 12/02/2015 07:52 PM, Salil Mehta wrote:
This patch adds the initializzation code to disable the hardware
vlan support for VLAN Tag stripping by default for now.
Proper support of "hardware VLAN assitance" feature would
soon come in the next coming patches.
Signed-off-by: Salil Mehta
---
PATCH V6:
- No change over the earlier patch
PATCH V5:
- Minor merge/reject change resolved to application of previous patch
PATCH V4/V3/V2:
- No change over the initial floated patch
PATCH V1:
- Initial code to disable the hardware VLAN assist for now
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c |7 +++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h |1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index b5e4c44..f302ef9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -176,6 +176,11 @@ static void hns_ppe_cnt_clr_ce(struct hns_ppe_cb *ppe_cb)
PPE_CNT_CLR_CE_B, 1);
}
+static void hns_ppe_set_vlan_strip(struct hns_ppe_cb *ppe_cb, int en)
+{
+ dsaf_write_dev(ppe_cb, PPEV2_VLAN_STRIP_EN_REG, en);
Why not call it directly?
+}
+
/**
* hns_ppe_checksum_hw - set ppe checksum caculate
* @ppe_device: ppe device
@@ -336,6 +341,8 @@ static void hns_ppe_init_hw(struct hns_ppe_cb *ppe_cb)
hns_ppe_cnt_clr_ce(ppe_cb);
if (!AE_IS_VER1(dsaf_dev->dsaf_ver)) {
+ hns_ppe_set_vlan_strip(ppe_cb, 0);
+
/* set default RSS key in h/w */
hns_ppe_set_rss_key(ppe_cb, ppe_cb->rss_key);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 98c163e..6c18ca9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -318,6 +318,7 @@
#define PPE_CFG_PARSE_TAG_REG 0x94
#define PPE_CFG_PRO_CHECK_EN_REG 0x98
#define PPEV2_CFG_TSO_EN_REG0xA0
+#define PPEV2_VLAN_STRIP_EN_REG 0xAC
Please indent with tabs, like all the surrounding #define's are indented
(except PPEV2_CFG_TSO_EN_REG).
#define PPE_INTEN_REG 0x100
#define PPE_RINT_REG 0x104
#define PPE_INTSTS_REG0x108
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ravb: add R8A7791 support
On 12/1/2015 10:44 AM, Simon Horman wrote: Add support for yet another ARM member of the R-Car family, R-Car M2-W, also known as R8A7791. Signed-off-by: Sergei Shtylyov --- The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if it's applied to 'net.git' instead. :-) Changes in version 2: - fixed the SoC name in the changelog. I have no particular problem with this patch but as mentioned elsewhere I have been working on a more comprehensive patchset which I have now posted as: "[PATCH 0/2 net-next] ravb: More compat strings" Dave, please ignore my patch in favor of Simon's series (after it gets fixed up, of course). MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] reset: Add brcm,bcm63xx-reset device tree binding
Hello. On 11/30/2015 11:57 PM, Simon Arlott wrote: Add device tree binding for the BCM63xx soft reset controller. The BCM63xx contains a soft-reset controller activated by setting a bit (that must previously have cleared). Signed-off-by: Simon Arlott --- .../bindings/reset/brcm,bcm63xx-reset.txt | 37 ++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/brcm,bcm63xx-reset.txt diff --git a/Documentation/devicetree/bindings/reset/brcm,bcm63xx-reset.txt b/Documentation/devicetree/bindings/reset/brcm,bcm63xx-reset.txt new file mode 100644 index 000..48e9daf --- /dev/null +++ b/Documentation/devicetree/bindings/reset/brcm,bcm63xx-reset.txt @@ -0,0 +1,37 @@ +BCM63xx reset controller + +The BCM63xx contains a basic soft reset controller in the perf register +set which resets components using a bit in a register. + +Please also refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: +- compatible: Should be "brcm,bcm-reset", "brcm,bcm63xx-reset" Wildcards (xx) are not allowed here. Please choose a "least common denominator" SoC and name the string after it. [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 net-next] ravb: Add fallback compatibility strings
Hello. On 12/1/2015 10:43 AM, Simon Horman wrote: Add fallback compatibility strings for R-Car Gen 2 & 3 SoC Families. This is in keeping with the fallback scheme being adopted wherever appropriate for drivers for Renesas SoCs. Also correct typo. Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/net/renesas,ravb.txt | 11 +-- drivers/net/ethernet/renesas/ravb_main.c | 2 ++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index b486f3f5f6a3..115006325bff 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -1,12 +1,19 @@ * Renesas Electronics Ethernet AVB This file provides information on what the device node for the Ethernet AVB -interface contains. +interface. Why? [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ravb: add R8A7791 support
Add support for yet another ARM member of the R-Car family, R-Car M2-W,
also known as R8A7791.
Signed-off-by: Sergei Shtylyov
---
The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if it's
applied to 'net.git' instead. :-)
Changes in version 2:
- fixed the SoC name in the changelog.
Documentation/devicetree/bindings/net/renesas,ravb.txt |1 +
drivers/net/ethernet/renesas/ravb_main.c |1 +
2 files changed, 2 insertions(+)
Index: net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt
===
--- net-next.orig/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -5,6 +5,7 @@ interface contains.
Required properties:
- compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790
SoC.
+ "renesas,etheravb-r8a7791" if the device is a part of R8A7791 SoC.
"renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC.
"renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC.
- reg: offset and length of (1) the register block and (2) the stream buffer.
Index: net-next/drivers/net/ethernet/renesas/ravb_main.c
===
--- net-next.orig/drivers/net/ethernet/renesas/ravb_main.c
+++ net-next/drivers/net/ethernet/renesas/ravb_main.c
@@ -1655,6 +1655,7 @@ static int ravb_mdio_release(struct ravb
static const struct of_device_id ravb_match_table[] = {
{ .compatible = "renesas,etheravb-r8a7790", .data = (void *)RCAR_GEN2 },
+ { .compatible = "renesas,etheravb-r8a7791", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,etheravb-r8a7794", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,etheravb-r8a7795", .data = (void *)RCAR_GEN3 },
{ }
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ravb: add R8A7791 support
Hello. On 11/30/2015 03:42 AM, Simon Horman wrote: Add support for yet another ARM member of the R-Car family, R-Car M2, also R-Car M2-W? Right, forgot about the postfixes. known as R8A7791. There's also R-Car M2-N, aka R8A7793, but you probably know that ;-) Will fix. I would prefer if we added generic gen2 and gen3 compat strings to the driver and only documented new soc-specific compat strings. That's a new policy it seems. Previously you preferred the SoC-specific strings to be used, didn;t you? Actually by chance I was planning to up patches to do that and add compat strings for the missing Gen2 boards. But I won't complain if you beat me to it. No, I'm pretty busy as is. :-) MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ravb: add R8A7791 support
Hello.
On 11/29/2015 10:26 PM, Geert Uytterhoeven wrote:
Add support for yet another ARM member of the R-Car family, R-Car M2, also
R-Car M2-W?
Right, forgot about the postfixes.
known as R8A7791.
There's also R-Car M2-N, aka R8A7793, but you probably know that ;-)
Will fix.
Gr{oetje,eeting}s,
Geert
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ravb: add R8A7791 support
Add support for yet another ARM member of the R-Car family, R-Car M2, also
known as R8A7791.
Signed-off-by: Sergei Shtylyov
---
The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if it's
applied to 'net.git' instead. :-)
Documentation/devicetree/bindings/net/renesas,ravb.txt |1 +
drivers/net/ethernet/renesas/ravb_main.c |1 +
2 files changed, 2 insertions(+)
Index: net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt
===
--- net-next.orig/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -5,6 +5,7 @@ interface contains.
Required properties:
- compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790
SoC.
+ "renesas,etheravb-r8a7791" if the device is a part of R8A7791 SoC.
"renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC.
"renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC.
- reg: offset and length of (1) the register block and (2) the stream buffer.
Index: net-next/drivers/net/ethernet/renesas/ravb_main.c
===
--- net-next.orig/drivers/net/ethernet/renesas/ravb_main.c
+++ net-next/drivers/net/ethernet/renesas/ravb_main.c
@@ -1655,6 +1655,7 @@ static int ravb_mdio_release(struct ravb
static const struct of_device_id ravb_match_table[] = {
{ .compatible = "renesas,etheravb-r8a7790", .data = (void *)RCAR_GEN2 },
+ { .compatible = "renesas,etheravb-r8a7791", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,etheravb-r8a7794", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,etheravb-r8a7795", .data = (void *)RCAR_GEN3 },
{ }
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/14] DEVICETREE: Add bindings for PIC32 usart driver
Hello.
On 11/21/2015 3:17 AM, Joshua Henderson wrote:
From: Andrei Pistirica
Document the devicetree bindings for the USART peripheral found on
Microchip PIC32 class devices.
Signed-off-by: Andrei Pistirica
Signed-off-by: Joshua Henderson
---
.../bindings/serial/microchip,pic32-usart.txt | 29
1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/serial/microchip,pic32-usart.txt
diff --git a/Documentation/devicetree/bindings/serial/microchip,pic32-usart.txt
b/Documentation/devicetree/bindings/serial/microchip,pic32-usart.txt
new file mode 100644
index 000..c87321c
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/microchip,pic32-usart.txt
@@ -0,0 +1,29 @@
+* Microchip Universal Synchronous Asynchronous Receiver/Transmitter (USART)
+
+Required properties:
+- compatible: Should be "microchip,pic32-usart"
+- reg: Should contain registers location and length
+- interrupts: Should contain interrupt
+- pinctrl: Should contain pinctrl for TX/RX/RTS/CTS
No such prop in the example.
+
+Optional properties:
+- microchip,uart-has-rtscts : Indicate the uart has hardware flow control
+- rts-gpios: RTS pin for USP-based UART if microchip,uart-has-rtscts
+- cts-gpios: CTS pin for USP-based UART if microchip,uart-has-rtscts
+
+Example:
+ usart0: serial@1f822000 {
+ compatible = "microchip,pic32-usart";
+ reg = <0x1f822000 0x50>;
+ interrupts = ,
+,
+;
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &pinctrl_uart1
+ &pinctrl_uart1_cts
+ &pinctrl_uart1_rts>;
The above 2 props are undocumented.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/14] DEVICETREE: Add bindings for PIC32 SDHC host controller
Hello.
On 11/21/2015 3:17 AM, Joshua Henderson wrote:
From: Andrei Pistirica
Document the devicetree bindings for the SDHC peripheral found on
Microchip PIC32 class devices.
Signed-off-by: Andrei Pistirica
Signed-off-by: Joshua Henderson
---
.../devicetree/bindings/mmc/sdhci-pic32.txt| 24
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-pic32.txt
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pic32.txt
b/Documentation/devicetree/bindings/mmc/sdhci-pic32.txt
new file mode 100644
index 000..f16388c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pic32.txt
@@ -0,0 +1,24 @@
+* Microchip PIC32 SDHCI Controller
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-pic32 driver.
+
+Required properties:
+- compatible: Should be "microchip,pic32-sdhci"
+- reg: Should contain registers location and length
+- interrupts: Should contain interrupt
+- pinctrl: Should contain pinctrl for data and command lines
This is a required prop, yet the example doesn't contain it?
+
+Optional properties:
+- no-1-8-v: 1.8V voltage selection not supported
+- piomode: disable DMA support
+
+Example:
+
+ sdhci@1f8ec000 {
+ compatible = "microchip,pic32-sdhci";
+ reg = <0x1f8ec000 0x100>;
+ interrupts = ;
+ clocks = <&REFCLKO4>, <&PBCLK5>;
+ clock-names = "base_clk", "sys_clk";
The "clocks" and "clock-names" props are not documented.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb
Hello. On 11/21/2015 01:37 AM, Tim Bird wrote: Add optional async_irq to msm_hsusb binding doc. Signed-off-by: Tim Bird Acked-by: Rob Herring --- Documentation/devicetree/bindings/usb/msm-hsusb.txt | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt index 8654a3e..7ba1dff 100644 --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt @@ -23,7 +23,12 @@ Required properties: "qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY - regs: Offset and length of the register set in the memory map -- interrupts: interrupt-specifier for the OTG interrupt. +- interrupts: interrupt-specifier for the OTG interrupts + +- interrupt-names: Should contain the following: + "core_irq"USB core interrupt + "async_irq" Asynchronous interrupt to wake up from low power mode I think the "_irq" part can be dropped... [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 net-next 4/5] net:hns: Add support of ethtool TSO set option for Hip06 in HNS
On 11/19/2015 11:58 PM, Salil Mehta wrote:
From: Salil
This patch adds the support of ethtool TSO option to V1 patch,
meant to add support of Hip06 SoC to HNS
Signed-off-by: Salil Mehta
Signed-off-by: lisheng
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 47 +
1 file changed, 47 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 055e14c..a0763ab 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -1386,6 +1386,51 @@ static int hns_nic_change_mtu(struct net_device *ndev,
int new_mtu)
return ret;
}
+static int hns_nic_set_features(struct net_device *netdev,
+ netdev_features_t features)
+{
+ struct hns_nic_priv *priv = netdev_priv(netdev);
+ struct hnae_handle *h = priv->ae_handle;
+
+ switch (priv->enet_ver) {
+ case AE_VERSION_1:
+ if ((features & NETIF_F_TSO) || (features & NETIF_F_TSO6))
if ((features & (NETIF_F_TSO| NETIF_F_TSO6))
+ netdev_info(netdev, "enet v1 do not support tso!\n");
+ break;
The *break* should have the same indentation level as *if*.
+ default:
+ if ((features & NETIF_F_TSO) || (features & NETIF_F_TSO6)) {
if ((features & (NETIF_F_TSO| NETIF_F_TSO6))
+ priv->ops.fill_desc = fill_tso_desc;
+ priv->ops.maybe_stop_tx = hns_nic_maybe_stop_tso;
+ /* The chip only support 7*4096 */
+ netif_set_gso_max_size(netdev, 7 * 4096);
+ h->dev->ops->set_tso_stats(h, 1);
+ } else {
+ priv->ops.fill_desc = fill_v2_desc;
+ priv->ops.maybe_stop_tx = hns_nic_maybe_stop_tx;
+ h->dev->ops->set_tso_stats(h, 0);
+ }
+ break;
Same here.
+ }
+ netdev->features = features;
+ return 0;
+}
+
+static netdev_features_t hns_nic_fix_features(
+ struct net_device *netdev, netdev_features_t features)
+{
+ struct hns_nic_priv *priv = netdev_priv(netdev);
+
+ switch (priv->enet_ver) {
+ case AE_VERSION_1:
+ features &= ~(NETIF_F_TSO | NETIF_F_TSO6 |
+ NETIF_F_HW_VLAN_CTAG_FILTER);
+ break;
+ default:
+ break;
+ }
Here it's indented correctly.
+ return features;
+}
+
/**
* nic_set_multicast_list - set mutl mac address
* @netdev: net device
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] ARM: dts: rockchip: rk3288-veyron: rename pinctrl node reboot to reset
Hello.
On 11/18/2015 12:50 PM, Andy Yan wrote:
rename pinctrl node reboot to reset to match it's lable name
Label? BTW, I'm not seeing it on this node...
Signed-off-by: Andy Yan
---
Changes in v3:
- rename a pinctrl node in rk3288-veyron, the original name will be
used in the incoming reboot notifier driver
Changes in v2: None
arch/arm/boot/dts/rk3288-veyron.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi
b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 2fa7a0d..292aaaf 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -495,7 +495,7 @@
};
};
- reboot {
+ reset {
ap_warm_reset_h: ap-warm-reset-h {
rockchip,pins = ;
};
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 1/3] dt-bindings: Add a binding for Mediatek xHCI host controller
Hello. On 11/17/2015 12:18 PM, Chunfeng Yun wrote: add a DT binding documentation of xHCI host controller for the MT8173 SoC from Mediatek. Signed-off-by: Chunfeng Yun --- .../devicetree/bindings/usb/mt8173-xhci.txt| 51 ++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt new file mode 100644 index 000..a78f20b --- /dev/null +++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt @@ -0,0 +1,51 @@ +MT8173 xHCI + +The device node for Mediatek SOC USB3.0 host controller + +Required properties: + - compatible : should contain "mediatek,mt8173-xhci" + - reg : specifies physical base address and size of the registers, + the first one for MAC, the second for IPPC + - interrupts : interrupt used by the controller + - power-domains : a phandle to USB power domain node to control USB's + mtcmos What's that? + - vusb33-supply : regulator of USB avdd3.3v + + - clocks : a list of phandle + clock-specifier pairs, one for each + entry in clock-names + - clock-names : must contain + "sys_ck": for clock of xHCI MAC + "wakeup_deb_p0": for USB wakeup debounce clock of port0 + "wakeup_deb_p0": for USB wakeup debounce clock of port1 "wakeup_deb_p1"? + + - phys : a list of phandle + phy specifier pairs + +Optional properties: + - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup ^^ IP? + mode; + - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup + control register, it depends on "mediatek,wakeup-src". + - vbus-supply : reference to the VBUS regulator; + - usb3-lpm-capable : supports USB3.0 LPM [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] extcon: add MAX3355 driver
Hello.
On 11/10/2015 2:52 AM, Chanwoo Choi wrote:
I received the reply from you after too long time (17~18day).
You better to reply it more a little more quickly
if you have the question or new patches.
I've replied as soon as I had my new idea.
MAX3355E chip integrates a charge pump and comparators to enable a system with
an integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
device. In addition to sensing/controlling Vbus, the chip also passes thru the
ID signal from the USB OTG connector. On some Renesas boards, this signal is
just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only
host and gadget USB controllers sharing the same USB bus; however, we'd like
to allow host or gadget drivers to be loaded depending on the cable type,
hence
the need for the MAX3355 extcon driver. The Vbus status signals are also wired
to GPIOs (however, we're not currently intested in them), the OFFVBUS# signal
is controlled by the host controllers, there's also the SHDN# signal wired to
GPIO, which should be high for normal operation.
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 ++
drivers/extcon/Kconfig |6
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 122
4 files changed, 150 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+MAX3355 USB OTG chip
Need manufactor information as following :
-> Maxim MAX3355
Would be Maxim enough? Or perhaps I should use Maxim Integrated
[Products]?
You haven't replied to my questions.
+
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the
GPIO pin
+ connected to the MAX3355's SHDN# pin;
+- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+usb-otg {
+compatible = "maxim,max3355";
+maxim,shdn-gpio = <&gpio2 4 GPIO_ACTIVE_LOW>;
+maxim,id-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
Kernel already supported the gpio helper function to get gpio from devicetree.
I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
include/linux/of_gpio.h.
gpios = <&gpio2 4 GPIO_ACTIVE_LOW>, <&gpio5 31 GPIO_ACTIVE_HIGH>;
OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
to insist on using this one...
Moreover, it now says "gpios" isn't allowed for the new bindings. So I
have to strongly disagree here...
OK. But, I recommend you use the 'gpiod' with devm_gpiod_get
instead of using devm_gpio_request_one() directly as following:
You can refer drivers/extcon/extcon-usb-gpio.c about using gpiod.
For example,
data->shdn_gpiod = devm_gpiod_get(dev, "maxim,shdn", GPIOD_IN);
data->id_gpiod = devm_gpiod_get(dev, "maxim,id", GPIOD_IN);
Thanks, done now. I just had another idea: how about I add an optional
"enable-gpio" property to the 'extcon-usb-gpio' driver? I wouldn't need my own
driver then at all... :-)
What is meaning of 'enable-gpio' property?
You better to explain your goal about 'enable-gpio' property
This optional property would serve for enabling the valid signal on the ID
GPIO, the same way I'm using the SHDN# GPIO in the MAX3355 driver.
Also, If you think that it is generic way about
adding 'enable-gpio' property to extcon-usb-gpio.c,
you can try it.
Yes, I think it would be generic enough.
Thanks,
Chanwoo Choi
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] extcon: add MAX3355 driver
Hello.
On 10/23/2015 08:56 AM, Chanwoo Choi wrote:
MAX3355E chip integrates a charge pump and comparators to enable a system with
an integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
device. In addition to sensing/controlling Vbus, the chip also passes thru the
ID signal from the USB OTG connector. On some Renesas boards, this signal is
just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only
host and gadget USB controllers sharing the same USB bus; however, we'd like
to allow host or gadget drivers to be loaded depending on the cable type,
hence
the need for the MAX3355 extcon driver. The Vbus status signals are also wired
to GPIOs (however, we're not currently intested in them), the OFFVBUS# signal
is controlled by the host controllers, there's also the SHDN# signal wired to
GPIO, which should be high for normal operation.
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 ++
drivers/extcon/Kconfig |6
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 122
4 files changed, 150 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+MAX3355 USB OTG chip
Need manufactor information as following :
-> Maxim MAX3355
Would be Maxim enough? Or perhaps I should use Maxim Integrated [Products]?
You haven't replied to my questions.
+
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the
GPIO pin
+ connected to the MAX3355's SHDN# pin;
+- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+usb-otg {
+compatible = "maxim,max3355";
+maxim,shdn-gpio = <&gpio2 4 GPIO_ACTIVE_LOW>;
+maxim,id-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
Kernel already supported the gpio helper function to get gpio from devicetree.
I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
include/linux/of_gpio.h.
gpios = <&gpio2 4 GPIO_ACTIVE_LOW>, <&gpio5 31 GPIO_ACTIVE_HIGH>;
OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
to insist on using this one...
Moreover, it now says "gpios" isn't allowed for the new bindings. So I have
to strongly disagree here...
OK. But, I recommend you use the 'gpiod' with devm_gpiod_get
instead of using devm_gpio_request_one() directly as following:
You can refer drivers/extcon/extcon-usb-gpio.c about using gpiod.
For example,
data->shdn_gpiod = devm_gpiod_get(dev, "maxim,shdn", GPIOD_IN);
data->id_gpiod = devm_gpiod_get(dev, "maxim,id", GPIOD_IN);
Thanks, done now. I just had another idea: how about I add an optional
"enable-gpio" property to the 'extcon-usb-gpio' driver? I wouldn't need my own
driver then at all... :-)
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: henninger: remove board DT
The Henninger low cost board was never sold and so had no users outside
Renesas (and Cogent Embedded). Instead Renesas has made the Porter board
which has mostly similar hardware. Now that the Porter board support is on
par with Henninger, we can remove the Henninger's device tree file.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151028-v4.3-rc7' tag of Simon Horman's
'renesas.git' repo.
arch/arm/boot/dts/Makefile |1
arch/arm/boot/dts/r8a7791-henninger.dts | 320
2 files changed, 321 deletions(-)
Index: renesas/arch/arm/boot/dts/Makefile
===
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -530,7 +530,6 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
- r8a7791-henninger.dtb \
r8a7791-koelsch.dtb \
r8a7791-porter.dtb \
r8a7793-gose.dtb \
Index: renesas/arch/arm/boot/dts/r8a7791-henninger.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-henninger.dts
+++ /dev/null
@@ -1,320 +0,0 @@
-/*
- * Device Tree Source for the Henninger board
- *
- * Copyright (C) 2014 Renesas Solutions Corp.
- * Copyright (C) 2014 Cogent Embedded, Inc.
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
- */
-
-/dts-v1/;
-#include "r8a7791.dtsi"
-#include
-
-/ {
- model = "Henninger";
- compatible = "renesas,henninger", "renesas,r8a7791";
-
- aliases {
- serial0 = &scif0;
- };
-
- chosen {
- bootargs = "console=ttySC0,38400 ignore_loglevel rw
root=/dev/nfs ip=dhcp";
- stdout-path = &scif0;
- };
-
- memory@4000 {
- device_type = "memory";
- reg = <0 0x4000 0 0x4000>;
- };
-
- memory@2 {
- device_type = "memory";
- reg = <2 0x 0 0x4000>;
- };
-
- vcc_sdhi0: regulator@0 {
- compatible = "regulator-fixed";
-
- regulator-name = "SDHI0 Vcc";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- regulator-always-on;
- };
-
- vccq_sdhi0: regulator@1 {
- compatible = "regulator-gpio";
-
- regulator-name = "SDHI0 VccQ";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <330>;
-
- gpios = <&gpio2 12 GPIO_ACTIVE_HIGH>;
- gpios-states = <1>;
- states = <330 1
- 180 0>;
- };
-
- vcc_sdhi2: regulator@2 {
- compatible = "regulator-fixed";
-
- regulator-name = "SDHI2 Vcc";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- regulator-always-on;
- };
-
- vccq_sdhi2: regulator@3 {
- compatible = "regulator-gpio";
-
- regulator-name = "SDHI2 VccQ";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <330>;
-
- gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
- gpios-states = <1>;
- states = <330 1
- 180 0>;
- };
-};
-
-&extal_clk {
- clock-frequency = <2000>;
-};
-
-&pfc {
- scif0_pins: serial0 {
- renesas,groups = "scif0_data_d";
- renesas,function = "scif0";
- };
-
- ether_pins: ether {
- renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
- renesas,function = "eth";
- };
-
- phy1_pins: phy1 {
- renesas,groups = "intc_irq0";
- renesas,function = "intc";
- };
-
- sdhi0_pins: sd0 {
- renesas,groups = "sdhi0_data4", "sdhi0_ctrl";
- renesas,function = "sdhi0";
- };
-
- sdhi2_pins: sd2 {
- renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
- renesas,function = "sdhi2";
- };
-
- i2c2_pins: i2c2 {
- renesas,groups = "i2c2";
- renesas,function = &qu
Re: [PATCH] ARM: shmobile: porter: add CAN0 DT support
On 10/28/2015 01:41 AM, Simon Horman wrote:
Define the Porter board dependent part of the CAN0 device node.
This patch is analogous to the commit 457acc4a6ce8 (ARM: shmobile:
henninger: add CAN0 DT support) as there are no differences between the
boards in this respect.
Signed-off-by: Sergei Shtylyov
Thanks, I have queued this up for v4.5 after updating the changelog
as per checkpatch.pl's insight:
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("")' - ie: 'commit 457acc4a6ce8 ("ARM: shmobile: henninger: add CAN0 DT support")'
#8:
This patch is analogous to the commit 457acc4a6ce8 (ARM: shmobile:
Oops, sorry, forgot to update the patch description.
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: porter: add CAN0 DT support
Define the Porter board dependent part of the CAN0 device node.
This patch is analogous to the commit 457acc4a6ce8 (ARM: shmobile:
henninger: add CAN0 DT support) as there are no differences between the
boards in this respect.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151026-v4.3-rc7' tag of Simon Horman's
'renesas.git' repo.
arch/arm/boot/dts/r8a7791-porter.dts | 12
1 file changed, 12 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -134,6 +134,11 @@
renesas,groups = "vin0_data8", "vin0_clk";
renesas,function = "vin0";
};
+
+ can0_pins: can0 {
+ renesas,groups = "can0_data";
+ renesas,function = "can0";
+ };
};
&scif0 {
@@ -288,3 +293,10 @@
&pciec {
status = "okay";
};
+
+&can0 {
+ pinctrl-0 = <&can0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] extcon: add MAX3355 driver
Hello. On 10/21/2015 05:57 AM, Chanwoo Choi wrote: I think this patch is too much delay. I recommend you better to develop this driver based on latest extcon-next branch[1]. [1] https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-next I would really appreciate if you answer my questions, I think most of them are still valid... MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: of_mdiobus_register_phy() and deferred probe
Hello.
On 10/22/2015 04:31 PM, Geert Uytterhoeven wrote:
Due to a probe deferral of an interrupt controller[1], the Micrel
Ethernet PHY on
r8a7791/koelsch started failing to get its IRQ:
no irq domain found for /interrupt-controller@e61c !
However, of_mdiobus_register_phy() uses irq_of_parse_and_map(), which plainly
ignores EPROBE_DEFER, and it just continues.
Later I get:
sh-eth ee70.ethernet eth0: attached PHY 1 (IRQ -1) to driver
Micrel KSZ8041RNLI
instead of
sh-eth ee70.ethernet eth0: attached PHY 1 (IRQ 408) to driver
Micrel KSZ8041RNLI
Ethernet still works, as the interrupt seems to be unneeded(?).
Yes, the phylib uses PHY polling anyway, IRQ isn't strictly necessary.
Has anyone already looked into fixing of_mdio to handle deferred probing?
It's the first time I hear about that. Will have to look into this...
Gr{oetje,eeting}s,
Geert
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: shmobile: r8a7791: fix "gpio-ranges" props
On R8A7791, GPIO banks 1 and 7 are missing pins 26 to 31. Correct the "gpio-ranges" properties of the GPIO1 node (GPIO7 is already correct). Signed-off-by: Sergei Shtylyov --- This patch is against the 'renesas-devel-20151019-v4.3-rc6' of Simon Horman's 'renesas.git' repo. arch/arm/boot/dts/r8a7791.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: renesas/arch/arm/boot/dts/r8a7791.dtsi === --- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi +++ renesas/arch/arm/boot/dts/r8a7791.dtsi @@ -100,7 +100,7 @@ interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>; #gpio-cells = <2>; gpio-controller; - gpio-ranges = <&pfc 0 32 32>; + gpio-ranges = <&pfc 0 32 26>; #interrupt-cells = <2>; interrupt-controller; clocks = <&mstp9_clks R8A7791_CLK_GPIO1>; -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: shmobile: r8a7790: fix "gpio-ranges" props
On R8A7790, GPIO banks 1 and 2 are missing pins 30 and 31. Correct the "gpio-ranges" properties of the corresponding device nodes. Signed-off-by: Sergei Shtylyov --- This patch is against the 'renesas-devel-20151019-v4.3-rc6' of Simon Horman's 'renesas.git' repo. arch/arm/boot/dts/r8a7790.dtsi |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: renesas/arch/arm/boot/dts/r8a7790.dtsi === --- renesas.orig/arch/arm/boot/dts/r8a7790.dtsi +++ renesas/arch/arm/boot/dts/r8a7790.dtsi @@ -143,7 +143,7 @@ interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>; #gpio-cells = <2>; gpio-controller; - gpio-ranges = <&pfc 0 32 32>; + gpio-ranges = <&pfc 0 32 30>; #interrupt-cells = <2>; interrupt-controller; clocks = <&mstp9_clks R8A7790_CLK_GPIO1>; @@ -156,7 +156,7 @@ interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>; #gpio-cells = <2>; gpio-controller; - gpio-ranges = <&pfc 0 64 32>; + gpio-ranges = <&pfc 0 64 30>; #interrupt-cells = <2>; interrupt-controller; clocks = <&mstp9_clks R8A7790_CLK_GPIO2>; -- To unsubscribe from this list: send the line "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] DT: mmc: sh_mmcif: document R8A779[34] support
Hello. On 10/21/2015 11:38 AM, Ulf Hansson wrote: Renesas R8A7794 SoC also has the MMCIF controller... Signed-off-by: Sergei Shtylyov Thanks, applied for next. Oops, just noticed the subject was stale. I wasn't adding R8A7793 support in that version. Is it possible to fix? I have updated the subject, no worries! Perfect! Thanks a lot. :-) Kind regards Uffe MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: shmobile: silk: add SDHI1 DT support
On 10/21/2015 03:31 AM, Simon Horman wrote: There should have been [PATCH v3] in the subject, of course. Thanks for following up. I have queued this up for v4.5. Again, not seeing anything new today from renesas.git... Thanks for noticing, it should be there now. Hm, again nothing... :-( MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] DT: mmc: sh_mmcif: document R8A779[34] support
Hello. On 10/16/2015 04:07 PM, Ulf Hansson wrote: Renesas R8A7794 SoC also has the MMCIF controller... Signed-off-by: Sergei Shtylyov Thanks, applied for next. Oops, just noticed the subject was stale. I wasn't adding R8A7793 support in that version. Is it possible to fix? Kind regards Uffe [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] extcon: add MAX3355 driver
Hello.
On 12/18/2014 12:58 AM, Sergei Shtylyov wrote:
MAX3355E chip integrates a charge pump and comparators to enable a system with
an integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
device. In addition to sensing/controlling Vbus, the chip also passes thru the
ID signal from the USB OTG connector. On some Renesas boards, this signal is
just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only
host and gadget USB controllers sharing the same USB bus; however, we'd like
to allow host or gadget drivers to be loaded depending on the cable type,
hence
the need for the MAX3355 extcon driver. The Vbus status signals are also wired
to GPIOs (however, we're not currently intested in them), the OFFVBUS# signal
is controlled by the host controllers, there's also the SHDN# signal wired to
GPIO, which should be high for normal operation.
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 ++
drivers/extcon/Kconfig |6
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 122
4 files changed, 150 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+MAX3355 USB OTG chip
Need manufactor information as following :
-> Maxim MAX3355
Would be Maxim enough? Or perhaps I should use Maxim Integrated [Products]?
You haven't replied to my questions.
+
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the
GPIO pin
+ connected to the MAX3355's SHDN# pin;
+- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+usb-otg {
+compatible = "maxim,max3355";
+maxim,shdn-gpio = <&gpio2 4 GPIO_ACTIVE_LOW>;
+maxim,id-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
Kernel already supported the gpio helper function to get gpio from devicetree.
I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
include/linux/of_gpio.h.
gpios = <&gpio2 4 GPIO_ACTIVE_LOW>, <&gpio5 31 GPIO_ACTIVE_HIGH>;
OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
to insist on using this one...
Moreover, it now says "gpios" isn't allowed for the new bindings. So I
have to strongly disagree here...
[...]
+static irqreturn_t max3355_id_irq(int irq, void *dev_id)
+{
+struct max3355_data *data = dev_id;
+int id = gpio_get_value(data->id_gpio);
+
+extcon_set_cable_state(data->edev, "USB-HOST", !id);
You have to get the gpio flag in the devicetree by using of_get_gpio_flags()
function
and then you would set the cable state according to gpio state and flag.
I'm sorry but I just don't see why I have to do it. This is not a generic
GPIO driver, and the polarities of the GPIOs are determined solely by the
MAX3355 specs.
Again, got not reply...
[...]
+static int max3355_probe(struct platform_device *pdev)
+{
+struct device_node *np = pdev->dev.of_node;
+struct max3355_data *data;
+int gpio, irq, ret;
+
+data = devm_kzalloc(&pdev->dev, sizeof(struct max3355_data),
+GFP_KERNEL);
+if (!data)
+return -ENOMEM;
+
+data->edev = devm_extcon_dev_allocate(&pdev->dev, max3355_cable);
+if (IS_ERR(data->edev)) {
+dev_err(&pdev->dev, "failed to allocate extcon device\n");
+return PTR_ERR(data->edev);
+}
+data->edev->name = kstrdup(np->name, GFP_KERNEL);
+
+gpio = of_get_named_gpio(np, "maxim,id-gpio", 0);
Use of_get_gpio() or of_get_gpio_flags().
OK, I'll use the first one.
No, I won't due to not being able to use "gpios" anymore.
[...]
+
+ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, max3355_id_irq,
+IRQF_TRIGGER_RISING |
+IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
Is it right to add both RISING and FALLING trigger?
How else I'm supposed to know when the OTG ID signal goes low and high?
and need to add IRQF_NO_SUSPEND to wakeup from suspend state when interrupt
h
Re: [PATCH v2] ARM: shmobile: silk: add SDHI1 DT support
Hello. On 10/19/2015 03:46 AM, Simon Horman wrote: There should have been [PATCH v3] in the subject, of course. Thanks for following up. I have queued this up for v4.5. Again, not seeing anything new today from renesas.git... MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: shmobile: silk: add SDHI1 DT support
There should have been [PATCH v3] in the subject, of course. -- To unsubscribe from this list: send the line "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 v10 3/3] arm64: dts: mediatek: add xHCI & usb phy for mt8173
Hello.
On 10/18/2015 6:51 AM, Chunfeng Yun wrote:
add xHCI and phy drivers for MT8173-EVB
Signed-off-by: Chunfeng Yun
[...]
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..46f5f50 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
[...]
@@ -487,6 +488,47 @@
clock-names = "source", "hclk";
status = "disabled";
};
+
+ usb30: usb@1127 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1127 0 0x1000>,
+ <0 0x11280700 0 0x0100>;
+ interrupts = ;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+ clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+ phys = <&phy_port0 PHY_TYPE_USB3>,
+ <&phy_port1 PHY_TYPE_USB2>;
+ mediatek,syscon-wakeup = <&pericfg>;
+ status = "okay";
+ };
+
+ u3phy: usb-phy@1129 {
+ compatible = "mediatek,mt8173-u3phy";
+ reg = <0 0x1129 0 0x800>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "u3phya_ref";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "okay";
Don't you need the "power-domains" prop here as well?
+
+ phy_port0: port@11290800 {
+ reg = <0 0x11290800 0 0x800>;
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ phy_port1: port@11291000 {
+ reg = <0 0x11291000 0 0x800>;
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
};
};
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: shmobile: silk: add SDHI1 DT support
Define the SILK board dependent part of the SDHI1 (connected to micro-SD
slot) device nodes along with the necessary voltage regulators.
Based on the original patch by Vladimir Barinov
.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151015-v4.3-rc5' tag of Simon Horman's
'renesas.git' repo.
Changes in version 3:
- removed the "disable-wp" property;
- added empty line before the regulator nodes;
- reformatted the changelog;
- refreshed the patch.
Changes in version 2:
- removed non-working SDHI0 stuff, renamed the patch;
- replaced SDHI1's "wp-gpios" property with "disable-wp".
arch/arm/boot/dts/r8a7794-silk.dts | 40 +
1 file changed, 40 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7794-silk.dts
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -12,6 +12,7 @@
/dts-v1/;
#include "r8a7794.dtsi"
+#include
/ {
model = "SILK";
@@ -39,6 +40,30 @@
regulator-boot-on;
regulator-always-on;
};
+
+ vcc_sdhi1: regulator@3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI1 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = <&gpio4 26 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi1: regulator@4 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI1 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
};
&extal_clk {
@@ -71,6 +96,11 @@
renesas,function = "mmc";
};
+ sdhi1_pins: sd1 {
+ renesas,groups = "sdhi1_data4", "sdhi1_ctrl";
+ renesas,function = "sdhi1";
+ };
+
qspi_pins: spi0 {
renesas,groups = "qspi_ctrl", "qspi_data4";
renesas,function = "qspi";
@@ -147,6 +177,16 @@
status = "okay";
};
+&sdhi1 {
+ pinctrl-0 = <&sdhi1_pins>;
+ pinctrl-names = "default";
+
+ vmmc-supply = <&vcc_sdhi1>;
+ vqmmc-supply = <&vccq_sdhi1>;
+ cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
&qspi {
pinctrl-0 = <&qspi_pins>;
pinctrl-names = "default";
--
To unsubscribe from this list: send the line "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] DT: mmc: sh_mmcif: document R8A779[34] support
Renesas R8A7794 SoC also has the MMCIF controller... Signed-off-by: Sergei Shtylyov --- The patch is against Ulf Hansson's 'mmc.git' repo's 'next' branches plus the patch I posted earlier today... Changes in version 3: - resolved reject. Changes in version 2: - deferred R8A7793 support to the patch posted earlier by Ulrich Hecht; - fixed typo in the changelog. Documentation/devicetree/bindings/mmc/renesas,mmcif.txt |1 + 1 file changed, 1 insertion(+) Index: mmc/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt === --- mmc.orig/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt +++ mmc/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt @@ -11,6 +11,7 @@ Required properties: - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs + - "renesas,mmcif-r8a7794" for the MMCIF found in r8a7794 SoCs - clocks: reference to the functional clock -- To unsubscribe from this list: send the line "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] DT: mmc: sh_mmcif: fix "compatible" property text
The "compatible" property text contradicts even the example given in the MMCIF
binding document itself; moreover, the Renesas MMCIF driver only matches on
the generic "compatible" string and doesn't look for the SoC specific strings
at all. Thus describe "renesas,sh-mmcif" as a fallback value.
Fixes: b4c27763d749 ("mmc: sh_mmcif: Document DT bindings")
Signed-off-by: Sergei Shtylyov
---
The patch is against Ulf Hansson's 'mmc.git' repo's 'fixes' or 'next' branches.
Changes in version 3:
- reworded the "compatible" property description to look like the majority of
the Renesas bindings.
Changes in version 2:
- kept the SoC specific "compatible" property values mandatory and made the
generic string a fallback.
Documentation/devicetree/bindings/mmc/renesas,mmcif.txt |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: mmc/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
===
--- mmc.orig/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
+++ mmc/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
@@ -6,11 +6,11 @@ and the properties used by the MMCIF dev
Required properties:
-- compatible: must contain one of the following
+- compatible: should be "renesas,mmcif-", "renesas,sh-mmcif" as a
+ fallback. Examples with are:
- "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
- "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs
- "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs
- - "renesas,sh-mmcif" for the generic MMCIF
- clocks: reference to the functional clock
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: porter: add HS-USB DT support
Hello.
On 10/15/2015 3:18 AM, Simon Horman wrote:
Enable HS-USB device for the Porter board, defining the GPIO that the
driver should check when probing (which is the ID output from MAX3355
OTG chip).
Note that there will be pinctrl-related error messages if both internal
PCI and HS-USB drivers are enabled but they should be just ignored.
This patch is analogous to the commit 6f4f7156e0e6 (ARM: shmobile:
henninger: enable HS-USB) as there are no differences between the
boards in this respect.
Signed-off-by: Sergei Shtylyov
Thanks Sergei,
I have queued this up for v4.5.
I took the liberty of tweaking the changelog to address a complaint made
by Mr. Check Patch.
Which means I forgot to run it again. Sorry about that. :-<
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("")' - ie: 'commit 6f4f7156e0e6 ("ARM: shmobile: henninger: enable HS-USB")'
Keep forgetting about the now enforced quotes...
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: porter: add HS-USB DT support
Enable HS-USB device for the Porter board, defining the GPIO that the
driver should check when probing (which is the ID output from MAX3355
OTG chip).
Note that there will be pinctrl-related error messages if both internal
PCI and HS-USB drivers are enabled but they should be just ignored.
This patch is analogous to the commit 6f4f7156e0e6 (ARM: shmobile:
henninger: enable HS-USB) as there are no differences between the
boards in this respect.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151013v2-v4.3-rc5' tag of Simon Horman's
'renesas.git' repo.
arch/arm/boot/dts/r8a7791-porter.dts |8
1 file changed, 8 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -269,6 +269,14 @@
status = "okay";
};
+&hsusb {
+ pinctrl-0 = <&usb0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ renesas,enable-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+};
+
&usbphy {
status = "okay";
};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] arm64: dts: mt8173: Add nor flash node
Hello.
On 10/14/2015 4:07 AM, Daniel Kurtz wrote:
Add Mediatek nor flash node
Signed-off-by: Bayi Cheng
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..385c2e4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -365,6 +365,21 @@
status = "disabled";
};
+ nor_flash: spi@1100d000 {
I don't think this is a good label name for a SPI controller.
You think "spi" is not a good name for SPI controller?
Or you mean the label "nor_flash"?
I think I said clearly: "label". :-)
Would you prefer:
spi_nor_flash: spi@1100d000
I'd prefer the "_nor_flash" part to be dropped, to be used for the real
flash device (if needed) which is a sub-node of this node.
[...]
-Dan
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] arm64: dts: mt8173: Add nor flash node
Hello.
On 10/13/2015 12:39 PM, Bayi Cheng wrote:
Add Mediatek nor flash node
Signed-off-by: Bayi Cheng
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..385c2e4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -365,6 +365,21 @@
status = "disabled";
};
+ nor_flash: spi@1100d000 {
I don't think this is a good label name for a SPI controller.
+ compatible = "mediatek,mt8173-nor";
+ reg = <0 0x1100d000 0 0xe0>;
+ clocks = <&pericfg CLK_PERI_SPI>,
+<&topckgen CLK_TOP_SPINFI_IFR_SEL>;
+ clock-names = "spi", "sf";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ };
+ };
+
i2c3: i2c3@1101 {
Grr, the name should be "i2c@1101".
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: porter: enable internal PCI and USB PHY
Enable internal AHB-PCI bridges for the USB EHCI/OHCI controllers attached
to them and also enable USB PHY device for the Porter board. We have to
enable everything in one patch since EHCI/OHCI devices are already linked
to the USB PHY device.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151012-v4.3-rc5' tag of Simon Horman's
'renesas.git' repo.
arch/arm/boot/dts/r8a7791-porter.dts | 28
1 file changed, 28 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -120,6 +120,16 @@
renesas,function = "i2c2";
};
+ usb0_pins: usb0 {
+ renesas,groups = "usb0";
+ renesas,function = "usb0";
+ };
+
+ usb1_pins: usb1 {
+ renesas,groups = "usb1";
+ renesas,function = "usb1";
+ };
+
vin0_pins: vin0 {
renesas,groups = "vin0_data8", "vin0_clk";
renesas,function = "vin0";
@@ -245,6 +255,24 @@
};
};
+&pci0 {
+ pinctrl-0 = <&usb0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pci1 {
+ pinctrl-0 = <&usb1_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&usbphy {
+ status = "okay";
+};
+
&pcie_bus_clk {
status = "okay";
};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: porter: enable PCIe
Enable the PCIe controller and clock for the Porter board.
This patch is analogous to the commit 485f3ce67c11 ("ARM: shmobile:
henninger: Enable PCIe Controller & PCIe bus clock") as there are no
differences between the boards in this respect.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151008-v4.3-rc4' tag of Simon Horman's
'renesas.git' repo plus the Porter I2C2, VIN0/ADV7180, and QSPI patches posted
earlier.
arch/arm/boot/dts/r8a7791-porter.dts |8
1 file changed, 8 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -244,3 +244,11 @@
};
};
};
+
+&pcie_bus_clk {
+ status = "okay";
+};
+
+&pciec {
+ status = "okay";
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: shmobile: porter: add QSPI DT support
Define the Porter board dependent part of the QSPI device node.
Add device nodes for Spansion S25FL512S SPI flash and the MTD partitions
on it.
This patch is mostly analogous to the commit f59838d44835 ("ARM:
shmobile: henninger: add QSPI DT support") as there are no differences
between the boards in this respect.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151008-v4.3-rc4' tag of Simon Horman's
'renesas.git' repo plus the Porter I2C2 and VIN0/ADV7180 patches posted earlier.
Changes in version 2:
- fixed the commit citing style and reformatted that whole paragraph.
arch/arm/boot/dts/r8a7791-porter.dts | 38 +++
1 file changed, 38 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -110,6 +110,11 @@
renesas,function = "sdhi2";
};
+ qspi_pins: spi0 {
+ renesas,groups = "qspi_ctrl", "qspi_data4";
+ renesas,function = "qspi";
+ };
+
i2c2_pins: i2c2 {
renesas,groups = "i2c2";
renesas,function = "i2c2";
@@ -165,6 +170,39 @@
status = "okay";
};
+&qspi {
+ pinctrl-0 = <&qspi_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25fl512s", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <3000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ m25p,fast-read;
+
+ partition@0 {
+ label = "loader_prg";
+ reg = <0x 0x0004>;
+ read-only;
+ };
+ partition@4 {
+ label = "user_prg";
+ reg = <0x0004 0x0040>;
+ read-only;
+ };
+ partition@44 {
+ label = "flash_fs";
+ reg = <0x0044 0x03bc>;
+ };
+ };
+};
+
&i2c2 {
pinctrl-0 = <&i2c2_pins>;
pinctrl-names = "default";
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: porter: add QSPI DT support
Define the Porter board dependent part of the QSPI device node.
Add device nodes for Spansion S25FL512S SPI flash and the MTD partitions
on it.
This patch is mostly analogous to the commit f59838d44835 (ARM: shmobile:
henninger: add QSPI DT support) as there are no differences between the
boards in this respect.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151008-v4.3-rc4' tag of Simon Horman's
'renesas.git' repo plus the Porter I2C2 and VIN0/ADV7180 patches posted earlier.
arch/arm/boot/dts/r8a7791-porter.dts | 38 +++
1 file changed, 38 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -110,6 +110,11 @@
renesas,function = "sdhi2";
};
+ qspi_pins: spi0 {
+ renesas,groups = "qspi_ctrl", "qspi_data4";
+ renesas,function = "qspi";
+ };
+
i2c2_pins: i2c2 {
renesas,groups = "i2c2";
renesas,function = "i2c2";
@@ -165,6 +170,39 @@
status = "okay";
};
+&qspi {
+ pinctrl-0 = <&qspi_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25fl512s", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <3000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ m25p,fast-read;
+
+ partition@0 {
+ label = "loader_prg";
+ reg = <0x 0x0004>;
+ read-only;
+ };
+ partition@4 {
+ label = "user_prg";
+ reg = <0x0004 0x0040>;
+ read-only;
+ };
+ partition@44 {
+ label = "flash_fs";
+ reg = <0x0044 0x03bc>;
+ };
+ };
+};
+
&i2c2 {
pinctrl-0 = <&i2c2_pins>;
pinctrl-names = "default";
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: henninger: add MSIOF0 DT support
On 05/07/2014 12:47 AM, Sergei Shtylyov wrote: Define the Henninger board dependent part of the MSIOF0 device node. Add device node for Renesas R2A11302FT PMIC for which no bindings exist yet. I've just realized that there's no such PMIC on the Henninger/Porter boards and MSIOF0 is only connected to CN6, hence this patch was wrong. The .dts is going to be deleted anyway though... Based on the Koelsch MSIOF device tree patch by Geert Uytterhoeven. Signed-off-by: Sergei Shtylyov MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: porter: add I2C2 DT support
Hello.
On 10/09/2015 04:13 AM, Simon Horman wrote:
Define the Porter board dependent part of the I2C2 device node.
This patch is analogous to the commit 29a647c396a0 ("ARM: shmobile:
henninger: add I2C2 DT support") as there are no differences between
the boards in this respect.
Signed-off-by: Sergei Shtylyov
Thanks Sergei,
I have queued this up for v4.4.
Not seeing anything from renesas.git running 'git fetch'. Forgot to push? :-)
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: porter: add VIN0/ADV7180 DT support
Define the Porter board dependent part of the VIN0 device node.
Add the device node for Analog Devices ADV7180 video decoder to I2C2 bus.
Add the necessary subnodes to interconnect VIN0 and ADV7180 devices.
This patch is analogous to the commit 8d62f4f75320 ("ARM: shmobile:
henninger: add VIN0/ADV7180 DT support") as there are no differences
between the boards in this respect.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151008-v4.3-rc4' tag of Simon Horman's
'renesas.git' repo plus the Porter I2C2 support patch just posted.
arch/arm/boot/dts/r8a7791-porter.dts | 35 +++
1 file changed, 35 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -114,6 +114,11 @@
renesas,groups = "i2c2";
renesas,function = "i2c2";
};
+
+ vin0_pins: vin0 {
+ renesas,groups = "vin0_data8", "vin0_clk";
+ renesas,function = "vin0";
+ };
};
&scif0 {
@@ -166,8 +171,38 @@
status = "okay";
clock-frequency = <40>;
+
+ composite-in@20 {
+ compatible = "adi,adv7180";
+ reg = <0x20>;
+ remote = <&vin0>;
+
+ port {
+ adv7180: endpoint {
+ bus-width = <8>;
+ remote-endpoint = <&vin0ep>;
+ };
+ };
+ };
};
&sata0 {
status = "okay";
};
+
+/* composite video input */
+&vin0 {
+ status = "ok";
+ pinctrl-0 = <&vin0_pins>;
+ pinctrl-names = "default";
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vin0ep: endpoint {
+ remote-endpoint = <&adv7180>;
+ bus-width = <8>;
+ };
+ };
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: porter: add I2C2 DT support
Define the Porter board dependent part of the I2C2 device node.
This patch is analogous to the commit 29a647c396a0 ("ARM: shmobile:
henninger: add I2C2 DT support") as there are no differences between
the boards in this respect.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151008-v4.3-rc4' tag of Simon Horman's
'renesas.git' repo.
arch/arm/boot/dts/r8a7791-porter.dts | 13 +
1 file changed, 13 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -109,6 +109,11 @@
renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
renesas,function = "sdhi2";
};
+
+ i2c2_pins: i2c2 {
+ renesas,groups = "i2c2";
+ renesas,function = "i2c2";
+ };
};
&scif0 {
@@ -155,6 +160,14 @@
status = "okay";
};
+&i2c2 {
+ pinctrl-0 = <&i2c2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <40>;
+};
+
&sata0 {
status = "okay";
};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: porter: add SDHI0/2 DT support
Hello. On 10/8/2015 5:12 AM, Simon Horman wrote: Define the Porter board dependent part of the SDHI0/2 device nodes along with the necessary voltage regulators (note that the Vcc regulators are dummy -- they are required but don't actually exist on the board). Also, GPIOs have to be used for the CD and WP signals due to the SDHI driver constraints... This patch is analogous to the commit 1299df03d719 (ARM: shmobile: henninger: add SDHI0/2 DT support) as there are no differences between those boards in this respect. Signed-off-by: Sergei Shtylyov --- This patch is against the 'renesas-devel-20151006-v4.3-rc4' tag of Simon Horman's 'renesas.git' repo. Thanks I have queued this up after addressing some issues in the changelog that checkpatch complained about: * text > 75 characters wide * Missing '"' around name of patch referred to Its looking like there is already quite a log shared between Lot? r8a7791-porter.dts and r8a7791-henninger.dts. Do you have any thoughts on consolidating or sharing common elements between them somehow? I'm still planning to remove the Henninger's .dts for good. It was never sold and so had no users outside Renesas (and Cogent Embedded), I was told. Thanks, that sounds like a good plan to me. Do you have any thoughts on when? Well, I was going to reach the feature parity between these 2 boards, i.e. to support all devices on Porter that are supported on Henninger... MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: porter: enable SATA0
Enable SATA0 device for the Porter board.
This patch is analogous to the commit 5a62ec57004f ("ARM: shmobile:
henninger: enable SATA0") as there are no differences between the boards
in this respect.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151007-v4.3-rc4' tag of Simon Horman's
'renesas.git' repo.
arch/arm/boot/dts/r8a7791-porter.dts |4
1 file changed, 4 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -154,3 +154,7 @@
cd-gpios = <&gpio6 22 GPIO_ACTIVE_LOW>;
status = "okay";
};
+
+&sata0 {
+ status = "okay";
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: porter: add SDHI0/2 DT support
On 10/07/2015 06:39 AM, Simon Horman wrote: Define the Porter board dependent part of the SDHI0/2 device nodes along with the necessary voltage regulators (note that the Vcc regulators are dummy -- they are required but don't actually exist on the board). Also, GPIOs have to be used for the CD and WP signals due to the SDHI driver constraints... This patch is analogous to the commit 1299df03d719 (ARM: shmobile: henninger: add SDHI0/2 DT support) as there are no differences between those boards in this respect. Signed-off-by: Sergei Shtylyov --- This patch is against the 'renesas-devel-20151006-v4.3-rc4' tag of Simon Horman's 'renesas.git' repo. Thanks I have queued this up after addressing some issues in the changelog that checkpatch complained about: * text > 75 characters wide * Missing '"' around name of patch referred to Sorry about that, forgot to run thru checkpatch.pl (as usual :-). MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: porter: add SDHI0/2 DT support
Hello. On 10/7/2015 6:39 AM, Simon Horman wrote: Define the Porter board dependent part of the SDHI0/2 device nodes along with the necessary voltage regulators (note that the Vcc regulators are dummy -- they are required but don't actually exist on the board). Also, GPIOs have to be used for the CD and WP signals due to the SDHI driver constraints... This patch is analogous to the commit 1299df03d719 (ARM: shmobile: henninger: add SDHI0/2 DT support) as there are no differences between those boards in this respect. Signed-off-by: Sergei Shtylyov --- This patch is against the 'renesas-devel-20151006-v4.3-rc4' tag of Simon Horman's 'renesas.git' repo. Thanks I have queued this up after addressing some issues in the changelog that checkpatch complained about: * text > 75 characters wide * Missing '"' around name of patch referred to Its looking like there is already quite a log shared between Lot? r8a7791-porter.dts and r8a7791-henninger.dts. Do you have any thoughts on consolidating or sharing common elements between them somehow? I'm still planning to remove the Henninger's .dts for good. It was never sold and so had no users outside Renesas (and Cogent Embedded), I was told. MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: porter: add SDHI0/2 DT support
Define the Porter board dependent part of the SDHI0/2 device nodes along with
the necessary voltage regulators (note that the Vcc regulators are dummy --
they are required but don't actually exist on the board). Also, GPIOs have to
be used for the CD and WP signals due to the SDHI driver constraints...
This patch is analogous to the commit 1299df03d719 (ARM: shmobile: henninger:
add SDHI0/2 DT support) as there are no differences between those boards in
this respect.
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'renesas-devel-20151006-v4.3-rc4' tag of Simon
Horman's 'renesas.git' repo.
arch/arm/boot/dts/r8a7791-porter.dts | 76 +++
1 file changed, 76 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -10,6 +10,7 @@
/dts-v1/;
#include "r8a7791.dtsi"
+#include
/ {
model = "Porter";
@@ -33,6 +34,50 @@
device_type = "memory";
reg = <2 0x 0 0x4000>;
};
+
+ vcc_sdhi0: regulator@0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI0 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vccq_sdhi0: regulator@1 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI0 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = <&gpio2 12 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
+
+ vcc_sdhi2: regulator@2 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI2 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vccq_sdhi2: regulator@3 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI2 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
};
&extal_clk {
@@ -54,6 +99,16 @@
renesas,groups = "intc_irq0";
renesas,function = "intc";
};
+
+ sdhi0_pins: sd0 {
+ renesas,groups = "sdhi0_data4", "sdhi0_ctrl";
+ renesas,function = "sdhi0";
+ };
+
+ sdhi2_pins: sd2 {
+ renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
+ renesas,function = "sdhi2";
+ };
};
&scif0 {
@@ -78,3 +133,24 @@
micrel,led-mode = <1>;
};
};
+
+&sdhi0 {
+ pinctrl-0 = <&sdhi0_pins>;
+ pinctrl-names = "default";
+
+ vmmc-supply = <&vcc_sdhi0>;
+ vqmmc-supply = <&vccq_sdhi0>;
+ cd-gpios = <&gpio6 6 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&sdhi2 {
+ pinctrl-0 = <&sdhi2_pins>;
+ pinctrl-names = "default";
+
+ vmmc-supply = <&vcc_sdhi2>;
+ vqmmc-supply = <&vccq_sdhi2>;
+ cd-gpios = <&gpio6 22 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: shmobile: silk: add SDHI1 DT support
Hello. Sorry for tyhe long delay, I've been busy with other things. Now I'm dealing with SDHI again, this time for the Porter board. On 09/29/2015 11:44 AM, Magnus Damm wrote: Define the SILK board dependent part of the SDHI1 (connected to micro-SD slot) device nodes along with the necessary voltage regulators. Based on the original patch by Vladimir Barinov . Signed-off-by: Sergei Shtylyov --- This patch is against 'renesas-devel-20150810-v4.2-rc6' tag of Simon Horman's 'renesas.git' repo plus the R8A7794/SILK QSPI patches just re-posted. It needs the R8A7794 GPIO patches in order to compile. Changes in version 2: - removed not working SDHI0 stuff, renamed the patch; - replaced SDHI1's "wp-gpios" property with "disable-wp". I am wondering if you could explain the motivation for the "disable-wp" update Please see the comment in mmc_sd_get_ro(). and weather it is appropriate for other r8a779* dts files. In case of micro-SD slots, yes. The MMC binding document says it should only be specified if the controller has WP detection logic. We, so far, seem to have been replying on the GPIOs despite this logic is present (according to the R-Car gen2 SDHI manuals I have). The driver will first call mmc_gpio_get_ro() and when that fails due to "wp-gpios" not being specified, it proceeds to reading the register but that is forbidden by TMIO_MMC_WRPROTECT_DISABLE flag set for the R-Car gen1/2 chips, so 0 is always returned from tmio_mmc_get_ro(). There seems to be no point in going that far (and doing the runtime PM dances) -- Alternatively, the driver could be fixed to check the flag before the RPM call unlike what it does now. If the driver can be updated to do the right thing then that seems preferable to me. If so would it be the case that the presence of the "disable-wp" property would not have any run-time effect? and MMC_CAP2_NO_WRITE_PROTECT (set when "disable-wp" is specified) prohibits doing that... That sounds reasonable to me. I'm still wondering why TMIO_MMC_WRPROTECT_DISABLE is set for the R-Car SoCs. Morimoto-san, any comments? Your change logs are too terse. :-) I will follow up on this. [...] Now what is the issue that you guys are having? My main issue is that I don't understand why checking the write protect bit is always prohibited for the R-Car SoCs (by setting TMIO_MMC_WRPROTECT_DISABLE), i.e. it can only be read via GPIO (though that GPIO is just an alias of the WP signal). I believe the reason is that we decided to keep it simple - so we preferred to use GPIO instead of native SDHI signals. So GPIO WP instead of the not-always-present SDHI WP signal. Historically CD and WP may on some boards be routed on different pins than the SDHI CD and WP lines, and if we support both GPIO and native SDHI signals we need to handle both cases. If you look at the driver code, it's already capable of handling both cases. With GPIO there is only one case to handle. And it is not exactly hot path to handle WP and CD so the overhead must be minimal. [...] The on-chip SoC SDHI devices in DT and the driver on R-Car Gen2 assumes no WP and CD signals by default. It is up to each board to opt-in to add the GPIOs for WP and CD. It is very simple and should make it possible to power down the SDHI instances if no cards are inserted and let the GPIO IRQ wake up things for us. Again, if you look at the driver code, it first powers up the controller, (thru runtime PM) and only then checks the TMIO_MMC_WRPROTECT_DISABLE flag. That's what I tried to change but didn't succeed because the current MMC code will have already powered up the controller by that time. I still don't understand what the real problem is though... The original issue revolved around the "disable-wp" prop. The common MMC bindings say that this prop should only be used "when the controller has a dedicated write-protect detection logic". This logic is obviously present but its use seems suppressed on the R-Car SoCs by the infamous flag... :-) Thanks, / magnus MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: porter: add Ether DT support
Define the Porter board dependent part of the Ether device node.
Enable DHCP and NFS root for the kernel booting.
This patch is analogous to the commit 26b0d2cf73cb (ARM: shmobile: henninger:
add Ether DT support) as there are no differences between those boards in this
respect.
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'renesas-devel-20151005-v4.3-rc4' tag of Simon
Horman's 'renesas.git' repo.
arch/arm/boot/dts/r8a7791-porter.dts | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -20,7 +20,7 @@
};
chosen {
- bootargs = "ignore_loglevel";
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
stdout-path = &scif0;
};
@@ -44,6 +44,16 @@
renesas,groups = "scif0_data_d";
renesas,function = "scif0";
};
+
+ ether_pins: ether {
+ renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
+ renesas,function = "eth";
+ };
+
+ phy1_pins: phy1 {
+ renesas,groups = "intc_irq0";
+ renesas,function = "intc";
+ };
};
&scif0 {
@@ -52,3 +62,19 @@
status = "okay";
};
+
+ðer {
+ pinctrl-0 = <ðer_pins &phy1_pins>;
+ pinctrl-names = "default";
+
+ phy-handle = <&phy1>;
+ renesas,ether-link-active-low;
+ status = "ok";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ interrupt-parent = <&irqc0>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ micrel,led-mode = <1>;
+ };
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: fix SILK board name
Unfortunately, the SILK board bindings were not quite correct, as the board name should be all caps. Fix that, adding the board model # in parens and removing stray semicolon. Signed-off-by: Sergei Shtylyov --- Documentation/devicetree/bindings/arm/shmobile.txt |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: renesas/Documentation/devicetree/bindings/arm/shmobile.txt === --- renesas.orig/Documentation/devicetree/bindings/arm/shmobile.txt +++ renesas/Documentation/devicetree/bindings/arm/shmobile.txt @@ -57,5 +57,5 @@ Boards: compatible = "renesas,marzen", "renesas,r8a7779" - Porter (M2-LCDP) compatible = "renesas,porter", "renesas,r8a7791" - - Silk -compatible = "renesas,silk", "renesas,r8a7794"; + - SILK (RTP0RC7794LCB00011S) +compatible = "renesas,silk", "renesas,r8a7794" -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: r8a7794: link PCI USB devices to USB PHY
Hello. On 10/02/2015 05:00 AM, Simon Horman wrote: Describe the PCI USB devices that are behind the PCI bridges, adding necessary links to the USB PHY device. Signed-off-by: Sergei Shtylyov --- This patch is against 'renesas-devel-20150911v2-v4.2' tag of Simon Horman's 'renesas.git' repo plus the R8A7794/SILK PCI USB and USB PHY support patches just posted. Does this series have any dependencies (e.g. bindings) other This patch, you mean? than the aforementioned R8A7794/SILK PCI USB and USB PHY support patches? Thanks, I have queued this up for v4.4. Thank you! I think I have got everything now but please let me know if you have any shmobile DT patches outstanding which are ready to be queued-up. Yes, the R8A7794 HS-USB patch. MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: shmobile: silk: enable USB PHY
Enable USB PHY device for the SILK board.
Signed-off-by: Sergei Shtylyov
---
arch/arm/boot/dts/r8a7794-silk.dts |4
1 file changed, 4 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7794-silk.dts
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -210,3 +210,7 @@
pinctrl-0 = <&usb1_pins>;
pinctrl-names = "default";
};
+
+&usbphy {
+ status = "okay";
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ARM: shmobile: r8a7794: add USB PHY DT support
Define the R8A7794 generic part of the USB PHY device node. It is up to the
board file to enable the device.
Signed-off-by: Sergei Shtylyov
---
Changes in version 2:
- added the "power-domains" property.
arch/arm/boot/dts/r8a7794.dtsi | 20
1 file changed, 20 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -690,6 +690,26 @@
0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
};
+ usbphy: usb-phy@e6590100 {
+ compatible = "renesas,usb-phy-r8a7794";
+ reg = <0 0xe6590100 0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&mstp7_clks R8A7794_CLK_HSUSB>;
+ clock-names = "usbhs";
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+
+ usb0: usb-channel@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+ usb2: usb-channel@2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] Add USB PHY device tree support for R8A7794/SILK board
Hello. Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20151001-v4.3-rc3' tag. Here we add the USB PHY device tree support on the R8A7794/SILK low cost board. [1/2] ARM: shmobile: r8a7794: add USB PHY DT support [2/2] ARM: shmobile: silk: enable USB PHY WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: shmobile: porter: initial device tree
Add the initial device tree for the R8A7791 SoC based Porter low cost board
(which is a slightly modified version of the Henninger board).
SCIF0 serial port support is included, so that the serial console can work.
Signed-off-by: Sergei Shtylyov
Acked-by: Geert Uytterhoeven
---
This patch is against the 'renesas-devel-20150930-v4.3-rc3' tag of Simon
Horman's 'renesas.git' repo.
Changes in version 2:
- removed the 'console=' kernel parameter from the "bootargs" prop;
- removed trailing space in the change log;
- added Geert's ACK.
arch/arm/boot/dts/Makefile |1
arch/arm/boot/dts/r8a7791-porter.dts | 54 +++
2 files changed, 55 insertions(+)
Index: renesas/arch/arm/boot/dts/Makefile
===
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -532,6 +532,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r8a7790-lager.dtb \
r8a7791-henninger.dtb \
r8a7791-koelsch.dtb \
+ r8a7791-porter.dtb \
r8a7793-gose.dtb \
r8a7794-alt.dtb \
r8a7794-silk.dtb \
Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -0,0 +1,54 @@
+/*
+ * Device Tree Source for the Porter board
+ *
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7791.dtsi"
+
+/ {
+ model = "Porter";
+ compatible = "renesas,porter", "renesas,r8a7791";
+
+ aliases {
+ serial0 = &scif0;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel";
+ stdout-path = &scif0;
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0 0x4000 0 0x4000>;
+ };
+
+ memory@2 {
+ device_type = "memory";
+ reg = <2 0x 0 0x4000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <2000>;
+};
+
+&pfc {
+ scif0_pins: serial0 {
+ renesas,groups = "scif0_data_d";
+ renesas,function = "scif0";
+ };
+};
+
+&scif0 {
+ pinctrl-0 = <&scif0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
