Questions about DSS device tree adaptation

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

 



Hi,

I'd like to get some feedback for the DSS DT work.

I have currently this in omap4.dtsi, under ocp. It's still a hack, for
example there's sdi for testing even though omap4 doesn't have SDI
output.

dss {
	compatible = "ti,omap4-dss";
	ti,hwmods = "dss_core";
                                               
	dispc {
		compatible = "ti,omap4-dispc";
		ti,hwmods = "dss_dispc";
	};
                                               
	dpi: dpi {
		compatible = "ti,omap4-dpi";
	};
                                               
	sdi: sdi {
		compatible = "ti,omap3-sdi";
	};
                                               
	dsi1: dsi@1 {
		compatible = "ti,omap4-dsi";
		ti,hwmods = "dss_dsi1";
		id = <0>;
		vdds_dsi-supply = <&vcxio>;
	};
                                               
	dsi2: dsi@2 {
		compatible = "ti,omap4-dsi";
		ti,hwmods = "dss_dsi2";
		id = <1>;
		vdds_dsi-supply = <&vcxio>;
	};
                                               
	hdmi {
		compatible = "ti,omap4-hdmi";
		ti,hwmods = "dss_hdmi";
                                               
		hpd_gpio = <0>;
		ls_oe = <0>;
	};
                                               
	rfbi: rfbi {
		compatible = "ti,omap4-rfbi";
		ti,hwmods = "dss_rfbi";
	};
                                               
	venc {
		compatible = "ti,omap4-venc";
		ti,hwmods = "dss_venc";
	};
};

And in omap4-panda.dtsi I have:

&dpi {
	dvi {
		compatible = "ti,tfp410";
		data-lines = <24>;
		channel = <2>;
		enable-gpio = <0>;
		ddc = <&dviddc>;
	};
};


A few notes/questions about the above:

dispc is not an output interface (so it won't have any children), it
doesn't have anything to customize in the dt data, and it's present on
all OMAPs. Should it still be present in the DT data, or should the
device be created dynamically in platform code?

dpi and sdi are not hwmods as the rest of the nodes. They are, from HW
point of view, more or less parts of DSS or perhaps DISPC.

dsi nodes have the id property, which is used by the driver to choose
between DSI1 and DSI2 HW modules. Is there a better way to do this than
a custom property?

Who/where/when should the devices for dss submodules be created? The
device for dss-node is created automatically by the of-platform code(?),
but the rest of the submodules need to be handled by me somehow.

I'm currently using of_platform_populate() in the probe of ti,omap4-dss
driver to create the subdevices, but this approach doesn't feel right.
Shouldn't the devices be created already at the boot time by platform
code, not by the driver code?

Is the "simple-bus", that ocp node also uses, something that I could use
here? If I define the dss node to be compatible with simple-bus also,
does it mean that the of-platform code creates the submodules for me?
Are there any side-effects?

How about the actual panel devices. Above there's the "ti,tfp410"
device. The panel devices are not plain platform devices, so I need to
handle those myself. Can I somehow handle that in the platform code,
creating omap_dss_devices at boot time, or do I need to create those
devices in, for example in this case, dpi-driver's probe?

 Tomi

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux