This is the first generation Amazon Echo from 2016.
Audio support is not yet implemented.
Signed-off-by: André Hentschel <[email protected]>
---
I have local patches for the microphone array, but cleaning that up will take some time.
Audio output seems to be even harder work...
You can find a tutorial on how to boot the Echo here:
https://labs.f-secure.com/archive/alexa-are-you-listening/
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-echo.dts | 466 +++++++++++++++++++++++++++++++
2 files changed, 467 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-echo.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b21b3a64641a..923dabc09203 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -685,6 +685,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += \
omap3-devkit8000.dtb \
omap3-devkit8000-lcd43.dtb \
omap3-devkit8000-lcd70.dtb \
+ omap3-echo.dtb \
omap3-evm.dtb \
omap3-evm-37xx.dtb \
omap3-gta04a3.dtb \
diff --git a/arch/arm/boot/dts/omap3-echo.dts b/arch/arm/boot/dts/omap3-echo.dts
new file mode 100644
index 000000000000..751560b18f79
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-echo.dts
@@ -0,0 +1,466 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2019 André Hentschel <[email protected]>
+ */
+/dts-v1/;
+
+#include "omap36xx.dtsi"
+
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "Amazon Echo (first generation)";
+ compatible = "amazon,omap3-echo", "ti,omap3630", "ti,omap3";
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&vdd1_reg>;
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0xc600000>; /* 198 MB */
+ };
+
+ vcc5v: fixedregulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vcc3v3: fixedregulator1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vcc1v8: fixedregulator2 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+ post-power-on-delay-ms = <40>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&button_pins>;
+
+ mute-button {
+ label = "mute";
+ linux,code = <KEY_MUTE>;
+ gpios = <&gpio3 6 GPIO_ACTIVE_LOW>; /* GPIO_70 */
+ wakeup-source;
+ };
+
+ help-button {
+ label = "help";
+ linux,code = <KEY_HELP>;
+ gpios = <&gpio3 8 GPIO_ACTIVE_LOW>; /* GPIO_72 */
+ wakeup-source;
+ };
+ };
+
+ rotary: rotary-encoder {
+ compatible = "rotary-encoder";
+ gpios = <
+ &gpio3 5 GPIO_ACTIVE_HIGH /* GPIO_69 */
+ &gpio3 12 GPIO_ACTIVE_HIGH /* GPIO_76 */
+ >;
+ linux,axis = <REL_X>;
+ rotary-encoder,relative-axis;
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+
+ tps: tps@2d {
+ reg = <0x2d>;
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+
+ lp5523A: lp5523A@32 {
+ compatible = "national,lp5523";
+ label = "q1";
+ reg = <0x32>;
+ clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */
+ enable-gpio = <&gpio4 13 GPIO_ACTIVE_HIGH>; /* GPIO_109 */
+
+ chan0 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan1 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan2 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan3 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan4 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan5 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan6 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan7 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan8 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ };
+
+ lp5523B: lp5523B@33 {
+ compatible = "national,lp5523";
+ label = "q3";
+ reg = <0x33>;
+ clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */
+
+ chan0 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan1 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan2 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan3 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan4 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan5 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan6 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan7 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan8 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ };
+
+ lp5523C: lp5523C@34 {
+ compatible = "national,lp5523";
+ label = "q4";
+ reg = <0x34>;
+ clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */
+
+ chan0 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan1 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan2 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan3 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan4 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan5 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan6 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan7 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan8 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ };
+
+ lp5523D: lp552D@35 {
+ compatible = "national,lp5523";
+ label = "q2";
+ reg = <0x35>;
+ clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */
+
+ chan0 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan1 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan2 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan3 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan4 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan5 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan6 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan7 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ chan8 {
+ led-cur = /bits/ 8 <12>;
+ max-cur = /bits/ 8 <15>;
+ };
+ };
+};
+
+#include "tps65910.dtsi"
+
+&omap3_pmx_core {
+ tps_pins: pinmux_tps_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21e0, PIN_INPUT_PULLUP | PIN_OFF_INPUT_PULLUP | PIN_OFF_OUTPUT_LOW | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* sys_nirq.sys_nirq */
+ >;
+ };
+
+ button_pins: pinmux_button_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x20dc, PIN_INPUT | MUX_MODE4) /* dss_data0.gpio_70 */
+ OMAP3_CORE1_IOPAD(0x20e0, PIN_INPUT | MUX_MODE4) /* dss_data2.gpio_72 */
+ >;
+ };
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_clk.sdmmc1_clk */
+ OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_cmd.sdmmc1_cmd */
+ OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat0.sdmmc1_dat0 */
+ OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat1.sdmmc1_dat1 */
+ OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat2.sdmmc1_dat2 */
+ OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat3.sdmmc1_dat3 */
+ >;
+ };
+
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_clk.sdmmc2_clk */
+ OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_cmd.sdmmc2_cmd */
+ OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat0.sdmmc2_dat0 */
+ OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat1.sdmmc2_dat1 */
+ OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat2.sdmmc2_dat2 */
+ OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat3.sdmmc2_dat3 */
+ OMAP3_CORE1_IOPAD(0x2164, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat4.sdmmc2_dat4 */
+ OMAP3_CORE1_IOPAD(0x2166, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat5.sdmmc2_dat5 */
+ OMAP3_CORE1_IOPAD(0x2168, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat6.sdmmc2_dat6 */
+ OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat7.sdmmc2_dat7 */
+ >;
+ };
+};
+
+&omap3_pmx_core2 {
+ mmc3_pins: pinmux_mmc3_pins {
+ pinctrl-single,pins = <
+ OMAP3630_CORE2_IOPAD(0x25d8, PIN_INPUT_PULLUP | MUX_MODE2) /* etk_clk.sdmmc3_clk */
+ OMAP3630_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP | MUX_MODE2) /* etk_ctl.sdmmc3_cmd */
+ OMAP3630_CORE2_IOPAD(0x25e2, PIN_INPUT_PULLUP | MUX_MODE2) /* etk_d3.sdmmc3_dat3 */
+ OMAP3630_CORE2_IOPAD(0x25e4, PIN_INPUT_PULLUP | MUX_MODE2) /* etk_d4.sdmmc3_dat0 */
+ OMAP3630_CORE2_IOPAD(0x25e6, PIN_INPUT_PULLUP | MUX_MODE2) /* etk_d5.sdmmc3_dat1 */
+ OMAP3630_CORE2_IOPAD(0x25e8, PIN_INPUT_PULLUP | MUX_MODE2) /* etk_d6.sdmmc3_dat2 */
+ >;
+ };
+};
+
+&mmc1 {
+ status = "okay";
+ bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <&vmmc_reg>;
+};
+
+&mmc2 {
+ status = "okay";
+ bus-width = <8>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
+ vmmc-supply = <&vmmc_reg>;
+};
+
+&mmc3 {
+ status = "okay";
+ bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc3_pins>;
+ non-removable;
+ disable-wp;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ vmmc-supply = <&vcc3v3>;
+ vqmmc-supply = <&vcc1v8>;
+};
+
+
+&tps {
+ pinctrl-names = "default";
+ pinctrl-0 = <&tps_pins>;
+
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+
+ ti,en-ck32k-xtal;
+ ti,system-power-controller;
+
+ vcc1-supply = <&vcc5v>;
+ vcc2-supply = <&vcc5v>;
+ vcc3-supply = <&vcc5v>;
+ vcc4-supply = <&vcc5v>;
+ vcc5-supply = <&vcc5v>;
+ vcc6-supply = <&vcc5v>;
+ vcc7-supply = <&vcc5v>;
+ vccio-supply = <&vcc5v>;
+
+ regulators {
+
+ vio_reg: regulator@1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vdd1_reg: regulator@2 {
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd2_reg: regulator@3 {
+ regulator-name = "vdd_dsp";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ };
+
+ vdd3_reg: regulator@4 {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ vdig1_reg: regulator@5 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <2700000>;
+ regulator-always-on;
+ };
+
+ vdig2_reg: regulator@6 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vpll_reg: regulator@7 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+
+ vdac_reg: regulator@8 {
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vaux1_reg: regulator@9 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2850000>;
+ regulator-always-on;
+ };
+
+ vaux2_reg: regulator@10 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vaux33_reg: regulator@11 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vmmc_reg: regulator@12 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+ };
+};
+
+&sgx_module {
+ status = "disabled";
+};
--
2.17.1
* André Hentschel <[email protected]> [191224 16:11]:
> This is the first generation Amazon Echo from 2016.
> Audio support is not yet implemented.
OK looks good to me, just worried about one part:
> +&sgx_module {
> + status = "disabled";
> +};
We should have a separate am3703.dtsi or whatever the SoC model
disabling sgx if not there on the SoC. That way board specific
dts files can just include it without having to debug this issue
over and over.
Regards,
Tony
Am 24.12.19 um 19:45 schrieb Tony Lindgren:
> * André Hentschel <[email protected]> [191224 16:11]:
>> This is the first generation Amazon Echo from 2016.
>> Audio support is not yet implemented.
>
> OK looks good to me, just worried about one part:
>
>> +&sgx_module {
>> + status = "disabled";
>> +};
>
> We should have a separate am3703.dtsi or whatever the SoC model
> disabling sgx if not there on the SoC. That way board specific
> dts files can just include it without having to debug this issue
> over and over.
Thanks for the quick review in that time of the year!
The sgx issue came up in newer kernels and I had to bisect it to 3b72fc895a2e57f70276b46f386f35d752adf555
The device just wasn't booting without a message, so yes, we should make it easier for others to figure it out.
SoC is DM3725 and only DM3730 has sgx support. And it's hard to say if the base is am37xx or omap36xx.
But I see the reasons you picked am3703, so I would move everything from omap36xx.dtsi to am3703.dtsi except sgx?
And then include am3703.dtsi in omap36xx.dtsi before sgx support?
Or would it be better to have sgx support in a separate dtsi?
On Wed, Dec 25, 2019 at 6:05 AM André Hentschel <[email protected]> wrote:
>
> Am 24.12.19 um 19:45 schrieb Tony Lindgren:
> > * André Hentschel <[email protected]> [191224 16:11]:
> >> This is the first generation Amazon Echo from 2016.
> >> Audio support is not yet implemented.
> >
> > OK looks good to me, just worried about one part:
> >
> >> +&sgx_module {
> >> + status = "disabled";
> >> +};
> >
> > We should have a separate am3703.dtsi or whatever the SoC model
> > disabling sgx if not there on the SoC. That way board specific
> > dts files can just include it without having to debug this issue
> > over and over.
>
> Thanks for the quick review in that time of the year!
> The sgx issue came up in newer kernels and I had to bisect it to 3b72fc895a2e57f70276b46f386f35d752adf555
> The device just wasn't booting without a message, so yes, we should make it easier for others to figure it out.
> SoC is DM3725 and only DM3730 has sgx support. And it's hard to say if the base is am37xx or omap36xx.
> But I see the reasons you picked am3703, so I would move everything from omap36xx.dtsi to am3703.dtsi except sgx?
> And then include am3703.dtsi in omap36xx.dtsi before sgx support?
I can see value in having a 3703 base and including that in the 36xx
with SGX and DSP nodes, but why not jus make SGX disabled by default.
Those who want/need it can enable it on a per-board basis.
> Or would it be better to have sgx support in a separate dtsi?
I am not sure how much DSP stuff is in there, but the DM3730 is the
AM3703 + DSP and 3D.
adam
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi,
> Am 24.12.2019 um 19:45 schrieb Tony Lindgren <[email protected]>:
>
> * André Hentschel <[email protected]> [191224 16:11]:
>> This is the first generation Amazon Echo from 2016.
>> Audio support is not yet implemented.
>
> OK looks good to me, just worried about one part:
>
>> +&sgx_module {
>> + status = "disabled";
>> +};
>
> We should have a separate am3703.dtsi or whatever the SoC model
> disabling sgx if not there on the SoC.
I think the am3703 is a dm3730 (omap3630) where the SGX and the
DSP have not passed production test and are "disabled" by eFuses.
This is a common procedure in silicon production to increase yield.
Therefore, there is a register which allows to dynamically determine
what components (SGX and DSP) are available on a specific SoC chip.
See "Table 1-6. Chip Identification" in the common
"AM/DM37x Multimedia Device TRM".
Such bits exists for omap34xx and for omap36xx (aka am37xx/dm37xx).
That way there is no need to disable/enable sgx through device tree
variations and introducing more complexity by introducing more and more
DTS for variants (am3703.dtsi, am3715.dtsi, dm3720.dtsi, dm3730.dtsi?).
BTW: what about a board that is/was produced in either am3703 or dm3730
variants? Can they still share an omap36xx.dtsi based DTB?
So IMHO if there is an issue with sgx enabled on am3703 but no SGX
hardware available on a specific SoC, the sysc setup should somehow read
the bits and effectively disable all SGX related setup if it is not
available on the SoC. If I remember correctly, some older hwmods did
such things by checking SoC variant bits.
BR and thanks,
Nikolaus
Am 25.12.19 um 18:01 schrieb H. Nikolaus Schaller:
> I think the am3703 is a dm3730 (omap3630) where the SGX and the
> DSP have not passed production test and are "disabled" by eFuses.
> This is a common procedure in silicon production to increase yield.
>
> Therefore, there is a register which allows to dynamically determine
> what components (SGX and DSP) are available on a specific SoC chip.
> See "Table 1-6. Chip Identification" in the common
> "AM/DM37x Multimedia Device TRM".
>
> Such bits exists for omap34xx and for omap36xx (aka am37xx/dm37xx).
>
> That way there is no need to disable/enable sgx through device tree
> variations and introducing more complexity by introducing more and more
> DTS for variants (am3703.dtsi, am3715.dtsi, dm3720.dtsi, dm3730.dtsi?).
>
> BTW: what about a board that is/was produced in either am3703 or dm3730
> variants? Can they still share an omap36xx.dtsi based DTB?
>
> So IMHO if there is an issue with sgx enabled on am3703 but no SGX
> hardware available on a specific SoC, the sysc setup should somehow read
> the bits and effectively disable all SGX related setup if it is not
> available on the SoC. If I remember correctly, some older hwmods did
> such things by checking SoC variant bits.
I like the idea, but I'm not in the position to vote for it and I don't
understand the sysc code enough to implement that.
Am 25.12.19 um 13:53 schrieb Adam Ford:
> On Wed, Dec 25, 2019 at 6:05 AM André Hentschel <[email protected]> wrote:
>> And then include am3703.dtsi in omap36xx.dtsi before sgx support?
> I can see value in having a 3703 base and including that in the 36xx
> with SGX and DSP nodes, but why not jus make SGX disabled by default.
> Those who want/need it can enable it on a per-board basis.
>> Or would it be better to have sgx support in a separate dtsi?
>
> I am not sure how much DSP stuff is in there, but the DM3730 is the
> AM3703 + DSP and 3D.
For clarification this reduced table should help:
DM3730 | DM3725 | AM3715 | AM3703
DSP X | X | |
SGX X | | X |
Where X is "supported"
* André Hentschel <[email protected]> [191227 14:29]:
> Am 25.12.19 um 18:01 schrieb H. Nikolaus Schaller:
> > I think the am3703 is a dm3730 (omap3630) where the SGX and the
> > DSP have not passed production test and are "disabled" by eFuses.
> > This is a common procedure in silicon production to increase yield.
> >
> > Therefore, there is a register which allows to dynamically determine
> > what components (SGX and DSP) are available on a specific SoC chip.
> > See "Table 1-6. Chip Identification" in the common
> > "AM/DM37x Multimedia Device TRM".
> >
> > Such bits exists for omap34xx and for omap36xx (aka am37xx/dm37xx).
> >
> > That way there is no need to disable/enable sgx through device tree
> > variations and introducing more complexity by introducing more and more
> > DTS for variants (am3703.dtsi, am3715.dtsi, dm3720.dtsi, dm3730.dtsi?).
> >
> > BTW: what about a board that is/was produced in either am3703 or dm3730
> > variants? Can they still share an omap36xx.dtsi based DTB?
> >
> > So IMHO if there is an issue with sgx enabled on am3703 but no SGX
> > hardware available on a specific SoC, the sysc setup should somehow read
> > the bits and effectively disable all SGX related setup if it is not
> > available on the SoC. If I remember correctly, some older hwmods did
> > such things by checking SoC variant bits.
>
> I like the idea, but I'm not in the position to vote for it and I don't
> understand the sysc code enough to implement that.
We can easily do both. So no worries, I can easily add SoC capabilites
support at some point.
> Am 25.12.19 um 13:53 schrieb Adam Ford:
> > On Wed, Dec 25, 2019 at 6:05 AM André Hentschel <[email protected]> wrote:
> >> And then include am3703.dtsi in omap36xx.dtsi before sgx support?
> > I can see value in having a 3703 base and including that in the 36xx
> > with SGX and DSP nodes, but why not jus make SGX disabled by default.
> > Those who want/need it can enable it on a per-board basis.
> >> Or would it be better to have sgx support in a separate dtsi?
> >
> > I am not sure how much DSP stuff is in there, but the DM3730 is the
> > AM3703 + DSP and 3D.
>
> For clarification this reduced table should help:
> DM3730 | DM3725 | AM3715 | AM3703
> DSP X | X | |
> SGX X | | X |
>
> Where X is "supported"
And let's also add minimal dm3725.dtsi, am3715.dtsi and am3703.dtsi
to make things simple. The device tree is supposed to describe the
hardware, and in most cases the SoC version is fixed and need no
dynamic detection.
André, can you please add those three dtsi files since you have at
least one test case? :)
Regards,
Tony
Am 30.12.19 um 18:29 schrieb Tony Lindgren:
> * André Hentschel <[email protected]> [191227 14:29]:
>> For clarification this reduced table should help:
>> DM3730 | DM3725 | AM3715 | AM3703
>> DSP X | X | |
>> SGX X | | X |
>>
>> Where X is "supported"
>
> And let's also add minimal dm3725.dtsi, am3715.dtsi and am3703.dtsi
> to make things simple. The device tree is supposed to describe the
> hardware, and in most cases the SoC version is fixed and need no
> dynamic detection.
>
> André, can you please add those three dtsi files since you have at
> least one test case? :)
Done, but I'm not sure how to handle the DSP stuff, so I only sent the SGX changes as I understood you want them to be
Hi Tony,
> Am 30.12.2019 um 18:29 schrieb Tony Lindgren <[email protected]>:
>
> * André Hentschel <[email protected]> [191227 14:29]:
>> Am 25.12.19 um 18:01 schrieb H. Nikolaus Schaller:
>>> I think the am3703 is a dm3730 (omap3630) where the SGX and the
>>> DSP have not passed production test and are "disabled" by eFuses.
>>> This is a common procedure in silicon production to increase yield.
>>>
>>> Therefore, there is a register which allows to dynamically determine
>>> what components (SGX and DSP) are available on a specific SoC chip.
>>> See "Table 1-6. Chip Identification" in the common
>>> "AM/DM37x Multimedia Device TRM".
>>>
>>> Such bits exists for omap34xx and for omap36xx (aka am37xx/dm37xx).
>>>
>>> That way there is no need to disable/enable sgx through device tree
>>> variations and introducing more complexity by introducing more and more
>>> DTS for variants (am3703.dtsi, am3715.dtsi, dm3720.dtsi, dm3730.dtsi?).
>>>
>>> BTW: what about a board that is/was produced in either am3703 or dm3730
>>> variants? Can they still share an omap36xx.dtsi based DTB?
>>>
>>> So IMHO if there is an issue with sgx enabled on am3703 but no SGX
>>> hardware available on a specific SoC, the sysc setup should somehow read
>>> the bits and effectively disable all SGX related setup if it is not
>>> available on the SoC. If I remember correctly, some older hwmods did
>>> such things by checking SoC variant bits.
>>
>> I like the idea, but I'm not in the position to vote for it and I don't
>> understand the sysc code enough to implement that.
>
> We can easily do both. So no worries, I can easily add SoC capabilites
> support at some point.
>
>> Am 25.12.19 um 13:53 schrieb Adam Ford:
>>> On Wed, Dec 25, 2019 at 6:05 AM André Hentschel <[email protected]> wrote:
>>>> And then include am3703.dtsi in omap36xx.dtsi before sgx support?
>>> I can see value in having a 3703 base and including that in the 36xx
>>> with SGX and DSP nodes, but why not jus make SGX disabled by default.
>>> Those who want/need it can enable it on a per-board basis.
>>>> Or would it be better to have sgx support in a separate dtsi?
>>>
>>> I am not sure how much DSP stuff is in there, but the DM3730 is the
>>> AM3703 + DSP and 3D.
>>
>> For clarification this reduced table should help:
>> DM3730 | DM3725 | AM3715 | AM3703
>> DSP X | X | |
>> SGX X | | X |
>>
>> Where X is "supported"
>
> And let's also add minimal dm3725.dtsi, am3715.dtsi and am3703.dtsi
> to make things simple.
Well, is that "simple"?
We also have to add omap3503, omap3515, omap3520, omap3530.dtsi.
And probably am3351,2,4,6,7,8,9 variants with different capabilities
(PRU, SGX, CAN, ZCZ ports to name some).
And to be correct, there should be a different "compatible".
Rob asked me when reviewing the pvrsgx bindings if the img,5xx variants
can be autodetected to reduce bindings complexity.
> The device tree is supposed to describe the
> hardware, and in most cases the SoC version is fixed and need no
> dynamic detection.
There may be exactly the same board populated with either one since
they are drop-in pin compatible. So this may proliferate to the
board.dts files and u-boot can have to load different .dtb.
>
> André, can you please add those three dtsi files since you have at
> least one test case? :)
>
> Regards,
>
> Tony
BR,
Nikolaus
* H. Nikolaus Schaller <[email protected]> [191231 08:16]:
> > Am 30.12.2019 um 18:29 schrieb Tony Lindgren <[email protected]>:
> > And let's also add minimal dm3725.dtsi, am3715.dtsi and am3703.dtsi
> > to make things simple.
>
> Well, is that "simple"?
Well simple from "adding support for a new device in most case" point
of view yes..
> We also have to add omap3503, omap3515, omap3520, omap3530.dtsi.
> And probably am3351,2,4,6,7,8,9 variants with different capabilities
> (PRU, SGX, CAN, ZCZ ports to name some).
>
> And to be correct, there should be a different "compatible".
..and yes the number of permutations quickly gets out of control :)
The SoC specific compatibles should be there though. So everybody,
please keep adding them as we encounter the missing ones.
Note that we don't seem to have much any feature detection for the
newer TI parts. At least am4 and dra7 already rely on
of_machine_is_compatible() checks for omap_hwmod_43xx_data.c and
omap_hwmod_7xx_data.c.
> Rob asked me when reviewing the pvrsgx bindings if the img,5xx variants
> can be autodetected to reduce bindings complexity.
Yes also dynamic detection is needed, and we do have that working
for many SoCs. The use in ti-sysc driver is still missing though,
and newer SoCs never had feature detection added.
> > The device tree is supposed to describe the
> > hardware, and in most cases the SoC version is fixed and need no
> > dynamic detection.
>
> There may be exactly the same board populated with either one since
> they are drop-in pin compatible. So this may proliferate to the
> board.dts files and u-boot can have to load different .dtb.
Yeah. I'm afraid we're already depending for bootloader picking
the right dtb for many cases, such as capes etc.
Regards,
Tony