LED accessed via I2C
Anton Kachalov
rnouse at google.com
Thu Oct 8 06:26:44 AEDT 2020
In addition, you may try to start with the i2c-tools package. With
*i2cdetect* and *i2cset* you may actually discover all available devices on
specific i2c bus and then write to a specific i2c device by it's address.
Once you get it work, you should try to find suitable kernel driver that
may use your i2c device. For instance, if the i2c interface (with registers
read/write) is just a specific register write, you may try to re-use i2c
gpio driver and then use it as gpio led as described:
https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt
On Sun, 4 Oct 2020 at 20:35, Milton Miller II <miltonm at us.ibm.com> wrote:
> On October 4, 2020 around 4:05am in some timezone, S.Nishikawa wrote:
> >Hi,
> >
> >In our hardware, the Alert LED is attached to the end of the CPLD and
> >is
> >accessed via I2C. I think phosphor-led-sysfs controls LEDs with GPIO,
> >
> >but how can I control the LED beyond I2C?
>
>
> Actually phosphor-led-manager will control any device that has a
> kernel driver exposing the LED interface. For PCA i2c devices
> we tend to expose all the pins as gpio then individual gpios as
> gpio led devices because the led subsystem will change the led
> instance number based on which pins of the package are LED.
>
> It sounds like your cpld has a custom interface. If the leds
> can be controlled via a separate i2c addressed endpoint I would
> suggest a multi-function device binding using the mfd subsystem.
> If it is directly controled by a register consider registering
> a regmap like many voltage monitor and control devices. One
> advantage of regmap is it provides both locking and caching of
> the values written, controllable on a per-register basis.
>
> You will need a kernel driver for the remaining function that
> is accessible over the i2c interface.
>
> See https://www.kernel.org/doc/html/latest/leds/leds-class.html#
> for information on the kernel LED subsystem.
>
> I hope this gets you headed in a productive direction.
> milton
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20201007/f8fc8acd/attachment.htm>
More information about the openbmc
mailing list