On Thu, 2012-09-13 at 15:23 +0900, Alex Courbot wrote: > On Thursday 13 September 2012 13:50:47 Tomi Valkeinen wrote: > > I want to reiterate my opinion that I think power sequences in DT data > > is the wrong way to go. Powering sequences are device specific issues > > and should be handled in the device driver. But I also think that power > > sequences inside the drivers would probably be useful. > > I understand the logic behind handling powering sequences in the device > driver, but as we discussed for some classes of devices this might just not > scale. I don't know how many different panels (each with different powering > sequences) are relying on pwm_backlight, but the alternative of embedding > support for all of them into the kernel (and bloating the kernel image) or > having a 3 kilometers list in the kernel configuration to individually chose > which panel to support (which would be cumbersome and make the kernel less > portable across boards) does not look much appealing to me. With power > sequences encoded in the DT, we could have one .dtsi file per panel that would > be included from the board's .dts file - no bloat, no drivers explosion, > portability preserved. Yes, I see that side of the argument also. And to be honest, I don't know what kind of data is DT supposed to contain (or if there even is a strict definition for that). I have my opinion because I think that's how things should be: DT tells us what devices there are and how they connect, and the driver handles the rest. I may be a perfectionist, though, which is not good =). As for the kernel bloat, it's a valid issue, but I wonder if it would be an issue in practice. I don't know how many different supported devices we'd have, and how many bytes the data for each device would consume. I'm not even sure what amount of bytes would be acceptable. But I'm guessing that we wouldn't have very many devices, and if the per device data is made compact there wouldn't be that many bytes per device. And with non-hotpluggable platform devices the unused device data could be discarded after init. Anyway, having the power sequences doesn't affect me if I don't use them, so I have nothing against them =). > DT support is actually the main point of power sequences, as outside of the DT > we can always work the old way and use callbacks. If we were to remove DT > support, I am not sure this work would still be worth being merged. We can't use board callbacks when running with a DT enabled kernel. What I meant is that the driver could contain a power sequence for the device (or multiple supported devices). So it'd essentially be the same as getting the power sequence from the DT data. But I haven't looked at the power sequence data structures, so I'm not sure if they are geared for DT use. If so, they would probably need tuning to be good for in-kernel use. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
