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 devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
