Re: [PATCH v2] arm, am335x: add support for the bosch shc board
Hello Tony,
Am 01.12.2015 um 06:53 schrieb Tony Lindgren:
* Heiko Schocher [151130 21:21]:
Hello Tony,
Am 30.11.2015 um 22:41 schrieb Tony Lindgren:
* Heiko Schocher [151117 00:25]:
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-shc.dts
+&tps {
+ compatible = "ti,tps65217";
+ ti,pmic-shutdown-controller;
+
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dcdc1_reg: regulator@0 {
+ reg = <0>;
+ regulator-name = "vdds_dpr";
+ regulator-compatible = "dcdc1";
+ regulator-min-microvolt = <130>;
+ regulator-max-microvolt = <145>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2_reg: regulator@1 {
+ reg = <1>;
+ /*
+* VDD_MPU voltage limits 0.95V - 1.26V with
+* +/-4% tolerance
+*/
+ regulator-compatible = "dcdc2";
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <1375000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <7>;
+ };
+
+ dcdc3_reg: regulator@2 {
+ reg = <2>;
+ /*
+* VDD_CORE voltage limits 0.95V - 1.1V with
+* +/-4% tolerance
+*/
+ regulator-name = "vdd_core";
+ regulator-compatible = "dcdc3";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <1125000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: regulator@3 {
+ reg = <3>;
+ regulator-name = "vio,vrtc,vdds";
+ regulator-compatible = "ldo1";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ ldo2_reg: regulator@4 {
+ reg = <4>;
+ regulator-name = "vdd_3v3aux";
+ regulator-compatible = "ldo2";
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ ldo3_reg: regulator@5 {
+ reg = <5>;
+ regulator-name = "vdd_1v8";
+ regulator-compatible = "ldo3";
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ ldo4_reg: regulator@6 {
+ reg = <6>;
+ regulator-name = "vdd_3v3a";
+ regulator-compatible = "ldo4";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+ };
+};
Applying this into omap-for-v4.5/dt.. But I'm getting concerned about this
"regulator-always-on" stuff and having multiple copies of the same thing.
I think we should have a common am33xx-tps65217.dtsi file that has the
regulators defined at one place and other then include it. And they are
controllable AFAIK..
Hmm... Mark Brown (added to Cc) suggested to move this regulator nodes
into the board DT file and remove such files [1].
Hmm it was probably the name of that file causing confusion as it was not
am33xx specific. If we have many board variants using almost the same exact
regulators and configuration it totally makes sense to have a shared dtsi
file for them :)
Ack.
It may actually be better to have it as am33xx-common.dtsi and I bet that
covers quite a few am33xx boards for the basic shared functionality.
I try to find some time to make such a patch...
bye,
Heiko
Regards,
Tony
[1] https://lkml.org/lkml/2015/10/21/581
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm, am335x: add support for the bosch shc board
Hello Tony,
Am 30.11.2015 um 22:41 schrieb Tony Lindgren:
* Heiko Schocher [151117 00:25]:
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-shc.dts
+&tps {
+ compatible = "ti,tps65217";
+ ti,pmic-shutdown-controller;
+
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dcdc1_reg: regulator@0 {
+ reg = <0>;
+ regulator-name = "vdds_dpr";
+ regulator-compatible = "dcdc1";
+ regulator-min-microvolt = <130>;
+ regulator-max-microvolt = <145>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2_reg: regulator@1 {
+ reg = <1>;
+ /*
+* VDD_MPU voltage limits 0.95V - 1.26V with
+* +/-4% tolerance
+*/
+ regulator-compatible = "dcdc2";
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <1375000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <7>;
+ };
+
+ dcdc3_reg: regulator@2 {
+ reg = <2>;
+ /*
+* VDD_CORE voltage limits 0.95V - 1.1V with
+* +/-4% tolerance
+*/
+ regulator-name = "vdd_core";
+ regulator-compatible = "dcdc3";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <1125000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: regulator@3 {
+ reg = <3>;
+ regulator-name = "vio,vrtc,vdds";
+ regulator-compatible = "ldo1";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ ldo2_reg: regulator@4 {
+ reg = <4>;
+ regulator-name = "vdd_3v3aux";
+ regulator-compatible = "ldo2";
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ ldo3_reg: regulator@5 {
+ reg = <5>;
+ regulator-name = "vdd_1v8";
+ regulator-compatible = "ldo3";
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ ldo4_reg: regulator@6 {
+ reg = <6>;
+ regulator-name = "vdd_3v3a";
+ regulator-compatible = "ldo4";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+ };
+};
Applying this into omap-for-v4.5/dt.. But I'm getting concerned about this
"regulator-always-on" stuff and having multiple copies of the same thing.
I think we should have a common am33xx-tps65217.dtsi file that has the
regulators defined at one place and other then include it. And they are
controllable AFAIK..
Hmm... Mark Brown (added to Cc) suggested to move this regulator nodes
into the board DT file and remove such files [1].
bye,
Heiko
[1] https://lkml.org/lkml/2015/10/21/581
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm, am335x: add support for the bosch shc board
Hello all, Am 18.11.2015 um 09:24 schrieb Heiko Schocher: Hello Dave, Am 17.11.2015 um 22:29 schrieb Dave Gerlach: Hi, On 11/17/2015 02:24 AM, Heiko Schocher wrote: add support for the am335x based shc board. UART: 0-2 and 4 DRAM: 512 MiB MMC: OMAP SD/MMC: 0 @ 26 MHz OMAP SD/MMC: 1 @ 26 MHz I2C: at24 eeprom, pcf8563 USB: USB1 (host) Signed-off-by: Heiko Schocher --- The following patches are needed to get all working for the shc board: - disable clkout on pcf8563 accepted. http://www.spinics.net/lists/devicetree/msg98542.html - leds: leds-gpio: add shutdown function accepted. https://lkml.org/lkml/2015/10/13/169 - net: phy: smsc: disable energy detect mode accepted [PATCH v2 2/2] net: phy: smsc: disable energy detect mode https://lkml.org/lkml/2015/10/17/2 [PATCH v2 1/2] drivers: net: cpsw: add phy-handle parsing https://lkml.org/lkml/2015/10/17/4 - ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328204.html @Dave: What is the current state of this patch? I have the same problem here on this am335x based board A different approach is being taken for resolving the issue of rtc hwmod on am43x epos evm [1], which is what I was attempting to solve with the patch you have linked. We decided to avoid changing omap_hwmod code and I haven't been pursuing the ti,no-init flag anymore. Maybe I overlook something, but I cannot see, how [1] solves the RTC hwmod problem on am335x SoC based boards. Not all boards have this problem, so the RTC hwmod cannot be disabled for all am335x boards ... It must be somehow configurable for boards ... I have am335x boards which use the rtc from the SoC gentle ping ... No more comments on this patch? Is it Ok for mainline or are there more issues? bye, Heiko Regards, Dave [1] http://www.spinics.net/lists/linux-omap/msg121987.html bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm, am335x: add support for the bosch shc board
Hello Dave, Am 17.11.2015 um 22:29 schrieb Dave Gerlach: Hi, On 11/17/2015 02:24 AM, Heiko Schocher wrote: add support for the am335x based shc board. UART: 0-2 and 4 DRAM: 512 MiB MMC: OMAP SD/MMC: 0 @ 26 MHz OMAP SD/MMC: 1 @ 26 MHz I2C: at24 eeprom, pcf8563 USB: USB1 (host) Signed-off-by: Heiko Schocher --- The following patches are needed to get all working for the shc board: - disable clkout on pcf8563 accepted. http://www.spinics.net/lists/devicetree/msg98542.html - leds: leds-gpio: add shutdown function accepted. https://lkml.org/lkml/2015/10/13/169 - net: phy: smsc: disable energy detect mode accepted [PATCH v2 2/2] net: phy: smsc: disable energy detect mode https://lkml.org/lkml/2015/10/17/2 [PATCH v2 1/2] drivers: net: cpsw: add phy-handle parsing https://lkml.org/lkml/2015/10/17/4 - ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328204.html @Dave: What is the current state of this patch? I have the same problem here on this am335x based board A different approach is being taken for resolving the issue of rtc hwmod on am43x epos evm [1], which is what I was attempting to solve with the patch you have linked. We decided to avoid changing omap_hwmod code and I haven't been pursuing the ti,no-init flag anymore. Maybe I overlook something, but I cannot see, how [1] solves the RTC hwmod problem on am335x SoC based boards. Not all boards have this problem, so the RTC hwmod cannot be disabled for all am335x boards ... It must be somehow configurable for boards ... I have am335x boards which use the rtc from the SoC Regards, Dave [1] http://www.spinics.net/lists/linux-omap/msg121987.html bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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, am335x: add support for the bosch shc board
add support for the am335x based shc board.
UART: 0-2 and 4
DRAM: 512 MiB
MMC: OMAP SD/MMC: 0 @ 26 MHz
OMAP SD/MMC: 1 @ 26 MHz
I2C: at24 eeprom, pcf8563
USB: USB1 (host)
Signed-off-by: Heiko Schocher
---
The following patches are needed to get all working
for the shc board:
- disable clkout on pcf8563
accepted.
http://www.spinics.net/lists/devicetree/msg98542.html
- leds: leds-gpio: add shutdown function
accepted.
https://lkml.org/lkml/2015/10/13/169
- net: phy: smsc: disable energy detect mode
accepted
[PATCH v2 2/2] net: phy: smsc: disable energy detect mode
https://lkml.org/lkml/2015/10/17/2
[PATCH v2 1/2] drivers: net: cpsw: add phy-handle parsing
https://lkml.org/lkml/2015/10/17/4
- ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328204.html
@Dave: What is the current state of this patch?
I have the same problem here on this am335x based board
- [PATCH v2] regulator: tps65217: remove tps65217.dtsi file
http://www.kernelhub.org/?msg=868907&p=2
- bootlog and automated tests:
http://xeidos.ddns.net/buildbot/waterfall
Changes in v2:
- Use IOPAD pinmux macro as Robert Nelson
suggested.
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/am335x-shc.dts | 577 +++
2 files changed, 579 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am335x-shc.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..65d750f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -466,7 +466,8 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-pepper.dtb \
am335x-lxm.dtb \
am335x-chiliboard.dtb \
- am335x-wega-rdk.dtb
+ am335x-wega-rdk.dtb \
+ am335x-shc.dtb
dtb-$(CONFIG_ARCH_OMAP4) += \
omap4-duovero-parlor.dtb \
omap4-panda.dtb \
diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
new file mode 100644
index 000..1b5b044
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -0,0 +1,577 @@
+/*
+ * support for the bosch am335x based shc c3 board
+ *
+ * Copyright, C) 2015 Heiko Schocher
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include
+
+/ {
+ model = "Bosch SHC";
+ compatible = "ti,am335x-shc", "ti,am335x-bone", "ti,am33xx";
+
+ aliases {
+ mmcblk0 = &mmc1;
+ mmcblk1 = &mmc2;
+ };
+
+ cpus {
+ cpu@0 {
+ /*
+* To consider voltage drop between PMIC and SoC,
+* tolerance value is reduced to 2% from 4% and
+* voltage value is increased as a precaution.
+*/
+ operating-points = <
+ /* kHzuV */
+ 594000 1225000
+ 294000 1125000
+ >;
+ voltage-tolerance = <2>; /* 2 percentage */
+ cpu0-supply = <&dcdc2_reg>;
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+
+ back_button {
+ label = "Back Button";
+ gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
+ linux,code = ;
+ debounce-interval = <1000>;
+ gpio-key,wakeup;
+ };
+
+ front_button {
+ label = "Front Button";
+ gpios = <&gpio1 25 GPIO_ACTIVE_HIGH>;
+ linux,code = ;
+ debounce-interval = <1000>;
+ gpio-key,wakeup;
+ };
+ };
+
+ leds {
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_leds_s0>;
+
+ compatible = "gpio-leds";
+
+ led@1 {
+ label = "shc:power:red";
+ gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led@2 {
+ label = "shc:power:bl";
+ gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "timer";
+ default-state = "on";
+ };
+
+ led@3 {
+ label = "shc:lan:red";
+ gpios = <&gp
Re: [PATCH] arm, am335x: add support for the bosch shc board
Hello Robert,
Am 16.11.2015 um 14:23 schrieb Robert Nelson:
+
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins = <
+ /* Slave 1 */
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE0)
+ 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE0)
+ 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE0)
+ 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)
+ 0x124 (PIN_INPUT_PULLDOWN | MUX_MODE0)
+ 0x128 (PIN_INPUT_PULLDOWN | MUX_MODE0)
+ 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)
+ 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE0)
+ 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE0)
+ 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE0)
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE0)
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE0)
Please use the AM33XX_IOPAD pinmux macro:
All boards have recently be converted:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg121329.html
Uh.. missed this, changed. Wait for more comments before posting v2.
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm, am335x: add support for the bosch shc board
add support for the am335x based shc board.
UART: 0-2 and 4
DRAM: 512 MiB
MMC: OMAP SD/MMC: 0 @ 26 MHz
OMAP SD/MMC: 1 @ 26 MHz
I2C: at24 eeprom, pcf8563
USB: USB1 (host)
Signed-off-by: Heiko Schocher
---
The following patches are needed to get all working
for the shc board:
- disable clkout on pcf8563
accepted.
http://www.spinics.net/lists/devicetree/msg98542.html
- leds: leds-gpio: add shutdown function
accepted.
https://lkml.org/lkml/2015/10/13/169
- net: phy: smsc: disable energy detect mode
accepted
[PATCH v2 2/2] net: phy: smsc: disable energy detect mode
https://lkml.org/lkml/2015/10/17/2
[PATCH v2 1/2] drivers: net: cpsw: add phy-handle parsing
https://lkml.org/lkml/2015/10/17/4
- ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328204.html
@Dave: What is the current state of this patch?
I have the same problem here on this am335x based board
- [PATCH v2] regulator: tps65217: remove tps65217.dtsi file
http://www.kernelhub.org/?msg=868907&p=2
- bootlog and automated tests:
http://xeidos.ddns.net/buildbot/waterfall
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/am335x-shc.dts | 577 +++
2 files changed, 579 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am335x-shc.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..65d750f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -466,7 +466,8 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-pepper.dtb \
am335x-lxm.dtb \
am335x-chiliboard.dtb \
- am335x-wega-rdk.dtb
+ am335x-wega-rdk.dtb \
+ am335x-shc.dtb
dtb-$(CONFIG_ARCH_OMAP4) += \
omap4-duovero-parlor.dtb \
omap4-panda.dtb \
diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
new file mode 100644
index 000..c2aceea
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -0,0 +1,577 @@
+/*
+ * support for the bosch am335x based shc c3 board
+ *
+ * Copyright (C) 2015 Heiko Schocher
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include
+
+/ {
+ model = "Bosch SHC";
+ compatible = "ti,am335x-shc", "ti,am335x-bone", "ti,am33xx";
+
+ aliases {
+ mmcblk0 = &mmc1;
+ mmcblk1 = &mmc2;
+ };
+
+ cpus {
+ cpu@0 {
+ /*
+* To consider voltage drop between PMIC and SoC,
+* tolerance value is reduced to 2% from 4% and
+* voltage value is increased as a precaution.
+*/
+ operating-points = <
+ /* kHzuV */
+ 594000 1225000
+ 294000 1125000
+ >;
+ voltage-tolerance = <2>; /* 2 percentage */
+ cpu0-supply = <&dcdc2_reg>;
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+
+ back_button {
+ label = "Back Button";
+ gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
+ linux,code = ;
+ debounce-interval = <1000>;
+ gpio-key,wakeup;
+ };
+
+ front_button {
+ label = "Front Button";
+ gpios = <&gpio1 25 GPIO_ACTIVE_HIGH>;
+ linux,code = ;
+ debounce-interval = <1000>;
+ gpio-key,wakeup;
+ };
+ };
+
+ leds {
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_leds_s0>;
+
+ compatible = "gpio-leds";
+
+ led@1 {
+ label = "shc:power:red";
+ gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led@2 {
+ label = "shc:power:bl";
+ gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "timer";
+ default-state = "on";
+ };
+
+ led@3 {
+ label = "shc:lan:red";
+ gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
+
[PATCH v2] regulator: tps65217: remove tps65217.dtsi file
remove tps65217.dtsi and adapt all boards, which
used it.
Signed-off-by: Heiko Schocher
Tested-by: Keerthy
Acked-by: Mark Brown
---
Suggested by Mark Brown, see:
https://lkml.org/lkml/2015/10/21/581
Changes in v2:
- accidentially removed tps65217.txt
do not remove it, add Sebastian Reichel to
cc, as he also deteted this.
- add Acked-by from Mark Brown
- add Tested-by from j-keerthy
.../devicetree/bindings/regulator/tps65217.txt | 10
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 --
arch/arm/boot/dts/am335x-chilisom.dtsi | 14 +-
arch/arm/boot/dts/am335x-nano.dts | 14 +-
arch/arm/boot/dts/am335x-pepper.dts| 14 +-
arch/arm/boot/dts/am335x-sl50.dts | 13 -
arch/arm/boot/dts/tps65217.dtsi| 56 --
7 files changed, 68 insertions(+), 67 deletions(-)
delete mode 100644 arch/arm/boot/dts/tps65217.dtsi
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
index 4f05d20..d181096 100644
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
@@ -26,7 +26,11 @@ Example:
ti,pmic-shutdown-controller;
regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
dcdc1_reg: dcdc1 {
+ reg = <0>;
regulator-min-microvolt = <90>;
regulator-max-microvolt = <180>;
regulator-boot-on;
@@ -34,6 +38,7 @@ Example:
};
dcdc2_reg: dcdc2 {
+ reg = <1>;
regulator-min-microvolt = <90>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -41,6 +46,7 @@ Example:
};
dcdc3_reg: dcc3 {
+ reg = <2>;
regulator-min-microvolt = <90>;
regulator-max-microvolt = <150>;
regulator-boot-on;
@@ -48,6 +54,7 @@ Example:
};
ldo1_reg: ldo1 {
+ reg = <3>;
regulator-min-microvolt = <100>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -55,6 +62,7 @@ Example:
};
ldo2_reg: ldo2 {
+ reg = <4>;
regulator-min-microvolt = <90>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -62,6 +70,7 @@ Example:
};
ldo3_reg: ldo3 {
+ reg = <5>;
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -69,6 +78,7 @@ Example:
};
ldo4_reg: ldo4 {
+ reg = <6>;
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
regulator-boot-on;
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index fec7834..0c4bde0 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -285,10 +285,8 @@
};
};
-
-/include/ "tps65217.dtsi"
-
&tps {
+ compatible = "ti,tps65217";
/*
* Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
* mode") at poweroff. Most BeagleBone versions do not support RTC-only
@@ -309,12 +307,17 @@
ti,pmic-shutdown-controller;
regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
dcdc1_reg: regulator@0 {
+ reg = <0>;
regulator-name = "vdds_dpr";
regulator-always-on;
};
dcdc2_reg: regulator@1 {
+ reg = <1>;
/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4%
tolerance */
regulator-name = "vdd_mpu";
Re: [PATCH] regulator: tps65217: remove tps65217.dtsi file
Hello Sebastian, Am 27.10.2015 um 13:21 schrieb Sebastian Reichel: Hi, On Mon, Oct 26, 2015 at 10:13:55AM +0100, Heiko Schocher wrote: remove tps65217.dtsi and adapt all boards, which used it. Signed-off-by: Heiko Schocher --- Suggested by Mark Brown, see: https://lkml.org/lkml/2015/10/21/581 .../devicetree/bindings/regulator/tps65217.txt | 78 -- why did you delete the binding description? Didn;t I sent a v2? I realized this after sending the v1 patch, and prepared a v2, which does not remove this file ... Uh, yes, seems I missed sending it ... Sorry. Send a v2 ASAP, thanks! bye, Heiko -- -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: tps65217: remove tps65217.dtsi file
Hello Keerthy,
Am 27.10.2015 um 07:06 schrieb Keerthy:
Hi Heiko,
On Monday 26 October 2015 02:43 PM, Heiko Schocher wrote:
remove tps65217.dtsi and adapt all boards, which
used it.
I boot tested this on am335x-bone and am335x-boneblack boards and could
successfully boot and i even
checked the regulators registered am335x-bone:
cat /sys/class/regulator/regulator.*/name
regulator-dummy
vmmcsd_fixed
DCDC1
DCDC2
DCDC3
LDO1
LDO2
LDO3
LDO4
Looks good to me. For am335x-bone and am335x-boneblack you can add
Tested-by: Keerthy
Thanks for testing!
bye,
Heiko
Best Regards,
Keerthy
Signed-off-by: Heiko Schocher
---
Suggested by Mark Brown, see:
https://lkml.org/lkml/2015/10/21/581
.../devicetree/bindings/regulator/tps65217.txt | 78 --
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++-
arch/arm/boot/dts/am335x-chilisom.dtsi | 14 +++-
arch/arm/boot/dts/am335x-nano.dts | 14 +++-
arch/arm/boot/dts/am335x-pepper.dts| 14 +++-
arch/arm/boot/dts/am335x-sl50.dts | 13 +++-
arch/arm/boot/dts/tps65217.dtsi| 56
7 files changed, 58 insertions(+), 145 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/regulator/tps65217.txt
delete mode 100644 arch/arm/boot/dts/tps65217.dtsi
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
deleted file mode 100644
index 4f05d20..000
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-TPS65217 family of regulators
-
-Required properties:
-- compatible: "ti,tps65217"
-- reg: I2C slave address
-- regulators: list of regulators provided by this controller, must be named
- after their hardware counterparts: dcdc[1-3] and ldo[1-4]
-- regulators: This is the list of child nodes that specify the regulator
- initialization data for defined regulators. Not all regulators for the given
- device need to be present. The definition for each of these nodes is defined
- using the standard binding for regulators found at
- Documentation/devicetree/bindings/regulator/regulator.txt.
-
-Optional properties:
-- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
-
- The valid names for regulators are:
- tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
-tps: tps@24 {
-compatible = "ti,tps65217";
-ti,pmic-shutdown-controller;
-
-regulators {
-dcdc1_reg: dcdc1 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <180>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-dcdc2_reg: dcdc2 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-dcdc3_reg: dcc3 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <150>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo1_reg: ldo1 {
-regulator-min-microvolt = <100>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo2_reg: ldo2 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo3_reg: ldo3 {
-regulator-min-microvolt = <180>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo4_reg: ldo4 {
-regulator-min-microvolt = <180>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-};
-};
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index fec7834..0c4bde0 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -285,10 +285,8 @@
};
};
-
-/include/ "tps65217.dtsi"
-
&tps {
+compatible = "ti,tps65217";
/*
* Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
* mode") at poweroff. Most BeagleBone versions do not support RTC-only
@@ -309,12 +307,17 @@
ti,pmic-shutdown-controller;
regulators {
+#
[PATCH] regulator: tps65217: remove tps65217.dtsi file
remove tps65217.dtsi and adapt all boards, which
used it.
Signed-off-by: Heiko Schocher
---
Suggested by Mark Brown, see:
https://lkml.org/lkml/2015/10/21/581
.../devicetree/bindings/regulator/tps65217.txt | 78 --
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++-
arch/arm/boot/dts/am335x-chilisom.dtsi | 14 +++-
arch/arm/boot/dts/am335x-nano.dts | 14 +++-
arch/arm/boot/dts/am335x-pepper.dts| 14 +++-
arch/arm/boot/dts/am335x-sl50.dts | 13 +++-
arch/arm/boot/dts/tps65217.dtsi| 56
7 files changed, 58 insertions(+), 145 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/regulator/tps65217.txt
delete mode 100644 arch/arm/boot/dts/tps65217.dtsi
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
deleted file mode 100644
index 4f05d20..000
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-TPS65217 family of regulators
-
-Required properties:
-- compatible: "ti,tps65217"
-- reg: I2C slave address
-- regulators: list of regulators provided by this controller, must be named
- after their hardware counterparts: dcdc[1-3] and ldo[1-4]
-- regulators: This is the list of child nodes that specify the regulator
- initialization data for defined regulators. Not all regulators for the given
- device need to be present. The definition for each of these nodes is defined
- using the standard binding for regulators found at
- Documentation/devicetree/bindings/regulator/regulator.txt.
-
-Optional properties:
-- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
-
- The valid names for regulators are:
- tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
- tps: tps@24 {
- compatible = "ti,tps65217";
- ti,pmic-shutdown-controller;
-
- regulators {
- dcdc1_reg: dcdc1 {
- regulator-min-microvolt = <90>;
- regulator-max-microvolt = <180>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- dcdc2_reg: dcdc2 {
- regulator-min-microvolt = <90>;
- regulator-max-microvolt = <330>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- dcdc3_reg: dcc3 {
- regulator-min-microvolt = <90>;
- regulator-max-microvolt = <150>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo1_reg: ldo1 {
- regulator-min-microvolt = <100>;
- regulator-max-microvolt = <330>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo2_reg: ldo2 {
- regulator-min-microvolt = <90>;
- regulator-max-microvolt = <330>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo3_reg: ldo3 {
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <330>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo4_reg: ldo4 {
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <330>;
- regulator-boot-on;
- regulator-always-on;
- };
- };
- };
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index fec7834..0c4bde0 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -285,10 +285,8 @@
};
};
-
-/include/ "tps65217.dtsi"
-
&tps {
+ compatible = "ti,tps65217";
/*
* Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
* mode") at poweroff. Most BeagleBone versions do not support RTC-only
@@ -309,12 +30
Re: [PATCH] net, can, ti_hecc: add DT support for the ti,hecc controller
Hello Marc,
Am 19.10.2015 um 08:58 schrieb Marc Kleine-Budde:
On 10/19/2015 08:39 AM, Heiko Schocher wrote:
add DT support for the ti hecc controller, used on
am3517 SoCs.
A similar patch was posted a few days ago, see
http://comments.gmane.org/gmane.linux.can/8616 and my comments.
Uh, sorry! Seems I missed them ...
Please coordinate with Anton Glukhov (Cc'ed) and/or pick up his patches
as they are in better shape.
Yes, I try the patchset from Anton ... thanks for pointing to them.
@Anton: Do you have a newer version, which contains the comments
from Marc?
bye,
Heiko
Marc
Signed-off-by: Heiko Schocher
---
.../devicetree/bindings/net/can/ti_hecc-can.txt| 20 ++
arch/arm/boot/dts/am3517.dtsi | 13 +++
drivers/net/can/ti_hecc.c | 45 +-
3 files changed, 76 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
diff --git a/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
new file mode 100644
index 000..09fab59
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
@@ -0,0 +1,20 @@
+* TI HECC CAN *
+
+Required properties:
+ - compatible: Should be "ti,hecc"
We usually put the name of the first SoC this IP core appears in to the
compatible.
Ok, so "ti,am335xx-hecc" would be OK?
@Anton: you used "am35x" ... it should be "am35xx"
+ - reg: Should contain CAN controller registers location and length
+ - interrupts: Should contain IRQ line for the CAN controller
I'm missing the description of the ti,* properties. I think they are
required, too. Although the code doesn't enforce it.
Ok.
+
+Example:
+
+ can0: hecc@5c05 {
+ compatible = "ti,hecc";
+ reg = <0x5c05 0x4000>;
+ interrupts = <24>;
+ ti,hecc_scc_offset = <0>;
+ ti,hecc_scc_ram_offset = <0x3000>;
+ ti,hecc_ram_offset = <0x3000>;
+ ti,hecc_mbx_offset = <0x2000>;
+ ti,hecc_int_line = <0>;
+ ti,hecc_version = <1>;
Versioning in the OF world is done via the compatible. Are the offsets a
per SoC parameter? I'm not sure if it's better to put
the offsets into the driver.
I am unsure here too..
+ };
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index 5e3f5e8..47bc429 100644
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -25,6 +25,19 @@
interrupt-names = "mc";
};
+ can0: hecc@5c05 {
+ compatible = "ti,hecc";
+ reg = <0x5c05 0x4000>;
+ interrupts = <24>;
+ ti,hecc_scc_offset = <0>;
+ ti,hecc_scc_ram_offset = <0x3000>;
+ ti,hecc_ram_offset = <0x3000>;
+ ti,hecc_mbx_offset = <0x2000>;
+ ti,hecc_int_line = <0>;
+ ti,hecc_version = <1>;
+ status = "disabled";
+ };
+
davinci_emac: ethernet@0x5c00 {
compatible = "ti,am3517-emac";
ti,hwmods = "davinci_emac";
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index c08e8ea..f1705d5 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -875,16 +875,56 @@ static const struct net_device_ops ti_hecc_netdev_ops = {
.ndo_change_mtu = can_change_mtu,
};
+#if defined(CONFIG_OF)
+static const struct of_device_id ti_hecc_can_dt_ids[] = {
+ {
+ .compatible = "ti,hecc",
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(of, ti_hecc_can_dt_ids);
+#endif
Please remove the ifdef, use __maybe_unused instead.
+
+static const struct ti_hecc_platform_data
+*ti_hecc_can_get_driver_data(struct platform_device *pdev)
+{
+ if (pdev->dev.of_node) {
+ struct ti_hecc_platform_data *data;
+ struct device_node *np = pdev->dev.of_node;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return NULL;
+
+ of_property_read_u32(np, "ti,hecc_scc_offset",
+&data->scc_hecc_offset);
+ of_property_read_u32(np, "ti,hecc_scc_ram_offset",
+&data->scc_ram_offset);
+ of_property_read_u32(np, "ti,hecc_ram_offset",
+
[PATCH] net, can, ti_hecc: add DT support for the ti,hecc controller
add DT support for the ti hecc controller, used on
am3517 SoCs.
Signed-off-by: Heiko Schocher
---
.../devicetree/bindings/net/can/ti_hecc-can.txt| 20 ++
arch/arm/boot/dts/am3517.dtsi | 13 +++
drivers/net/can/ti_hecc.c | 45 +-
3 files changed, 76 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
diff --git a/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
new file mode 100644
index 000..09fab59
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
@@ -0,0 +1,20 @@
+* TI HECC CAN *
+
+Required properties:
+ - compatible: Should be "ti,hecc"
+ - reg: Should contain CAN controller registers location and length
+ - interrupts: Should contain IRQ line for the CAN controller
+
+Example:
+
+ can0: hecc@5c05 {
+ compatible = "ti,hecc";
+ reg = <0x5c05 0x4000>;
+ interrupts = <24>;
+ ti,hecc_scc_offset = <0>;
+ ti,hecc_scc_ram_offset = <0x3000>;
+ ti,hecc_ram_offset = <0x3000>;
+ ti,hecc_mbx_offset = <0x2000>;
+ ti,hecc_int_line = <0>;
+ ti,hecc_version = <1>;
+ };
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index 5e3f5e8..47bc429 100644
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -25,6 +25,19 @@
interrupt-names = "mc";
};
+ can0: hecc@5c05 {
+ compatible = "ti,hecc";
+ reg = <0x5c05 0x4000>;
+ interrupts = <24>;
+ ti,hecc_scc_offset = <0>;
+ ti,hecc_scc_ram_offset = <0x3000>;
+ ti,hecc_ram_offset = <0x3000>;
+ ti,hecc_mbx_offset = <0x2000>;
+ ti,hecc_int_line = <0>;
+ ti,hecc_version = <1>;
+ status = "disabled";
+ };
+
davinci_emac: ethernet@0x5c00 {
compatible = "ti,am3517-emac";
ti,hwmods = "davinci_emac";
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index c08e8ea..f1705d5 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -875,16 +875,56 @@ static const struct net_device_ops ti_hecc_netdev_ops = {
.ndo_change_mtu = can_change_mtu,
};
+#if defined(CONFIG_OF)
+static const struct of_device_id ti_hecc_can_dt_ids[] = {
+ {
+ .compatible = "ti,hecc",
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(of, ti_hecc_can_dt_ids);
+#endif
+
+static const struct ti_hecc_platform_data
+*ti_hecc_can_get_driver_data(struct platform_device *pdev)
+{
+ if (pdev->dev.of_node) {
+ struct ti_hecc_platform_data *data;
+ struct device_node *np = pdev->dev.of_node;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return NULL;
+
+ of_property_read_u32(np, "ti,hecc_scc_offset",
+&data->scc_hecc_offset);
+ of_property_read_u32(np, "ti,hecc_scc_ram_offset",
+&data->scc_ram_offset);
+ of_property_read_u32(np, "ti,hecc_ram_offset",
+&data->hecc_ram_offset);
+ of_property_read_u32(np, "ti,hecc_mbx_offset",
+&data->mbx_offset);
+ of_property_read_u32(np, "ti,hecc_int_line",
+&data->int_line);
+ of_property_read_u32(np, "ti,hecc_version",
+&data->version);
+ return data;
+ }
+ return (const struct ti_hecc_platform_data *)
+ dev_get_platdata(&pdev->dev);
+}
+
static int ti_hecc_probe(struct platform_device *pdev)
{
struct net_device *ndev = (struct net_device *)0;
struct ti_hecc_priv *priv;
- struct ti_hecc_platform_data *pdata;
+ const struct ti_hecc_platform_data *pdata;
struct resource *mem, *irq;
void __iomem *addr;
int err = -ENODEV;
- pdata = dev_get_platdata(&pdev->dev);
+ pdata = ti_hecc_can_get_driver_data(pdev);
if (!pdata) {
dev_err(&pdev->dev, "No platform data
Re: [PATCH] arm, omap2, sram: On HS/EMU devices, only 64K internal SRAM is available.
Hello Tony,
Am 15.10.2015 um 00:20 schrieb Tony Lindgren:
* Tony Lindgren [151014 10:56]:
* Heiko Schocher [151012 22:58]:
Of this, secure content (including PPA) uses initial
portion of the SRAM. This chunk is not (and shouldn't
be) accessible from the public code.
The minimum size of this chunk (0x350) is used in this
patch. Available size is rounded off to 63K.
Both values would require a change if size of secure
content grows beyond 0x350.
Makes sense to me. And something similar is needed at least for
dm814x to get rid of the imprecise abort during boot with
commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during
early kernel startup") applied.
Is this needed as a fix to the -rc cycle, or can this wait for
v4.4?
Actually I think we may have a regression somwhere. If you look
at commit 8b9a2810b02e ("ARM: OMAP4+: Move SRAM data to DT")
this should all be handled by drivers/misc/sram.c nowadays.
So for most SoCs, we should completely skip the plat-omap/sram.c
code.
Yes, correct. So it should be enough for changing the DT, thanks.
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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, omap2, sram: On HS/EMU devices, only 64K internal SRAM is available.
Hello Tony,
Am 14.10.2015 um 19:49 schrieb Tony Lindgren:
* Heiko Schocher [151012 22:58]:
Of this, secure content (including PPA) uses initial
portion of the SRAM. This chunk is not (and shouldn't
be) accessible from the public code.
The minimum size of this chunk (0x350) is used in this
patch. Available size is rounded off to 63K.
Both values would require a change if size of secure
content grows beyond 0x350.
Makes sense to me. And something similar is needed at least for
dm814x to get rid of the imprecise abort during boot with
commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during
early kernel startup") applied.
Is this needed as a fix to the -rc cycle, or can this wait for
v4.4?
I need it for an upcoming boards support, so 4.4 is fine for me,
thanks!
bye,
Heiko
Regards,
Tony
Signed-off-by: Heiko Schocher
Signed-off-by: Ayoub Zaki
---
arch/arm/mach-omap2/sram.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index cd488b8..2e7c00f 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -47,6 +47,28 @@
#define GP_DEVICE 0x300
+/**
+ * Size of chunk used by secure content in the HS/EMU devices.
+ *
+ * This size is not fixed. It depends upon the implementation of PPA.
+ * May need to be modified if the size grows.
+ */
+#define AM33XX_HS_HEADER_SIZE 0x0350
+
+/**
+ * Start of public SRAM on HS/EMU devices.
+ */
+#define AM33XX_SRAM_PA 0x4030
+#define AM33XX_SRAM_PUB_PA (AM33XX_SRAM_PA + AM33XX_HS_HEADER_SIZE)
+
+/**
+ * Size of public SRAM available on HS/EMU devices.
+ *
+ * This size also depends upon AM33XX_HS_HEADER_SIZE.
+ * Current value is derived from nearest round-off.
+ */
+#define AM33XX_SRAM_PUB_SIZE 0xfc00 /* 63K */
+
#define ROUND_DOWN(value,boundary)((value) & (~((boundary)-1)))
static unsigned long omap_sram_start;
@@ -99,6 +121,9 @@ static void __init omap_detect_sram(void)
} else {
omap_sram_size = 0x8000; /* 32K */
}
+ } else if (soc_is_am33xx()) {
+ omap_sram_start = AM33XX_SRAM_PUB_PA;
+ omap_sram_size = AM33XX_SRAM_PUB_SIZE;
} else {
omap_sram_start = OMAP2_SRAM_PUB_PA;
omap_sram_size = 0x800; /* 2K */
--
2.1.0
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices
Hello Lokesh,
Am 13.10.2015 um 08:46 schrieb Lokesh Vutla:
+Nishanth,
On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
On embedded devices, often there is a combination of
removable mmc devices (e.g. MMC/SD cards) and hard
wired ones (e.g. eMMC). Depending on the hardware
configuration, the 'mmcblkN' node might change if
the removable device is available or not at boot time.
E.g. if the removable device is attached at boot time,
it might become mmxblk0. And the hard wired one mmcblk1.
But if the removable device isn't there at boot time,
the hard wired one will become mmcblk0. This makes it
somehow difficult to hard code the root device to the
non-removable device and boot fast.
Why not use "root=PARTUUID=${uuid}" option instead of relying on mmcblk no?
U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
does this in u-boot.
Good tip ... I do not know, if it is possible to update U-Boot
on this boards...
Current U-Boot says:
U-Boot 2013.01.01_heads/master-gc7900a0 (2015-05-06 - 20:37:15)
I2C: ready
DRAM: 512 MiB
[...]
U-Boot# mmc rescan
U-Boot# mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
PartStart SectorNum Sectors UUIDType
1 63 144522 000ce343-01 0e Boot
2 144585 659861 000ce343-02 83
U-Boot# part uuid mmc 0:2 uuid
Unknown command 'part' - try 'help'
U-Boot#
So, if this patch has no chance for mainline, please let me
know it, thanks!
bye,
Heiko
[1]
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=437bc42e7ff930dc4d4bd47199d2e823cf84bf4c;hp=85d17be374678ec37fd1e55db994a942e400dc80
Thanks and regards,
Lokesh
Signed-off-by: Heiko Schocher
---
Dirk Behme tried to bring this in, last mail I found:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
where Dirk worked in Arnds suggestion to use the
"/aliases" device node"
I adapt this to the omap_hsmmc driver.
Is there another solution for this problem?
Or why was this patch not accepted to mainline?
drivers/mmc/card/block.c | 6 --
drivers/mmc/host/omap_hsmmc.c | 6 ++
include/linux/mmc/host.h | 3 +++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c742cfd..62250d8 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2106,7 +2106,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
struct mmc_blk_data *md;
int devidx, ret;
- devidx = find_first_zero_bit(dev_use, max_devices);
+ devidx = find_next_zero_bit(dev_use, max_devices,
+ card->host->devidx);
if (devidx >= max_devices)
return ERR_PTR(-ENOSPC);
__set_bit(devidx, dev_use);
@@ -2124,7 +2125,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
* index anymore so we keep track of a name index.
*/
if (!subname) {
- md->name_idx = find_first_zero_bit(name_use, max_devices);
+ md->name_idx = find_next_zero_bit(name_use, max_devices,
+ card->host->devidx);
__set_bit(md->name_idx, name_use);
} else
md->name_idx = ((struct mmc_blk_data *)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7fb0753..0b45b48 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2059,6 +2059,12 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->pbias_enabled = 0;
host->vqmmc_enabled = 0;
+ if (pdev->dev.of_node) {
+ ret = of_alias_get_id(pdev->dev.of_node, "mmcblk");
+ if (ret >= 0)
+ host->mmc->devidx = ret;
+ }
+
ret = omap_hsmmc_gpio_init(mmc, host, pdata);
if (ret)
goto err_gpio;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 83b81fd..4f071681 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -382,6 +382,9 @@ struct mmc_host {
int dsr_req;/* DSR value is valid */
u32 dsr;/* optional driver stage (DSR) value */
+ /* preferred mmc block device index (mmcblkX) */
+ unsigned intdevidx;
+
unsigned long private[0] cacheline_aligned;
};
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm, omap2, sram: On HS/EMU devices, only 64K internal SRAM is available.
Of this, secure content (including PPA) uses initial
portion of the SRAM. This chunk is not (and shouldn't
be) accessible from the public code.
The minimum size of this chunk (0x350) is used in this
patch. Available size is rounded off to 63K.
Both values would require a change if size of secure
content grows beyond 0x350.
Signed-off-by: Heiko Schocher
Signed-off-by: Ayoub Zaki
---
arch/arm/mach-omap2/sram.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index cd488b8..2e7c00f 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -47,6 +47,28 @@
#define GP_DEVICE 0x300
+/**
+ * Size of chunk used by secure content in the HS/EMU devices.
+ *
+ * This size is not fixed. It depends upon the implementation of PPA.
+ * May need to be modified if the size grows.
+ */
+#define AM33XX_HS_HEADER_SIZE 0x0350
+
+/**
+ * Start of public SRAM on HS/EMU devices.
+ */
+#define AM33XX_SRAM_PA 0x4030
+#define AM33XX_SRAM_PUB_PA (AM33XX_SRAM_PA + AM33XX_HS_HEADER_SIZE)
+
+/**
+ * Size of public SRAM available on HS/EMU devices.
+ *
+ * This size also depends upon AM33XX_HS_HEADER_SIZE.
+ * Current value is derived from nearest round-off.
+ */
+#define AM33XX_SRAM_PUB_SIZE 0xfc00 /* 63K */
+
#define ROUND_DOWN(value,boundary) ((value) & (~((boundary)-1)))
static unsigned long omap_sram_start;
@@ -99,6 +121,9 @@ static void __init omap_detect_sram(void)
} else {
omap_sram_size = 0x8000; /* 32K */
}
+ } else if (soc_is_am33xx()) {
+ omap_sram_start = AM33XX_SRAM_PUB_PA;
+ omap_sram_size = AM33XX_SRAM_PUB_SIZE;
} else {
omap_sram_start = OMAP2_SRAM_PUB_PA;
omap_sram_size = 0x800; /* 2K */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices
On embedded devices, often there is a combination of
removable mmc devices (e.g. MMC/SD cards) and hard
wired ones (e.g. eMMC). Depending on the hardware
configuration, the 'mmcblkN' node might change if
the removable device is available or not at boot time.
E.g. if the removable device is attached at boot time,
it might become mmxblk0. And the hard wired one mmcblk1.
But if the removable device isn't there at boot time,
the hard wired one will become mmcblk0. This makes it
somehow difficult to hard code the root device to the
non-removable device and boot fast.
Signed-off-by: Heiko Schocher
---
Dirk Behme tried to bring this in, last mail I found:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
where Dirk worked in Arnds suggestion to use the
"/aliases" device node"
I adapt this to the omap_hsmmc driver.
Is there another solution for this problem?
Or why was this patch not accepted to mainline?
drivers/mmc/card/block.c | 6 --
drivers/mmc/host/omap_hsmmc.c | 6 ++
include/linux/mmc/host.h | 3 +++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c742cfd..62250d8 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2106,7 +2106,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
struct mmc_blk_data *md;
int devidx, ret;
- devidx = find_first_zero_bit(dev_use, max_devices);
+ devidx = find_next_zero_bit(dev_use, max_devices,
+ card->host->devidx);
if (devidx >= max_devices)
return ERR_PTR(-ENOSPC);
__set_bit(devidx, dev_use);
@@ -2124,7 +2125,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
* index anymore so we keep track of a name index.
*/
if (!subname) {
- md->name_idx = find_first_zero_bit(name_use, max_devices);
+ md->name_idx = find_next_zero_bit(name_use, max_devices,
+ card->host->devidx);
__set_bit(md->name_idx, name_use);
} else
md->name_idx = ((struct mmc_blk_data *)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7fb0753..0b45b48 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2059,6 +2059,12 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->pbias_enabled = 0;
host->vqmmc_enabled = 0;
+ if (pdev->dev.of_node) {
+ ret = of_alias_get_id(pdev->dev.of_node, "mmcblk");
+ if (ret >= 0)
+ host->mmc->devidx = ret;
+ }
+
ret = omap_hsmmc_gpio_init(mmc, host, pdata);
if (ret)
goto err_gpio;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 83b81fd..4f071681 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -382,6 +382,9 @@ struct mmc_host {
int dsr_req;/* DSR value is valid */
u32 dsr;/* optional driver stage (DSR) value */
+ /* preferred mmc block device index (mmcblkX) */
+ unsigned intdevidx;
+
unsigned long private[0] cacheline_aligned;
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arm, am1808: using mmc1 controller and dma
Hello Juha, Rajashekhara, Sudhakar wrote: > Hi, > > On Fri, Dec 02, 2011 at 14:25:48, Heiko Schocher wrote: >> Hello Rajashekhara, Sudhakar, >> >> Rajashekhara, Sudhakar wrote: >>> Hi, >>> >>> On Fri, Dec 02, 2011 at 13:05:22, Heiko Schocher wrote: >>>> Hello, >>>> >>>> trying Linux 3.2.0-rc3 on an am1808 based board using MMCSD1 controller, >>>> and facing problems with using DMA. Deactivating use_dma=0 in the >>>> davinci_mmc controller and mmc works in pio mode without problems. >>>> So there are no hardware problems, pinmux is ok, psc are all on. >>>> >>> Please refer to the discussion at [1] where similar issue was discussed. Go >>> through the > > [...] > >> Yuhu! that works for me! But I had to fix it a little, because "edma_info" >> is now named "info". Here my diff: >> > > Yup, this patch was on an older version. > >> diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c >> index da90103..e10a251 100644 >> --- a/arch/arm/mach-davinci/dma.c >> +++ b/arch/arm/mach-davinci/dma.c >> @@ -1513,7 +1513,7 @@ static int __init edma_probe(struct platform_device >> *pdev) >> * started by the codec engine will not cause audio defects. >> */ >> for (i = 0; i < edma_cc[j]->num_channels; i++) >> - map_dmach_queue(j, i, EVENTQ_1); >> + map_dmach_queue(j, i, info[j]->default_queue); >> >> queue_tc_mapping = info[j]->queue_tc_mapping; >> queue_priority_mapping = info[j]->queue_priority_mapping; >> >>> [1] >>> http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg17926.html >>> >> Do you prepare a patch, or should I send it? >> > > You can go ahead and submit the patch but Juha was the person who found out > this issue. Juha, can you post this patch, or is it ok for you, if I post it with your "Reported-by" and "Signed-off-by"? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arm, am1808: using mmc1 controller and dma
Hello Rajashekhara, Sudhakar, Rajashekhara, Sudhakar wrote: > Hi, > > On Fri, Dec 02, 2011 at 13:05:22, Heiko Schocher wrote: >> Hello, >> >> trying Linux 3.2.0-rc3 on an am1808 based board using MMCSD1 controller, >> and facing problems with using DMA. Deactivating use_dma=0 in the >> davinci_mmc controller and mmc works in pio mode without problems. >> So there are no hardware problems, pinmux is ok, psc are all on. >> > > Please refer to the discussion at [1] where similar issue was discussed. Go > through the Oh, sorry, missed this! Thanks for the hint! > entire thread. In the patch posted by Juha in this link, I see that except > for the below > hunk all others are integrated. > > @@ -1508,7 +1506,7 @@ static int __init edma_probe(struct platform_device > *pdev) > * started by the codec engine will not cause audio defects. > */ > for (i = 0; i < edma_info[j]->num_channels; i++) > - map_dmach_queue(j, i, EVENTQ_1); > + map_dmach_queue(j, i, edma_info[j]->default_queue); > > queue_tc_mapping = info[j].queue_tc_mapping; > queue_priority_mapping = info[j].queue_priority_mapping; > > Can you check whether the above patch fixes your issue? Yuhu! that works for me! But I had to fix it a little, because "edma_info" is now named "info". Here my diff: diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index da90103..e10a251 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -1513,7 +1513,7 @@ static int __init edma_probe(struct platform_device *pdev) * started by the codec engine will not cause audio defects. */ for (i = 0; i < edma_cc[j]->num_channels; i++) - map_dmach_queue(j, i, EVENTQ_1); + map_dmach_queue(j, i, info[j]->default_queue); queue_tc_mapping = info[j]->queue_tc_mapping; queue_priority_mapping = info[j]->queue_priority_mapping; > [1] > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg17926.html > Do you prepare a patch, or should I send it? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
arm, am1808: using mmc1 controller and dma
Hello, trying Linux 3.2.0-rc3 on an am1808 based board using MMCSD1 controller, and facing problems with using DMA. Deactivating use_dma=0 in the davinci_mmc controller and mmc works in pio mode without problems. So there are no hardware problems, pinmux is ok, psc are all on. Tried this on the AM1808 evalboard TMDXEXP1808L, and Linux 3.1 works with DMA without problems. Difference: On the AM1808 Evalboard TMDXEXP1808L MMCSD0 controller is used on my am1808 based board MMCSD1! Debugging in code and found, that on the am1808 evalboard I get on startup (first DMA access): CMD13, arg 0x, R1/R5/R6/R7 response a status back in mmc_davinci_irq(): TRNDNE (0x1000) Transfer done RSPDNE (0x0004) Response succesfully has received DATDNE (0x0001) The data has been fully transmitted On the am1808 based board with using MMCSD1 I get: CMD13, arg 0x, R1/R5/R6/R7 response TRNDNE (0x1000) Transfer done DRRDY (0x0400) MMCDRR is ready New data arrived and can be read by cpu or dma RSPDNE (0x0004) Response succesfully has received after that command, I see no more mmc accesses ... some ideas? Looking in the sprufu5.pdf (AM18x ARM Microprocessor Enhanced Direct Memory Access (EDMA3) Controller" chapter "2.6 Event, Channel, and PaRAM Mapping": "Most of the DMA channels are tied to a specific hardware peripheral event, thus allowing transfers to be triggered by events from device peripherals or external hardware." The mapping is defined in the device specific manual http://www.ti.com/lit/ds/sprs653b/sprs653b.pdf chapter "5.9.1 EDMA3 Channel Synchronization Events" and there I found: EDMA0 Controller Event 16 MMCSD0 Receive EDMA0 Controller Event 17 MMCSD0 Transmit EDMA1 Controller Event 28 MMCSD1 Receive EDMA1 Controller Event 29 MMCSD1 Transmit The Linux 3.1 Code is using EDMA1 Controller Event 28 MMCSD1 Receive EDMA1 Controller Event 29 MMCSD1 Transmit as events for the MMCSD1 controller ... so, this should be ok ... I see no more differences between MMCSD0 and MMCSD1 ... maybe I miss something? Have somebody running an am1808 based board with using MMCSD controller 1? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
