Hi,
Tomi Valkeinen wrote:
> Hi,
>
[snip]
>> diff --git a/arch/arm/plat-omap/include/plat/display.h
>> b/arch/arm/plat-omap/include/plat/display.h
>> index 586944d..3e6eec1 100644
>> --- a/arch/arm/plat-omap/include/plat/display.h
>> +++ b/arch/arm/plat-omap/include/plat/display.h
>> @@ -434,6 +434,7 @@ struct omap_dss_device {
>> struct omap_overlay_manager *manager;
>>
>> enum omap_dss_display_state state;
>> + enum omap_channel channel;
>
> Isn't this the same as dssdev->manager->id?
>
> Yes, this channel stuff is a bit confusing, even the enum "omap_channel"
> is badly named (should at least have "dss" in it). But
> omap_overlay_manager should represent the output pipe, so I
> don't think there's need for channel field in dss_device.
The panel somehow needs to tell which manager it is connected to. We went with
with the way of declaring a new member 'channel' and setting that parameter up
in the
board file.
The current way to relate the manager and device is done by checking the
dssdev->type
in dss_recheck_connections() and then calling set_device()
This is not sufficient any more since two of the managers can support similar
types of
displays.
So in the channel approach the following happens:
-mgr->id's are initialized at bootup.
-devices and managers are connected using 'channel'.
-mgr->id automatically becomes equal to channel.
Can we set something like dssdev->manager->id in the board file itself?
Archit
>
> I think in many places we could even pass
> omap_overlay_manager pointer around, instead of omap_channel.
> However, for low level dispc functions it's perhaps cleaner
> to pass the channel ID though.
>
> Tomi--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
