All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Benoit Cousson <b-cousson@ti.com>, Tony Lindgren <tony@atomide.com>
Cc: linux-omap mailing list <linux-omap@vger.kernel.org>
Subject: Questions about DSS device tree adaptation
Date: Wed, 22 Feb 2012 14:07:23 +0200	[thread overview]
Message-ID: <1329912443.2070.58.camel@deskari> (raw)

[-- Attachment #1: Type: text/plain, Size: 3247 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

             reply	other threads:[~2012-02-22 12:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-22 12:07 Tomi Valkeinen [this message]
2012-02-23 11:43 ` Questions about DSS device tree adaptation Cousson, Benoit
2012-02-23 12:56   ` Tomi Valkeinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1329912443.2070.58.camel@deskari \
    --to=tomi.valkeinen@ti.com \
    --cc=b-cousson@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.