Hi! > > > One such example is the laptop in front of me, which has 3 channels > > > wired to an RGB LED and 1 channel wired as a backlight control signal > > > (i.e. using pwm-backlight). Another example is a devboard where the > > > 4 channels are wired to 4 LEDs. > > > > Ok, so this is actually important. In this case you should have PWM > > layer, exporting PWMs, and then rgb-LED driver that takes three of > > those PWMs and turns them into LED, no? > > > > And ... surprise ... that is likely to help other people, as LEDs > > connected to PWMs are quite common. > > > > Hmm.? > > > > If you can't do this for some reason, you should probably explain in > > the changelog, because this is going to be FAQ. > > > > This is exactly what the downstream implementation does and in the case > of a solid color LED this works fine. > > But the hardware has a shared chunk of memory where you can write > duty-cycle values, then for each PWM channel you can specify the > start/stop index and pace for the PWM to read and update the configured > duty-cycle. This is how the hardware implements pattern support. Ok. > So downstream they have (last time I looked at the code) an addition in > the PWM API where the LED driver can inform the PWM driver part about > the indices to use. Naturally I don't think that's a good idea. Dunno. Is it bad idea? pattern support for other PWMs (vibration?) seems useful, too. Yes, it means more discussion and extending PWMs properly.. > Additionally, representing this as individual PWM channels means we're > loosing the grouping that now comes from the description of multicolor > LEDs, which serves the basis for synchronizing the pattern traversal > between the involved channels. Yes, keeping grouping would be nice, but perhaps pattern API for PWMs can do that too? You can have solid-color-only driver now, with patterns being added as discussion with PWM people progresses... Best regards, Pavel --
