linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Archit Taneja <a0393947@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices
Date: Fri, 04 May 2012 09:00:06 +0000	[thread overview]
Message-ID: <1336122006.2701.19.camel@deskari> (raw)
In-Reply-To: <4FA39091.8010007@ti.com>

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

On Fri, 2012-05-04 at 13:47 +0530, Archit Taneja wrote:
> On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:

> > @@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
> >   		oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
> >   	}
> >
> > -	for (i = 0; i<  oh_count; i++) {
> > -		oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
> > -		if (!oh) {
> > -			pr_err("Could not look up %s\n",
> > -				curr_dss_hwmod[i].oh_name);
> > -			return -ENODEV;
> > -		}
> > +	dss_pdev = NULL;
> >
> > -		pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
> > -				curr_dss_hwmod[i].id, oh,
> > +	for (i = 0; i<  oh_count; i++) {
> > +		pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
> > +				curr_dss_hwmod[i].id,
> > +				curr_dss_hwmod[i].oh_name,
> >   				NULL, 0,
> > -				NULL, 0, 0);
> > +				dss_pdev);
> > +
> > +		if (IS_ERR(pdev)) {
> > +			pr_err("Could not build omap_device for %s\n",
> > +					curr_dss_hwmod[i].oh_name);
> > +
> > +			return PTR_ERR(pdev);
> > +		}
> >
> > -		if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",
> > -				curr_dss_hwmod[i].oh_name))
> > -			return -ENODEV;
> > +		if (i == 0)
> > +			dss_pdev = pdev;
> 
> The above line is a bit tricky to understand, maybe something like this 
> may explain the parent-child setting better:
> 
> 		if (!strcmp(curr_dss_hwmod[i].oh_name, "dss_core"))
> 			dss_pdev = pdev;

I agree that it's a bit confusing. But your suggestion is not very good
either, as the code does not work properly if the dss_core is not the
first one created. I'll look into it. Perhaps I can separate the code
into a small function, and then I can more easily do something like:

dss_pdev = create_the_device();

for () {
	// create the rest of the devices
	create_the_device();
}

and that would clarify what's going on.

> I had another general question about the parent-child series. What is 
> the use of the platform device omap_display_device (with the name 
> "omapdss"). Is it just a way to get the board data?

Originally, before hwmods, we had only omapdss device, which contained
all the dss code. Then came hwmods, and the omapdss was split into
smaller devices, but omapdss was still there.

As I see it, omapdss is currently a "virtual" higher level device
(virtual in the sense that it doesn't correspond directly to any HW),
and the code for omapdss is more or less in the core.c file. It's used
to pass the board data, but also has some generic dss stuff that all dss
subdevices can use.

I think in the long run we should remove omapdss device, and probably
handle the generic stuff in dss_core (dss.c), which, as a parent to
other subdevices, should fit fine for the role.

For the time being we can't remove it. It's the only simple way to pass
callbacks from the arch code with device tree.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-05-04  9:00 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-03 13:57 [PATCH 00/25] OMAPDSS: DT preparation patches v2 Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 01/25] OMAPDSS: panel-dvi: add PD gpio handling Tomi Valkeinen
2012-05-09 16:50   ` Russ Dill
2012-05-09 17:32     ` Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 02/25] OMAP: board-files: remove custom PD GPIO handling for DVI output Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 03/25] OMAPDSS: TFP410: rename dvi -> tfp410 Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 04/25] OMAPDSS: TFP410: rename dvi files to tfp410 Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 05/25] OMAPDSS: TFP410: pdata rewrite Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 06/25] OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev->id Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 07/25] OMAPDSS: Taal: move reset gpio handling to taal driver Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 08/25] OMAPDSS: clean up the omapdss platform data mess Tomi Valkeinen
2012-05-04  5:44   ` Archit Taneja
2012-05-04  8:32     ` Tomi Valkeinen
2012-05-04  8:48       ` Archit Taneja
2012-05-04  8:49         ` Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 09/25] OMAPDSS: remove return from platform_driver_unreg Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 10/25] OMAPDSS: use platform_driver_probe for core/dispc/dss Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices Tomi Valkeinen
2012-05-04  6:15   ` Archit Taneja
2012-05-04  8:37     ` Tomi Valkeinen
2012-05-04  8:29   ` Archit Taneja
2012-05-04  9:00     ` Tomi Valkeinen [this message]
2012-05-04  9:25       ` Archit Taneja
2012-05-03 13:57 ` [PATCH 12/25] OMAPDSS: create DPI & SDI devices Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 13/25] OMAPDSS: create DPI & SDI drivers Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 14/25] OMAPDSS: remove uses of dss_runtime_get/put Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 15/25] OMAPDSS: handle output-driver reg/unreg more dynamically Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 16/25] OMAPDSS: move the creation of debugfs files Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 17/25] OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 18/25] OMAPDSS: add __init & __exit Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 19/25] OMAPFB: " Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 20/25] OMAPDSS: change default_device handling Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 21/25] OMAPDSS: interface drivers register their panel devices Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 22/25] OMAPDSS: init omap_dss_devices internally Tomi Valkeinen
2012-05-03 13:57 ` [PATCH 23/25] OMAPDSS: DSI: implement generic DSI pin config Tomi Valkeinen
2012-05-03 13:58 ` [PATCH 24/25] OMAPDSS: DSI: improve DSI module id handling Tomi Valkeinen
2012-05-04  9:21   ` Archit Taneja
2012-05-04  9:53     ` Tomi Valkeinen
2012-05-04 10:17       ` Archit Taneja
2012-05-04 10:11         ` Tomi Valkeinen
2012-05-03 13:58 ` [PATCH 25/25] OMAPDSS: separate pdata based initialization Tomi Valkeinen
2012-05-07 17:46 ` [PATCH 00/25] OMAPDSS: DT preparation patches v2 Tony Lindgren
2012-05-08  8:44   ` Tomi Valkeinen
2012-05-08 16:00     ` Tony Lindgren
2012-05-09  8:09   ` Tomi Valkeinen
2012-05-09 15:45     ` Tony Lindgren
2012-05-10  7:11       ` Tomi Valkeinen
2012-05-10 16:13         ` Tony Lindgren

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=1336122006.2701.19.camel@deskari \
    --to=tomi.valkeinen@ti.com \
    --cc=a0393947@ti.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).