On Tue, Oct 13, 2015 at 09:26:24PM +0300, Grygorii Strashko wrote: > I think You might need to check pin muxing in DT-file. if you have smth like > > dss_dpi_pins_cm_t35x: pinmux_dss_dpi_pins_cm_t35x { > pinctrl-single,pins = < > OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */ > OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */ > > ^^^^^ it will not work as gpio. > > OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */ > OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */ > OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */ > OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */ > >; > }; It is not there as proven in very first mail reading mux register value CONTROL_PADCONF_DSS_DATA0 0x480020DC: 0x1040104 Turned out to be hardware problem, scheme I have does not match PCB - device controled by GPIO 71 is actually powered by VSDI_CSI (vpll2), but on scheme there is line directly from power supply. And as 2.6.37 does not disable regulator it worked there. Shame on me and sorry for the noise. Regards, ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html