Skip to contentSkip to conversation

leds: lp8860: Support additional features

RFC Milo Kim 3 participants 6 messages Jan 6, 2016 – Jan 12, 2016 LED

lore
Share & tools
lore

Milo Kim

author
#0 lore raw

Hi Dan,

I'm going to support additional features for LP8860 LED driver.

* New functions
- SPI support (only I2C is supported at this moment)
- Brightness control by external PWM signal
- Loading EEPROM value by using Linux firmware interface
- Display mode support (currently, only cluster mode is supported)

So, leds-lp8860 driver architecture will be changed as below.

MFD: I2C/SPI operation, loading EEPROM values from firmware file
Backlight: LP8860 display mode support
LED: LP8860 cluster mode support

* MFD (new)
- Three files will be created.

    lp8860-core.c, lp8860-i2c.c and lp8860-spi.c
  - Firmware I/F
    Firmware binary file contains default EEPROM values.
    lp8860-core will request a firmware and write values via I2C/SPI.
    Bin files will be delivered in separate location later.
    This feature will support several EEPROM versions with single driver.
  - MFD devices
    lp8860-core will create MFD child devices based on EEPROM value.
    LED_STRING_CONF[2:0] bits will be read.
    mode 0: backlight
         1: backlight + LED
         2: backlight + LED 1, 2
         3: backlight + LED 1, 2, 3
         4: backlight 1, 2
         5: backlight
         6: backlight + LED 1, 2
         7: LED 1,2,3,4
    (Please refer to the page 28 and 29 of LP8860 datasheet.
     http://www.ti.com/lit/ds/symlink/lp8860-q1.pdf)

* Backlight (new)
- PWM control mode support
- Register backlight device

* LED (will be modified)
- Unlock/lock EEPROM code will be moved to lp8860-core part
- Multiple LED output channels will be supported

I'd like to have your opinion prior to creating patches.

Jacek,
It would be best if you have better idea for this. Thanks!

Best regards,
Milo

#1 lore raw

Milo

Thanks for the email sorry I did not get to it till now

Quoted 12 lines · Milo Kim

Hi Dan,

I'm going to support additional features for LP8860 LED driver.

* New functions
- SPI support (only I2C is supported at this moment)
- Brightness control by external PWM signal
- Loading EEPROM value by using Linux firmware interface
- Display mode support (currently, only cluster mode is supported)

So, leds-lp8860 driver architecture will be changed as below.

Quoted 7 lines

MFD: I2C/SPI operation, loading EEPROM values from firmware file
Backlight: LP8860 display mode support
LED: LP8860 cluster mode support

* MFD (new)
- Three files will be created.

    lp8860-core.c, lp8860-i2c.c and lp8860-spi.c

Why would you do this? The led driver uses regmap. You just need to register the regmap interface and all the writes and reads will be directed accordingly.

You would need to create a probe that would initialize the correct interface. MFD is not required here.

Quoted 4 lines

- Firmware I/F
Firmware binary file contains default EEPROM values. lp8860-core will request a firmware and write values via I2C/SPI. Bin files will be delivered in separate location later.

Where? The linux-firmware repo?

Quoted 1 line

This feature will support several EEPROM versions with single driver.

I would prefer to move this firmware loading into a bootloader. Since this is a back light driver it does not make sense to load the firmware once the file system is available. Most applications will need backlight very early in the boot sequence to produce a SoL (Sign of Life). Loading the firmware at file system run time does not make sense. When/how would create the necessary led interfaces?

It would be better to load the FW very early. I would probably create a device tree node that tells the driver whether to control the device directly or use the loaded firmware.

Quoted 13 lines

- MFD devices

    lp8860-core will create MFD child devices based on EEPROM value.
    LED_STRING_CONF[2:0] bits will be read.
    mode 0: backlight
         1: backlight + LED
         2: backlight + LED 1, 2
         3: backlight + LED 1, 2, 3
         4: backlight 1, 2
         5: backlight
         6: backlight + LED 1, 2
         7: LED 1,2,3,4
    (Please refer to the page 28 and 29 of LP8860 datasheet.
     http://www.ti.com/lit/ds/symlink/lp8860-q1.pdf)

Well is this something we can add to the DT and program the EEPROM on the fly for implementations that do not require TI firmware?
Is loading the EEPROM firmware an absolute requirement? Can't the individuals just update the EEPROM values in the core file?
Are all the EEPROM values 0x00? I am not seeing any default values in the TRM.

Quoted 9 lines

* Backlight (new)
- PWM control mode support
- Register backlight device

* LED (will be modified)
- Unlock/lock EEPROM code will be moved to lp8860-core part
- Multiple LED output channels will be supported

Quoted 7 lines

I'd like to have your opinion prior to creating patches.

Jacek,
It would be best if you have better idea for this. Thanks!

Best regards,
Milo

Dan

Signature · 2 lines
------------------
Dan Murphy
#2 lore raw

Milo

Quoted 14 lines · Dan Murphy

<snip>

Quoted 13 lines

- MFD devices

    lp8860-core will create MFD child devices based on EEPROM value.
    LED_STRING_CONF[2:0] bits will be read.
    mode 0: backlight
         1: backlight + LED
         2: backlight + LED 1, 2
         3: backlight + LED 1, 2, 3
         4: backlight 1, 2
         5: backlight
         6: backlight + LED 1, 2
         7: LED 1,2,3,4
    (Please refer to the page 28 and 29 of LP8860 datasheet.
     http://www.ti.com/lit/ds/symlink/lp8860-q1.pdf)
Quoted 5 lines

Well is this something we can add to the DT and program the EEPROM on the fly for implementations that do not require TI firmware?
Is loading the EEPROM firmware an absolute requirement? Can't the individuals just update the EEPROM values in the core file?
Are all the EEPROM values 0x00? I am not seeing any default values in the TRM.

Ok I found a default table in the data sheet based on part value. So there may be a need to use the default EEPROM values and adjust during boot.

Dan

Quoted 18 lines
Quoted 9 lines

* Backlight (new)
- PWM control mode support
- Register backlight device

* LED (will be modified)
- Unlock/lock EEPROM code will be moved to lp8860-core part
- Multiple LED output channels will be supported

Quoted 7 lines

I'd like to have your opinion prior to creating patches.

Jacek,
It would be best if you have better idea for this. Thanks!

Best regards,
Milo

Dan

Signature · 2 lines
------------------
Dan Murphy
author
#3 lore raw
In reply to Dan Murphy

Hi Dan,

Thanks for your comment.

Quoted 25 lines · Dan Murphy

Milo

Thanks for the email sorry I did not get to it till now

Quoted 12 lines · Milo Kim

Hi Dan,

I'm going to support additional features for LP8860 LED driver.

* New functions
- SPI support (only I2C is supported at this moment)
- Brightness control by external PWM signal
- Loading EEPROM value by using Linux firmware interface
- Display mode support (currently, only cluster mode is supported)

So, leds-lp8860 driver architecture will be changed as below.

Quoted 7 lines

MFD: I2C/SPI operation, loading EEPROM values from firmware file
Backlight: LP8860 display mode support
LED: LP8860 cluster mode support

* MFD (new)
- Three files will be created.

     lp8860-core.c, lp8860-i2c.c and lp8860-spi.c
Quoted 5 lines

Why would you do this? The led driver uses regmap. You just need to register the regmap interface and all the writes and reads will be directed accordingly.

You would need to create a probe that would initialize the correct interface. MFD is not required here.

Good point. I agree. Separate file is not necessary if regmap is configured.

Quoted 7 lines
Quoted 5 lines

- Firmware I/F
Firmware binary file contains default EEPROM values. lp8860-core will request a firmware and write values via I2C/SPI. Bin files will be delivered in separate location later.

Where? The linux-firmware repo?

Yes, that was my plan.

Quoted 7 lines
Quoted 1 line

This feature will support several EEPROM versions with single driver.

I would prefer to move this firmware loading into a bootloader. Since this is a back light driver it does not make sense to load the firmware once the file system is available. Most applications will need backlight very early in the boot sequence to produce a SoL (Sign of Life). Loading the firmware at file system run time does not make sense. When/how would create the necessary led interfaces?

Yes, backlight control in early stage - it's true. In other backlight projects, some vendors write register values in both stages - bootloader and kernel. With regard to LP8860, I don't have any requirement from vendor/customer side yet.

Quoted 2 lines

It would be better to load the FW very early. I would probably create a device tree node that tells the driver whether to control the device directly or use the loaded firmware.

I think this is a good option for supporting various applications.

Quoted 14 lines
Quoted 13 lines

- MFD devices

     lp8860-core will create MFD child devices based on EEPROM value.
     LED_STRING_CONF[2:0] bits will be read.
     mode 0: backlight
          1: backlight + LED
          2: backlight + LED 1, 2
          3: backlight + LED 1, 2, 3
          4: backlight 1, 2
          5: backlight
          6: backlight + LED 1, 2
          7: LED 1,2,3,4
     (Please refer to the page 28 and 29 of LP8860 datasheet.
      http://www.ti.com/lit/ds/symlink/lp8860-q1.pdf)
Quoted 4 lines

Well is this something we can add to the DT and program the EEPROM on the fly for implementations that do not require TI firmware?
Is loading the EEPROM firmware an absolute requirement? Can't the individuals just update the EEPROM values in the core file?

There is no requirement. Only few EEPROM values can be updated.
However, it could cause a problem if wrong values are written in EEPROM, so we used to provide whole values from 0x60 to 0x78.

The reason why I'm considering firmware I/F is kernel maintenance.
Without DT modification, new options can be applied through the firmware. It provides more useful feature in development stage.
And I spent much times to check register values on debugging. In most cases, wrong values were written in customer side. So I think this situation could be improved if the driver uses the firmware.

However, as you pointed, firmware I/F is not the best solution because EEPROM should be updated early as soon as possible. I agree DT property would be better.

Best regards,
Milo

#4 lore raw
In reply to Milo Kim

Hi Milo,

Quoted 42 lines · Milo Kim

Hi Dan,

I'm going to support additional features for LP8860 LED driver.

* New functions
- SPI support (only I2C is supported at this moment)
- Brightness control by external PWM signal
- Loading EEPROM value by using Linux firmware interface
- Display mode support (currently, only cluster mode is supported)

So, leds-lp8860 driver architecture will be changed as below.

MFD: I2C/SPI operation, loading EEPROM values from firmware file
Backlight: LP8860 display mode support
LED: LP8860 cluster mode support

* MFD (new)
- Three files will be created.

     lp8860-core.c, lp8860-i2c.c and lp8860-spi.c
   - Firmware I/F
     Firmware binary file contains default EEPROM values.
     lp8860-core will request a firmware and write values via I2C/SPI.
     Bin files will be delivered in separate location later.
     This feature will support several EEPROM versions with single driver.
   - MFD devices
     lp8860-core will create MFD child devices based on EEPROM value.
     LED_STRING_CONF[2:0] bits will be read.
     mode 0: backlight
          1: backlight + LED
          2: backlight + LED 1, 2
          3: backlight + LED 1, 2, 3
          4: backlight 1, 2
          5: backlight
          6: backlight + LED 1, 2
          7: LED 1,2,3,4
     (Please refer to the page 28 and 29 of LP8860 datasheet.
      http://www.ti.com/lit/ds/symlink/lp8860-q1.pdf)

* Backlight (new)
- PWM control mode support
- Register backlight device

Quoted 8 lines

* LED (will be modified)
- Unlock/lock EEPROM code will be moved to lp8860-core part
- Multiple LED output channels will be supported

I'd like to have your opinion prior to creating patches.

Jacek,
It would be best if you have better idea for this. Thanks!

I'll wait for the first version of the patch. You haven't provided any info on how you want to add the support for multiple channels, so there is nothing I can refer to.

Signature · 2 lines
Best Regards,
Jacek Anaszewski
author
#5 lore raw

Hi Jacek,

Quoted 50 lines · Jacek Anaszewski

Hi Milo,

Quoted 47 lines · Milo Kim

Hi Dan,

I'm going to support additional features for LP8860 LED driver.

* New functions
- SPI support (only I2C is supported at this moment)
- Brightness control by external PWM signal
- Loading EEPROM value by using Linux firmware interface
- Display mode support (currently, only cluster mode is supported)

So, leds-lp8860 driver architecture will be changed as below.

MFD: I2C/SPI operation, loading EEPROM values from firmware file
Backlight: LP8860 display mode support
LED: LP8860 cluster mode support

* MFD (new)
- Three files will be created.

     lp8860-core.c, lp8860-i2c.c and lp8860-spi.c

- Firmware I/F
Firmware binary file contains default EEPROM values. lp8860-core will request a firmware and write values via I2C/SPI. Bin files will be delivered in separate location later. This feature will support several EEPROM versions with single
driver.
- MFD devices

     lp8860-core will create MFD child devices based on EEPROM value.
     LED_STRING_CONF[2:0] bits will be read.
     mode 0: backlight
          1: backlight + LED
          2: backlight + LED 1, 2
          3: backlight + LED 1, 2, 3
          4: backlight 1, 2
          5: backlight
          6: backlight + LED 1, 2
          7: LED 1,2,3,4
     (Please refer to the page 28 and 29 of LP8860 datasheet.
      http://www.ti.com/lit/ds/symlink/lp8860-q1.pdf)

* Backlight (new)
- PWM control mode support
- Register backlight device

* LED (will be modified)
- Unlock/lock EEPROM code will be moved to lp8860-core part
- Multiple LED output channels will be supported

Quoted 8 lines
Quoted 4 lines

I'd like to have your opinion prior to creating patches.

Jacek,
It would be best if you have better idea for this. Thanks!

I'll wait for the first version of the patch. You haven't provided any info on how you want to add the support for multiple channels, so there is nothing I can refer to.

OK, thanks. Multiple channel configuration can be done through the device tree or by reading the firmware. I'm considering the DT properties. I'll submit the patches in few weeks.

Best regards,
Milo