of name clash with other subsystems
headers.
And actually the prefix here should be QCOM_LED_FLASH to avoid ambiguity
with flash memory. If you dropped the vendor prefix then you'd get
possible name clash with led-class-flash.h namespace prefix.
--
Best regards,
Jacek Anaszewski
Sven,
On 2/6/21 2:14 PM, Sven Schuchmann wrote:
Hello Dan,
Von: Jacek Anaszewski
Gesendet: Freitag, 5. Februar 2021 19:37
Hi Pavel,
On 2/5/21 11:23 AM, Pavel Machek wrote:
Hi!
patternProperties:
"(^led-[0-9a-f]$|led)":
@@ -99,6 +104,7 @@ examples:
moment.
Best regards,
Pavel
--
Best regards,
Jacek Anaszewski
num_colors++;
}
For this part:
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
qcom_flash_setup_led(led, temp);
+ if (rc) {
+ for (i = 0; i < parsed_leds; i++)
+
led_classdev_flash_unregister(_dev->leds[i].cdev);
+ pr_debug("Probe failed setting up leds (%d)\n", rc);
+ return rc;
+ }
+
+ parsed_leds++;
+ }
+ leds_dev->num_leds = parsed_leds;
+ return 0;
+}
+
+static int qcom_flash_remove(struct platform_device *pdev)
+{
+ struct qcom_flash_device *leds_dev = platform_get_drvdata(pdev);
+ int i, parsed_leds = leds_dev->num_leds;
+
+ mutex_destroy(_dev->lock);
+ if (leds_dev->flash_boost_reg)
+ regulator_put(leds_dev->flash_boost_reg);
+ if (leds_dev->torch_boost_reg)
+ regulator_put(leds_dev->torch_boost_reg);
+ for (i = 0; i < parsed_leds; i++)
+ led_classdev_flash_unregister(_dev->leds[i].cdev);
+
+ return 0;
+}
+
+static const struct of_device_id qcom_flash_spmi_of_match[] = {
+ { .compatible = "qcom,spmi-flash" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, qcom_flash_spmi_of_match);
+
+static struct platform_driver qcom_flash_driver = {
+ .driver = {
+ .name = "qcom,spmi-flash",
+ .of_match_table = of_match_ptr(qcom_flash_spmi_of_match),
+ },
+ .probe = qcom_flash_probe,
+ .remove = qcom_flash_remove,
+};
+module_platform_driver(qcom_flash_driver);
+
+MODULE_DESCRIPTION("Qualcomm SPMI Flash LED driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Nícolas F. R. A. Prado ");
--
Best regards,
Jacek Anaszewski
ARTUP_DLY_10US 0
+#define QCOM_SPMI_FLASH_STARTUP_DLY_32US 1
+#define QCOM_SPMI_FLASH_STARTUP_DLY_64US 2
+#define QCOM_SPMI_FLASH_STARTUP_DLY_128US 3
+
+#endif
--
Best regards,
Jacek Anaszewski
,
Jacek Anaszewski
-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
d that support to
drivers/media/v4l2-core/v4l2-flash-led-class.c then you could
simplify the code in this driver quite nicely.
But it's up to you.
That being said:
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
/leds/leds-mt6360.yaml
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
wn specification.
So... what is the timelimit on moonlight?
But if it is used for camera illumination, I believe it should be
simply called flash.
Let's keep FLASH reserved for LED flash class devices.
This device has already two other flash iouts.
Also iouts amperage gives clue that they have three different
functions.
--
Best regards,
Jacek Anaszewski
0>;
+ };
+ led@4 {
+ reg = <4>;
+ function = LED_FUNCTION_FLASH;
+ color = ;
+ function-enumerator = <1>;
+ led-max-microamp = <20>;
+ flash-max-microamp = <50>;
+ flash-max-timeout-us = <1024000>;
+ };
+ led@5 {
+ reg = <5>;
+ function = LED_FUNCTION_FLASH;
+ color = ;
+ function-enumerator = <2>;
+ led-max-microamp = <20>;
+ flash-max-microamp = <50>;
+ flash-max-timeout-us = <1024000>;
+ };
+ };
+...
--
Best regards,
Jacek Anaszewski
)
-{};
-
-#endif /* IS_ENABLED(CONFIG_LEDS_CLASS_MULTICOLOR) */
#endif/* _LINUX_MULTICOLOR_LEDS_H_INCLUDED */
Here the same comment as for the patch 1/6.
With that:
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
: the flash LED to set strobe on
It would be good if patch description mentioned also moving the
functions outside of #ifdef block.
With that:
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
OONLIGHT "moonlight"
#define LED_FUNCTION_MTD "mtd"
#define LED_FUNCTION_PANIC "panic"
#define LED_FUNCTION_PROGRAMMING "programming"
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
*parent,
--
Best regards,
Jacek Anaszewski
on enables support for dual Flash LED drivers found on
+ Mediatek MT6360 PMIC.
+ Independent current sources supply for each flash LED support torch
+ and strobe mode.
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
/* IS_ENABLED(CONFIG_LEDS_CLASS_FLASH) */
+
/**
* led_set_flash_strobe - setup flash strobe
* @fled_cdev: the flash LED to set strobe on
--
Best regards,
Jacek Anaszewski
On 11/24/20 8:33 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年11月24日 週二 上午4:52寫道：
On 11/23/20 4:00 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年11月20日 週五 上午6:26寫道：
On 11/19/20 10:57 PM, Pavel Machek wrote:
On Thu 2020-11-19 22:03:14, Jacek Anaszewski wrote:
Hi Pavel, Gene,
On 11/18/20
ell - your driver will
need that.
--
Best regards,
Jacek Anaszewski
On 11/23/20 4:20 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年11月20日 週五 上午6:29寫道：
Hi Gene,
On 11/18/20 11:47 AM, Gene Chen wrote:
From: Gene Chen
Add flash registration with undefined CONFIG_LEDS_CLASS_FLASH
Signed-off-by: Gene Chen
---
include/linux/led-class-flash.h | 36
On 11/23/20 4:00 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年11月20日 週五 上午6:26寫道：
On 11/19/20 10:57 PM, Pavel Machek wrote:
On Thu 2020-11-19 22:03:14, Jacek Anaszewski wrote:
Hi Pavel, Gene,
On 11/18/20 10:37 PM, Pavel Machek wrote:
Hi!
From: Gene Chen
Add LED_COLOR_ID_MOONLIGHT
MEOUT;
+
+ if (fled_stat & fled_short_mask)
+ rfault |= LED_FAULT_SHORT_CIRCUIT;
+
+ if (fled_stat & MT6360_FLEDLVF_MASK)
+ rfault |= LED_FAULT_UNDER_VOLTAGE;
+
+ *fault = rfault;
+ return 0;
+}
+
[...]
--
Best regards,
Jacek Anaszewski
got warning from buildbot.
+ struct led_classdev_flash *fled_cdev)
+{};
+
+#endif /* IS_ENABLED(CONFIG_LEDS_CLASS_FLASH) */
+
/**
* led_set_flash_strobe - setup flash strobe
* @fled_cdev: the flash LED to set strobe on
--
Best regards,
Jacek
On 11/19/20 10:57 PM, Pavel Machek wrote:
On Thu 2020-11-19 22:03:14, Jacek Anaszewski wrote:
Hi Pavel, Gene,
On 11/18/20 10:37 PM, Pavel Machek wrote:
Hi!
From: Gene Chen
Add LED_COLOR_ID_MOONLIGHT definitions
Why is moonlight a color? Camera flashes are usually white, no?
At least
LED_FUNCTION_MOONLIGHT, it was evidently too late for me that evening...
--
Best regards,
Jacek Anaszewski
= MT6360_LED_ISNK1 && reg <= MT6360_LED_ISNKML))
+ ret = mt6360_init_isnk_properties(led, _data);
+ else
+ ret = mt6360_init_flash_properties(led, _data);
+
+ if (ret)
+ goto out_flash_release;
+
+ ret = mt6360_led_register(>dev, led, _data);
+ if (ret)
+ goto out_flash_release;
+
+ i++;
+ }
+
+ platform_set_drvdata(pdev, priv);
+ return 0;
+
+out_flash_release:
+ mt6360_v4l2_flash_release(priv);
+ return ret;
+}
+
+static int mt6360_led_remove(struct platform_device *pdev)
+{
+ struct mt6360_priv *priv = platform_get_drvdata(pdev);
+
+ mt6360_v4l2_flash_release(priv);
+ return 0;
+}
+
+static const struct of_device_id __maybe_unused mt6360_led_of_id[] = {
+ { .compatible = "mediatek,mt6360-led", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, mt6360_led_of_id);
+
+static struct platform_driver mt6360_led_driver = {
+ .driver = {
+ .name = "mt6360-led",
+ .of_match_table = mt6360_led_of_id,
+ },
+ .probe = mt6360_led_probe,
+ .remove = mt6360_led_remove,
+};
+module_platform_driver(mt6360_led_driver);
+
+MODULE_AUTHOR("Gene Chen ");
+MODULE_DESCRIPTION("MT6360 LED Driver");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
or property set to LED_COLOR_ID_RGB, or three separate
LEDs.
Effectively, you should have two separate DT examples here to make it
clear: one for the case with three LED class devices and one with
LED multicolor class device.
+ };
+...
--
Best regards,
Jacek Anaszewski
On 11/16/20 11:01 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年10月31日 週六 上午6:34寫道：
On 10/30/20 9:51 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年10月28日 週三 上午1:28寫道：
On 10/27/20 10:28 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年10月21日 週三 上午5:47寫道：
On 10/20/20 8:44 AM, Gene Chen wrote
Hi Evgeiny,
Thank you for the patch.
There is a typo in the subject: s/hangle/handle/
Otherwise:
Acked-by: Jacek Anaszewski
On 11/13/20 5:06 PM, Baskov Evgeiny wrote:
If an error happens in jpeg_get_drv_data(), i.e. match fails,
jpeg->variant field is NULL, so we cannot acc
++
3 files changed, 1361 insertions(+)
create mode 100644 drivers/leds/leds-qpnp.c
--
Best regards,
Jacek Anaszewski
drivers/leds/flash/leds-rt4505.c
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
On 10/30/20 9:51 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年10月28日 週三 上午1:28寫道：
On 10/27/20 10:28 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年10月21日 週三 上午5:47寫道：
On 10/20/20 8:44 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年10月9日 週五 上午5:51寫道：
Hi Gene,
On 10/7/20 3:42 AM, Gene Chen
intensity is set
- to. The percentage is calculated for each grouped LED via the
- equation below:
--
Best regards,
Jacek Anaszewski
On 10/28/20 5:57 AM, ChiYuan Huang wrote:
Hi,
Jacek Anaszewski 於 2020年10月28日 週三 上午12:40寫道：
Hi Pavel, ChiYuan,
On 10/27/20 9:29 AM, Pavel Machek wrote:
Hi!
From: ChiYuan Huang
Add support for RT4505 flash led controller. It can support up to 1.5A
flash current with hardware timeout
On 10/27/20 10:28 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年10月21日 週三 上午5:47寫道：
On 10/20/20 8:44 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年10月9日 週五 上午5:51寫道：
Hi Gene,
On 10/7/20 3:42 AM, Gene Chen wrote:
From: Gene Chen
Add MT6360 LED driver include 2-channel Flash LED
th your flash?
The locking is needed since this can be called via led_set_brightness()
from any place in the kernel, and especially from triggers.
--
Best regards,
Jacek Anaszewski
On 10/20/20 8:44 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年10月9日 週五 上午5:51寫道：
Hi Gene,
On 10/7/20 3:42 AM, Gene Chen wrote:
From: Gene Chen
Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode,
3-channel RGB LED support Register/Flash/Breath Mode, and 1-channel
for each flash LED support torch
+ and strobe mode.
+
--
Best regards,
Jacek Anaszewski
ed-max-microamp = <20>;
+ flash-max-microamp = <50>;
+ flash-max-timeout-us = <1024000>;
+ };
+ };
+...
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
--
Best regards,
Jacek Anaszewski
uled setups. In such cases, I'll just laugh.)
If you know or can find out someone using it with more than 4 CPUs, I
can obviously raise the limit before the merge.
--
Best regards,
Jacek Anaszewski
On 9/22/20 10:41 PM, Jacek Anaszewski wrote:
Hi Pavel,
On 9/22/20 12:42 AM, Pavel Machek wrote:
Hi!
Can I get details of your setup?
I don't use this trigger, but I can imagine that someone does.
Well, if someone exists, we can increase the limit, or convince them
to change their setup
On 9/24/20 8:21 AM, Gene Chen wrote:
Jacek Anaszewski 於 2020年9月24日 週四 上午5:49寫道：
Hi Gene,
Thank you for the update. I have some more comments below.
On 9/23/20 2:50 PM, Gene Chen wrote:
From: Gene Chen
Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode,
and 4
+
+ i++;
+ }
+
+ platform_set_drvdata(pdev, priv);
+ return 0;
+
+out_flash_release:
+ mt6360_v4l2_flash_release(priv);
+ return ret;
+}
+
+static int mt6360_led_remove(struct platform_device *pdev)
+{
+ struct mt6360_priv *priv = platform_get_drvdata(pdev);
+
+ mt6360_v4l2_flash_release(priv);
+ return 0;
+}
+
+static const struct of_device_id __maybe_unused mt6360_led_of_id[] = {
+ { .compatible = "mediatek,mt6360-led", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, mt6360_led_of_id);
+
+static struct platform_driver mt6360_led_driver = {
+ .driver = {
+ .name = "mt6360-led",
+ .of_match_table = mt6360_led_of_id,
+ },
+ .probe = mt6360_led_probe,
+ .remove = mt6360_led_remove,
+};
+module_platform_driver(mt6360_led_driver);
+
+MODULE_AUTHOR("Gene Chen ");
+MODULE_DESCRIPTION("MT6360 LED Driver");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
the BIN_ATTR
conversion would not be neccessary...)
The limitation you proposed breaks the trigger on many plafforms.
--
Best regards,
Jacek Anaszewski
rked year ago to remove PAGE_SIZE limit,
and I even applied it to my for-next tree, but that was at
the time of handling maintainership to yourself, and you
seem to not have picked that commit.
Was that intentional? We had even Greg's ack [0].
[0] https://lkml.org/lkml/2019/9/30/397
--
Best regards,
Jacek Anaszewski
On 9/20/20 7:33 PM, Marek Behun wrote:
On Sun, 20 Sep 2020 18:55:28 +0200
Jacek Anaszewski wrote:
On 9/20/20 5:39 PM, Marek Behun wrote:
On Sun, 20 Sep 2020 16:15:09 +0200
Jacek Anaszewski wrote:
Hi Pavel,
On 9/19/20 11:38 AM, Pavel Machek wrote:
commit
On 9/20/20 5:39 PM, Marek Behun wrote:
On Sun, 20 Sep 2020 16:15:09 +0200
Jacek Anaszewski wrote:
Hi Pavel,
On 9/19/20 11:38 AM, Pavel Machek wrote:
commit 318681d3e019e39354cc6c2155a7fd1bb8e8084d
Author: Pavel Machek
Date: Sat Sep 19 11:34:58 2020 +0200
ledtrig-cpu: Limit to 4
;I doubt" is not a sufficient argument.
+ continue;
+
snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
led_trigger_register_simple(trig->name, >_trig);
--
Best regards,
Jacek Anaszewski
On 9/16/20 2:15 AM, Marek Behun wrote:
On Tue, 15 Sep 2020 23:35:25 +0200
Jacek Anaszewski wrote:
Hi Marek,
On 9/15/20 5:26 PM, Marek Behún wrote:
Allow setting netdev LED trigger as default when given LED DT node has
the `trigger-sources` property pointing to a node corresponding
arse(), which makes sense only if trigger will be
default, I presume.
See timer_trig_activate() in drivers/leds/trigger/ledtrig-timer.c
for reference.
--
Best regards,
Jacek Anaszewski
Hi Alexander,
On 9/15/20 11:14 AM, Alexander Dahl wrote:
Hello Jacek,
thanks for your feedback. See below.
Am Freitag, 11. September 2020, 23:26:43 CEST schrieb Jacek Anaszewski:
On 9/11/20 5:40 PM, Alexander Dahl wrote:
The function 'led_compose_name()' is called
y && !init_data->devicename) {
dev_err(parent, "Mandatory device name is missing");
return -EINVAL;
--
Best regards,
Jacek Anaszewski
be set to torch or flash, but in LED subsystem we don't have
the counterpart.
--
Best regards,
Jacek Anaszewski
as reason why I asked for not
supporting strobe from sysfs.
What you say now is even more confusing when we look at your ack
under this patch:
commit 7aea8389a77abf9fde254aca2434a605c7704f58
Author: Jacek Anaszewski
Date: Fri Jan 9 07:22:51 2015 -0800
leds: Add LED Flash class exten
m_get_drvdata(pdev);
+ int i;
+
+ for (i = MT6360_LED_FLASH1; i <= MT6360_LED_FLASH2; i++) {
+ struct mt6360_led *led = priv->leds[i];
+
+ if (led && led->v4l2_flash)
+ v4l2_flash_release(led->v4l2_flash);
+
+ }
You're using this for loop twice, so it would be nice to wrap
it with a function to avoid code redundancy.
+
+ return 0;
+}
+
+static const struct of_device_id __maybe_unused mt6360_led_of_id[] = {
+ { .compatible = "mediatek,mt6360-led", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mt6360_led_of_id);
+
+static struct platform_driver mt6360_led_driver = {
+ .driver = {
+ .name = "mt6360-led",
+ .of_match_table = mt6360_led_of_id,
+ },
+ .probe = mt6360_led_probe,
+ .remove = mt6360_led_remove,
+};
+module_platform_driver(mt6360_led_driver);
+
+MODULE_AUTHOR("Gene Chen ");
+MODULE_DESCRIPTION("MT6360 Led Driver");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
en needed.
I agree that one driver is enough.
But we should not need flash_strobe file in sysfs. Simply use V4L2 for
that.
Apart from the fact that we can't remove it from LED flash class ABI
now, why would you like to prevent the user from exploiting main feature
of the hardware?
--
Best regar
is one hardware driver needed, the V4L2 Flash layer just takes over
control over it when needed.
--
Best regards,
Jacek Anaszewski
cense for the yaml file. You can expect that for v4.
Stay tuned
Alex
--
Best regards,
Jacek Anaszewski
Hi Alexander,
On 9/4/20 9:53 AM, Alexander Dahl wrote:
Hi Jacek,
Am Dienstag, 1. September 2020, 23:08:09 CEST schrieb Jacek Anaszewski:
Hi Alexander,
Thanks for the v2.
On 8/31/20 11:02 PM, Alexander Dahl wrote:
Hei hei,
for leds-gpio you can use the properties 'function' and 'color
| 9 +-
3 files changed, 93 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/leds/leds-pwm.txt
create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm.yaml
For both patches:
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
Hi Alexander,
On 8/28/20 9:00 AM, Alexander Dahl wrote:
Hello Jacek,
Am Donnerstag, 27. August 2020, 23:28:45 CEST schrieb Jacek Anaszewski:
On 8/26/20 11:37 AM, Alexander Dahl wrote:
From: Alexander Dahl
If LEDs are configured through device tree and the property 'label' is
omitted
4 files changed, 742 insertions(+)
--
Best regards,
Jacek Anaszewski
dev_err(dev, "failed to register PWM led for %s: %d\n",
led->name, ret);
This part looks good, but corresponding update of
Documentation/devicetree/bindings/leds/leds-pwm.txt is needed as well.
It would be good to switch to yaml by this occassion.
--
Best regards,
Jacek Anaszewski
It don't have enough time for reviewing patches and thus don't
want to be listed as regular LED maintainer. Nonetheless I may still
give a review from time to time.
Signed-off-by: Jacek Anaszewski
---
MAINTAINERS | 2 --
1 file changed, 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
G_LEDS_BRIGHTNESS_HW_CHANGED
@@ -345,6 +352,9 @@ struct led_trigger {
int (*activate)(struct led_classdev *led_cdev);
void(*deactivate)(struct led_classdev *led_cdev);
+ /* LED-private triggers have this set */
+ struct led_hw_trigger_type *trigger_type
.
This is normally used for motherboard lightning, right? I believe this
is getting common on gaming boards, and we want common support for
that.
I agree.
--
Best regards,
Jacek Anaszewski
got the names right so please let me know if that
is not correct.
You miss LED function, that should be in the second section.
--
Best regards,
Jacek Anaszewski
On 7/11/20 10:24 PM, Pavel Machek wrote:
On Sat 2020-07-11 19:19:22, Jacek Anaszewski wrote:
On 7/11/20 5:57 PM, Pavel Machek wrote:
Hi!
Add the multicolor brightness call back to support the multicolor
framework. This call back allows setting brightness on grouped channels
Extra space
On 7/11/20 5:57 PM, Pavel Machek wrote:
Hi!
Add the multicolor brightness call back to support the multicolor
framework. This call back allows setting brightness on grouped channels
Extra space before "brightness".
And before "This".
--
Best regards,
Jacek Anaszewski
ork(_cdev->set_brightness_work);
}
EXPORT_SYMBOL_GPL(led_classdev_suspend);
Acked-by: Jacek Anaszewski
Pavel, this needs to go to stable as well, so let's add the tag:
Fixes: 81fe8e5b73e3 ("leds: core: Add led_set_brightness_nosleep{nopm}
functions")
--
Best regards,
Jacek Anaszewski
This function is "nopm" for a reason - we do not make here any
pm management related operations.
Instead of that, please just add
flush_work(_cdev->set_brightness_work);
at the end of led_classdev_suspend()
in drivers/leds/led-class.c.
--
Best regards,
Jacek Anaszewski
Dan,
On 6/21/20 10:24 PM, Jacek Anaszewski wrote:
Dan,
On 6/21/20 4:12 PM, Dan Murphy wrote:
Jacek
On 6/19/20 5:10 PM, Jacek Anaszewski wrote:
Dan,
On 6/19/20 6:35 PM, Dan Murphy wrote:
Jacek
On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
Dan
Dan,
On 6/21/20 4:12 PM, Dan Murphy wrote:
Jacek
On 6/19/20 5:10 PM, Jacek Anaszewski wrote:
Dan,
On 6/19/20 6:35 PM, Dan Murphy wrote:
Jacek
On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
Dan,
On 6/18/20 11:44 PM, Dan Murphy wrote:
Jacek
On 6
Dan,
On 6/19/20 6:35 PM, Dan Murphy wrote:
Jacek
On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
Dan,
On 6/18/20 11:44 PM, Dan Murphy wrote:
Jacek
On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
Dan,
On 6/18/20 12:33 AM, Dan Murphy wrote:
Jacek
On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
Dan,
On 6/18/20 11:44 PM, Dan Murphy wrote:
Jacek
On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
Dan,
On 6/18/20 12:33 AM, Dan Murphy wrote:
Jacek
On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
Dan,
On 6/17/20 9:22 PM, Dan Murphy wrote:
Pavel
Dan,
On 6/18/20 11:44 PM, Dan Murphy wrote:
Jacek
On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
Dan,
On 6/18/20 12:33 AM, Dan Murphy wrote:
Jacek
On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
Dan,
On 6/17/20 9:22 PM, Dan Murphy wrote:
Pavel/Jacek
On 6/17/20 11:28 AM, kernel test robot
Dan,
On 6/18/20 12:33 AM, Dan Murphy wrote:
Jacek
On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
Dan,
On 6/17/20 9:22 PM, Dan Murphy wrote:
Pavel/Jacek
On 6/17/20 11:28 AM, kernel test robot wrote:
Hi Dan,
I love your patch! Yet something to improve:
[auto build test ERROR on pavel-linux
EDS_CLASS_MULTI_COLOR
depends on OF
select FW_LOADER
select FW_LOADER_USER_HELPER
--
Best regards,
Jacek Anaszewski
Dan,
On 6/8/20 4:34 PM, Dan Murphy wrote:
Jacek
On 6/6/20 2:59 PM, Jacek Anaszewski wrote:
Dan,
On 6/6/20 6:39 PM, Dan Murphy wrote:
Pavek
Thanks for the review
On 6/6/20 10:53 AM, Pavel Machek wrote:
Hi!
Introduce a multicolor class that groups colored LEDs
within a LED node
Hi Dennis,
On 6/8/20 8:32 AM, Denis Osterland-Heim wrote:
Hi Jacek,
is your ack still valid for the new versions of the patch-set?
Due to the changes I made, I am not sure.
Yes, you can keep it.
--
Best regards,
Jacek Anaszewski
color: hue and lightness. The former is
controlled via the intensity file and the latter is controlled
via brightness file.
Acked-by: Jacek Anaszewski
Signed-off-by: Dan Murphy
diff --git a/Documentation/ABI/testing/sysfs-class-led-multicolor
b/Documentation/ABI/testing/sysfs-class-led
egister(_cdev->fl_cdev);
+ }
+ return ret;
+}
+
+static int mt6360_led_remove(struct platform_device *pdev)
+{
+ struct mt6360_led_data *mld = platform_get_drvdata(pdev);
+ struct mt6360_fled_classdev *mtfled_cdev;
+ int i;
+
+ for (i = 0; i < MT6360_FLED_MAX; i++) {
+ mtfled_cdev = mld->mtfled_cdev + i;
+ v4l2_flash_release(mtfled_cdev->v4l2_flash);
+ led_classdev_flash_unregister(_cdev->fl_cdev);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id __maybe_unused mt6360_led_of_id[] = {
+ { .compatible = "mediatek,mt6360_led", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mt6360_led_of_id);
+
+static struct platform_driver mt6360_led_driver = {
+ .driver = {
+ .name = "mt6360_led",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mt6360_led_of_id),
+ },
+ .probe = mt6360_led_probe,
+ .remove = mt6360_led_remove,
+};
+module_platform_driver(mt6360_led_driver);
+
+MODULE_AUTHOR("Gene Chen ");
+MODULE_DESCRIPTION("MT6360 Led Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h
index ea13040..2b81ab5 100644
--- a/include/linux/mfd/mt6360.h
+++ b/include/linux/mfd/mt6360.h
@@ -29,6 +29,11 @@ struct mt6360_pmu_data {
unsigned int chip_rev;
};
+struct mt6360_pmu_irq_desc {
+ const char *name;
+ irq_handler_t irq_handler;
+};
+
/* PMU register defininition */
#define MT6360_PMU_DEV_INFO (0x00)
#define MT6360_PMU_CORE_CTRL1 (0x01)
@@ -236,5 +241,4 @@ struct mt6360_pmu_data {
#define CHIP_VEN_MASK (0xF0)
#define CHIP_VEN_MT6360 (0x50)
#define CHIP_REV_MASK (0x0F)
-
#endif /* __MT6360_H__ */
--
Best regards,
Jacek Anaszewski
cycle in linux-next, especially taking into
account addition of new sysfs interface, that is bit quirky.
Effectively 5.8 seems to not have been viable since few weeks.
--
Best regards,
Jacek Anaszewski
of solving this in more generic way [0],
but you opposed then [1]. Just for the record.
[0]
https://lore.kernel.org/linux-leds/20170913175400.42744-1-dtw...@google.com/
[1] https://lore.kernel.org/linux-leds/20170914205804.GA24339@amd/
--
Best regards,
Jacek Anaszewski
and the latter is controlled
via brightness file.
Acked-by: Jacek Anaszewski
Signed-off-by: Dan Murphy
---
[...]
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -30,6 +30,17 @@ config LEDS_CLASS_FLASH
for the flash related features of a LED device. It can be built
mutex_destroy(>mutex);
+
+ return 0;
+}
+
+static const struct of_device_id aw2013_match_table[] = {
+ { .compatible = "awinic,aw2013", },
+ { /* sentinel */ },
+};
+
+MODULE_DEVICE_TABLE(of, aw2013_match_table);
+
+static struct i2c_driver aw2013_driver = {
+ .driver = {
+ .name = "leds-aw2013",
+ .of_match_table = of_match_ptr(aw2013_match_table),
+ },
+ .probe_new = aw2013_probe,
+ .remove = aw2013_remove,
+};
+
+module_i2c_driver(aw2013_driver);
+
+MODULE_AUTHOR("Nikita Travkin ");
+MODULE_DESCRIPTION("AW2013 LED driver");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
Dan,
On 5/3/20 2:32 PM, Dan Murphy wrote:
Add DT bindings for the LEDs multicolor class framework.
Add multicolor ID to the color ID list for device tree bindings.
CC: Rob Herring
Acked-by: Pavel Machek
Acked-by: Jacek Anaszewski
Signed-off-by: Dan Murphy
---
.../bindings/leds/leds-class
:
depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
It is required to enforce building driver as a module if
LED mc framework is configured as such.
With this (and DT bindings nits) addressed, for patches 1-6:
Acked-by: Jacek Anaszewski
It's been a long journey. Thank you for your
Dan,
Thanks for improving the bindings. Now we have one indentation
related issue, please look below at the example.
On 4/29/20 10:28 PM, Dan Murphy wrote:
Add DT bindings for the LEDs multicolor class framework.
Add multicolor ID to the color ID list for device tree bindings.
CC: Rob Herring
Hi Dan,
Thanks for the conversion, but now the binding example is missing.
In Documentation/devicetree/bindings/leds/common.yaml we do have
examples.
Best regards,
Jacek Anaszewski
On 4/29/20 2:56 PM, Dan Murphy wrote:
Add DT bindings for the LEDs multicolor class framework.
Add multicolor ID
+
8 files changed, 209 insertions(+), 47 deletions(-)
For patches 10/16 - 16/16:
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
5 = 69
+adjusted_green_value = 128 * 43/255 = 21
+adjusted_blue_value = 128 * 226/255 = 113
+
+Reading the parent brightness file will return the current brightness value of
Ditto.
--
Best regards,
Jacek Anaszewski
/devicetree/bindings/leds/leds-class-multicolor.txt
b/Documentation/devicetree/bindings/leds/leds-class-multicolor.txt
new file mode 100644
index ..4b1bd82f2a42
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.txt
Why isn't it yaml?
--
Best regards,
Jacek
d_cdev;
+ led_cdev->brightness_set_blocking = lp50xx_brightness_set;
+ ret =
devm_led_classdev_multicolor_register_ext(>client->dev,
+ >mc_cdev,
+ _data);
[...]
--
Best regards,
Jacek Anaszewski
Dan,
On 10/22/19 6:37 PM, Dan Murphy wrote:
> Jacek
>
> On 10/18/19 4:56 PM, Jacek Anaszewski wrote:
>> On 10/18/19 11:48 PM, Jacek Anaszewski wrote:
>>> Dan,
>> + ret = lp5xx_parse_channel_child(child, cfg, i);
>>> I went into details of this parsin
Matti,
On 10/22/19 2:40 PM, Vaittinen, Matti wrote:
> Hello Jacek,
>
> Thanks for the clarifications. I think I now understand the LED
> subsystem a bit better :)
>
> On Mon, 2019-10-21 at 21:09 +0200, Jacek Anaszewski wrote:
>> Hi Matti,
>>
>> On 10/21
> As I mentioned above, this driver is currently not using DT at all.
> Reason why it does not is that I didn't know all the LEDs are usually
> having own DT entries/drivers.
>
> But there is actually reason for bundling the LEDs to same driver. What
> is not shown in driver is that LEDs can be controlled by PMIC state
> machine so that they are indicating charger states. Other option is
This can be handled by the LED trigger that your driver should expose.
On activation the trigger would setup the hardware to control the
LEDs. But that can be covered later.
> driving LEDs using this driver - but forcing one of the LEDs will cause
> also the other LED to be under SW control. Eg, one can't control just
> single LED using SW, its both of them or none.
So this limitation will have to by documented in the trigger ABI.
>> This is how it is commonly done.
>>
>> You can reference the LM36274 led driver as this is a MFD device to
>> the
>> ti-lmu.c in the MFD directory.
>
> Thanks for pointing this out. I will gladly see how others have it
> implemented! I just would like to know if the DT binding is really a
> must? In this case I am unsure what LED related extra information we
> could really give from DT (for this specific device).
>
> I just checked the lm36274 you mentioned. I see that also lm36274 do
> parse the dt and set the name itself (so maybe the led_class is not
> doing this after all?) - although the name setting code in lm36274 is a
> bit peculiar as it loops through all child nodes and overwrites the old
> name if it finds more than one "label" properties from nodes (if I read
> the code correctly).
>
> In any case I am unsure what is the benefit from using DT and adding
> the DT parsing code for this PMIC's LEDs. I could understand DT usage
> if LED class handled dt parsing and if there was something to configure
> in BD71828 LEDs - but I see no such benefits in this case.
I hope I was able to clarify most of your doubts.
--
Best regards,
Jacek Anaszewski
lp55xx_map_channel() since random
access to array elements will be possible via lookup tables mapping
colors to array element id.
And regarding my amendments to the DT parser - attached is the
patch for your patch, that is compile-tested.
> +
> +max_intensity_err_out:
> + kfree(max_intensity_fi
{
> dev_err(dev, "led register err: %d\n", ret);
> return ret;
> @@ -525,6 +592,82 @@ void lp55xx_unregister_sysfs(struct lp55xx_chip *chip)
> }
> EXPORT_SYMBOL_GPL(lp55xx_unregister_sysfs);
>
--
Best regards,
Jacek Anaszewski
1 - 100 of 3275 matches
Mail list logo
