Hi! > > Actually we could achieve the goal by listing all available pattern > > configurations for given LED class device, so in case of Qualcomm LPG > > driver we could have transition-pattern-1 to transition-pattern-15 > > listed after executing "cat trigger". > > > > There's a common pattern-table of 24 (or 64) entries, that is shared > among the 8 LPGs (each LPG simply has to indices pointing into the > shared table). Each entry in the table holds a value between 0 and 511. > So that's a lot of "available pattern configurations". > > I wonder if I'm not missing some vital constraints here that could > > make this design unfeasible. > > > > Regardless of how we expose RGBs to userspace, the 8 LPG hardware blocks > are independent of each other. The fact that they end up controlling > something that is perceived by the human eye as some mixed color is to > me a matter of system integration, and as such should not convolute the > implementation of the individual instances. Well... the 8 LPG blocks share the pattern-table.. and the pattern-table is very limited. We could statically allocate 3 entries to each LPG block, but that would not be too useful. And if we dynamically allocate entries depending on patterns, then the LPG blocks are no longer independent. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
