Re: [PATCH] ARM: dts: Add support for Liebherr's BK4 device (vf610 based)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 21, 2018 at 12:27 PM, Lukasz Majewski <lukma@xxxxxxx> wrote:
> This commit adds DTS support for BK4 device from Liebherr. It
> uses vf610 SoC from NXP.
>
> Signed-off-by: Lukasz Majewski <lukma@xxxxxxx>
> ---
>  arch/arm/boot/dts/Makefile      |   1 +
>  arch/arm/boot/dts/vf610-bk4.dts | 504 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 505 insertions(+)
>  create mode 100644 arch/arm/boot/dts/vf610-bk4.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b5bd3de87c33..e6f159895fa9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -577,6 +577,7 @@ dtb-$(CONFIG_SOC_LS1021A) += \
>         ls1021a-twr.dtb
>  dtb-$(CONFIG_SOC_VF610) += \
>         vf500-colibri-eval-v3.dtb \
> +       vf610-bk4.dtb \
>         vf610-colibri-eval-v3.dtb \
>         vf610m4-colibri.dtb \
>         vf610-cosmic.dtb \
> diff --git a/arch/arm/boot/dts/vf610-bk4.dts b/arch/arm/boot/dts/vf610-bk4.dts
> new file mode 100644
> index 000000000000..4ad7e739a0ad
> --- /dev/null
> +++ b/arch/arm/boot/dts/vf610-bk4.dts
> @@ -0,0 +1,504 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lukma@xxxxxxx
> + */
> +
> +/dts-v1/;
> +#include "vf610.dtsi"
> +
> +/ {
> +       model = "Liebherr BK4 controller";
> +       compatible = "lwn,bk4", "fsl,vf610";
> +
> +       chosen {
> +               bootargs = "console=ttyLP1,115200";

You could pass stdout-path instead.

> +       };
> +
> +       memory@80000000 {
> +               reg = <0x80000000 0x8000000>;
> +       };
> +
> +       audio_ext: mclk_osc {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <24576000>;
> +       };

This seems to be unused.

> +
> +       enet_ext: eth_osc {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <50000000>;
> +       };
> +
> +       leds {
> +               compatible = "gpio-leds";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_gpio_leds>;
> +
> +               /* LED D5 */
> +               led0: heartbeat {
> +                       label = "heartbeat";
> +                       gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> +                       default-state = "on";
> +                       linux,default-trigger = "heartbeat";
> +               };
> +       };
> +
> +       regulators {
> +               compatible = "simple-bus";
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               reg_3p3v: regulator@0 {

Please move all regulators outside of the simple-bus container and use
this naming convention:

reg_3p3v: regulator-3p3v {

> +&dspi3 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_dspi3>;
> +       bus-num = <3>;
> +       status = "okay";
> +
> +       spidev3@0 {
> +               compatible = "fsl,vf610-dspi";
> +               spi-max-frequency = <30000000>;
> +               reg = <0>;
> +               fsl,spi-slave-mode;

Such property does not exist.

I also thought that spidev nodes in dt were not recommended.

> +&iomuxc {

Like Stefan mentioned it is common practice on imx dts files to place
the iomuxc node as the last one.


> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_bk4_common>;

This seems to be not called from any driver.

We usually use a hog group for such purpose.

> +
> +       pinctrl_bk4_common: commongrp {
> +               fsl,pins = <
> +                       /* One_Wire_PSU_EN */
> +                       VF610_PAD_PTC29__GPIO_102               0x1183
> +                       /* SPI */
> +                       VF610_PAD_PTB26__GPIO_96                0x1183
> +                       VF610_PAD_PTE14__GPIO_119               0x1183
> +                       VF610_PAD_PTE4__GPIO_109                0x1181
> +                       /* Feedback_Lines */
> +                       VF610_PAD_PTC31__GPIO_104               0x1181
> +                       VF610_PAD_PTA7__GPIO_134                0x1181
> +                       VF610_PAD_PTD9__GPIO_88         0x1181
> +                       VF610_PAD_PTE1__GPIO_106                0x1183
> +                       VF610_PAD_PTB2__GPIO_24         0x1181
> +                       VF610_PAD_PTB3__GPIO_25         0x1181
> +                       VF610_PAD_PTB1__GPIO_23         0x1181
> +                       /* SDHC */
> +                       VF610_PAD_PTE19__GPIO_124               0x1183
> +                       VF610_PAD_PTB23__GPIO_93                0x1181

If they are related to SDHC they should be better placed under the sdhc nodes.


> +                       /* GPI */
> +                       VF610_PAD_PTE2__GPIO_107                0x1181
> +                       VF610_PAD_PTE3__GPIO_108                0x1181
> +                       VF610_PAD_PTE5__GPIO_110                0x1181
> +                       VF610_PAD_PTE6__GPIO_111                0x1181
> +                       /* GPO */
> +                       VF610_PAD_PTE0__GPIO_105                0x1183
> +                       VF610_PAD_PTE7__GPIO_112                0x1183
> +                       /* RS485 */
> +                       VF610_PAD_PTB8__GPIO_30         0x1183
> +                       VF610_PAD_PTB9__GPIO_31         0x1183
> +                       VF610_PAD_PTE8__GPIO_113                0x1183
> +                       /* MPBUS MPB_EN */
> +                       VF610_PAD_PTE28__GPIO_133               0x1183
> +                       /* LEDS */
> +                       VF610_PAD_PTE15__GPIO_120               0x1183
> +                       VF610_PAD_PTA12__GPIO_5         0x1183
> +                       VF610_PAD_PTA16__GPIO_6         0x1183
> +                       VF610_PAD_PTE9__GPIO_114                0x1183
> +                       VF610_PAD_PTE20__GPIO_125               0x1183
> +                       VF610_PAD_PTE23__GPIO_128               0x1183
> +                       VF610_PAD_PTE16__GPIO_121               0x1183
> +                       /* MISC */
> +                       VF610_PAD_PTE10__GPIO_115               0x1183
> +                       VF610_PAD_PTE11__GPIO_116               0x1183
> +                       VF610_PAD_PTE17__GPIO_122               0x1183
> +                       VF610_PAD_PTC30__GPIO_103               0x1183
> +                       VF610_PAD_PTB0__GPIO_22         0x1181
> +                       /* RESETINFO */
> +                       VF610_PAD_PTE26__GPIO_131               0x1183
> +                       VF610_PAD_PTD6__GPIO_85         0x1181
> +                       VF610_PAD_PTE27__GPIO_132               0x1181
> +                       VF610_PAD_PTE13__GPIO_118               0x1181
> +                       VF610_PAD_PTE21__GPIO_126               0x1181
> +                       VF610_PAD_PTE22__GPIO_127               0x1181
> +                       /* EE_5V_EN */
> +                       VF610_PAD_PTE18__GPIO_123               0x1183
> +                       /* EE_5V_OC_N */
> +                       VF610_PAD_PTE25__GPIO_130               0x1181

Seems like a long list of pins without any driver associated.

Please review such list carefully and assign to nodes that have a
driver associated, such as rs485,LEDS, etc.

> +
> +&usbphy0 {
> +       status = "okay";
> +};
> +
> +&usbphy1 {
> +       status = "okay";
> +};
> +
> +&qspi0 {

This is not placed in alphabetical order.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux