linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Marangi <ansuelsmth@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>, Pavel Machek <pavel@ucw.cz>,
	Lee Jones <lee@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Christian Marangi <ansuelsmth@gmail.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-leds@vger.kernel.org, netdev@vger.kernel.org
Subject: [PATCH 04/11] Documentation: leds: leds-class: Document new Hardware driven LEDs APIs
Date: Thu, 27 Apr 2023 02:15:34 +0200	[thread overview]
Message-ID: <20230427001541.18704-5-ansuelsmth@gmail.com> (raw)
In-Reply-To: <20230427001541.18704-1-ansuelsmth@gmail.com>

Document new Hardware driven LEDs APIs.

Some LEDs can be programmed to be entirely driven by hw. This is not
limited to blink but also to turn off or on autonomously.
To support this feature, a LED needs to implement various additional
ops and needs to declare specific support for the supported triggers.

Add documentation for each required value and API to make hw control
possible and implementable by both LEDs and triggers.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 Documentation/leds/leds-class.rst | 56 +++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst
index cd155ead8703..a7bc31e9b919 100644
--- a/Documentation/leds/leds-class.rst
+++ b/Documentation/leds/leds-class.rst
@@ -169,6 +169,62 @@ Setting the brightness to zero with brightness_set() callback function
 should completely turn off the LED and cancel the previously programmed
 hardware blinking function, if any.
 
+Hardware driven LEDs
+====================
+
+Some LEDs can be programmed to be entirely driven by hw. This is not
+limited to blink but also to turn off or on autonomously.
+To support this feature, a LED needs to implement various additional
+ops and needs to declare specific support for the supported triggers.
+
+With hw control we refer to the LED driven by hardware.
+
+LED driver must define the following value to support hw control:
+
+    - hw_control_trigger:
+               unique trigger name supported by the LED in hw control
+               mode.
+
+    - trigger_supported_flags_mask:
+                mask of the different supported trigger mode for the
+                defined trigger in hw control mode.
+
+LED driver must implement the following API to support hw control:
+
+     - hw_control_set:
+                activate hw control, LED driver will use the provided
+                flags passed from the supported trigger, parse them to
+                a set of mode and setup the LED to be driven by hardware
+                following the requested modes.
+
+                Set LED_OFF via the brightness_set to deactivate hw control.
+
+    - hw_control_get:
+                get from a LED already in hw control, the active modes,
+                parse them and set in flags the current active flags for
+                the supported trigger.
+
+    - hw_control_is_supported:
+                check if the flags passed by the supported trigger can
+                be parsed and activate hw control on the LED.
+
+LED driver can activate additional modes by default to workaround the
+impossibility of supporting each different mode on the supported trigger.
+Example are hardcoding the blink speed to a set interval, enable special
+feature like bypassing blink if some requirements are not met.
+
+A helper led_trigger_can_hw_control() is provided to check if the LED
+can actually run in hw control.
+
+A trigger should first use such helper to verify if hw control is possible,
+use hw_control_is_supported to check if the flags are supported and only at
+the end use hw_control_set to activate hw control.
+
+A trigger can use hw_control_get to check if a LED is already in hw control
+and init their flags.
+
+When the LED is in hw control, no software blink is possible and doing so
+will effectively disable hw control.
 
 Known Issues
 ============
-- 
2.39.2


  parent reply	other threads:[~2023-04-27  0:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-27  0:15 [PATCH 00/11] leds: introduce new LED hw control APIs Christian Marangi
2023-04-27  0:15 ` [PATCH 01/11] leds: add binding for LEDs hw control Christian Marangi
2023-04-27  0:15 ` [PATCH 02/11] leds: add binding to check support for LED " Christian Marangi
2023-04-30 18:08   ` Andrew Lunn
2023-04-27  0:15 ` [PATCH 03/11] leds: add helper function to use trigger in hw blink mode Christian Marangi
2023-04-27  0:15 ` Christian Marangi [this message]
2023-05-11  3:06   ` [PATCH 04/11] Documentation: leds: leds-class: Document new Hardware driven LEDs APIs Bagas Sanjaya
2023-04-27  0:15 ` [PATCH 05/11] leds: trigger: netdev: introduce validating requested mode Christian Marangi
2023-04-30 22:42   ` Andrew Lunn
2023-04-27  0:15 ` [PATCH 06/11] leds: trigger: netdev: add knob to set hw control possible Christian Marangi
2023-04-27  0:15 ` [PATCH 07/11] leds: trigger: netdev: reject interval and device store for hw_control Christian Marangi
2023-05-08 11:31   ` Sascha Hauer
2023-04-27  0:15 ` [PATCH 08/11] leds: trigger: netdev: add support for LED hw control Christian Marangi
2023-04-30 17:55   ` Andrew Lunn
2023-05-02 16:00     ` Christian Marangi
2023-04-27  0:15 ` [PATCH 09/11] leds: trigger: netdev: init mode if hw control already active Christian Marangi
2023-04-27  0:15 ` [PATCH 10/11] leds: trigger: netdev: expose netdev trigger modes in linux include Christian Marangi
2023-04-27  0:15 ` [PATCH 11/11] net: dsa: qca8k: implement hw_control ops Christian Marangi
2023-05-08 12:25 ` [PATCH 00/11] leds: introduce new LED hw control APIs Sascha Hauer
2023-05-08 12:33   ` Christian Marangi
2023-05-08 12:52     ` Sascha Hauer
2023-05-08 13:11       ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230427001541.18704-5-ansuelsmth@gmail.com \
    --to=ansuelsmth@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).