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 08/21] OMAPDSS: clean up the omapdss platform data mess
Date: Thu, 08 Mar 2012 08:33:52 +0000 [thread overview]
Message-ID: <1331195632.2354.37.camel@deskari> (raw)
In-Reply-To: <4F586B28.1050403@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]
On Thu, 2012-03-08 at 13:47 +0530, Archit Taneja wrote:
> On Thursday 08 March 2012 01:32 PM, Tomi Valkeinen wrote:
> >> why do we check board_data being NULL here and not in omap_display_init()?
> >
> > I added it for DT case, because then we don't have board_data for the
> > devices defined in the DT data. However, for now we always have the
> > board_data, and in this patch I should just move the code. So I'll
> > remove the check, and add it later with DT code if needed.
>
> Ok. When DT will be in use, would omap_display_init() be called or not?
No. Currently the board files create and fill the board_data, and then
call omap_display_init.
With DT, the DT data will contain all the dynamic, per-board
information. Something like:
dss {
dpi {
dvi {
pd-gpio = <10>;
...
};
};
dsi@1 {
taal {
reset-gpio = <20>;
...
};
}
...
};
The DT data will be passed individually to each dss driver (i.e. dsi
driver will get its DT node, etc.). The drivers will read the data, and
initialize themselves with that, more or less the same manner they'd do
with the board_data from board files.
However, we currently have this "omapdss" device, which is not a hwmod
device at all. In the long run I think the omapdss device should be
removed, but for now we need it. And device has to be created in the
arch code, the same way it's now created in omap_display_init().
So with DT we need a new func, omap_display_init_dt() or such, which
creates the omapdss device, and also creates a board_data which contains
the ctx_loss etc function pointers. But the board data won't have any
display data, those come directly from DT data.
It's a bit messy solution, but it should allow us to have both DT and
non-DT working at the same time, with quite minimal changes to the board
files.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-03-08 8:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-07 12:44 [PATCH 00/21] OMAPDSS: DT preparation patches Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 01/21] OMAPDSS: panel-dvi: add PD gpio handling Tomi Valkeinen
2012-03-07 17:59 ` Archit Taneja
2012-03-08 7:54 ` Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 02/21] OMAP: board-files: remove custom PD GPIO handling for DVI output Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 03/21] OMAPDSS: TFP410: rename dvi -> tfp410 Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 04/21] OMAPDSS: TFP410: rename dvi files to tfp410 Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 05/21] OMAPDSS: TFP410: pdata rewrite Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 06/21] OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev->id Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 07/21] OMAPDSS: Taal: move reset gpio handling to taal driver Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 08/21] OMAPDSS: clean up the omapdss platform data mess Tomi Valkeinen
2012-03-07 18:23 ` Archit Taneja
2012-03-08 8:02 ` Tomi Valkeinen
2012-03-08 8:29 ` Archit Taneja
2012-03-08 8:33 ` Tomi Valkeinen [this message]
2012-03-08 8:55 ` Archit Taneja
2012-03-07 12:44 ` [PATCH 09/21] OMAPDSS: remove return from platform_driver_unreg Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 10/21] OMAPDSS: use platform_driver_probe for core/dispc/dss Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 11/21] OMAPDSS: register dss drivers in module init Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 12/21] OMAPDSS: create custom pdevs for DSS omap_devices Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 13/21] OMAPDSS: create DPI & SDI devices Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 14/21] OMAPDSS: create DPI & SDI drivers Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 15/21] OMAPDSS: remove uses of dss_runtime_get/put Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 16/21] OMAPDSS: handle output-driver reg/unreg more dynamically Tomi Valkeinen
2012-03-08 8:46 ` Archit Taneja
2012-03-08 8:46 ` Tomi Valkeinen
2012-03-08 9:34 ` Archit Taneja
2012-03-08 9:34 ` Tomi Valkeinen
2012-03-08 9:51 ` Archit Taneja
2012-03-07 12:44 ` [PATCH 17/21] OMAPDSS: move the creation of debugfs files Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 18/21] OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 19/21] OMAPDSS: add __init & __exit Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 20/21] OMAPFB: " Tomi Valkeinen
2012-03-07 12:44 ` [PATCH 21/21] OMAPDSS: change default_device handling 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=1331195632.2354.37.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).