Openbmc archive at lore.kernel.org
 help / color / Atom feed
* LED accessed via I2C
@ 2020-10-04  9:04 S.Nishikawa
  2020-10-04 18:34 ` Milton Miller II
  0 siblings, 1 reply; 3+ messages in thread
From: S.Nishikawa @ 2020-10-04  9:04 UTC (permalink / raw)
  To: openbmc

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?

Thanks,
----
Shunpei Nishikawa

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re:  LED accessed via I2C
  2020-10-04  9:04 LED accessed via I2C S.Nishikawa
@ 2020-10-04 18:34 ` Milton Miller II
  2020-10-07 19:26   ` Anton Kachalov
  0 siblings, 1 reply; 3+ messages in thread
From: Milton Miller II @ 2020-10-04 18:34 UTC (permalink / raw)
  To: S.Nishikawa; +Cc: openbmc

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: LED accessed via I2C
  2020-10-04 18:34 ` Milton Miller II
@ 2020-10-07 19:26   ` Anton Kachalov
  0 siblings, 0 replies; 3+ messages in thread
From: Anton Kachalov @ 2020-10-07 19:26 UTC (permalink / raw)
  To: Milton Miller II; +Cc: OpenBMC Maillist, S.Nishikawa


[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

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@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
>
>

[-- Attachment #2: Type: text/html, Size: 2669 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-04  9:04 LED accessed via I2C S.Nishikawa
2020-10-04 18:34 ` Milton Miller II
2020-10-07 19:26   ` Anton Kachalov

Openbmc archive at lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/openbmc/0 openbmc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 openbmc openbmc/ https://lore.kernel.org/openbmc \
		openbmc@lists.ozlabs.org openbmc@ozlabs.org
	public-inbox-index openbmc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.ozlabs.lists.openbmc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git