| Message ID | 9bff40f434e5298890e5d139cc36cc46a0ca2d76.1615369068.git.jan.kiszka@siemens.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | arm64: Add TI AM65x-based IOT2050 boards | expand |
On 10:37-20210310, Jan Kiszka wrote: > From: Jan Kiszka <jan.kiszka@siemens.com> > + spidev@0 { > + compatible = "rohm,dh2228fv"; > + spi-max-frequency = <20000000>; > + reg = <0>; Jan, As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/ #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581: compatible = "rohm,dh2228fv"; I cannot pick up nodes that are'nt documented as yaml in Documentation/devicetree I know this is irritating to find such nodes that already have previous users and the person coming last gets to deal with "new rules".. but sorry for catching this so late. Here are the options that come to mind: option 1) - drop the node and resubmit. option 2) - get the documentation into linux master tree and then submit the patches. I think we should just drop the node and resubmit - since this is a more intrusive change and I don't have your platform handy, I am going to suggest you make a call :( Additionally please install yamlint and dtbs_schema -> run dtbs_check. I see more than a few warnings there which may need some closer look. A full log against linux-next is here: https://pastebin.ubuntu.com/p/qR69h28c5f/ PS: https://github.com/nmenon/kernel_patch_verify/blob/master/kpv I have been using my script to verify with kpv -C -V -n num_patches and then digging through the logs. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 11.03.21 14:17, Nishanth Menon wrote: > On 10:37-20210310, Jan Kiszka wrote: >> From: Jan Kiszka <jan.kiszka@siemens.com> >> + spidev@0 { >> + compatible = "rohm,dh2228fv"; >> + spi-max-frequency = <20000000>; >> + reg = <0>; > > Jan, > > As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning > > WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/ > #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581: > compatible = "rohm,dh2228fv"; > > I cannot pick up nodes that are'nt documented as yaml in > Documentation/devicetree > > I know this is irritating to find such nodes that already have previous > users and the person coming last gets to deal with "new rules".. but > sorry for catching this so late. > > Here are the options that come to mind: > > option 1) - drop the node and resubmit. > > option 2) - get the documentation into linux master tree and then submit > the patches. > As you said, I'm not setting a precedence here: arch/arm/boot/dts/imx28-cfa10049.dts: compatible = "rohm,dh2228fv"; arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv"; arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible = "rohm,dh2228fv"; drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" }, Was just just never documented as binding? Or why is no one allowed to use this anymore? What is to be used instead for spidev? > > I think we should just drop the node and resubmit - since this is a more > intrusive change and I don't have your platform handy, I am going to > suggest you make a call :( This breaks userspace here, and we would need to carry that node on top. BTW, I already brought up the topic internally to get you some boards for testing. > > Additionally please install yamlint and dtbs_schema -> run dtbs_check. I > see more than a few warnings there which may need some closer look. > I've done that and addressed all that I could (former patch 4). We import those from k3, and I don't feel confident how to resolve them. See also v1 of this patch. Jan > > A full log against linux-next is here: https://pastebin.ubuntu.com/p/qR69h28c5f/ > > > PS: https://github.com/nmenon/kernel_patch_verify/blob/master/kpv > > I have been using my script to verify with kpv -C -V -n num_patches and > then digging through the logs. > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
On 14:44-20210311, Jan Kiszka wrote: > On 11.03.21 14:17, Nishanth Menon wrote: > > On 10:37-20210310, Jan Kiszka wrote: > >> From: Jan Kiszka <jan.kiszka@siemens.com> > >> + spidev@0 { > >> + compatible = "rohm,dh2228fv"; > >> + spi-max-frequency = <20000000>; > >> + reg = <0>; > > > > Jan, > > > > As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning > > > > WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/ > > #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581: > > compatible = "rohm,dh2228fv"; > > > > I cannot pick up nodes that are'nt documented as yaml in > > Documentation/devicetree > > > > I know this is irritating to find such nodes that already have previous > > users and the person coming last gets to deal with "new rules".. but > > sorry for catching this so late. > > > > Here are the options that come to mind: > > > > option 1) - drop the node and resubmit. > > > > option 2) - get the documentation into linux master tree and then submit > > the patches. > > > > As you said, I'm not setting a precedence here: > > arch/arm/boot/dts/imx28-cfa10049.dts: compatible = "rohm,dh2228fv"; > arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv"; > arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible = "rohm,dh2228fv"; > drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" }, > > Was just just never documented as binding? Or why is no one allowed to > use this anymore? What is to be used instead for spidev? See [1] compare the compatibles against Documentation/devicetree/bindings -> I think you should describe what your hardware really is though. Unfortunately devicetree migration has been far from being smooth.. it was like chewing an elephant - linux community had to attack it in pieces.. Yes - it was unfortunately one of those cases where the driver support was introduced long back and no binding was introduced at that time (it was'nt mandatory then).. then we added a mandatory requirement that it be documented in txt.. over years realized things are'nt great with unstructured txt description of binding, now moving on converting existing txt files to yaml and schemas to static check the dts... evolution over the years, I guess. I am on a fight internally as well to have all our legacy txt files converted over to yaml.. and am having to put up a stance - see [2] [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c#n678 [2] https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc@finally/T/#u > > > > > I think we should just drop the node and resubmit - since this is a more > > intrusive change and I don't have your platform handy, I am going to > > suggest you make a call :( > > This breaks userspace here, and we would need to carry that node on top. > Uggh... that sucks.. but I think that would be lower tradeoff to make than me (as it stands now) having to drop the patch series. > BTW, I already brought up the topic internally to get you some boards > for testing. Thanks.. While it might help me personally to get some on my internal farm, it might be good to get them on kernelci as well on the longer run. > > I've done that and addressed all that I could (former patch 4). We > import those from k3, and I don't feel confident how to resolve them. > See also v1 of this patch. Yeah - i noticed that upstream dt-schema has gotten even more stricter even though the dts has remained the same.. I need to spend time in digging at it. At this point the only big kicker is the checkpatch stuff which I cant let through - if i do that arnd will probably kick everything from my PR out :( - which I cant do. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 11.03.21 15:00, Nishanth Menon wrote: > On 14:44-20210311, Jan Kiszka wrote: >> On 11.03.21 14:17, Nishanth Menon wrote: >>> On 10:37-20210310, Jan Kiszka wrote: >>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>> + spidev@0 { >>>> + compatible = "rohm,dh2228fv"; >>>> + spi-max-frequency = <20000000>; >>>> + reg = <0>; >>> >>> Jan, >>> >>> As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning >>> >>> WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/ >>> #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581: >>> compatible = "rohm,dh2228fv"; >>> >>> I cannot pick up nodes that are'nt documented as yaml in >>> Documentation/devicetree >>> >>> I know this is irritating to find such nodes that already have previous >>> users and the person coming last gets to deal with "new rules".. but >>> sorry for catching this so late. >>> >>> Here are the options that come to mind: >>> >>> option 1) - drop the node and resubmit. >>> >>> option 2) - get the documentation into linux master tree and then submit >>> the patches. >>> >> >> As you said, I'm not setting a precedence here: >> >> arch/arm/boot/dts/imx28-cfa10049.dts: compatible = "rohm,dh2228fv"; >> arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv"; >> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible = "rohm,dh2228fv"; >> drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" }, >> >> Was just just never documented as binding? Or why is no one allowed to >> use this anymore? What is to be used instead for spidev? > > See [1] compare the compatibles against > Documentation/devicetree/bindings -> I think you should describe what > your hardware really is though. This SPI bus is routed to an Arduino connector. By default, userspace (e.g. mraa) takes ownership and adds the desired logic for what is being connected. We have no idea what shield or other extension the user adds, though. > > Unfortunately devicetree migration has been far from being smooth.. it > was like chewing an elephant - linux community had to attack it in > pieces.. > > Yes - it was unfortunately one of those cases where the driver support > was introduced long back and no binding was introduced at that time (it > was'nt mandatory then).. then we added a mandatory requirement that it > be documented in txt.. over years realized things are'nt great with > unstructured txt description of binding, now moving on converting > existing txt files to yaml and schemas to static check the dts... > evolution over the years, I guess. > > I am on a fight internally as well to have all our legacy txt files > converted over to yaml.. and am having to put up a stance - see [2] > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c#n678 > [2] https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc@finally/T/#u > The problem here is not simple txt->yml conversion: There is no official binding for spidev yet, just existing users and the driver waiting for them. >> >>> >>> I think we should just drop the node and resubmit - since this is a more >>> intrusive change and I don't have your platform handy, I am going to >>> suggest you make a call :( >> >> This breaks userspace here, and we would need to carry that node on top. >> > > Uggh... that sucks.. but I think that would be lower tradeoff to make > than me (as it stands now) having to drop the patch series. > >> BTW, I already brought up the topic internally to get you some boards >> for testing. > > Thanks.. While it might help me personally to get some on my internal > farm, it might be good to get them on kernelci as well on the longer > run. > Will keep that on the radar. I definitely want to get it into the CIP LAVA lab which is testing LTS as well. >> >> I've done that and addressed all that I could (former patch 4). We >> import those from k3, and I don't feel confident how to resolve them. >> See also v1 of this patch. > > Yeah - i noticed that upstream dt-schema has gotten even more stricter > even though the dts has remained the same.. I need to spend time in > digging at it. > > At this point the only big kicker is the checkpatch stuff which I cant > let through - if i do that arnd will probably kick everything from my > PR out :( - which I cant do. > Are we talking about spidev here? Then let's drop that node, but I do need to know how to describe spidev properly Or is it about those other warnings coming from your dtsi files, now being surfaced? If you can tell me how to resolve them, I can write patches. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
On 15:14-20210311, Jan Kiszka wrote: [...] > > > > See [1] compare the compatibles against > > Documentation/devicetree/bindings -> I think you should describe what > > your hardware really is though. > > This SPI bus is routed to an Arduino connector. By default, userspace > (e.g. mraa) takes ownership and adds the desired logic for what is being > connected. We have no idea what shield or other extension the user adds, > though. overlays look like the right approach for variable systems like these. It is not exactly plug and play.. but it does provide a level of flexibility that is helpful. [..] > The problem here is not simple txt->yml conversion: There is no official > binding for spidev yet, just existing users and the driver waiting for them. > I think we should discuss in the spidev list to get it resolved. > > Thanks.. While it might help me personally to get some on my internal > > farm, it might be good to get them on kernelci as well on the longer > > run. > > > > Will keep that on the radar. I definitely want to get it into the CIP > LAVA lab which is testing LTS as well. Cool. > Are we talking about spidev here? Then let's drop that node, but I do > need to know how to describe spidev properly yes - the spidev is my problem. can you drop the node and repost? i cant locally modify and hope it works. > > Or is it about those other warnings coming from your dtsi files, now > being surfaced? If you can tell me how to resolve them, I can write patches. I will look at the warnings later today.. I dont think they are triggered by the board dts. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 11.03.21 15:21, Nishanth Menon wrote: > On 15:14-20210311, Jan Kiszka wrote: > > [...] > >>> >>> See [1] compare the compatibles against >>> Documentation/devicetree/bindings -> I think you should describe what >>> your hardware really is though. >> >> This SPI bus is routed to an Arduino connector. By default, userspace >> (e.g. mraa) takes ownership and adds the desired logic for what is being >> connected. We have no idea what shield or other extension the user adds, >> though. > > overlays look like the right approach for variable systems like these. > It is not exactly plug and play.. but it does provide a level of > flexibility that is helpful. Yes, that's for extensions which have kernel drivers. The default model here is userspace, though. Will add as a separate patch to our queue for now. > > [..] >> The problem here is not simple txt->yml conversion: There is no official >> binding for spidev yet, just existing users and the driver waiting for them. >> > > I think we should discuss in the spidev list to get it resolved. > >>> Thanks.. While it might help me personally to get some on my internal >>> farm, it might be good to get them on kernelci as well on the longer >>> run. >>> >> >> Will keep that on the radar. I definitely want to get it into the CIP >> LAVA lab which is testing LTS as well. > > Cool. > >> Are we talking about spidev here? Then let's drop that node, but I do >> need to know how to describe spidev properly > > yes - the spidev is my problem. can you drop the node and repost? i cant > locally modify and hope it works. > Done. >> >> Or is it about those other warnings coming from your dtsi files, now >> being surfaced? If you can tell me how to resolve them, I can write patches. > > I will look at the warnings later today.. I dont think they are > triggered by the board dts. > That was also my interpretation of the results. Some are even just copies from what you get for the EVM boards. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
On 15:36-20210311, Jan Kiszka wrote: > On 11.03.21 15:21, Nishanth Menon wrote: > > On 15:14-20210311, Jan Kiszka wrote: > > > > [...] > > > >>> > >>> See [1] compare the compatibles against > >>> Documentation/devicetree/bindings -> I think you should describe what > >>> your hardware really is though. > >> > >> This SPI bus is routed to an Arduino connector. By default, userspace > >> (e.g. mraa) takes ownership and adds the desired logic for what is being > >> connected. We have no idea what shield or other extension the user adds, > >> though. > > > > overlays look like the right approach for variable systems like these. > > It is not exactly plug and play.. but it does provide a level of > > flexibility that is helpful. > > Yes, that's for extensions which have kernel drivers. The default model > here is userspace, though. Will add as a separate patch to our queue for > now. My colleagues did some checkups and pulled up a few thread on spidev of potential interests.. See: https://patchwork.kernel.org/project/spi-devel-general/patch/1427499742-26916-1-git-send-email-broonie@kernel.org/ https://yurovsky.github.io/2016/10/07/spidev-linux-devices.html etc... I'd split the spidev node alone as an addendum indicate the checkpatch warning, describe the details and loop in spidev list, Mark, et.al. to discuss the direction. I am hoping we can get this resolved or get a direction for .13-rc1 But that said, I see some examples such as for i in `git grep ".compatible" drivers/spi/spidev.c|grep =|cut -d '=' -f2|cut -d ' ' -f2`; do git grep $i Documentation/devicetree/bindings/; done Documentation/devicetree/bindings/spi/spi-mux.yaml: compatible = "lineartechnology,ltc2488"; Documentation/devicetree/bindings/misc/ge-achc.txt:- compatible : Should be "ge,achc" Documentation/devicetree/bindings/misc/ge-achc.txt: compatible = "ge,achc"; Documentation/devicetree/bindings/misc/lwn-bk4.txt:- compatible : Should be "lwn,bk4" Documentation/devicetree/bindings/misc/lwn-bk4.txt: compatible = "lwn,bk4"; So, the shield could be hosting one of those say ge,achc or maybe lwn,bk4 ?- will probably be good to document the dts is for such a configuration, though it is possible that such a configuration might work for others? I agree with Mark that "dt should indicate specific hardware" and we should constraint the definition in such a scope? [...] > > > >> Are we talking about spidev here? Then let's drop that node, but I do > >> need to know how to describe spidev properly > > > > yes - the spidev is my problem. can you drop the node and repost? i cant > > locally modify and hope it works. > > > > Done. Thanks, I will try and pick up the v5 later today - need to redo my sanity checkups. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile index 386ef98ccf7d..d56c742f5a10 100644 --- a/arch/arm64/boot/dts/ti/Makefile +++ b/arch/arm64/boot/dts/ti/Makefile @@ -7,6 +7,8 @@ # dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb +dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb +dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board.dtb diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi new file mode 100644 index 000000000000..34bca374bb76 --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi @@ -0,0 +1,661 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) Siemens AG, 2018-2021 + * + * Authors: + * Le Jin <le.jin@siemens.com> + * Jan Kiszka <jan.kiszk@siemens.com> + * + * Common bits of the IOT2050 Basic and Advanced variants + */ + +/dts-v1/; + +#include "k3-am654.dtsi" +#include <dt-bindings/phy/phy.h> + +/ { + aliases { + spi0 = &mcu_spi0; + }; + + chosen { + stdout-path = "serial3:115200n8"; + bootargs = "earlycon=ns16550a,mmio32,0x02810000"; + }; + + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + ranges; + + secure_ddr: secure-ddr@9e800000 { + reg = <0 0x9e800000 0 0x01800000>; /* for OP-TEE */ + alignment = <0x1000>; + no-map; + }; + + mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@a0000000 { + compatible = "shared-dma-pool"; + reg = <0 0xa0000000 0 0x100000>; + no-map; + }; + + mcu_r5fss0_core0_memory_region: r5f-memory@a0100000 { + compatible = "shared-dma-pool"; + reg = <0 0xa0100000 0 0xf00000>; + no-map; + }; + + mcu_r5fss0_core1_dma_memory_region: r5f-dma-memory@a1000000 { + compatible = "shared-dma-pool"; + reg = <0 0xa1000000 0 0x100000>; + no-map; + }; + + mcu_r5fss0_core1_memory_region: r5f-memory@a1100000 { + compatible = "shared-dma-pool"; + reg = <0 0xa1100000 0 0xf00000>; + no-map; + }; + + rtos_ipc_memory_region: ipc-memories@a2000000 { + reg = <0x00 0xa2000000 0x00 0x00200000>; + alignment = <0x1000>; + no-map; + }; + }; + + leds { + compatible = "gpio-leds"; + pinctrl-names = "default"; + pinctrl-0 = <&leds_pins_default>; + + status-led-red { + gpios = <&wkup_gpio0 32 GPIO_ACTIVE_HIGH>; + panic-indicator; + }; + + status-led-green { + gpios = <&wkup_gpio0 24 GPIO_ACTIVE_HIGH>; + }; + + user-led1-red { + gpios = <&pcal9535_3 14 GPIO_ACTIVE_HIGH>; + }; + + user-led1-green { + gpios = <&pcal9535_2 15 GPIO_ACTIVE_HIGH>; + }; + + user-led2-red { + gpios = <&wkup_gpio0 17 GPIO_ACTIVE_HIGH>; + }; + + user-led2-green { + gpios = <&wkup_gpio0 22 GPIO_ACTIVE_HIGH>; + }; + }; + + dp_refclk: clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <19200000>; + }; +}; + +&wkup_pmx0 { + wkup_i2c0_pins_default: wkup-i2c0-pins-default { + pinctrl-single,pins = < + /* (AC7) WKUP_I2C0_SCL */ + AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT, 0) + /* (AD6) WKUP_I2C0_SDA */ + AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT, 0) + >; + }; + + mcu_i2c0_pins_default: mcu-i2c0-pins-default { + pinctrl-single,pins = < + /* (AD8) MCU_I2C0_SCL */ + AM65X_WKUP_IOPAD(0x00e8, PIN_INPUT, 0) + /* (AD7) MCU_I2C0_SDA */ + AM65X_WKUP_IOPAD(0x00ec, PIN_INPUT, 0) + >; + }; + + arduino_i2c_aio_switch_pins_default: arduino-i2c-aio-switch-pins-default { + pinctrl-single,pins = < + /* (R2) WKUP_GPIO0_21 */ + AM65X_WKUP_IOPAD(0x0024, PIN_OUTPUT, 7) + >; + }; + + push_button_pins_default: push-button-pins-default { + pinctrl-single,pins = < + /* (T1) MCU_OSPI1_CLK.WKUP_GPIO0_25 */ + AM65X_WKUP_IOPAD(0x0034, PIN_INPUT, 7) + >; + }; + + arduino_uart_pins_default: arduino-uart-pins-default { + pinctrl-single,pins = < + /* (P4) MCU_UART0_RXD */ + AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4) + /* (P5) MCU_UART0_TXD */ + AM65X_WKUP_IOPAD(0x0048, PIN_OUTPUT, 4) + >; + }; + + arduino_io_d2_to_d3_pins_default: arduino-io-d2-to-d3-pins-default { + pinctrl-single,pins = < + /* (P1) WKUP_GPIO0_31 */ + AM65X_WKUP_IOPAD(0x004C, PIN_OUTPUT, 7) + /* (N3) WKUP_GPIO0_33 */ + AM65X_WKUP_IOPAD(0x0054, PIN_OUTPUT, 7) + >; + }; + + arduino_io_oe_pins_default: arduino-io-oe-pins-default { + pinctrl-single,pins = < + /* (N4) WKUP_GPIO0_34 */ + AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT, 7) + /* (M2) WKUP_GPIO0_36 */ + AM65X_WKUP_IOPAD(0x0060, PIN_OUTPUT, 7) + /* (M3) WKUP_GPIO0_37 */ + AM65X_WKUP_IOPAD(0x0064, PIN_OUTPUT, 7) + /* (M4) WKUP_GPIO0_38 */ + AM65X_WKUP_IOPAD(0x0068, PIN_OUTPUT, 7) + /* (M1) WKUP_GPIO0_41 */ + AM65X_WKUP_IOPAD(0x0074, PIN_OUTPUT, 7) + >; + }; + + mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-pins-default { + pinctrl-single,pins = < + /* (V1) MCU_OSPI0_CLK */ + AM65X_WKUP_IOPAD(0x0000, PIN_OUTPUT, 0) + /* (U2) MCU_OSPI0_DQS */ + AM65X_WKUP_IOPAD(0x0008, PIN_INPUT, 0) + /* (U4) MCU_OSPI0_D0 */ + AM65X_WKUP_IOPAD(0x000c, PIN_INPUT, 0) + /* (U5) MCU_OSPI0_D1 */ + AM65X_WKUP_IOPAD(0x0010, PIN_INPUT, 0) + /* (R4) MCU_OSPI0_CSn0 */ + AM65X_WKUP_IOPAD(0x002c, PIN_OUTPUT, 0) + >; + }; + + db9_com_mode_pins_default: db9-com-mode-pins-default { + pinctrl-single,pins = < + /* (AD3) WKUP_GPIO0_5, used as uart0 mode 0 */ + AM65X_WKUP_IOPAD(0x00c4, PIN_OUTPUT, 7) + /* (AC3) WKUP_GPIO0_4, used as uart0 mode 1 */ + AM65X_WKUP_IOPAD(0x00c0, PIN_OUTPUT, 7) + /* (AC1) WKUP_GPIO0_7, used as uart0 term */ + AM65X_WKUP_IOPAD(0x00cc, PIN_OUTPUT, 7) + /* (AC2) WKUP_GPIO0_6, used as uart0 en */ + AM65X_WKUP_IOPAD(0x00c8, PIN_OUTPUT, 7) + >; + }; + + leds_pins_default: leds-pins-default { + pinctrl-single,pins = < + /* (T2) WKUP_GPIO0_17, used as user led1 red */ + AM65X_WKUP_IOPAD(0x0014, PIN_OUTPUT, 7) + /* (R3) WKUP_GPIO0_22, used as user led1 green */ + AM65X_WKUP_IOPAD(0x0028, PIN_OUTPUT, 7) + /* (R5) WKUP_GPIO0_24, used as status led red */ + AM65X_WKUP_IOPAD(0x0030, PIN_OUTPUT, 7) + /* (N2) WKUP_GPIO0_32, used as status led green */ + AM65X_WKUP_IOPAD(0x0050, PIN_OUTPUT, 7) + >; + }; + + mcu_spi0_pins_default: mcu-spi0-pins-default { + pinctrl-single,pins = < + /* (Y1) MCU_SPI0_CLK */ + AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 0) + /* (Y3) MCU_SPI0_D0 */ + AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 0) + /* (Y2) MCU_SPI0_D1 */ + AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 0) + /* (Y4) MCU_SPI0_CS0 */ + AM65X_WKUP_IOPAD(0x009c, PIN_OUTPUT, 0) + >; + }; + + minipcie_pins_default: minipcie-pins-default { + pinctrl-single,pins = < + /* (P2) MCU_OSPI1_DQS.WKUP_GPIO0_27 */ + AM65X_WKUP_IOPAD(0x003C, PIN_OUTPUT, 7) + >; + }; +}; + +&main_pmx0 { + main_uart1_pins_default: main-uart1-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x0174, PIN_INPUT, 6) /* (AE23) UART1_RXD */ + AM65X_IOPAD(0x014c, PIN_OUTPUT, 6) /* (AD23) UART1_TXD */ + AM65X_IOPAD(0x0178, PIN_INPUT, 6) /* (AD22) UART1_CTSn */ + AM65X_IOPAD(0x017c, PIN_OUTPUT, 6) /* (AC21) UART1_RTSn */ + >; + }; + + main_i2c3_pins_default: main-i2c3-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x01c0, PIN_INPUT, 2) /* (AF13) I2C3_SCL */ + AM65X_IOPAD(0x01d4, PIN_INPUT, 2) /* (AG12) I2C3_SDA */ + >; + }; + + main_mmc1_pins_default: main-mmc1-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x02d4, PIN_INPUT_PULLDOWN, 0) /* (C27) MMC1_CLK */ + AM65X_IOPAD(0x02d8, PIN_INPUT_PULLUP, 0) /* (C28) MMC1_CMD */ + AM65X_IOPAD(0x02d0, PIN_INPUT_PULLUP, 0) /* (D28) MMC1_DAT0 */ + AM65X_IOPAD(0x02cc, PIN_INPUT_PULLUP, 0) /* (E27) MMC1_DAT1 */ + AM65X_IOPAD(0x02c8, PIN_INPUT_PULLUP, 0) /* (D26) MMC1_DAT2 */ + AM65X_IOPAD(0x02c4, PIN_INPUT_PULLUP, 0) /* (D27) MMC1_DAT3 */ + AM65X_IOPAD(0x02dc, PIN_INPUT_PULLUP, 0) /* (B24) MMC1_SDCD */ + AM65X_IOPAD(0x02e0, PIN_INPUT_PULLUP, 0) /* (C24) MMC1_SDWP */ + >; + }; + + usb0_pins_default: usb0-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x02bc, PIN_OUTPUT, 0) /* (AD9) USB0_DRVVBUS */ + >; + }; + + usb1_pins_default: usb1-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x02c0, PIN_OUTPUT, 0) /* (AC8) USB1_DRVVBUS */ + >; + }; + + arduino_io_d4_to_d9_pins_default: arduino-io-d4-to-d9-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x0084, PIN_OUTPUT, 7) /* (AG18) GPIO0_33 */ + AM65X_IOPAD(0x008C, PIN_OUTPUT, 7) /* (AF17) GPIO0_35 */ + AM65X_IOPAD(0x0098, PIN_OUTPUT, 7) /* (AH16) GPIO0_38 */ + AM65X_IOPAD(0x00AC, PIN_OUTPUT, 7) /* (AH15) GPIO0_43 */ + AM65X_IOPAD(0x00C0, PIN_OUTPUT, 7) /* (AG15) GPIO0_48 */ + AM65X_IOPAD(0x00CC, PIN_OUTPUT, 7) /* (AD15) GPIO0_51 */ + >; + }; + + dss_vout1_pins_default: dss-vout1-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x0000, PIN_OUTPUT, 1) /* VOUT1_DATA0 */ + AM65X_IOPAD(0x0004, PIN_OUTPUT, 1) /* VOUT1_DATA1 */ + AM65X_IOPAD(0x0008, PIN_OUTPUT, 1) /* VOUT1_DATA2 */ + AM65X_IOPAD(0x000c, PIN_OUTPUT, 1) /* VOUT1_DATA3 */ + AM65X_IOPAD(0x0010, PIN_OUTPUT, 1) /* VOUT1_DATA4 */ + AM65X_IOPAD(0x0014, PIN_OUTPUT, 1) /* VOUT1_DATA5 */ + AM65X_IOPAD(0x0018, PIN_OUTPUT, 1) /* VOUT1_DATA6 */ + AM65X_IOPAD(0x001c, PIN_OUTPUT, 1) /* VOUT1_DATA7 */ + AM65X_IOPAD(0x0020, PIN_OUTPUT, 1) /* VOUT1_DATA8 */ + AM65X_IOPAD(0x0024, PIN_OUTPUT, 1) /* VOUT1_DATA9 */ + AM65X_IOPAD(0x0028, PIN_OUTPUT, 1) /* VOUT1_DATA10 */ + AM65X_IOPAD(0x002c, PIN_OUTPUT, 1) /* VOUT1_DATA11 */ + AM65X_IOPAD(0x0030, PIN_OUTPUT, 1) /* VOUT1_DATA12 */ + AM65X_IOPAD(0x0034, PIN_OUTPUT, 1) /* VOUT1_DATA13 */ + AM65X_IOPAD(0x0038, PIN_OUTPUT, 1) /* VOUT1_DATA14 */ + AM65X_IOPAD(0x003c, PIN_OUTPUT, 1) /* VOUT1_DATA15 */ + AM65X_IOPAD(0x0040, PIN_OUTPUT, 1) /* VOUT1_DATA16 */ + AM65X_IOPAD(0x0044, PIN_OUTPUT, 1) /* VOUT1_DATA17 */ + AM65X_IOPAD(0x0048, PIN_OUTPUT, 1) /* VOUT1_DATA18 */ + AM65X_IOPAD(0x004c, PIN_OUTPUT, 1) /* VOUT1_DATA19 */ + AM65X_IOPAD(0x0050, PIN_OUTPUT, 1) /* VOUT1_DATA20 */ + AM65X_IOPAD(0x0054, PIN_OUTPUT, 1) /* VOUT1_DATA21 */ + AM65X_IOPAD(0x0058, PIN_OUTPUT, 1) /* VOUT1_DATA22 */ + AM65X_IOPAD(0x005c, PIN_OUTPUT, 1) /* VOUT1_DATA23 */ + AM65X_IOPAD(0x0060, PIN_OUTPUT, 1) /* VOUT1_VSYNC */ + AM65X_IOPAD(0x0064, PIN_OUTPUT, 1) /* VOUT1_HSYNC */ + AM65X_IOPAD(0x0068, PIN_OUTPUT, 1) /* VOUT1_PCLK */ + AM65X_IOPAD(0x006c, PIN_OUTPUT, 1) /* VOUT1_DE */ + >; + }; + + dp_pins_default: dp-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x0078, PIN_OUTPUT, 7) /* (AF18) DP rst_n */ + >; + }; + + main_i2c2_pins_default: main-i2c2-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x0074, PIN_INPUT, 5) /* (T27) I2C2_SCL */ + AM65X_IOPAD(0x0070, PIN_INPUT, 5) /* (R25) I2C2_SDA */ + >; + }; +}; + +&main_pmx1 { + main_i2c0_pins_default: main-i2c0-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x0000, PIN_INPUT, 0) /* (D20) I2C0_SCL */ + AM65X_IOPAD(0x0004, PIN_INPUT, 0) /* (C21) I2C0_SDA */ + >; + }; + + main_i2c1_pins_default: main-i2c1-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x0008, PIN_INPUT, 0) /* (B21) I2C1_SCL */ + AM65X_IOPAD(0x000c, PIN_INPUT, 0) /* (E21) I2C1_SDA */ + >; + }; + + ecap0_pins_default: ecap0-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x0010, PIN_INPUT, 0) /* (D21) ECAP0_IN_APWM_OUT */ + >; + }; +}; + +&wkup_uart0 { + /* Wakeup UART is used by System firmware */ + status = "reserved"; +}; + +&main_uart1 { + pinctrl-names = "default"; + pinctrl-0 = <&main_uart1_pins_default>; +}; + +&main_uart2 { + status = "disabled"; +}; + +&mcu_uart0 { + pinctrl-names = "default"; + pinctrl-0 = <&arduino_uart_pins_default>; +}; + +&main_gpio0 { + pinctrl-names = "default"; + pinctrl-0 = <&arduino_io_d4_to_d9_pins_default>; + gpio-line-names = + "main_gpio0-base", "", "", "", "", "", "", "", "", "", + "", "", "", "", "", "", "", "", "", "", + "", "", "", "", "", "", "", "", "", "", + "", "", "", "IO4", "", "IO5", "", "", "IO6", "", + "", "", "", "IO7", "", "", "", "", "IO8", "", + "", "IO9"; +}; + +&wkup_gpio0 { + pinctrl-names = "default"; + pinctrl-0 = < + &arduino_io_d2_to_d3_pins_default + &arduino_i2c_aio_switch_pins_default + &arduino_io_oe_pins_default + &push_button_pins_default + &db9_com_mode_pins_default + >; + gpio-line-names = + /* 0..9 */ + "wkup_gpio0-base", "", "", "", "UART0-mode1", "UART0-mode0", + "UART0-enable", "UART0-terminate", "", "WIFI-disable", + /* 10..19 */ + "", "", "", "", "", "", "", "", "", "", + /* 20..29 */ + "", "A4A5-I2C-mux", "", "", "", "USER-button", "", "", "","IO0", + /* 30..39 */ + "IO1", "IO2", "", "IO3", "IO17-direction", "A5", + "IO16-direction", "IO15-direction", "IO14-direction", "A3", + /* 40..49 */ + "", "IO18-direction", "A4", "A2", "A1", "A0", "", "", "IO13", + "IO11", + /* 50..51 */ + "IO12", "IO10"; +}; + +&wkup_i2c0 { + pinctrl-names = "default"; + pinctrl-0 = <&wkup_i2c0_pins_default>; + clock-frequency = <400000>; +}; + +&mcu_i2c0 { + pinctrl-names = "default"; + pinctrl-0 = <&mcu_i2c0_pins_default>; + clock-frequency = <400000>; + + psu: regulator@60 { + compatible = "ti,tps62363"; + reg = <0x60>; + regulator-name = "tps62363-vout"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + ti,vsel0-state-high; + ti,vsel1-state-high; + ti,enable-vout-discharge; + }; + + /* D4200 */ + pcal9535_1: gpio@20 { + compatible = "nxp,pcal9535"; + reg = <0x20>; + #gpio-cells = <2>; + gpio-controller; + gpio-line-names = + "A0-pull", "A1-pull", "A2-pull", "A3-pull", "A4-pull", + "A5-pull", "", "", + "IO14-enable", "IO15-enable", "IO16-enable", + "IO17-enable", "IO18-enable", "IO19-enable"; + }; + + /* D4201 */ + pcal9535_2: gpio@21 { + compatible = "nxp,pcal9535"; + reg = <0x21>; + #gpio-cells = <2>; + gpio-controller; + gpio-line-names = + "IO0-direction", "IO1-direction", "IO2-direction", + "IO3-direction", "IO4-direction", "IO5-direction", + "IO6-direction", "IO7-direction", + "IO8-direction", "IO9-direction", "IO10-direction", + "IO11-direction", "IO12-direction", "IO13-direction", + "IO19-direction"; + }; + + /* D4202 */ + pcal9535_3: gpio@25 { + compatible = "nxp,pcal9535"; + reg = <0x25>; + #gpio-cells = <2>; + gpio-controller; + gpio-line-names = + "IO0-pull", "IO1-pull", "IO2-pull", "IO3-pull", + "IO4-pull", "IO5-pull", "IO6-pull", "IO7-pull", + "IO8-pull", "IO9-pull", "IO10-pull", "IO11-pull", + "IO12-pull", "IO13-pull"; + }; +}; + +&main_i2c0 { + pinctrl-names = "default"; + pinctrl-0 = <&main_i2c0_pins_default>; + clock-frequency = <400000>; + + rtc: rtc8564@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + }; + + eeprom: eeprom@54 { + compatible = "atmel,24c08"; + reg = <0x54>; + pagesize = <16>; + }; +}; + +&main_i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&main_i2c1_pins_default>; + clock-frequency = <400000>; +}; + +&main_i2c2 { + pinctrl-names = "default"; + pinctrl-0 = <&main_i2c2_pins_default>; + clock-frequency = <400000>; +}; + +&main_i2c3 { + pinctrl-names = "default"; + pinctrl-0 = <&main_i2c3_pins_default>; + clock-frequency = <400000>; + + #address-cells = <1>; + #size-cells = <0>; + + edp-bridge@f { + compatible = "toshiba,tc358767"; + reg = <0x0f>; + pinctrl-names = "default"; + pinctrl-0 = <&dp_pins_default>; + reset-gpios = <&main_gpio0 30 GPIO_ACTIVE_HIGH>; + + clock-names = "ref"; + clocks = <&dp_refclk>; + + toshiba,hpd-pin = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + + bridge_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + }; + }; +}; + +&mcu_cpsw { + status = "disabled"; +}; + +&ecap0 { + pinctrl-names = "default"; + pinctrl-0 = <&ecap0_pins_default>; +}; + +&sdhci1 { + pinctrl-names = "default"; + pinctrl-0 = <&main_mmc1_pins_default>; + ti,driver-strength-ohm = <50>; + disable-wp; +}; + +&usb0 { + pinctrl-names = "default"; + pinctrl-0 = <&usb0_pins_default>; + dr_mode = "host"; +}; + +&usb1 { + pinctrl-names = "default"; + pinctrl-0 = <&usb1_pins_default>; + dr_mode = "host"; +}; + +&mcu_spi0 { + pinctrl-names = "default"; + pinctrl-0 = <&mcu_spi0_pins_default>; + + #address-cells = <1>; + #size-cells= <0>; + ti,pindir-d0-out-d1-in = <1>; + + spidev@0 { + compatible = "rohm,dh2228fv"; + spi-max-frequency = <20000000>; + reg = <0>; + }; +}; + +&tscadc0 { + status = "disabled"; +}; + +&tscadc1 { + adc { + ti,adc-channels = <0 1 2 3 4 5>; + }; +}; + +&ospi0 { + pinctrl-names = "default"; + pinctrl-0 = <&mcu_fss0_ospi0_pins_default>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0x0>; + spi-tx-bus-width = <1>; + spi-rx-bus-width = <1>; + spi-max-frequency = <50000000>; + cdns,tshsl-ns = <60>; + cdns,tsd2d-ns = <60>; + cdns,tchsh-ns = <60>; + cdns,tslch-ns = <60>; + cdns,read-delay = <2>; + #address-cells = <1>; + #size-cells = <1>; + }; +}; + +&dss { + pinctrl-names = "default"; + pinctrl-0 = <&dss_vout1_pins_default>; + + assigned-clocks = <&k3_clks 67 2>; + assigned-clock-parents = <&k3_clks 67 5>; +}; + +&dss_ports { + #address-cells = <1>; + #size-cells = <0>; + port@1 { + reg = <1>; + + dpi_out: endpoint { + remote-endpoint = <&bridge_in>; + }; + }; +}; + +&serdes0 { + status = "disabled"; +}; + +&pcie0_rc { + status = "disabled"; +}; + +&pcie0_ep { + status = "disabled"; +}; + +&pcie1_rc { + pinctrl-names = "default"; + pinctrl-0 = <&minipcie_pins_default>; + + num-lanes = <1>; + phys = <&serdes1 PHY_TYPE_PCIE 0>; + phy-names = "pcie-phy0"; + reset-gpios = <&wkup_gpio0 27 GPIO_ACTIVE_HIGH>; +}; + +&pcie1_ep { + status = "disabled"; +}; diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts new file mode 100644 index 000000000000..4f7e3f2a6265 --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts @@ -0,0 +1,61 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) Siemens AG, 2018-2021 + * + * Authors: + * Le Jin <le.jin@siemens.com> + * Jan Kiszka <jan.kiszk@siemens.com> + * + * AM6528-based (dual-core) IOT2050 Basic variant + * 1 GB RAM, no eMMC, main_uart0 on connector X30 + */ + +/dts-v1/; + +#include "k3-am65-iot2050-common.dtsi" + +/ { + compatible = "siemens,iot2050-basic", "ti,am654"; + model = "SIMATIC IOT2050 Basic"; + + memory@80000000 { + device_type = "memory"; + /* 1G RAM */ + reg = <0x00000000 0x80000000 0x00000000 0x40000000>; + }; + + cpus { + cpu-map { + /delete-node/ cluster1; + }; + /delete-node/ cpu@100; + /delete-node/ cpu@101; + }; + + /delete-node/ l2-cache1; +}; + +/* eMMC */ +&sdhci0 { + status = "disabled"; +}; + +&main_pmx0 { + main_uart0_pins_default: main-uart0-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x01e4, PIN_INPUT, 0) /* (AF11) UART0_RXD */ + AM65X_IOPAD(0x01e8, PIN_OUTPUT, 0) /* (AE11) UART0_TXD */ + AM65X_IOPAD(0x01ec, PIN_INPUT, 0) /* (AG11) UART0_CTSn */ + AM65X_IOPAD(0x01f0, PIN_OUTPUT, 0) /* (AD11) UART0_RTSn */ + AM65X_IOPAD(0x0188, PIN_INPUT, 1) /* (D25) UART0_DCDn */ + AM65X_IOPAD(0x018c, PIN_INPUT, 1) /* (B26) UART0_DSRn */ + AM65X_IOPAD(0x0190, PIN_OUTPUT, 1) /* (A24) UART0_DTRn */ + AM65X_IOPAD(0x0194, PIN_INPUT, 1) /* (E24) UART0_RIN */ + >; + }; +}; + +&main_uart0 { + pinctrl-names = "default"; + pinctrl-0 = <&main_uart0_pins_default>; +}; diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts new file mode 100644 index 000000000000..ec9617c13cdb --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts @@ -0,0 +1,60 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) Siemens AG, 2018-2021 + * + * Authors: + * Le Jin <le.jin@siemens.com> + * Jan Kiszka <jan.kiszk@siemens.com> + * + * AM6548-based (quad-core) IOT2050 Advanced variant + * 2 GB RAM, 16 GB eMMC, USB-serial converter on connector X30 + */ + +/dts-v1/; + +#include "k3-am65-iot2050-common.dtsi" + +/ { + compatible = "siemens,iot2050-advanced", "ti,am654"; + model = "SIMATIC IOT2050 Advanced"; + + memory@80000000 { + device_type = "memory"; + /* 2G RAM */ + reg = <0x00000000 0x80000000 0x00000000 0x80000000>; + }; +}; + +&main_pmx0 { + main_mmc0_pins_default: main-mmc0-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x01a8, PIN_INPUT_PULLDOWN, 0) /* (B25) MMC0_CLK */ + AM65X_IOPAD(0x01ac, PIN_INPUT_PULLUP, 0) /* (B27) MMC0_CMD */ + AM65X_IOPAD(0x01a4, PIN_INPUT_PULLUP, 0) /* (A26) MMC0_DAT0 */ + AM65X_IOPAD(0x01a0, PIN_INPUT_PULLUP, 0) /* (E25) MMC0_DAT1 */ + AM65X_IOPAD(0x019c, PIN_INPUT_PULLUP, 0) /* (C26) MMC0_DAT2 */ + AM65X_IOPAD(0x0198, PIN_INPUT_PULLUP, 0) /* (A25) MMC0_DAT3 */ + AM65X_IOPAD(0x0194, PIN_INPUT_PULLUP, 0) /* (E24) MMC0_DAT4 */ + AM65X_IOPAD(0x0190, PIN_INPUT_PULLUP, 0) /* (A24) MMC0_DAT5 */ + AM65X_IOPAD(0x018c, PIN_INPUT_PULLUP, 0) /* (B26) MMC0_DAT6 */ + AM65X_IOPAD(0x0188, PIN_INPUT_PULLUP, 0) /* (D25) MMC0_DAT7 */ + AM65X_IOPAD(0x01b8, PIN_OUTPUT_PULLUP, 7) /* (B23) MMC0_SDWP */ + AM65X_IOPAD(0x01b4, PIN_INPUT_PULLUP, 0) /* (A23) MMC0_SDCD */ + AM65X_IOPAD(0x01b0, PIN_INPUT, 0) /* (C25) MMC0_DS */ + >; + }; +}; + +/* eMMC */ +&sdhci0 { + pinctrl-names = "default"; + pinctrl-0 = <&main_mmc0_pins_default>; + bus-width = <8>; + non-removable; + ti,driver-strength-ohm = <50>; + disable-wp; +}; + +&main_uart0 { + status = "disabled"; +};