Hi,
Tomi Valkeinen wrote:
> Hi,
>
> On Thu, 2010-08-26 at 14:43 +0200, ext Archit Taneja wrote:
>> Add dss_features.c and dss_features.h for the dss_features framework
>>
>> Signed-off-by: Archit Taneja <archit@xxxxxx>
>
> Would a more static approach be cleaner? I mean something like this (pseudo
> code):
>
> static struct omap_dss_features omap3_dss_features = {
> /* array of register definitions */
> .registers = {
> {
> .register = FIRHINC,
> .high = 12,
> .low = 0,
> },
> {
> .register = FIRVINC,
> .high = 28,
> .low = 16,
> },
> ...
> },
>
> /* array of feature ids */
> .features = {
> GLOBAL_ALPHA,
> GLOBAL_ALPHA_VIDEO1,
> ...
> },
> };
>
> And then the code would select the omapX_dss_features struct
> to use depending on the omap version.
It looks way cleaner out here , not sure though what it would look
like once the whole file is filled up :)
One issue with having separate omapX_dss_features is something which might may
come later on : If there is a feature/value which is same in omap2 and omap3
but different in omap4, we will sill need to fill up all the structs completely.
We can get around this by filling one single struct on runtime :
all omap2 specific features filled up here
{
...
...
}
all common between omap2 and omap3 filled up here
{
...
...
}
all omap3 specific filled up here
{
...
...
}
And so on..
This will save up space, but won't give a very clean look ..
I think by the time all omap4(and 3630) features are added and remaining
omap2,3 checks are removed we will have atleast 20 or so register fields
and a dozen features. Initializing them statically for all omaps(including
the ES_REV's) will really stretch up the file. But it will still look clean :)
What's your call on this?
Archit
>
> Also, the feature/register defines should have some prefix,
> and perhaps they could be inside an enum?
Yes we can do this, I'll see while reworking what looks better(enum vs defines)
Archit
>
> Tomi--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
