On Fri, 2012-08-24 at 18:24 +0900, Alex Courbot wrote: > On Tuesday 21 August 2012 17:54:20 Tomi Valkeinen wrote: > > And as I said, I don't have any problems with some kind of generic power > > sequences. So the code in the board file could be moved and converted to > > use the power sequences, if that is better than just plain c code. > > My concern now is, provided that all drivers to their job and handle how their > devices are switched on and off, when (if at all) are encoded power sequences > better than their equivalent C code? There is the matching database size issue > that you mentionned, is it a sufficient concern to justify a new kernel feature? Good question. I think obviously the worst solution is to have separate .c driver files for each panel, where the drivers do 99% the same thing. So the question is how to represent the 1% difference the panels have. I think it depends on the panels. If it looks like all the panel have, say, max 2 regulators and one reset/enable gpio, and they are always enabled in the same order (regulators first, then the gpio), it should be easy to handle it in the driver without any power sequence framework. If the panels require more complex setups, then the code in the panel driver would probably start to form into a power sequence framework, and it would make sense to have it as a separate framework. Then again, if the panel setup is complex, it makes me wonder if it'd be just easier to handle it with c code in a separate driver. Also, the database size issue is a bit separate issue. There's the db size problem with or without the framework, if we do not pass the data from DT. So as clarification, I see 4 different options: - Power sequences in DT (as proposed in this series) - Custom panel data in DT, that the driver uses to power up properly - Power sequences in a panel database in kernel - Custom panel data in a panel db in kernel > On the other hand some devices like panels are typically not used in many > different appliances, so maybe it is not worth to separate them from their Yep, this is the reason for my concern with the database size. The DB could contain 10k panels, of which a board uses one. The rest just waste memory. But then again, 10k panels is probably not a realistic amount. It's difficult to guess the amount of memory used by such a database, though. If it uses, say, 8kB, I'm not sure if it's a reason to panic. And, as I mentioned, it could be optimized so that the driver throws away the unneeded panels at __init. Of course here the problem is that the panel needs to know what panels are needed. > board definition. As Mark mentionned, having .dtsi files for the DT (and their > equivalent .h for kernels that use platform data) might be a good middle > ground. I guess it's the perfectionist in me that leans toward handling it fully in the kernel, as I think that's architecturally correct thing to do. The DT data should contain parameters that can be configured per board, or nodes (like regulators) that are needed by other parts of the DT data. If the only reason why to do it via DT is to avoid the possible size problem with the panel database, perhaps what we should solve is the optimization of the database. If that seems unsolvable, then DT approach could be used as a workaround. And I have to say I'm not too familiar with DT, so if I'm wrong about what DT should contain, I'm all ears =). Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
