From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacek Anaszewski Subject: Re: [PATCH v2 3/3] leds: rt5033: Add RT5033 Flash led device driver Date: Tue, 13 Oct 2015 10:53:18 +0200 Message-ID: <561CC67E.6050107@samsung.com> References: <1444655578-19806-1-git-send-email-ingi2.kim@samsung.com> <1444655578-19806-4-git-send-email-ingi2.kim@samsung.com> <561BCD71.9020001@samsung.com> <561C7354.9080504@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-reply-to: <561C7354.9080504@samsung.com> Sender: linux-leds-owner@vger.kernel.org To: Ingi Kim Cc: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, sameo@linux.intel.com, lee.jones@linaro.org, rpurdie@rpsys.net, inki.dae@samsung.com, sw0312.kim@samsung.com, beomho.seo@samsung.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org List-Id: devicetree@vger.kernel.org Hi Ingi, On 10/13/2015 04:58 AM, Ingi Kim wrote: > Hi Jacek, > > Thanks for your kind comments > I also append reply below > > On 2015=EB=85=84 10=EC=9B=94 13=EC=9D=BC 00:10, Jacek Anaszewski wrot= e: >> Hi Ingi, >> >> Thanks for the update. Few comments below. >> >> On 10/12/2015 03:12 PM, Ingi Kim wrote: >>> This patch adds device driver of Richtek RT5033 PMIC. >>> The driver supports a current regulated output to drive >>> white LEDs for camera flash. >>> >>> Signed-off-by: Ingi Kim >>> --- >>> drivers/leds/Kconfig | 8 ++ >>> drivers/leds/Makefile | 1 + >>> drivers/leds/leds-rt5033.c | 223 +++++++++++++++++++++++= ++++++++++++++ >>> include/linux/mfd/rt5033-private.h | 49 ++++++++ >>> include/linux/mfd/rt5033.h | 22 +++- >>> 5 files changed, 301 insertions(+), 2 deletions(-) >>> create mode 100644 drivers/leds/leds-rt5033.c >>> >>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig >>> index 42990f2..29613e3 100644 >>> --- a/drivers/leds/Kconfig >>> +++ b/drivers/leds/Kconfig >>> @@ -345,6 +345,14 @@ config LEDS_PCA963X >>> LED driver chip accessed via the I2C bus. Supported >>> devices include PCA9633 and PCA9634 >>> >>> +config LEDS_RT5033 >>> + tristate "LED support for RT5033 PMIC" >>> + depends on LEDS_CLASS_FLASH && OF >>> + depends on MFD_RT5033 >>> + help >>> + This option enables support for on-chip LED driver on >>> + RT5033 PMIC. >>> + >>> config LEDS_WM831X_STATUS >>> tristate "LED support for status LEDs on WM831x PMICs" >>> depends on LEDS_CLASS >>> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile >>> index b503f92..bcc4d93 100644 >>> --- a/drivers/leds/Makefile >>> +++ b/drivers/leds/Makefile >>> @@ -23,6 +23,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE) +=3D leds-c= obalt-qube.o >>> obj-$(CONFIG_LEDS_COBALT_RAQ) +=3D leds-cobalt-raq.o >>> obj-$(CONFIG_LEDS_SUNFIRE) +=3D leds-sunfire.o >>> obj-$(CONFIG_LEDS_PCA9532) +=3D leds-pca9532.o >>> +obj-$(CONFIG_LEDS_RT5033) +=3D leds-rt5033.o >>> obj-$(CONFIG_LEDS_GPIO_REGISTER) +=3D leds-gpio-register.o >>> obj-$(CONFIG_LEDS_GPIO) +=3D leds-gpio.o >>> obj-$(CONFIG_LEDS_LP3944) +=3D leds-lp3944.o >>> diff --git a/drivers/leds/leds-rt5033.c b/drivers/leds/leds-rt5033.= c >>> new file mode 100644 >>> index 0000000..b470c94 >>> --- /dev/null >>> +++ b/drivers/leds/leds-rt5033.c >>> @@ -0,0 +1,223 @@ >>> +/* >>> + * led driver for RT5033 >>> + * >>> + * Copyright (C) 2015 Samsung Electronics, Co., Ltd. >>> + * Ingi Kim >>> + * >>> + * This program is free software; you can redistribute it and/or m= odify >>> + * it under the terms of the GNU General Public License version 2 = as >>> + * published by the Free Software Foundation. >>> + * >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#define RT5033_LED_FLASH_TIMEOUT_MIN 64000 >>> +#define RT5033_LED_FLASH_TIMEOUT_STEPS 32000 >>> +#define RT5033_LED_TORCH_CURRENT_LEVEL_MAX 16 >>> + >>> +/* Macro for getting offset of flash timeout */ >>> +#define GET_TIMEOUT_OFFSET(tm, step) ((tm) / (step) - 2) >>> + >>> +static struct rt5033_led *flcdev_to_led( >>> + struct led_classdev_flash *fled_cdev) >>> +{ >>> + return container_of(fled_cdev, struct rt5033_led, fled_cdev); >>> +} >>> + >>> +static int rt5033_led_brightness_set(struct led_classdev *led_cdev= , >>> + enum led_brightness brightness) >>> +{ >>> + struct led_classdev_flash *fled_cdev =3D lcdev_to_flcdev(led_c= dev); >>> + struct rt5033_led *led =3D flcdev_to_led(fled_cdev); >> >> I assume that you don't use mutex here deliberately? >> > > Actually I'm not sure why flash driver uses mutex. Which flash driver do you have on mind? > In consideration of blocking competition, however, I'd be better to u= se it > [...] >>> + >>> +static int rt5033_led_flash_strobe_set(struct led_classdev_flash *= fled_cdev, >>> + bool state) >>> +{ >>> + struct rt5033_led *led =3D flcdev_to_led(fled_cdev); >>> + u32 flash_tm_reg; >> >> I think that you need a mutex here and in rt5033_led_flash_strobe_se= t. Otherwise following is possible: >> >> Process 1: >> rt5033_led_flash_strobe_set(led_cdev, 1); >> >> regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION1, >> RT5033_FLED_FUNC1_MASK, RT5033_FLED_RESET); >> fled_cdev->led_cdev.brightness =3D LED_OFF; >> >> Process 2: >> led_set_brightness(led_cdev, 1); >> >> fled_cdev->led_cdev.brightness =3D 1; >> >> rt5033_led_brightness_set(led_cdev, LED_FULL); >> >> regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION1, >> RT5033_FLED_FUNC1_MASK, RT5033_FLED_PINCTRL); >> regmap_update_bits(led->regmap, RT5033_REG_FLED_CTRL1, >> RT5033_FLED_CTRL1_MASK, >> (brightness - 1) << 4); >> regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION2, >> RT5033_FLED_CTRL2_MASK, RT5033_FLED_ENFLED); >> >> Process 1: >> regmap_update_bits(led->regmap, RT5033_REG_FLED_STROBE_CTRL2= , >> RT5033_FLED_STRBCTRL2_MASK, flash_tm_reg); >> regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION1, >> RT5033_FLED_FUNC1_MASK, RT5033_FLED_STRB_SEL >> | RT5033_FLED_PINCTRL); >> regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION2, >> RT5033_FLED_FUNC2_MASK, RT5033_FLED_ENFLED >> >> In a result LED class device will report brightness value 1, >> whereas it would be inconsistent with hardware state, since >> flash strobe turns torch mode off. >> >> > > Thanks for your explanation in detail, > I was worried about cases of using shared resource for flash led. > because I thought flash led would be called just from camera or direc= tly itself. > I should consider using mutex You don't provide support for v4l2-flash-led-class and you don't implement external_strobe_set op. Only if the op is implemented a v4l2 device can switch the strobe source from software to external, which allows strobing the flash directly by camera sensor or ISP, but without software interaction. --=20 Best Regards, Jacek Anaszewski