* Stephen Warren wrote: > Thierry Reding wrote at Tuesday, December 20, 2011 3:32 AM: > > many PWMs it controls using the npwm member. Each of the functions in > > the pwm_ops structure gets an additional argument that specified the PWM > > number (it can be converted to a per-chip index by subtracting the > > chip's base). > > I think it'd be much more convenient for drivers if the PWM core passed > the device-relative PWM ID to the driver functions instead of the global > PWM ID; the common case is going to be for the driver to want to index > into some local array using the value, which means all drivers will have > to subtract the chip base. I doubt many drivers will care about the global > ID at all, and if they do, they can add the base back on. That was my initial plan as well, but then I looked to gpiolib for inspiration and decided to go the same way. But from what I hear now that wasn't so good. If there is a concensus that gpiolib has some flaws in this respect, then I think we should try to avoid them in the PWM framework. > > The total maximum number of PWM devices is currently fixed to 64, but > > can easily be made configurable via Kconfig. > > GPIO (and IRQ?) have static sized arrays for this kind of purpose too, > and I'm pretty sure I've seen discussions that this was a mistake, or > at least something that will hopefully be reworked. pinctrl was similar, > but it was requested this be reworked, and now I think the pin ID -> > pin descriptor table is a radix tree. > > In other words, can you do away with NR_PWM, and make it completely > dynamic? IRQ can be configured to use a radix tree if CONFIG_SPARSE_IRQ=y. I guess it doesn't hurt to always use a radix tree for PWM, so I'll read up on it and will try to address that in the next version. Thierry
Attachment:
pgpnPWAPSHGJf.pgp
Description: PGP signature
