On Thu, 2010-05-20 at 13:03 +0200, ext Guennadi Liakhovetski wrote: > Yes, I'd use u8 too, because the specs define "transaction types" to take > 6 bits and "DCS commands" to be 8-bit ints. But, you know, doesn't our > case fall under case (b) of Chapter 5 "Typedefs" of CodingStyle?:) I mean, CodingStyle says: "if there is a clear reason for why it under certain circumstances might be an "unsigned int" and under other configurations might be "unsigned long", then by all means go ahead and use a typedef." In our case the DSI transactions and DCS commands are always 6 and 8 bits, so I don't think it applies. And the transaction datatypes and DCS commands are really just payload sent to the peripheral, and the peripheral can do anything it wants with those. > wouldn't it make sense to create two typedefs for these to add some But wouldn't a typedef basically lock the possible transactions or DCS commands that you can give to the functions? And that was the original problem also. > type-safety? In fact, transaction types cannot be user-defined / > proprietary, right? So, for that an enum would work. It's only DCS Why they cannot be? I don't see any technical problem there, at least. And while I don't have any current use to extend transactions, I wouldn't want to limit it for any possible future use either. > But you only need specific panel drivers if you want to support their > proprietary commands? Otherwise you only need a set of parameters - > timeing requirements etc. - which you can perfectly just pass in platform > data? That's true. I guess you've gotten it easy, if you only have DSI video mode panels that do not need any special care =). Command mode panels are usually slightly more complex, and especially early prototypes of the panels can require quite a lot of trickery. And then there are DSI hubs, which make DSI command mode panels look trivial... 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
