On Tue, 2012-08-07 at 17:52 +0530, Chandrabhanu Mahapatra wrote: > Yes, this seems good to me. Its better to have all cpu_is checks of > dispc.c and dss.c in their probe functions and by the time > implementation of DSS version come to picture these can be move to dss > features or any other place appropriate. But how to handle OMAP revision > specific functions. Will Dss version handle that too, as like DSS1, > DSS1.1, DSS1.1.1, DSS2 say? Yes, something like that. I'm not sure how the version numbers should be created, though. If we had only OMAP, we could use the OMAP version as the DSS major version, and increasing minor version whenever the DSS is changed. So DSS3.2 could be the DSS used on OMAP3 SoCs, and it's the second revision, meaning that early OMAP3 versions would have had an different DSS version. However, the same DSS is used for other SoCs also, so the versioning is not that simple. I guess the other SoCs still always use a DSS that is designed for OMAP, so the major version would be solved by that. For example, AM3xxx DSS version would be DSS3.x. Minor version is more tricky, because OMAP and AM3 DSS can evolve separately, which means that a higher minor version may not contain the fix that exists in a lower minor version. Well, at least currently the AM3xxx's DSS is almost the same as OMAP3's, so perhaps I'm worrying too much. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
