Re: [PATCH 1/4] ARM: dts: omap3-pandora: add common device tree

[Dr. H. Nikolaus Schaller]

Am 12.02.2015 um 17:03 schrieb Tony Lindgren <tony@xxxxxxxxxxx>:

> Hi,
> 
> Few comments below.
> 
> * Marek Belisko <marek@xxxxxxxxxxxxx> [150212 05:07]:
>> +
>> +&omap3_pmx_core {
>> +
>> +	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 */
>> +		>;
> ...
> 
>> +&omap3_pmx_core2 {
>> +	/* define in CPU specific file that includes this one
>> +	 * use either OMAP3430_CORE2_IOPAD() or OMAP3630_CORE2_IOPAD()
>> +	 */
>> +};
> 
> OK looks like you have some SoC specific pins too.. I assume you
> guys have checked that all the pins defined in this file are at
> the same offset between 34xx and 36xx variants?

Yes. All in this file are common between 34xx and 36xx.
The 600mhz / 1ghz files cover the differences for pmx_core2 through the different macros
(OMAP3430_CORE2_IOPAD vs. OMAP3460_CORE2_IOPAD).

> 
>> +&i2c1 {
>> +	clock-frequency = <2600000>;
>> +
>> +	twl: twl@48 {
>> +		reg = <0x48>;
>> +		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>> +		interrupt-parent = <&intc>;
>> +
>> +		twl_power: power {
>> +			compatible = "ti,twl4030-power-reset";
>> +			ti,use_poweroff;
>> +		};
>> +
>> +		twl_audio: audio {
>> +			compatible = "ti,twl4030-audio";
>> +
>> +			codec {
>> +				ti,ramp_delay_value = <3>;
>> +			};
>> +		};
>> +	};
>> +};
> 
> Can be done later naturally, but ere you probably want
> ti,twl4030-power-idle or ti,twl4030-power-idle-osc-off
> if the osicllator can be shut down during off-idle.

Good hint. We have to check and test if it can be shut down.
But as said, this is just the beginning of DT support.

> 
>> +&gpmc {
>> +	ranges = <0 0 0x30000000 0x04>; /* CS0: NAND */
> 
> The ranges here allocate the GPMC partition, so it needs to be
> a minimum of 16MB:
> 
> 	ranges = <0 0 0x30000000 0x1000000>,	/* CS0: 16MB for NAND */
> 
>> +	nand@0,0 {
>> +		reg = <0 0 0>; /* CS0, offset 0 */
> 
> The reg is for the device driver to ioremap it's registers,
> for NAND it's just 4:
> 
> 		reg = <0 0 4>;	/* CS0, offset 0, IO size 4 */

Ok, that was a typo and we have not tested how compatible it is to the
board file scheme.

> 
>> +		filesystem@680000 {
>> +			label = "rootfs";
>> +			reg = <0xc80000 0>;	/* 0 = MTDPART_SIZ_FULL */
>> +		};
>> +	};
>> +};
> 
> Is the NAND the same size on all of them?

AFAIK not necessarily.

> I don't think dts
> has a binding for MTDPART_SIZ_FULL type thing..

It does not need a special binding, we just set the size to 0. This
is interpreted as MTDPART_SIZ_FULL later on. For board files,
there is just a #define in include/linux/mtd/partitions.h and it appears
to work.

> 
>> +	lcd: lcd@1 {
>> +		reg = <1>;	/* CS1 */
>> +		compatible =	"omapdss,tpo,td043mtea1";
>> +		spi-max-frequency = <100000>;
>> +		spi-cpol;
>> +		spi-cpha;
>> +
>> +		label = "lcd";
>> +		reset-gpios = <&gpio5 29 GPIO_ACTIVE_LOW>;	/* GPIO_157 */
>> +		vcc-supply = <&vaux1>;
>> +
>> +		port {
>> +			lcd_in: endpoint {
>> +				remote-endpoint = <&dpi_out>;
>> +			};
>> +		};
>> +	};
> 
> Oh there's already a binding for the LCD too? That’s great :)

Yes, we were happy to find that the panel driver has already been upgraded
for DT use.

> 
> Nine job, good to see this happening!
> 
> Regards,
> 
> 
> Tony

BR,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/