On 2012-10-29 12:04, Archit Taneja wrote: > On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote: >> Currently omapdss driver sets up the initial connections between >> overlays, overlay manager and a panel, based on default display >> parameter coming from the board file or via module parameters. >> >> This is unnecessary, as it's the higher level component that should >> decide what display to use and how. This patch removes the code from >> omapdss, and implements similar code to omapfb. >> >> The def_disp module parameter and the default display platform_data >> parameter are kept in omapdss, but omapdss doesn't do anything with >> them. It will just return the default display name with >> dss_get_default_display_name() call, which omapfb uses. This is done to >> keep the backward compatibility. > > We might need to do something similar for omap_vout and omapdrm also to > set the initial connections.
I believe omapdrm already does this.
For omap_vout... I'm not sure if we can do that. Both omapfb and
omap_vout work at the same time, so they could be setting up the
settings at the same time, perhaps with conflicting values. The reason I
left omap_vout out is that I think omapfb is always used with omap_vout,
thus the config can be left for omapfb. I didn't test this, though.
>> Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
>> ---
>> drivers/video/omap2/dss/core.c | 1 +
>> drivers/video/omap2/dss/display.c | 78
>> +++---------------------------
>> drivers/video/omap2/omapfb/omapfb-main.c | 77
>> ++++++++++++++++++++++++-----
>> include/video/omapdss.h | 1 +
>> 4 files changed, 75 insertions(+), 82 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/core.c
>> b/drivers/video/omap2/dss/core.c
>> index 685d9a9..4cb669e 100644
>> --- a/drivers/video/omap2/dss/core.c
>> +++ b/drivers/video/omap2/dss/core.c
>> @@ -57,6 +57,7 @@ const char *dss_get_default_display_name(void)
>> {
>> return core.default_display_name;
>> }
>> +EXPORT_SYMBOL(dss_get_default_display_name);
>
> Since we are exporting this, it might be better to name it
> omapdss_get_default_display_name
True.
>> enum omapdss_version omapdss_get_version(void)
>> {
>> diff --git a/drivers/video/omap2/dss/display.c
>> b/drivers/video/omap2/dss/display.c
>> index 1e58730..6d33112 100644
>> --- a/drivers/video/omap2/dss/display.c
>> +++ b/drivers/video/omap2/dss/display.c
>> @@ -320,86 +320,21 @@ void omapdss_default_get_timings(struct
>> omap_dss_device *dssdev,
>> }
>> EXPORT_SYMBOL(omapdss_default_get_timings);
>>
>> -/*
>> - * Connect dssdev to a manager if the manager is free or if force is
>> specified.
>> - * Connect all overlays to that manager if they are free or if force is
>> - * specified.
>> - */
>> -static int dss_init_connections(struct omap_dss_device *dssdev, bool
>> force)
>> +int dss_init_device(struct platform_device *pdev,
>> + struct omap_dss_device *dssdev)
>> {
>> + struct device_attribute *attr;
>> struct omap_dss_output *out;
>> - struct omap_overlay_manager *mgr;
>> int i, r;
>>
>> out = omapdss_get_output_from_dssdev(dssdev);
>>
>> - WARN_ON(dssdev->output);
>> - WARN_ON(out->device);
>> -
>> r = omapdss_output_set_device(out, dssdev);
>> if (r) {
>> DSSERR("failed to connect output to new device\n");
>> return r;
>> }
>
> So, we still manage the output-device links in the omapdss driver, but
> move the manager-output and overlay-manager links to omapfb. I guess
> this is fine. But maybe this split might change based on how generic
> panel framework looks like, and how much we want to expose outputs to
> fb/drm.
We can set the output-device link in omapdss because it's a hardware
configuration. A panel is connected to an output, so there's nothing to
configure there. ovls and ovl-mgrs, on the other hand, may be configured
depending on the use cases.
But yes, I wouldn't be surprised if this will be changed with common
panel framework.
Tomi
signature.asc
Description: OpenPGP digital signature
