On Mon, 21 Aug 2023, Marek Behún wrote: > On Fri, 18 Aug 2023 10:42:55 +0100 > Lee Jones <lee@xxxxxxxxxx> wrote: > > > On Wed, 02 Aug 2023, Marek Behún wrote: > > > > > Implement caching of the LED color and state values that are sent to MCU > > > in order to make the set_brightness() operation more efficient by > > > avoiding I2C transactions which are not needed. > > > > How many transactions does all of this extra code actually save? > > Depends on how many transactions are requested by userspace wanting to > change LED brightness, but see below. > > > > On Turris Omnia's MCU, which acts as the RGB LED controller, each LED > > > has a RGB color, and a ON/OFF state, which are configurable via I2C > > > commands CMD_LED_COLOR and CMD_LED_STATE. > > > > > > The CMD_LED_COLOR command sends 5 bytes and the CMD_LED_STATE command 2 > > > bytes over the I2C bus, which operates at 100 kHz. With I2C overhead > > > this allows only ~1670 color changing commands and ~3200 state changing > > > commands per second. > > > > Only? Seems like quite a lot. > > I may have chosen the wrong argument here. Yes, 1670 color changing > commands are more than enough for a LED controller. This is not the > problem. > > The problem is that the we need to be able to send other commands over > the same I2C bus, unrelated to the LED controller, and they need the > bandwidth. The MCU exposes an interrupt interface, and it can trigger > hundreds of interrupts per second. Each time we need to read the > interrupt state register. Whenever we are sending a LED color/state > changing command, the interrupt reading is waiting. > > So this is the reason why I want to avoid unnecessary I2C transactions. > > If I change the commit message to explain this, will you be satisfied? Yes, I expect so. > > > Currently, every time LED brightness or LED multi intensity is changed, > > > we send a CMD_LED_STATE command, and if the computed color (brightness > > > adjusted multi_intensity) is non-zero, we also send a CMD_LED_COLOR > > > command. > > > > > > Consider for example the situation when we have a netdev trigger enabled > > > for a LED. The netdev trigger does not change the LED color, only the > > > brightness (either to 0 or to currently configured brightness), and so > > > there is no need to send the CMD_LED_COLOR command. But each change of > > > brightness to 0 sends one CMD_LED_STATE command, and each change of > > > brightness to max_brightness sends one CMD_LED_STATE command and one > > > CMD_LED_COLOR command: > > > set_brightness(0) -> CMD_LED_STATE > > > set_brightness(255) -> CMD_LED_STATE + CMD_LED_COLOR > > > (unnecessary) > > > > > > We can avoid the unnecessary I2C transactions if we cache the values of > > > state and color that are sent to the controller. If the color does not > > > change from the one previously sent, there is no need to do the > > > CMD_LED_COLOR I2C transaction, and if the state does not change, there > > > is no need to do the CMD_LED_STATE transaction. > > > > > > Because we need to make sure that out cached values are consistent with > > > > Nit: "our" > > > > Thanks, I will fix this. > > > > + > > > + /* send the color change command */ > > > > Nit: Please start comments with an upper case char. > > OK, I will change it. > > > > + ret = i2c_master_send(client, cmd, 5); > > > + if (ret < 0) > > > + return ret; > > > + > > > + /* cache the RGB channel brightnesses */ > > > + for (int i = 0; i < OMNIA_LED_NUM_CHANNELS; ++i) > > > > Why the pre-increment? > > > > It's non-standard and doesn't appear to have any affect. > > According to git grep, current Linux sources contain around 7606 > occurances of pre-increment (++x) in for cycles: > git grep '; ++[a-z_]\+)' | wc -l > > and 81360 occurances of post-increment (x++): > git grep '; [a-z_]\+++)' | wc -l > > Yes, I admit that pre-increment is 10 times less frequent, but I do not > consider that to be non-standard. > > If you insist on this, I will change it. But I consider this > non-consequential... > > Please let me know whether you insist on it. I don't. It was a genuine question I was curious about. Just looks odd and made me wonder if it actually served a purpose. -- Lee Jones [李琼斯]
