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:
signature.asc
Description: This is a digitally signed message part
