AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-02 19:26:41 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
5e7004351a
linux_dsm_epyc7002/arch/arm/boot/dts/omap3-sb-t35.dtsi

49 lines
1.2 KiB
Plaintext
Raw Normal View History

ARM: dts: Add support for sbc-3xxx with cm-t3730 This adds support for CompuLab SBC-T3530, also known as cm-t3730: http://compulab.co.il/products/sbcs/sbc-t3530/ It seems that with the sbc-3xxx mainboard is also used on SBC-T3517 and SBC-T3730 with just a different CPU module: http://compulab.co.il/products/sbcs/sbc-t3517/ http://compulab.co.il/products/sbcs/sbc-t3730/ So let's add a common omap3-sb-t35.dtsi and then separate SoC specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and omap3-sbc-t3517.dts. I've tested this with SBC-T3730 as that's the only one I have. At least serial, both Ethernet controllers, MMC, and wl12xx WLAN work. Note that WLAN seems to be different for SBC-T3530. And SBC-T3517 may need some changes for the EMAC Ethernet if that's used instead of the smsc911x. Cc: devicetree@vger.kernel.org Cc: Mike Rapoport <mike@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-19 04:13:21 +07:00
/*
* Common support for CompuLab SB-T35 used on SBC-T3530, SBC-T3517 and SBC-T3730
*/
ARM: dts: sbc-t3x: refactor DT support Refactor the sbc-t3x device tree as a preparation for additional (sbc-t3530, sbc-t3517, etc.) boards support. No functional changes. The device tree will have the following structure: omap3-cm-t3x.dtsi | |<-- omap3-cm-t3x30.dtsi | | | | | | ----- ------- ------------ | | | CoM | | Board | | Base board | | | ----- ------- ------------ | | omap3-sb-t35.dtsi | | | | |<-- omap3-cm-t3730.dts <-- omap3-sbc-t3730.dts -->| | | | | |<-- omap3-cm-t3530.dts <-- omap3-sbc-t3530.dts -->| | | |<-------- omap3-cm-t3517.dts <-- omap3-sbc-t3517.dts -->| Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-01-12 20:22:45 +07:00
&omap3_pmx_core {
smsc2_pins: pinmux_smsc2_pins {
pinctrl-single,pins = <
OMAP3_CORE1_IOPAD(0x20b6, PIN_OUTPUT | MUX_MODE0) /* gpmc_ncs4.gpmc_ncs4 */
OMAP3_CORE1_IOPAD(0x20d2, PIN_INPUT_PULLUP | MUX_MODE4) /* gpmc_wait3.gpio_65 */
>;
};
};
ARM: dts: Add support for sbc-3xxx with cm-t3730 This adds support for CompuLab SBC-T3530, also known as cm-t3730: http://compulab.co.il/products/sbcs/sbc-t3530/ It seems that with the sbc-3xxx mainboard is also used on SBC-T3517 and SBC-T3730 with just a different CPU module: http://compulab.co.il/products/sbcs/sbc-t3517/ http://compulab.co.il/products/sbcs/sbc-t3730/ So let's add a common omap3-sb-t35.dtsi and then separate SoC specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and omap3-sbc-t3517.dts. I've tested this with SBC-T3730 as that's the only one I have. At least serial, both Ethernet controllers, MMC, and wl12xx WLAN work. Note that WLAN seems to be different for SBC-T3530. And SBC-T3517 may need some changes for the EMAC Ethernet if that's used instead of the smsc911x. Cc: devicetree@vger.kernel.org Cc: Mike Rapoport <mike@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-19 04:13:21 +07:00
&gpmc {
ranges = <4 0 0x2d000000 0x01000000>;
smsc2: ethernet@4,0 {
compatible = "smsc,lan9221", "smsc,lan9115";
ARM: dts: sbc-t3x: refactor DT support Refactor the sbc-t3x device tree as a preparation for additional (sbc-t3530, sbc-t3517, etc.) boards support. No functional changes. The device tree will have the following structure: omap3-cm-t3x.dtsi | |<-- omap3-cm-t3x30.dtsi | | | | | | ----- ------- ------------ | | | CoM | | Board | | Base board | | | ----- ------- ------------ | | omap3-sb-t35.dtsi | | | | |<-- omap3-cm-t3730.dts <-- omap3-sbc-t3730.dts -->| | | | | |<-- omap3-cm-t3530.dts <-- omap3-sbc-t3530.dts -->| | | |<-------- omap3-cm-t3517.dts <-- omap3-sbc-t3517.dts -->| Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-01-12 20:22:45 +07:00
pinctrl-names = "default";
pinctrl-0 = <&smsc2_pins>;
ARM: dts: Add support for sbc-3xxx with cm-t3730 This adds support for CompuLab SBC-T3530, also known as cm-t3730: http://compulab.co.il/products/sbcs/sbc-t3530/ It seems that with the sbc-3xxx mainboard is also used on SBC-T3517 and SBC-T3730 with just a different CPU module: http://compulab.co.il/products/sbcs/sbc-t3517/ http://compulab.co.il/products/sbcs/sbc-t3730/ So let's add a common omap3-sb-t35.dtsi and then separate SoC specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and omap3-sbc-t3517.dts. I've tested this with SBC-T3730 as that's the only one I have. At least serial, both Ethernet controllers, MMC, and wl12xx WLAN work. Note that WLAN seems to be different for SBC-T3530. And SBC-T3517 may need some changes for the EMAC Ethernet if that's used instead of the smsc911x. Cc: devicetree@vger.kernel.org Cc: Mike Rapoport <mike@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-19 04:13:21 +07:00
interrupt-parent = <&gpio3>;
interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
reg = <4 0 0xff>;
bank-width = <2>;
gpmc,mux-add-data;
ARM: dts: Fix GPMC timings for LAN9220 I've noticed occasional random oopsing on my gateway machine since I upgraded it to use device tree based booting. As this machine has worked reliably before that for a few years, pretty much the only difference was narrowed down to the GPMC timings. Turns out that for legacy based booting we are using bootloader timings for GPMC for smsc911x. With device tree we are passing the timings in the .dts file, and the device tree timings are not quite suitable for LAN9920. Enabling DEBUG in gpmc.c I noticed that the device tree configured timings are different from the the known working bootloader timings. So let's fix the timings to match the bootloader timings when looked at the gpmc dmesg output with DEBUG enabled. The changes were done by multiplying the bootloader tick values by six to get the nanosecond value for device tree. This is not generic from the device point of view as the calculations should be based on the device timings. Anyways, further improvments can be done based on the timings documentation for LAN9220. But let's first get things to a known good working state. Note that we still need to change the timings also for sb-t35 also as it has two LAN9220 instances on GPMC and we can currently include the generic timings only once. Also note that any boards that have LAN9221 instead of LAN9220 should be updated to use omap-gpmc-smsc9221.dtsi instead of omap-gpmc-smsc911x.dtsi. The LAN9221 timings are different from LAN9220 timings. Cc: Christoph Fritz <chf.fritz@googlemail.com> Cc: Dmitry Lifshitz <lifshitz@compulab.co.il> Cc: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-04-24 01:04:42 +07:00
gpmc,cs-on-ns = <1>;
gpmc,cs-rd-off-ns = <180>;
gpmc,cs-wr-off-ns = <180>;
gpmc,adv-rd-off-ns = <18>;
ARM: dts: Add support for sbc-3xxx with cm-t3730 This adds support for CompuLab SBC-T3530, also known as cm-t3730: http://compulab.co.il/products/sbcs/sbc-t3530/ It seems that with the sbc-3xxx mainboard is also used on SBC-T3517 and SBC-T3730 with just a different CPU module: http://compulab.co.il/products/sbcs/sbc-t3517/ http://compulab.co.il/products/sbcs/sbc-t3730/ So let's add a common omap3-sb-t35.dtsi and then separate SoC specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and omap3-sbc-t3517.dts. I've tested this with SBC-T3730 as that's the only one I have. At least serial, both Ethernet controllers, MMC, and wl12xx WLAN work. Note that WLAN seems to be different for SBC-T3530. And SBC-T3517 may need some changes for the EMAC Ethernet if that's used instead of the smsc911x. Cc: devicetree@vger.kernel.org Cc: Mike Rapoport <mike@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-19 04:13:21 +07:00
gpmc,adv-wr-off-ns = <48>;
gpmc,oe-on-ns = <54>;
gpmc,oe-off-ns = <168>;
gpmc,we-on-ns = <54>;
gpmc,we-off-ns = <168>;
gpmc,rd-cycle-ns = <186>;
gpmc,wr-cycle-ns = <186>;
ARM: dts: Fix GPMC timings for LAN9220 I've noticed occasional random oopsing on my gateway machine since I upgraded it to use device tree based booting. As this machine has worked reliably before that for a few years, pretty much the only difference was narrowed down to the GPMC timings. Turns out that for legacy based booting we are using bootloader timings for GPMC for smsc911x. With device tree we are passing the timings in the .dts file, and the device tree timings are not quite suitable for LAN9920. Enabling DEBUG in gpmc.c I noticed that the device tree configured timings are different from the the known working bootloader timings. So let's fix the timings to match the bootloader timings when looked at the gpmc dmesg output with DEBUG enabled. The changes were done by multiplying the bootloader tick values by six to get the nanosecond value for device tree. This is not generic from the device point of view as the calculations should be based on the device timings. Anyways, further improvments can be done based on the timings documentation for LAN9220. But let's first get things to a known good working state. Note that we still need to change the timings also for sb-t35 also as it has two LAN9220 instances on GPMC and we can currently include the generic timings only once. Also note that any boards that have LAN9221 instead of LAN9220 should be updated to use omap-gpmc-smsc9221.dtsi instead of omap-gpmc-smsc911x.dtsi. The LAN9221 timings are different from LAN9220 timings. Cc: Christoph Fritz <chf.fritz@googlemail.com> Cc: Dmitry Lifshitz <lifshitz@compulab.co.il> Cc: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-04-24 01:04:42 +07:00
gpmc,access-ns = <144>;
gpmc,page-burst-access-ns = <24>;
gpmc,bus-turnaround-ns = <90>;
gpmc,cycle2cycle-delay-ns = <90>;
ARM: dts: Add support for sbc-3xxx with cm-t3730 This adds support for CompuLab SBC-T3530, also known as cm-t3730: http://compulab.co.il/products/sbcs/sbc-t3530/ It seems that with the sbc-3xxx mainboard is also used on SBC-T3517 and SBC-T3730 with just a different CPU module: http://compulab.co.il/products/sbcs/sbc-t3517/ http://compulab.co.il/products/sbcs/sbc-t3730/ So let's add a common omap3-sb-t35.dtsi and then separate SoC specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and omap3-sbc-t3517.dts. I've tested this with SBC-T3730 as that's the only one I have. At least serial, both Ethernet controllers, MMC, and wl12xx WLAN work. Note that WLAN seems to be different for SBC-T3530. And SBC-T3517 may need some changes for the EMAC Ethernet if that's used instead of the smsc911x. Cc: devicetree@vger.kernel.org Cc: Mike Rapoport <mike@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-19 04:13:21 +07:00
gpmc,cycle2cycle-samecsen;
gpmc,cycle2cycle-diffcsen;
ARM: dts: Fix GPMC Ethernet timings for omap cm-t sbc-t boards for device tree Looks like we have wrong GPMC timings we have for the cm-t and sbc-t boards. This can cause occasional strange errors with at least doing an rsync of large files or doing apt-get dist-upgrade. Let's fix the issue in two phases. First let's simplify cm-t and sbc-t to use the shared omap-gpmc-smsc911x.dtsi to avoid fixing the issue in multiple places. Then we can fix the timings in a single place with a follow-up patch. Cc: Dmitry Lifshitz <lifshitz@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-04-24 01:04:30 +07:00
vddvario-supply = <&vddvario>;
vdd33a-supply = <&vdd33a>;
ARM: dts: Add support for sbc-3xxx with cm-t3730 This adds support for CompuLab SBC-T3530, also known as cm-t3730: http://compulab.co.il/products/sbcs/sbc-t3530/ It seems that with the sbc-3xxx mainboard is also used on SBC-T3517 and SBC-T3730 with just a different CPU module: http://compulab.co.il/products/sbcs/sbc-t3517/ http://compulab.co.il/products/sbcs/sbc-t3730/ So let's add a common omap3-sb-t35.dtsi and then separate SoC specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and omap3-sbc-t3517.dts. I've tested this with SBC-T3730 as that's the only one I have. At least serial, both Ethernet controllers, MMC, and wl12xx WLAN work. Note that WLAN seems to be different for SBC-T3530. And SBC-T3517 may need some changes for the EMAC Ethernet if that's used instead of the smsc911x. Cc: devicetree@vger.kernel.org Cc: Mike Rapoport <mike@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-12-19 04:13:21 +07:00
reg-io-width = <4>;
smsc,save-mac-address;
};
};
Reference in New Issue Copy Permalink