Hi Benoit, Thanks for the comments, ill study how we can leverage the hwmod fw for DSS features. Archit > -----Original Message----- > From: Cousson, Benoit > Sent: Tuesday, August 17, 2010 5:03 PM > To: Taneja, Archit > Cc: Tomi Valkeinen; Semwal, Sumit; > linux-omap@xxxxxxxxxxxxxxx; Paul Walmsley; Kevin Hilman > Subject: Re: DSS2 patch series > > Hi Archit, > > On 8/17/2010 1:16 PM, Taneja, Archit wrote: > > Hi, > > > >> Ok. Well, good that it's clear now =). > >> > >>> How do you think we can clean things up? > >> > >> If I remember right, there's some kind of feature framework being > >> worked on (or ready?), but I haven't looked at that at > all. That may > >> or may not suit our needs. > >> > >> But perhaps we could just have a separate dss_features.c > file, which > >> would contain a bunch of functions that can be used to ask > whether a > >> certain feature is supported, and also to ask certain values (max > >> dividers or similar). > > > > I talked to some more folks about this. To summarize: > > > > - The revision registers aren't reliable enough, it's better to use > > the combination of cpu_is_xxxx and and omap_rev macros. > These should > > be enough for making an DSS specific feature list. > > > > -The feature framework(HWMOD) can help out with the following things > > - The internal IP blocks within DSS. > > - The PRCM clocks and IRQs coming to DSS, and PM stuff > which I don't > > know much about. > > - Effectively, the information on how the outside world > communicates with DSS. > > > > -DSS features like number of vid pipelines, supported color > > modes,internal clocks and PLL info, bit fields needs to be > managed by us. > > You can use hwmod to store that as well. Other IPs might > require features management, so instead of doing a DSS > dedicated solution, you can directly leverage the existing > fmwk and extend it to manage your features. > > > One good input was that we can manage internal DSS clocks using the > > exisiting clock framework and custom clock modes. I don't know much > > about it. Others in the list can probably help out with this :) > > > > The present way of handling DSS2 clocks is good, but we > need to see if > > it can be scalable when more OMAPs come in. > > Good? It works, but this is still redoing what the clocks > framework can already do. The good approach will be to encode > your clocks nodes using the clock framework, as you've just said. > > > The dss_features.c idea sounds good, we will still have these new > > bunch of functions scattered around in the code. But it > will be much than an if else chain of omap checks. > > > > So should we stick with this idea? > > Using directly the hwmod struct sound a much better idea for > my point of view. > > Regards, > Benoit > -- 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
