Message-ID: <Y4P2UIBX8oYcmaZr@euler>
Date:   Sun, 27 Nov 2022 15:44:16 -0800
From:   Colin Foster <colin.foster@...advantage.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        Tony Lindgren <tony@...mide.com>,
        Benoît Cousson <bcousson@...libre.com>,
        soc@...nel.org, Olof Johansson <olof@...om.net>,
        Arnd Bergmann <arnd@...db.de>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v2 2/2] arm: dts: omap4: pcm959: add initial support for
 phytec pcm959

Hi Krzysztof,

I appreciate your feedback!

On Thu, Nov 24, 2022 at 12:57:48PM +0100, Krzysztof Kozlowski wrote:
> On 24/11/2022 00:32, Colin Foster wrote:
> > The Phytec PCM-959 is a development platform for the Phytec PCM-049 SOM.
> > Add initial functionality for the board. The verified interfaces and
> > peripherals are listed below for the SOM (PCM-049) and the dev board
> > (PCM-959)
> > 
> > The omap2plus_defconfig was used for testing. Only the On-board LEDs
> > required CONFIG_LEDS_PCA9532 addition.
> > 
> 
> Thank you for your patch. There is something to discuss/improve.
> 
> > +
> > +	reserved-memory {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		ranges;
> > +
> > +		dsp_memory_region: dsp-memory@...00000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x98000000 0x800000>;
> > +			reusable;
> > +			status = "okay";
> 
> Okay is by default, why adding it? Was it disabled in DTSI file?

No. This (and a lot of your points) are based on the fact that I mostly
started from omap4-panda-common.dtsi. I'll remove this and the one below
(and any others I come across, armed with this information).

> 
> > +		};
> > +
> > +		ipu_memory_region: ipu-memory@...00000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x98800000 0x7000000>;
> > +			reusable;
> > +			status = "okay";
> > +		};
> > +	};
> > +
> > +	chosen {
> > +		stdout-path = &uart3;
> > +	};
> > +
> > +	leds: leds {
> > +		compatible = "gpio-leds";
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <
> > +			&led_gpio_pins
> > +		>;
> 
> That's unusual syntax.
> 
> pinctrl-0 = <&led_gpio_pins>;

Noted. I'll fix it up. In the unlikely scenario that someone else tries
to support something similar to the OMAP4 pandaboard, it might be worth
sweeping through those .dts[,i] files and applying these suggestions.

> 
> 
> > +
> > +		led-0 {
> > +			label = "modul:red:status1";
> 
> You should rather use function and color. label is slowly getting
> deprecated.

Thanks for this info. I didn't know this.

For background, the naming was intended to remain consistent with the
vendor BSP, but there isn't _really_ a need for me to do that.

...

>+
> > +&omap4_pmx_wkup {
> > +	pinctrl-names = "default";
> > +	pinctrl-0= <
> > +		&smartreflex_i2c_pins
> > +		&fref_xtal_in_pins
> > +		&fref_clk3_out_pins
> > +		&sys_pins
> 
> Squash the lines.
> 
> > +	>;
...
> > +
> > +&i2c1 {
> > +	status = "okay";
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&i2c1_pins>;
> > +
> > +	clock-frequency = <400000>;
> > +
> > +	twl: twl@48 {
> 
> Node names should be generic.
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation

My apologies that you had to send this to me again. I'll make this
change here as well, noting it is another divergence from pandaboard
(which I understand is a good thing)

> 
> > +		compatible = "ti,twl6030";
> > +		reg = <0x48>;
> > +		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; /* IRQ_SYS_1N cascaded to gic */
> > +	};
> > +
> > +	core_vdd_reg: regulator@60 {
> > +		compatible = "ti,tps62361";
> > +		reg = <0x60>;
> > +
> > +		regulator-name = "tps62361-vout";
> > +		regulator-min-microvolt = <500000>;
> > +		regulator-max-microvolt = <1500000>;
> > +		regulator-coupled-max-spread = <300000>;
> > +		regulator-max-step-microvolt = <100000>;
> > +		regulator-boot-on;
> > +		regulator-always-on;
> > +		ti,vsel0-gpio = <&gpio5 22 GPIO_ACTIVE_HIGH>;
> > +		ti,vsel0-state-high;
> > +	};
> > +
> > +	temperature-sensor@4b {
> > +		compatible = "ti,tmp102";
> > +		reg = <0x4b>;
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_tempsense>;
> > +		interrupt-parent = <&gpio5>;
> > +		interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
> > +		#thermal-sensor-cells = <1>;
> > +	};
> > +
> > +	eeprom@50 {
> > +		compatible = "atmel,24c32";
> > +		reg = <0x50>;
> > +	};
> > +};
> > +
> > +#include "twl6030.dtsi"
> > +#include "twl6030_omap4.dtsi"
> 
> Includes are usually at beginning. Is it a convention for all OMAP DTSes
> to add it in the middle?

I thought it was curious as well. My hunch was these includes needed to
be after the twl node in order to resolve a reference earlier in the
file. I understand that to be incorrect... but thinking out loud maybe
that was the case for early implementations of DTC...?

I'll move it to the top and make sure it works. But yes, every .dts[i]
of the OMAP4 that use twl6030.dtsi all have these include near the end
of the file (omap4-sdp.dts, opam4-kc1.dts, omap4-var-som-om44.dtsi,
omap4-panda-common.dtsi, omap4-duovero.dtsi). "twl" node names... etc.

...

>> +
> > +&gpmc {
> > +	ranges = <5 0 0x2c000000 0x01000000>,
> > +		 <0 0 0x08000000 0x01000000>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <
> > +		&gpmc_pins
> > +		>;
> 
> Merge/squash lines.

Ack

...
> > diff --git a/arch/arm/boot/dts/omap4-phytec-pcm-959.dts b/arch/arm/boot/dts/omap4-phytec-pcm-959.dts
> > new file mode 100644
> > index 000000000000..f323d64660d7
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/omap4-phytec-pcm-959.dts
> > @@ -0,0 +1,48 @@
...
> > +
> > +		led-4 {
> > +			label = "board:green:free_use4";
> > +			linux,default-trigger = "none";
> > +			type = <PCA9532_TYPE_LED>;
> > +		};
> > +	};
> > +};
> > +
> 
> Drop trailing new line.

Ack

> 
> 
> Best regards,
> Krzysztof
> 

Powered by blists - more mailing lists