[PATCH/RFC v4 07/11] media-ctl: libv4l2subdev: add VYUY8_2X8 mbus code
The VYUY8_2X8 media bus format is the only one supported
by the S5C73M3 camera sensor, that is a part of the media
device on the Exynos4412-trats2 board.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
---
utils/media-ctl/libv4l2subdev.c |1 +
1 file changed, 1 insertion(+)
diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index 4c5fb12..a96ed7a 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -704,6 +704,7 @@ static struct {
{ "YUYV", V4L2_MBUS_FMT_YUYV8_1X16 },
{ "YUYV1_5X8", V4L2_MBUS_FMT_YUYV8_1_5X8 },
{ "YUYV2X8", V4L2_MBUS_FMT_YUYV8_2X8 },
+ { "VYUY8_2X8", V4L2_MBUS_FMT_VYUY8_2X8 },
{ "UYVY", V4L2_MBUS_FMT_UYVY8_1X16 },
{ "UYVY1_5X8", V4L2_MBUS_FMT_UYVY8_1_5X8 },
{ "UYVY2X8", V4L2_MBUS_FMT_UYVY8_2X8 },
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] media/platform: fix querycap
Hi Hans, Thanks for the patch. On 11/24/2014 10:37 AM, Hans Verkuil wrote: From: Hans Verkuil Querycap shouldn't set the version field (the core does that for you), but it should set the device_caps field. In addition, remove the CAPTURE and OUTPUT caps for M2M devices. These were already slated for removal, so it's time to do so. Signed-off-by: Hans Verkuil Cc: Lad, Prabhakar Cc: Kamil Debski Cc: Jacek Anaszewski Acked-by: Jacek Anaszewski Best Regards, Jacek Anaszewski --- drivers/media/platform/davinci/vpbe_display.c | 1 - drivers/media/platform/davinci/vpfe_capture.c | 4 ++-- drivers/media/platform/s5p-g2d/g2d.c | 10 ++ drivers/media/platform/s5p-jpeg/jpeg-core.c | 9 ++--- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 6 ++ drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 6 ++ 6 files changed, 10 insertions(+), 26 deletions(-) diff --git a/drivers/media/platform/davinci/vpbe_display.c b/drivers/media/platform/davinci/vpbe_display.c index 78b9ffe..21a5a56 100644 --- a/drivers/media/platform/davinci/vpbe_display.c +++ b/drivers/media/platform/davinci/vpbe_display.c @@ -639,7 +639,6 @@ static int vpbe_display_querycap(struct file *file, void *priv, struct vpbe_layer *layer = video_drvdata(file); struct vpbe_device *vpbe_dev = layer->disp_dev->vpbe_dev; - cap->version = VPBE_DISPLAY_VERSION_CODE; cap->device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING; cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS; snprintf(cap->driver, sizeof(cap->driver), "%s", diff --git a/drivers/media/platform/davinci/vpfe_capture.c b/drivers/media/platform/davinci/vpfe_capture.c index 3d0e3ae..271c460 100644 --- a/drivers/media/platform/davinci/vpfe_capture.c +++ b/drivers/media/platform/davinci/vpfe_capture.c @@ -930,8 +930,8 @@ static int vpfe_querycap(struct file *file, void *priv, v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_querycap\n"); - cap->version = VPFE_CAPTURE_VERSION_CODE; - cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING; + cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING; + cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS; strlcpy(cap->driver, CAPTURE_DRV_NAME, sizeof(cap->driver)); strlcpy(cap->bus_info, "VPFE", sizeof(cap->bus_info)); strlcpy(cap->card, vpfe_dev->cfg->card_name, sizeof(cap->card)); diff --git a/drivers/media/platform/s5p-g2d/g2d.c b/drivers/media/platform/s5p-g2d/g2d.c index d79e214..51e4edc 100644 --- a/drivers/media/platform/s5p-g2d/g2d.c +++ b/drivers/media/platform/s5p-g2d/g2d.c @@ -297,14 +297,8 @@ static int vidioc_querycap(struct file *file, void *priv, strncpy(cap->driver, G2D_NAME, sizeof(cap->driver) - 1); strncpy(cap->card, G2D_NAME, sizeof(cap->card) - 1); cap->bus_info[0] = 0; - cap->version = KERNEL_VERSION(1, 0, 0); - /* -* This is only a mem-to-mem video device. The capture and output -* device capability flags are left only for backward compatibility -* and are scheduled for removal. -*/ - cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT | - V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING; + cap->device_caps = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING; + cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS; return 0; } diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c index 6fcc7f0..d6f75b1 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c @@ -1001,13 +1001,8 @@ static int s5p_jpeg_querycap(struct file *file, void *priv, sizeof(cap->card)); } cap->bus_info[0] = 0; - /* -* This is only a mem-to-mem video device. The capture and output -* device capability flags are left only for backward compatibility -* and are scheduled for removal. -*/ - cap->capabilities = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_M2M | - V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT; + cap->device_caps = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_M2M; + cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS; return 0; } diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c index 74bcec8..c6c3452 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c @@ -269,15 +269,13 @@ static int vidioc_querycap(struct file *file, void *priv, strncpy(cap->driver, dev->plat_dev->name, sizeof(cap->driver) - 1); strncpy(cap->car
Re: [PATCH/RFC v4 01/11] mediactl: Introduce v4l2_subdev structure
Hi Sakari,
On 11/25/2014 12:36 PM, Sakari Ailus wrote:
Hi Jacek,
Thank you for the updated patchset.
On Fri, Nov 21, 2014 at 05:14:30PM +0100, Jacek Anaszewski wrote:
Add struct v4l2_subdev as a representation of the v4l2 sub-device
related to a media entity. Add sd property, the pointer to
the newly introduced structure, to the struct media_entity
and move fd property to it.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
---
utils/media-ctl/libmediactl.c | 30 +-
utils/media-ctl/libv4l2subdev.c | 34 +-
utils/media-ctl/mediactl-priv.h |5 +
utils/media-ctl/mediactl.h | 22 ++
4 files changed, 69 insertions(+), 22 deletions(-)
diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index ec360bd..53921f5 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -511,7 +511,6 @@ static int media_enum_entities(struct media_device *media)
entity = &media->entities[media->entities_count];
memset(entity, 0, sizeof(*entity));
- entity->fd = -1;
I think I'd definitely leave the fd to the media_entity itself. Not all the
entities are sub-devices, even right now.
I am aware of it, I even came across this issue while implementing the
function v4l2_subdev_apply_pipeline_fmt. I added suitable comment
explaining why the entity not being a sub-device has its representation.
I moved the fd out of media_entity by following Laurent's message [1],
where he mentioned this, however I think that it would be indeed
best if it remained intact.
entity->info.id = id | MEDIA_ENT_ID_FLAG_NEXT;
entity->media = media;
@@ -529,11 +528,13 @@ static int media_enum_entities(struct media_device *media)
entity->pads = malloc(entity->info.pads *
sizeof(*entity->pads));
entity->links = malloc(entity->max_links *
sizeof(*entity->links));
- if (entity->pads == NULL || entity->links == NULL) {
+ entity->sd = calloc(1, sizeof(*entity->sd));
+ if (entity->pads == NULL || entity->links == NULL || entity->sd
== NULL) {
ret = -ENOMEM;
break;
}
+ entity->sd->fd = -1;
media->entities_count++;
if (entity->info.flags & MEDIA_ENT_FL_DEFAULT) {
@@ -704,8 +705,9 @@ void media_device_unref(struct media_device *media)
free(entity->pads);
free(entity->links);
- if (entity->fd != -1)
- close(entity->fd);
+ if (entity->sd->fd != -1)
+ close(entity->sd->fd);
+ free(entity->sd);
}
free(media->entities);
@@ -726,13 +728,17 @@ int media_device_add_entity(struct media_device *media,
if (entity == NULL)
return -ENOMEM;
+ entity->sd = calloc(1, sizeof(*entity->sd));
+ if (entity->sd == NULL)
+ return -ENOMEM;
+
media->entities = entity;
media->entities_count++;
entity = &media->entities[media->entities_count - 1];
memset(entity, 0, sizeof *entity);
- entity->fd = -1;
+ entity->sd->fd = -1;
entity->media = media;
strncpy(entity->devname, devnode, sizeof entity->devname);
entity->devname[sizeof entity->devname - 1] = '\0';
@@ -955,3 +961,17 @@ int media_parse_setup_links(struct media_device *media,
const char *p)
return *end ? -EINVAL : 0;
}
+
+/*
-
+ * Media entity access
+ */
+
+int media_entity_get_fd(struct media_entity *entity)
+{
+ return entity->sd->fd;
+}
+
+void media_entity_set_fd(struct media_entity *entity, int fd)
+{
+ entity->sd->fd = fd;
+}
You access the fd directly now inside the library. I don't think there
should be a need to set it.
struct media_entity is defined in mediactl-priv.h, whose name implies
that it shouldn't be made public. Thats way I implemented the setter.
I use it in the libv4l-exynos4-camera.c.
diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index 8015330..09e0081 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -41,11 +41,11 @@
int v4l2_subdev_open(struct media_entity *entity)
{
- if (entity->fd != -1)
+ if (entity->sd->fd != -1)
return 0;
- entity->fd = open(entity->devname, O_RDWR);
- if (entity->fd == -1) {
+ entity->sd->fd = open(entity->devname, O_RDWR);
+ if (entity->sd->fd == -1
[PATCH/RFC v8 13/14] of: Add Skyworks Solutions, Inc. vendor prefix
Use "skyworks" as the vendor prefix for the Skyworks Solutions, Inc. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index c177cd7..3006825 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -137,6 +137,7 @@ ricoh Ricoh Co. Ltd. rockchip Fuzhou Rockchip Electronics Co., Ltd samsungSamsung Semiconductor sandiskSandisk Corporation +skyworks Skyworks Solutions, Inc. sbsSmart Battery System schindler Schindler seagateSeagate Technology PLC -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v8 14/14] DT: Add documentation for the Skyworks AAT1290
This patch adds device tree binding documentation for
1.5A Step-Up Current Regulator for Flash LEDs.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc:
---
.../devicetree/bindings/leds/leds-aat1290.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-aat1290.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-aat1290.txt
b/Documentation/devicetree/bindings/leds/leds-aat1290.txt
new file mode 100644
index 000..8f001dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-aat1290.txt
@@ -0,0 +1,17 @@
+* Skyworks Solutions, Inc. AAT1290 Current Regulator for Flash LEDs
+
+Required properties:
+
+- compatible : should be "skyworks,aat1290"
+- gpios : two gpio pins in order FLEN, EN/SET
+- flash-timeout-microsec : maximum flash timeout in microseconds -
+ it can be calculated using following formula:
+ T = 8.82 * 10^9 * Ct
+
+Example:
+
+flash_led: flash-led {
+ compatible = "skyworks,aat1290";
+ gpios = <&gpj1 1 0>, <&gpj1 2 0>;
+ flash-timeout-microsec = <194>;
+}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v8 12/14] leds: Add driver for AAT1290 current regulator
This patch adds a driver for the 1.5A Step-Up
Current Regulator for Flash LEDs. The device is
programmed through a Skyworks proprietary AS2Cwire
serial digital interface.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/Kconfig|7 +
drivers/leds/Makefile |1 +
drivers/leds/leds-aat1290.c | 472 +++
3 files changed, 480 insertions(+)
create mode 100644 drivers/leds/leds-aat1290.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2e66d55..ec4b78c 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -39,6 +39,13 @@ config LEDS_88PM860X
This option enables support for on-chip LED drivers found on Marvell
Semiconductor 88PM8606 PMIC.
+config LEDS_AAT1290
+ tristate "LED support for the AAT1290"
+ depends on LEDS_CLASS_FLASH
+ depends on OF
+ help
+This option enables support for the LEDs on the AAT1290.
+
config LEDS_LM3530
tristate "LCD Backlight driver for LM3530"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 57ca62b..b802251 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
# LED Platform Drivers
obj-$(CONFIG_LEDS_88PM860X)+= leds-88pm860x.o
+obj-$(CONFIG_LEDS_AAT1290) += leds-aat1290.o
obj-$(CONFIG_LEDS_BD2802) += leds-bd2802.o
obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
new file mode 100644
index 000..2f8bd99
--- /dev/null
+++ b/drivers/leds/leds-aat1290.c
@@ -0,0 +1,472 @@
+/*
+ * LED Flash class driver for the AAT1290
+ * 1.5A Step-Up Current Regulator for Flash LEDs
+ *
+ * Copyright (C) 2014, Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define AAT1290_MOVIE_MODE_CURRENT_ADDR17
+#define AAT1290_FLASH_SAFETY_TIMER_ADDR18
+#define AAT1290_MOVIE_MODE_CONFIG_ADDR 19
+#define AAT1290_MM_CURRENT_RATIO_ADDR 20
+#define AAT1290_LATCH_TIME_US 500
+#define AAT1290_EN_SET_TICK_TIME_US1
+#define AAT1290_MOVIE_MODE_OFF 1
+#define AAT1290_MOVIE_MODE_ON 3
+#define AAT1290_MAX_MM_CURR_PERCENT_0 16
+#define AAT1290_MAX_MM_CURR_PERCENT_100 1
+#define AAT1290_FLASH_TM_NUM_LEVELS16
+
+#define AAT1290_MM_TO_FL_1_92 1
+#define AAT1290_MM_TO_FL_3_7 2
+#define AAT1290_MM_TO_FL_5_5 3
+#define AAT1290_MM_TO_FL_7_3 4
+#define AAT1290_MM_TO_FL_9 5
+#define AAT1290_MM_TO_FL_10_7 6
+#define AAT1290_MM_TO_FL_12_4 7
+#define AAT1290_MM_TO_FL_148
+#define AAT1290_MM_TO_FL_15_9 9
+#define AAT1290_MM_TO_FL_17_5 10
+#define AAT1290_MM_TO_FL_19_1 11
+#define AAT1290_MM_TO_FL_20_8 12
+#define AAT1290_MM_TO_FL_22_4 13
+#define AAT1290_MM_TO_FL_2414
+#define AAT1290_MM_TO_FL_25_6 15
+#define AAT1290_MM_TO_FL_OFF 16
+
+struct aat1290_led_settings {
+ struct led_flash_setting torch_brightness;
+ struct led_flash_setting flash_brightness;
+ struct led_flash_setting flash_timeout;
+};
+
+struct aat1290_led {
+ struct platform_device *pdev;
+ struct mutex lock;
+
+ struct led_classdev_flash ldev;
+ struct v4l2_flash *v4l2_flash;
+
+ int flen_gpio;
+ int en_set_gpio;
+
+ u32 max_flash_tm;
+ bool movie_mode;
+
+ char *label;
+ unsigned int torch_brightness;
+ unsigned int flash_timeout;
+ struct work_struct work_brightness_set;
+};
+
+static struct aat1290_led *ldev_to_led(struct led_classdev_flash *ldev)
+{
+ return container_of(ldev, struct aat1290_led, ldev);
+}
+
+static void aat1290_as2cwire_write(struct aat1290_led *led, int addr, int
value)
+{
+ int i;
+
+ gpio_set_value(led->flen_gpio, 0);
+ gpio_set_value(led->en_set_gpio, 0);
+
+ udelay(10);
+
+ /* write address */
+ for (i = 0; i < addr; ++i) {
+ udelay(AAT1290_EN_SET_TICK_TIME_US);
+ gpio_set_value(led->en_set_gpio, 0);
+ udelay(AAT1290_EN_SET_TICK_TIME_US);
+ gpio_set_value(led->en_set_gpio, 1);
+ }
+
+ udelay(AAT1290_LATCH_TIME_US);
+
+ /* write data */
+ for (i = 0; i < value; ++i) {
+ udelay(AAT1290_EN_SET_TICK_TIME_US);
+ gpio_set_value(led->en_set_gpio, 0);
+ udelay(AAT1290_EN_SET_TICK_TIME_US);
+
[PATCH/RFC v8 09/14] mfd: max77693: adjust max77693_led_platform_data
Add "label" array for Device Tree strings with
the name of a LED device and make flash_timeout
a two element array, for caching the sub-led
related flash timeout.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Andrzej Hajda
Acked-by: Kyungmin Park
Cc: Lee Jones
Cc: SangYoung Son
Cc: Samuel Ortiz
---
include/linux/mfd/max77693.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
index f0b6585..30fa19ea 100644
--- a/include/linux/mfd/max77693.h
+++ b/include/linux/mfd/max77693.h
@@ -88,14 +88,15 @@ enum max77693_led_boost_mode {
};
struct max77693_led_platform_data {
+ const char *label[2];
u32 fleds[2];
u32 iout_torch[2];
u32 iout_flash[2];
u32 trigger[2];
u32 trigger_type[2];
+ u32 flash_timeout[2];
u32 num_leds;
u32 boost_mode;
- u32 flash_timeout;
u32 boost_vout;
u32 low_vsys;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v8 10/14] leds: Add support for max77693 mfd flash cell
This patch adds led-flash support to Maxim max77693 chipset.
A device can be exposed to user space through LED subsystem
sysfs interface or through V4L2 sub-device when the support
for V4L2 Flash sub-devices is enabled. Device supports up to
two leds which can work in flash and torch mode. The leds can
be triggered externally or by software.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Andrzej Hajda
Acked-by: Kyungmin Park
Cc: Lee Jones
Cc: Bryan Wu
Cc: Richard Purdie
Cc: SangYoung Son
Cc: Samuel Ortiz
---
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile|1 +
drivers/leds/leds-max77693.c | 1152 ++
3 files changed, 1163 insertions(+)
create mode 100644 drivers/leds/leds-max77693.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index fa8021e..2e66d55 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -463,6 +463,16 @@ config LEDS_TCA6507
LED driver chips accessed via the I2C bus.
Driver support brightness control and hardware-assisted blinking.
+config LEDS_MAX77693
+ tristate "LED support for MAX77693 Flash"
+ depends on LEDS_CLASS_FLASH
+ depends on MFD_MAX77693
+ depends on OF
+ help
+ This option enables support for the flash part of the MAX77693
+ multifunction device. It has build in control for two leds in flash
+ and torch mode.
+
config LEDS_MAX8997
tristate "LED support for MAX8997 PMIC"
depends on LEDS_CLASS && MFD_MAX8997
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index cbba921..57ca62b 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_LEDS_MC13783)+= leds-mc13783.o
obj-$(CONFIG_LEDS_NS2) += leds-ns2.o
obj-$(CONFIG_LEDS_NETXBIG) += leds-netxbig.o
obj-$(CONFIG_LEDS_ASIC3) += leds-asic3.o
+obj-$(CONFIG_LEDS_MAX77693)+= leds-max77693.o
obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
new file mode 100644
index 000..2e96fd9
--- /dev/null
+++ b/drivers/leds/leds-max77693.c
@@ -0,0 +1,1152 @@
+/*
+ * LED Flash class driver for the flash cell of max77693 mfd.
+ *
+ * Copyright (C) 2014, Samsung Electronics Co., Ltd.
+ *
+ * Authors: Jacek Anaszewski
+ * Andrzej Hajda
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MODE_OFF 0
+#define MODE_FLASH1(1 << 0)
+#define MODE_FLASH2(1 << 1)
+#define MODE_TORCH1(1 << 2)
+#define MODE_TORCH2(1 << 3)
+#define MODE_FLASH_EXTERNAL1 (1 << 4)
+#define MODE_FLASH_EXTERNAL2 (1 << 5)
+
+#define MODE_FLASH (MODE_FLASH1 | MODE_FLASH2 | \
+MODE_FLASH_EXTERNAL1 | MODE_FLASH_EXTERNAL2)
+
+#define FLED1_IOUT (1 << 0)
+#define FLED2_IOUT (1 << 1)
+
+enum {
+ FLED1,
+ FLED2
+};
+
+enum {
+ FLASH,
+ TORCH
+};
+
+struct max77693_sub_led {
+ struct led_classdev_flash ldev;
+ struct work_struct work_brightness_set;
+ struct v4l2_flash *v4l2_flash;
+
+ unsigned int torch_brightness;
+ unsigned int flash_timeout;
+};
+
+struct max77693_led {
+ struct regmap *regmap;
+ struct platform_device *pdev;
+ struct max77693_led_platform_data *pdata;
+ struct mutex lock;
+
+ struct max77693_sub_led sub_leds[2];
+
+ unsigned int current_flash_timeout;
+ unsigned int mode_flags;
+ u8 torch_iout_reg;
+ bool iout_joint;
+ int strobing_sub_led_id;
+};
+
+struct max77693_led_settings {
+ struct led_flash_setting torch_brightness;
+ struct led_flash_setting flash_brightness;
+ struct led_flash_setting flash_timeout;
+};
+
+static u8 max77693_led_iout_to_reg(u32 ua)
+{
+ if (ua < FLASH_IOUT_MIN)
+ ua = FLASH_IOUT_MIN;
+ return (ua - FLASH_IOUT_MIN) / FLASH_IOUT_STEP;
+}
+
+static u8 max77693_flash_timeout_to_reg(u32 us)
+{
+ return (us - FLASH_TIMEOUT_MIN) / FLASH_TIMEOUT_STEP;
+}
+
+static inline struct max77693_led *ldev1_to_led(
+ struct led_classdev_flash *ldev)
+{
+ struct max77693_sub_led *sub_led = container_of(ldev,
+ struct max77693_sub_led,
+ ldev);
+ return cont
[PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693
This patch adds device tree binding documentation for
the flash cell of the Maxim max77693 multifunctional device.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Andrzej Hajda
Acked-by: Kyungmin Park
Cc: Lee Jones
Cc: SangYoung Son
Cc: Samuel Ortiz
Cc: Bryan Wu
Cc: Richard Purdie
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc:
---
Documentation/devicetree/bindings/mfd/max77693.txt | 74
1 file changed, 74 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
b/Documentation/devicetree/bindings/mfd/max77693.txt
index 01e9f30..50a8dad 100644
--- a/Documentation/devicetree/bindings/mfd/max77693.txt
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -41,6 +41,62 @@ Optional properties:
To get more informations, please refer to documentaion.
[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
+- led-flash : the LED submodule device node
+
+There are two led outputs available - fled1 and fled2. Each of them can
+control a separate led or they can be connected together to double
+the maximum current for a single connected led. One led is represented
+by one child node.
+
+Required properties:
+- compatible : must be "maxim,max77693-flash"
+
+Optional properties:
+- maxim,fleds : array of current outputs in order: fled1, fled2
+ Note: both current outputs can be connected to a single led
+ Possible values:
+ 0 - the output is left disconnected,
+ 1 - a diode is connected to the output.
+- maxim,trigger-type : Array of trigger types in order: flash, torch
+ Possible trigger types:
+ 0 - Rising edge of the signal triggers the flash/torch,
+ 1 - Signal level controls duration of the flash/torch.
+- maxim,trigger : Array of flags indicating which trigger can activate given
led
+ in order: fled1, fled2
+ Possible flag values (can be combined):
+ 1 - FLASH pin of the chip,
+ 2 - TORCH pin of the chip,
+ 4 - software via I2C command.
+- maxim,boost-mode :
+ In boost mode the device can produce up to 1.2A of total current
+ on both outputs. The maximum current on each output is reduced
+ to 625mA then. If there are two child led nodes defined then boost
+ is enabled by default.
+ Possible values:
+ 0 - no boost,
+ 1 - adaptive mode,
+ 2 - fixed mode.
+- maxim,boost-vout : Output voltage of the boost module in millivolts.
+- maxim,vsys-min : Low input voltage level in millivolts. Flash is not fired
+ if chip estimates that system voltage could drop below this level due
+ to flash power consumption.
+
+A child node must be defined per sub-led.
+
+Required properties of the LED child node:
+- label : see Documentation/devicetree/bindings/leds/common.txt
+- maxim,fled_id : identifier of the fled output the led is connected to:
+ 1 - FLED1,
+ 2 - FLED2.
+
+Optional properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+ Range: 15625 - 25
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+ Range: 15625 - 100
+- flash-timeout-microsec : see
Documentation/devicetree/bindings/leds/common.txt
+ Range: 62500 - 100
+
Example:
max77693@66 {
compatible = "maxim,max77693";
@@ -73,4 +129,22 @@ Example:
pwms = <&pwm 0 4 0>;
pwm-names = "haptic";
};
+
+ led_flash: led-flash {
+ compatible = "maxim,max77693-flash";
+ maxim,fleds = <1 0>;
+ maxim,trigger = <7 0>;
+ maxim,trigger-type = <0 1>;
+ maxim,boost-mode = <0>;
+ maxim,boost-vout = <5000>;
+ maxim,vsys-min = <2400>;
+
+ camera-flash {
+ maxim,fled_id = <1>
+ label = "max77693-flash";
+ max-microamp = <25>;
+ flash-max-microamp = <100>;
+ flash-timeout-microsec = <100>;
+ }
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property
This patch adds a description of 'flashes' property to the samsung-fimc.txt. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Sylwester Nawrocki Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: --- .../devicetree/bindings/media/samsung-fimc.txt |7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt index 922d6f8..4b7ed03 100644 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt @@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera port A must be activated and the port B deactivated and for the state "active-b" it should be the other way around. +Optional properties: + +- flashes - array of strings with flash led names; the name has to + be same with the related led label + (see Documentation/devicetree/bindings/leds/common.txt) + The 'camera' node must include at least one 'fimc' child node. @@ -166,6 +172,7 @@ Example: clock-output-names = "cam_a_clkout", "cam_b_clkout"; pinctrl-names = "default"; pinctrl-0 = <&cam_port_a_clk_active>; + flashes = "max77693-flash1", "max77693-flash2"; status = "okay"; #address-cells = <1>; #size-cells = <1>; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v8 07/14] exynos4-is: Add support for v4l2-flash subdevs
This patch adds suppport for external v4l2-flash devices.
The support includes parsing "flashes" Device Tree property
and asynchronous subdevice registration.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Sylwester Nawrocki
---
drivers/media/platform/exynos4-is/media-dev.c | 65 -
drivers/media/platform/exynos4-is/media-dev.h | 13 -
2 files changed, 75 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index f315ef9..8807730 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -451,6 +451,47 @@ rpm_put:
return ret;
}
+static bool match_subdev_name(struct v4l2_subdev *sd,
+ struct v4l2_async_subdev *asd)
+{
+ return !strcmp(sd->name, (char *) asd->match.custom.priv);
+}
+
+static int fimc_md_register_flash_entities(struct fimc_md *fmd)
+{
+ struct device_node *parent = fmd->pdev->dev.of_node;
+ const char *flash_names[FIMC_MAX_FLASHES];
+ int ret, i;
+
+ ret = of_property_count_strings(parent, "flashes");
+ if (ret < 0) {
+ /* the property may not exist - this is valid state */
+ if (ret == -EINVAL)
+ return 0;
+ v4l2_err(&fmd->v4l2_dev, "Failed to retrieve flashes\n");
+ return -EINVAL;
+ }
+
+ fmd->num_flashes = ret;
+
+ if (fmd->num_flashes > FIMC_MAX_FLASHES) {
+ v4l2_err(&fmd->v4l2_dev, "Too many flash leds declared.\n");
+ return -EINVAL;
+ }
+
+ of_property_read_string_array(parent, "flashes", flash_names,
+ fmd->num_flashes);
+
+ for (i = 0; i < fmd->num_flashes; ++i) {
+ fmd->flash[i].asd.match_type = V4L2_ASYNC_MATCH_CUSTOM;
+ fmd->flash[i].asd.match.custom.match = match_subdev_name;
+ fmd->flash[i].asd.match.custom.priv = (void *) flash_names[i];
+ fmd->async_subdevs[fmd->num_sensors + i] = &fmd->flash[i].asd;
+ }
+
+ return 0;
+}
+
static int __of_get_csis_id(struct device_node *np)
{
u32 reg = 0;
@@ -1275,6 +1316,18 @@ static int subdev_notifier_bound(struct
v4l2_async_notifier *notifier,
struct fimc_sensor_info *si = NULL;
int i;
+ /* Register flash subdev if detected any */
+ for (i = 0; i < ARRAY_SIZE(fmd->flash); i++) {
+ if (!fmd->flash[i].asd.match.custom.priv)
+ continue;
+ if (!strcmp(fmd->flash[i].asd.match.custom.priv,
+ subdev->name)) {
+ fmd->flash[i].subdev = subdev;
+ fmd->num_flashes++;
+ return 0;
+ }
+ }
+
/* Find platform data for this sensor subdev */
for (i = 0; i < ARRAY_SIZE(fmd->sensor); i++)
if (fmd->sensor[i].asd.match.of.node == subdev->dev->of_node)
@@ -1385,6 +1438,12 @@ static int fimc_md_probe(struct platform_device *pdev)
goto err_m_ent;
}
+ ret = fimc_md_register_flash_entities(fmd);
+ if (ret < 0) {
+ mutex_unlock(&fmd->media_dev.graph_mutex);
+ goto err_m_ent;
+ }
+
mutex_unlock(&fmd->media_dev.graph_mutex);
ret = device_create_file(&pdev->dev, &dev_attr_subdev_conf_mode);
@@ -1401,12 +1460,14 @@ static int fimc_md_probe(struct platform_device *pdev)
goto err_attr;
}
- if (fmd->num_sensors > 0) {
+ if (fmd->num_sensors > 0 || fmd->num_flashes > 0) {
fmd->subdev_notifier.subdevs = fmd->async_subdevs;
- fmd->subdev_notifier.num_subdevs = fmd->num_sensors;
+ fmd->subdev_notifier.num_subdevs = fmd->num_sensors +
+ fmd->num_flashes;
fmd->subdev_notifier.bound = subdev_notifier_bound;
fmd->subdev_notifier.complete = subdev_notifier_complete;
fmd->num_sensors = 0;
+ fmd->num_flashes = 0;
ret = v4l2_async_notifier_register(&fmd->v4l2_dev,
&fmd->subdev_notifier);
diff --git a/drivers/media/platform/exynos4-is/media-dev.h
b/drivers/media/platform/exynos4-is/media-dev.h
index 0321454..feff9c8 100644
--- a/drivers/media/platform/exynos4-is/media-dev.h
+++ b/drivers/media/platform/exynos4-is/media-dev.h
@@ -34,6 +34,8 @@
#define FIMC_MAX_SENSORS 4
#define FIMC_MAX_CAMCLKS 2
+#define FIMC_MAX_FLASHES 2
+#define F
[PATCH/RFC v8 04/14] v4l2-async: change custom.match callback argument type
It is useful to have an access to the async sub-device
being matched, not only to the related struct device.
Change match callback argument from struct device
to struct v4l2_subdev. It will allow e.g. for matching
a sub-device by its "name" property.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Guennadi Liakhovetski
Cc: Laurent Pinchart
Cc: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-async.c | 16
include/media/v4l2-async.h |2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 85a6a34..8140992 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -22,10 +22,10 @@
#include
#include
-static bool match_i2c(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
#if IS_ENABLED(CONFIG_I2C)
- struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_client *client = i2c_verify_client(sd->dev);
return client &&
asd->match.i2c.adapter_id == client->adapter->nr &&
asd->match.i2c.address == client->addr;
@@ -34,14 +34,14 @@ static bool match_i2c(struct device *dev, struct
v4l2_async_subdev *asd)
#endif
}
-static bool match_devname(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_devname(struct v4l2_subdev *sd, struct v4l2_async_subdev
*asd)
{
- return !strcmp(asd->match.device_name.name, dev_name(dev));
+ return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
}
-static bool match_of(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
- return dev->of_node == asd->match.of.node;
+ return sd->dev->of_node == asd->match.of.node;
}
static LIST_HEAD(subdev_list);
@@ -52,7 +52,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier *
struct v4l2_subdev *sd)
{
struct v4l2_async_subdev *asd;
- bool (*match)(struct device *, struct v4l2_async_subdev *);
+ bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
list_for_each_entry(asd, ¬ifier->waiting, list) {
/* bus_type has been verified valid before */
@@ -79,7 +79,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier *
}
/* match cannot be NULL here */
- if (match(sd->dev, asd))
+ if (match(sd, asd))
return asd;
}
diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
index 7683569..1c0b586 100644
--- a/include/media/v4l2-async.h
+++ b/include/media/v4l2-async.h
@@ -51,7 +51,7 @@ struct v4l2_async_subdev {
unsigned short address;
} i2c;
struct {
- bool (*match)(struct device *,
+ bool (*match)(struct v4l2_subdev *,
struct v4l2_async_subdev *);
void *priv;
} custom;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v8 05/14] v4l2-ctrls: Add V4L2_CID_FLASH_SYNC_STROBE control
Add V4L2_CID_FLASH_SYNC_STROBE control for determining
whether a flash device strobe has to be synchronized
with other flash leds controller by the same device.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Sakari Ailus
Cc: Hans Verkuil
---
Documentation/DocBook/media/v4l/controls.xml |9 +
drivers/media/v4l2-core/v4l2-ctrls.c |2 ++
include/uapi/linux/v4l2-controls.h |1 +
3 files changed, 12 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index e013e4b..35e9ea3 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -4563,6 +4563,15 @@ interface and may change in the future.
after strobe during which another strobe will not be
possible. This is a read-only control.
+
+ V4L2_CID_FLASH_SYNC_STROBE
+ boolean
+
+
+ Synchronized strobe: whether the flash
+ should be strobed synchronously with the other ones controlled
+ by the same device
+
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 45c5b47..a7cca8c 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -846,6 +846,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_FLASH_FAULT: return "Faults";
case V4L2_CID_FLASH_CHARGE: return "Charge";
case V4L2_CID_FLASH_READY: return "Ready to Strobe";
+ case V4L2_CID_FLASH_SYNC_STROBE:return "Synchronize Strobe";
/* JPEG encoder controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -949,6 +950,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_FLASH_STROBE_STATUS:
case V4L2_CID_FLASH_CHARGE:
case V4L2_CID_FLASH_READY:
+ case V4L2_CID_FLASH_SYNC_STROBE:
case V4L2_CID_MPEG_VIDEO_DECODER_MPEG4_DEBLOCK_FILTER:
case V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE:
case V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 661f119..5bce13d 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -833,6 +833,7 @@ enum v4l2_flash_strobe_source {
#define V4L2_CID_FLASH_CHARGE (V4L2_CID_FLASH_CLASS_BASE + 11)
#define V4L2_CID_FLASH_READY (V4L2_CID_FLASH_CLASS_BASE + 12)
+#define V4L2_CID_FLASH_SYNC_STROBE (V4L2_CID_FLASH_CLASS_BASE + 13)
/* JPEG-class control IDs */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v8 06/14] media: Add registration helpers for V4L2 flash sub-devices
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Sakari Ailus
Cc: Hans Verkuil
---
drivers/media/v4l2-core/Kconfig | 11 +
drivers/media/v4l2-core/Makefile |2 +
drivers/media/v4l2-core/v4l2-flash.c | 516 ++
include/media/v4l2-flash.h | 138 +
4 files changed, 667 insertions(+)
create mode 100644 drivers/media/v4l2-core/v4l2-flash.c
create mode 100644 include/media/v4l2-flash.h
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index ba7e21a..f034f1a 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -44,6 +44,17 @@ config V4L2_MEM2MEM_DEV
tristate
depends on VIDEOBUF2_CORE
+# Used by LED subsystem flash drivers
+config V4L2_FLASH_LED_CLASS
+ tristate "Enable support for Flash sub-devices"
+ depends on VIDEO_V4L2_SUBDEV_API
+ depends on LEDS_CLASS_FLASH
+ ---help---
+ Say Y here to enable support for Flash sub-devices, which allow
+ to control LED class devices with use of V4L2 Flash controls.
+
+ When in doubt, say N.
+
# Used by drivers that need Videobuf modules
config VIDEOBUF_GEN
tristate
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index 63d29f2..44e858c 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_VIDEO_TUNER) += tuner.o
obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
+obj-$(CONFIG_V4L2_FLASH_LED_CLASS) += v4l2-flash.o
+
obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
obj-$(CONFIG_VIDEOBUF_DMA_CONTIG) += videobuf-dma-contig.o
diff --git a/drivers/media/v4l2-core/v4l2-flash.c
b/drivers/media/v4l2-core/v4l2-flash.c
new file mode 100644
index 000..f5075b0
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-flash.c
@@ -0,0 +1,516 @@
+/*
+ * V4L2 Flash LED sub-device registration helpers.
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation."
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define has_flash_op(v4l2_flash, op) \
+ (v4l2_flash && v4l2_flash->ops->op)
+
+#define call_flash_op(v4l2_flash, op, args...) \
+ (has_flash_op(v4l2_flash, op) ? \
+ v4l2_flash->ops->op(args) : \
+ -EINVAL)
+
+static inline enum led_brightness v4l2_flash_intensity_to_led_brightness(
+ struct v4l2_ctrl *ctrl,
+ s32 intensity)
+{
+ s64 __intensity = intensity - ctrl->minimum;
+
+ do_div(__intensity, ctrl->step);
+
+ return __intensity + 1;
+}
+
+static inline s32 v4l2_flash_led_brightness_to_intensity(
+ struct v4l2_ctrl *ctrl,
+ enum led_brightness brightness)
+{
+ return ((brightness - 1) * ctrl->step) + ctrl->minimum;
+}
+
+static int v4l2_flash_g_volatile_ctrl(struct v4l2_ctrl *c)
+{
+ struct v4l2_flash *v4l2_flash = v4l2_ctrl_to_v4l2_flash(c);
+ struct led_classdev_flash *flash = v4l2_flash->flash;
+ struct led_classdev *led_cdev = &flash->led_cdev;
+ struct v4l2_ctrl **ctrls = v4l2_flash->ctrls;
+ bool is_strobing;
+ int ret;
+
+ switch (c->id) {
+ case V4L2_CID_FLASH_TORCH_INTENSITY:
+ /*
+* Update torch brightness only if in TORCH_MODE.
+* In other modes torch led is turned off, which
+* would spuriously inform the user space that
+* V4L2_CID_FLASH_TORCH_INTENSITY control setting
+* has changed.
+*/
+ if (ctrls[LED_MODE]->val == V4L2_FLASH_LED_MODE_TORCH) {
+ ret = led_update_brightness(led_cdev);
+ if (ret < 0)
+ return ret;
+ c->val = v4l2_flash_led_brightness_to_intensity(
+ ctrls[TORCH_INTENSITY],
+ led_cdev->brightness);
+ }
+ return 0;
+ case V4L2_CID_FLASH_INDICATOR_INTENSITY:
+ ret = led_update_b
[PATCH/RFC v8 03/14] Documentation: leds: Add description of v4l2-flash sub-device
This patch extends LED Flash class documention by the description of interactions with v4l2-flash sub-device. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Bryan Wu Cc: Richard Purdie --- Documentation/leds/leds-class-flash.txt | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/leds/leds-class-flash.txt b/Documentation/leds/leds-class-flash.txt index d68565c..1a611ec 100644 --- a/Documentation/leds/leds-class-flash.txt +++ b/Documentation/leds/leds-class-flash.txt @@ -46,3 +46,16 @@ Following sysfs attributes are exposed for controlling flash led devices: until this flag is no longer set * 0x100 - the temperature of the LED has exceeded its allowed upper limit + +A LED subsystem driver can be controlled also from the level of VideoForLinux2 +subsystem. In order to enable this CONFIG_V4L2_FLASH_LED_CLASS symbol has to +be defined in the kernel config. The driver must call the v4l2_flash_init +function to get registered in the V4L2 subsystem. On remove the +v4l2_flash_release function has to be called (see ). + +After proper initialization a V4L2 Flash sub-device is created. The sub-device +exposes a number of V4L2 controls, which allow for controlling a LED Flash class +device with use of its internal kernel API. +Opening the V4L2 Flash sub-device makes the LED subsystem sysfs interface +unavailable. The interface is re-enabled after the V4L2 Flash sub-device +is closed. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
The documentation being added contains overall description of the LED Flash Class and the related sysfs attributes. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Bryan Wu Cc: Richard Purdie --- Documentation/leds/leds-class-flash.txt | 48 +++ 1 file changed, 48 insertions(+) create mode 100644 Documentation/leds/leds-class-flash.txt diff --git a/Documentation/leds/leds-class-flash.txt b/Documentation/leds/leds-class-flash.txt new file mode 100644 index 000..d68565c --- /dev/null +++ b/Documentation/leds/leds-class-flash.txt @@ -0,0 +1,48 @@ + +Flash LED handling under Linux +== + +Some LED devices support two modes - torch and flash. The modes are +supported by the LED class (see Documentation/leds/leds-class.txt) +and LED Flash class respectively. + +In order to enable support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol +must be defined in the kernel config. A flash LED driver must register +in the LED subsystem with led_classdev_flash_register to gain flash +capabilities. + +Following sysfs attributes are exposed for controlling flash led devices: + + - flash_brightness - flash LED brightness in microamperes (RW) + - max_flash_brightness - maximum available flash LED brightness (RO) + - indicator_brightness - privacy LED brightness in microamperes (RW) + - max_indicator_brightness - maximum privacy LED brightness in +microamperes (RO) + - flash_timeout - flash strobe duration in microseconds (RW) + - max_flash_timeout - maximum available flash strobe duration (RO) + - flash_strobe - flash strobe state (RW) + - flash_sync_strobe - one flash device can control more than one + sub-led; when this atrribute is set to 1 + the flash led will be strobed synchronously + with the other ones controlled by the same + device (RW) + - flash_fault - bitmask of flash faults that may have occurred, + possible flags are: + * 0x01 - flash controller voltage to the flash LED has exceeded +the limit specific to the flash controller + * 0x02 - the flash strobe was still on when the timeout set by +the user has expired; not all flash controllers may +set this in all such conditions + * 0x04 - the flash controller has overheated + * 0x08 - the short circuit protection of the flash controller +has been triggered + * 0x10 - current in the LED power supply has exceeded the limit +specific to the flash controller + * 0x40 - flash controller voltage to the flash LED has been +below the minimum limit specific to the flash + * 0x80 - the input voltage of the flash controller is below +the limit under which strobing the flash at full +current will not be possible. The condition persists +until this flag is no longer set + * 0x100 - the temperature of the LED has exceeded its allowed + upper limit -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v8 00/14] LED / flash API integration
This patch set is a follow-up of the LED / flash API integration series [1]. Changes since version 7: - removed explicit support for indicator leds from LED Flash class - indicator leds will be registered as a separate LED Flash class devices - added flash_sync_strobe sysfs attribute and related V4L2_CID_FLASH_SYNC_STROBE control - changed the way of matching V4L2 Flash sub-devices in a media device, which entailed modification in v4l2-async driver - modified max77693 DT bindings documentation - applied various fixes an cleanups Changes since version 6: - removed addition of public LED subsystem API for setting torch brightness in favour of internal API for synchronous and asynchronous led brightness level setting - fixed possible race condition upon creating LED Flash class related sysfs attributes Changes since version 5: - removed flash manager framework - its implementation needs further thorough discussion. - removed external strobe facilities from the LED Flash Class and provided external_strobe_set op in v4l2-flash. LED subsystem should be strobe provider agnostic. Thanks, Jacek Anaszewski [1] https://lkml.org/lkml/2014/7/11/914 Jacek Anaszewski (14): leds: Add LED Flash class extension to the LED subsystem Documentation: leds: Add description of LED Flash class extension Documentation: leds: Add description of v4l2-flash sub-device v4l2-async: change custom.match callback argument type v4l2-ctrls: Add V4L2_CID_FLASH_SYNC_STROBE control media: Add registration helpers for V4L2 flash sub-devices exynos4-is: Add support for v4l2-flash subdevs DT: Add documentation for exynos4-is 'flashes' property mfd: max77693: adjust max77693_led_platform_data leds: Add support for max77693 mfd flash cell DT: Add documentation for the mfd Maxim max77693 leds: Add driver for AAT1290 current regulator of: Add Skyworks Solutions, Inc. vendor prefix DT: Add documentation for the Skyworks AAT1290 Documentation/DocBook/media/v4l/controls.xml |9 + .../devicetree/bindings/leds/leds-aat1290.txt | 17 + .../devicetree/bindings/media/samsung-fimc.txt |7 + Documentation/devicetree/bindings/mfd/max77693.txt | 74 ++ .../devicetree/bindings/vendor-prefixes.txt|1 + Documentation/leds/leds-class-flash.txt| 61 ++ drivers/leds/Kconfig | 27 + drivers/leds/Makefile |3 + drivers/leds/led-class-flash.c | 446 drivers/leds/led-class.c |4 + drivers/leds/leds-aat1290.c| 472 drivers/leds/leds-max77693.c | 1152 drivers/media/platform/exynos4-is/media-dev.c | 65 +- drivers/media/platform/exynos4-is/media-dev.h | 13 +- drivers/media/v4l2-core/Kconfig| 11 + drivers/media/v4l2-core/Makefile |2 + drivers/media/v4l2-core/v4l2-async.c | 16 +- drivers/media/v4l2-core/v4l2-ctrls.c |2 + drivers/media/v4l2-core/v4l2-flash.c | 516 + include/linux/led-class-flash.h| 198 include/linux/leds.h |3 + include/linux/mfd/max77693.h |3 +- include/media/v4l2-async.h |2 +- include/media/v4l2-flash.h | 138 +++ include/uapi/linux/v4l2-controls.h |1 + 25 files changed, 3230 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/leds-aat1290.txt create mode 100644 Documentation/leds/leds-class-flash.txt create mode 100644 drivers/leds/led-class-flash.c create mode 100644 drivers/leds/leds-aat1290.c create mode 100644 drivers/leds/leds-max77693.c create mode 100644 drivers/media/v4l2-core/v4l2-flash.c create mode 100644 include/linux/led-class-flash.h create mode 100644 include/media/v4l2-flash.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v8 01/14] leds: Add LED Flash class extension to the LED subsystem
Some LED devices support two operation modes - torch and flash.
This patch provides support for flash LED devices in the LED subsystem
by introducing new sysfs attributes and kernel internal interface.
The attributes being introduced are: flash_brightness, flash_strobe,
flash_timeout, max_flash_timeout, max_flash_brightness, flash_fault
and flash_sync_strobe. All the flash related features are placed
in a separate module. Torch mode is supported by the LED class
interface.
The modifications aim to be compatible with V4L2 framework requirements
related to the flash devices management. The design assumes that V4L2
sub-device can take of the LED class device control and communicate
with it through the kernel internal interface. When V4L2 Flash sub-device
file is opened, the LED class device sysfs interface is made
unavailable.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/Kconfig| 10 +
drivers/leds/Makefile |1 +
drivers/leds/led-class-flash.c | 446 +++
drivers/leds/led-class.c|4 +
include/linux/led-class-flash.h | 198 +
include/linux/leds.h|3 +
6 files changed, 662 insertions(+)
create mode 100644 drivers/leds/led-class-flash.c
create mode 100644 include/linux/led-class-flash.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b3c0d8a..fa8021e 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -19,6 +19,16 @@ config LEDS_CLASS
This option enables the led sysfs class in /sys/class/leds. You'll
need this to do anything useful with LEDs. If unsure, say N.
+config LEDS_CLASS_FLASH
+ tristate "LED Flash Class Support"
+ depends on LEDS_CLASS
+ help
+ This option enables the flash led sysfs class in /sys/class/leds.
+ It wrapps LED Class and adds flash LEDs specific sysfs attributes
+ and kernel internal API to it. You'll need this to provide support
+ for the flash related features of a LED device. It can be built
+ as a module.
+
comment "LED drivers"
config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1c65a19..cbba921 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -2,6 +2,7 @@
# LED Core
obj-$(CONFIG_NEW_LEDS) += led-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
+obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
obj-$(CONFIG_LEDS_TRIGGERS)+= led-triggers.o
# LED Platform Drivers
diff --git a/drivers/leds/led-class-flash.c b/drivers/leds/led-class-flash.c
new file mode 100644
index 000..219b414
--- /dev/null
+++ b/drivers/leds/led-class-flash.c
@@ -0,0 +1,446 @@
+/*
+ * LED Flash class interface
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "leds.h"
+
+#define has_flash_op(flash, op)\
+ (flash && flash->ops->op)
+
+#define call_flash_op(flash, op, args...) \
+ ((has_flash_op(flash, op)) ?\
+ (flash->ops->op(flash, args)) : \
+ -EINVAL)
+
+static ssize_t flash_brightness_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_flash *flash = lcdev_to_flash(led_cdev);
+ unsigned long state;
+ ssize_t ret;
+
+ mutex_lock(&led_cdev->led_access);
+
+ if (led_sysfs_is_disabled(led_cdev)) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ ret = kstrtoul(buf, 10, &state);
+ if (ret)
+ goto unlock;
+
+ ret = led_set_flash_brightness(flash, state);
+ if (ret < 0)
+ goto unlock;
+
+ ret = size;
+unlock:
+ mutex_unlock(&led_cdev->led_access);
+ return ret;
+}
+
+static ssize_t flash_brightness_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_flash *flash = lcdev_to_flash(led_cdev);
+
+ /* no lock needed for this */
+ led_update_flash_brightness(flash);
+
+ return sprintf(buf, "%u\n", flash->brightness.val);
+}
+static DEVICE_ATTR_RW(flash_brightness);
+
+static ssize_t max_flash_brightness_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classd
Re: [PATCH/RFC v7 2/3] leds: Add LED Flash Class wrapper to LED subsystem
Hi Sakari,
Thanks for the review.
[...]
+static void led_clamp_align(struct led_flash_setting *s)
+{
+ u32 v, offset;
+
+ v = s->val + s->step / 2;
+ v = clamp(v, s->min, s->max);
+ offset = v - s->min;
+ offset = s->step * (offset / s->step);
You could use the rounddown() macro. I.e.
rounddown(v - s->min, s->step) + s->min;
I took this code snippet from v4l2-ctrls.c.
It allows for aligning the control value to the nearest
step - top or bottom, whereas rounddown only to the
bottom one.
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property
On 11/28/2014 12:14 PM, Mark Rutland wrote: On Fri, Nov 28, 2014 at 09:18:00AM +, Jacek Anaszewski wrote: This patch adds a description of 'flashes' property to the samsung-fimc.txt. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Sylwester Nawrocki Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: --- .../devicetree/bindings/media/samsung-fimc.txt |7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt index 922d6f8..4b7ed03 100644 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt @@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera port A must be activated and the port B deactivated and for the state "active-b" it should be the other way around. +Optional properties: + +- flashes - array of strings with flash led names; the name has to + be same with the related led label + (see Documentation/devicetree/bindings/leds/common.txt) + Why is this not an array of phandles to the LED nodes? That's much better than strings. This is because a single flash led device can control many sub-leds, which are represented by child nodes in the Device Tree. Every sub-led is registered as a separate LED Flash class device in the LED subsystem, but in fact they share the same struct device and thus have access only to the parent's phandle. The LED Flash class devices are wrapped by V4L2 sub-devices and register asynchronously within a media device. Since the v4l2_subdev structure has a 'name' field, it is convenient to initialize it with parsed 'label' property of a child led node and match the sub-devices in the media device basing on it. Also, I only seem to have recevied the documentation patches and none of the code -- in future when posting RFC DT patches, please Cc for the code too as it's useful context. Of course, I'll keep it in mind. Regards, Jacek -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] s5p-jpeg: Fix possible NULL pointer dereference in s_fmt
Some formats are not supported in encoding or decoding
mode for given type of buffer (e.g. V4L2_PIX_FMT_JPEG
is supported on output buffer only while in decoding
mode). Make S_FMT failing if not suitable format
is found.
Signed-off-by: Jacek Anaszewski
---
drivers/media/platform/s5p-jpeg/jpeg-core.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index d7571cd..dfab848 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1345,6 +1345,14 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct,
struct v4l2_format *f)
FMT_TYPE_OUTPUT : FMT_TYPE_CAPTURE;
q_data->fmt = s5p_jpeg_find_format(ct, pix->pixelformat, f_type);
+
+ if (!q_data->fmt) {
+ v4l2_err(&ct->jpeg->v4l2_dev,
+"Fourcc format (0x%08x) invalid.\n",
+f->fmt.pix.pixelformat);
+ return -EINVAL;
+ }
+
q_data->w = pix->width;
q_data->h = pix->height;
if (q_data->fmt->fourcc != V4L2_PIX_FMT_JPEG) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v4 11/11] Add a libv4l plugin for Exynos4 camera
Hi Sakari,
Thanks for the review.
On 11/27/2014 09:41 AM, Sakari Ailus wrote:
Hi Jacek,
On Fri, Nov 21, 2014 at 05:14:40PM +0100, Jacek Anaszewski wrote:
The plugin provides support for the media device on Exynos4 SoC.
It performs single plane <-> multi plane API conversion,
video pipeline linking and takes care of automatic data format
negotiation for the whole pipeline, after intercepting
VIDIOC_S_FMT or VIDIOC_TRY_FMT ioctls.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
---
configure.ac |1 +
lib/Makefile.am |7 +-
lib/libv4l-exynos4-camera/Makefile.am |7 +
lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c | 595 +
4 files changed, 609 insertions(+), 1 deletion(-)
create mode 100644 lib/libv4l-exynos4-camera/Makefile.am
create mode 100644 lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
diff --git a/configure.ac b/configure.ac
index c9b0524..ae653b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,7 @@ AC_CONFIG_FILES([Makefile
lib/libdvbv5/Makefile
lib/libv4l2rds/Makefile
lib/libv4l-mplane/Makefile
+ lib/libv4l-exynos4-camera/Makefile
utils/Makefile
utils/libv4l2util/Makefile
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 3a0e19c..56b3a9f 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -5,7 +5,12 @@ SUBDIRS = \
libv4l2rds \
libv4l-mplane
+if WITH_V4LUTILS
+SUBDIRS += \
+ libv4l-exynos4-camera
+endif
+
if LINUX_OS
SUBDIRS += \
libdvbv5
-endif
\ No newline at end of file
+endif
diff --git a/lib/libv4l-exynos4-camera/Makefile.am
b/lib/libv4l-exynos4-camera/Makefile.am
new file mode 100644
index 000..23c60c6
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/Makefile.am
@@ -0,0 +1,7 @@
+if WITH_V4L_PLUGINS
+libv4l2plugin_LTLIBRARIES = libv4l-exynos4-camera.la
+endif
+
+libv4l_exynos4_camera_la_SOURCES = libv4l-exynos4-camera.c
../../utils/media-ctl/libmediactl.c ../../utils/media-ctl/libv4l2subdev.c
../../utils/media-ctl/libv4l2media_ioctl.c ../../utils/media-ctl/mediatext.c
+libv4l_exynos4_camera_la_CFLAGS = -fvisibility=hidden -std=gnu99
+libv4l_exynos4_camera_la_LDFLAGS = -avoid-version -module -shared
-export-dynamic -lpthread
diff --git a/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
b/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
new file mode 100644
index 000..119c75c
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
@@ -0,0 +1,595 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "../../utils/media-ctl/libv4l2media_ioctl.h"
+#include "../../utils/media-ctl/mediactl.h"
+#include "../../utils/media-ctl/mediatext.h"
+#include "../../utils/media-ctl/v4l2subdev.h"
+#include "libv4l-plugin.h"
+
+struct media_device;
+struct media_entity;
+
+/*
+ * struct exynos4_camera_plugin - libv4l exynos4 camera plugin
+ * @media: media device comprising the vid_fd related video device
+ */
+struct exynos4_camera_plugin {
+ struct media_device *media;
+};
+
+#ifdef DEBUG
+#define V4L2_EXYNOS4_DBG(format, ARG...)\
+ printf("[%s:%d] [%s] " format " \n", __FILE__, __LINE__, __func__,
##ARG)
+#else
+#define V4L2_EXYNOS4_DBG(format, ARG...)
+#endif
+
+#define V4L2_EXYNOS4_ERR(format, ARG...)\
+ fprintf(stderr, "Libv4l Exynos4 camera plugin: "format "\n", ##ARG)
+
+#define V4L2_EXYNOS4_LOG(format, ARG...)\
+ fprintf(stdout, "Libv4l Exynos4 camera plugin: "format "\n", ##ARG)
+
+#if HAVE_VISIBILITY
+#define PLUGIN_PUBLIC __attribute__ ((visibility("default")))
+#else
+#define PLUGIN_PUBLIC
+#endif
+
+#define SYS_IOCTL(fd, cmd, arg) \
+ syscall(SYS_ioctl, (int)(fd), (unsigned long)(cmd), (void *)(arg))
+#define SIMPLE_CONVERT_IOCTL(fd, cmd, arg, __struc) ({ \
+ int __ret; \
+ struct __struc *req = arg; \
+ uint32_t type = req->type; \
+ req->type = convert_type(type); \
+ __ret = SYS_IOCTL(fd, cmd, arg);\
+
Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property
On 11/28/2014 01:30 PM, Mark Rutland wrote: On Fri, Nov 28, 2014 at 12:09:14PM +, Jacek Anaszewski wrote: On 11/28/2014 12:14 PM, Mark Rutland wrote: On Fri, Nov 28, 2014 at 09:18:00AM +, Jacek Anaszewski wrote: This patch adds a description of 'flashes' property to the samsung-fimc.txt. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Sylwester Nawrocki Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: --- .../devicetree/bindings/media/samsung-fimc.txt |7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt index 922d6f8..4b7ed03 100644 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt @@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera port A must be activated and the port B deactivated and for the state "active-b" it should be the other way around. +Optional properties: + +- flashes - array of strings with flash led names; the name has to + be same with the related led label + (see Documentation/devicetree/bindings/leds/common.txt) + Why is this not an array of phandles to the LED nodes? That's much better than strings. This is because a single flash led device can control many sub-leds, which are represented by child nodes in the Device Tree. Every sub-led is registered as a separate LED Flash class device in the LED subsystem, but in fact they share the same struct device and thus have access only to the parent's phandle. But that's a Linux infrastrcture issue, no? You don't have to use the node from the struct device to find the relevant phandle. Right. The LED Flash class devices are wrapped by V4L2 sub-devices and register asynchronously within a media device. Since the v4l2_subdev structure has a 'name' field, it is convenient to initialize it with parsed 'label' property of a child led node and match the sub-devices in the media device basing on it. While that might be convenient, I don't think it's fantastic to use that to describe the relationship, as this leaks Linux internals (e.g. I can refer to a name that doesn't exist in the DT but happens to be what Linux used, and it would work). Also, are the labels guaranteed to be globally unique? The labels are used for initializing class device name and kernel doesn't allow to initialize two devices with same names. This implies that labels are guaranteed to be globally unique. Unless I am missing something. Regards, Jacek -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 04/14] v4l2-async: change custom.match callback argument type
Hi Laurent,
On 11/29/2014 05:38 PM, Laurent Pinchart wrote:
Hi Jacek,
Thank you for the patch.
On Friday 28 November 2014 10:17:56 Jacek Anaszewski wrote:
It is useful to have an access to the async sub-device
being matched, not only to the related struct device.
Change match callback argument from struct device
to struct v4l2_subdev. It will allow e.g. for matching
a sub-device by its "name" property.
In principle I agree. However, we will need to reimplement v4l2-async based on
the component (drivers/base/component.c) framework at some point. As the
component framework is based on struct device, will it still be possible to
match on subdev name in that case ? If not, we might need to try to find
another approach to the issue.
There were reservations raised [1] concerning the way of matching
by name, as the labels are not guaranteed to be globally unique across
Device Tree. I admit, this issue has to be solved in a different way.
Especially in view of prospective transition to using
drivers/base/component.c
I propose to add a new structure:
struct v4l2_asd_match{
bool (*match)(struct v4l2_async_subdev *, void *);
void *priv;
}
and a function:
v4l2_async_register_subdev_with_match(struct v4l2_subdev *sd, struct
v4l2_asd_match*).
This way we could pass DT sub-node related to a sub-led in a priv
field of v4l2_asd_match upon registration.
This is similar approach as in case of drivers/base/component.c.
Best Regards,
Jacek Anaszewski
[1] http://www.spinics.net/lists/linux-leds/msg02532.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v4 05/11] mediactl: Add media device graph helpers
Hi Sakari,
Thanks for a review.
On 11/28/2014 06:06 PM, Sakari Ailus wrote:
Hi Jacek,
On Fri, Nov 21, 2014 at 05:14:34PM +0100, Jacek Anaszewski wrote:
Add new graph helpers useful for video pipeline discovering.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
---
utils/media-ctl/libmediactl.c | 174 +
utils/media-ctl/mediactl.h| 121
2 files changed, 295 insertions(+)
diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index af7dd43..a476601 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -35,6 +35,7 @@
#include
#include
+#include
#include
#include "mediactl.h"
@@ -87,6 +88,28 @@ struct media_entity *media_get_entity_by_name(struct
media_device *media,
return NULL;
}
+struct media_entity *media_get_entity_by_devname(struct media_device *media,
+ const char *devname, size_t
length)
+{
+ unsigned int i;
+
+ /* A match is impossible if the entity devname is longer than the
maximum
Over 80 characters per line.
+* size we can get from the kernel.
+*/
+ if (length >= FIELD_SIZEOF(struct media_entity, devname))
+ return NULL;
+
+ for (i = 0; i < media->entities_count; ++i) {
+ struct media_entity *entity = &media->entities[i];
+
+ if (strncmp(entity->devname, devname, length) == 0 &&
+ entity->devname[length] == '\0')
+ return entity;
+ }
+
+ return NULL;
+}
+
struct media_entity *media_get_entity_by_id(struct media_device *media,
__u32 id)
{
@@ -145,6 +168,11 @@ const char *media_entity_get_devname(struct media_entity
*entity)
return entity->devname[0] ? entity->devname : NULL;
}
+const char *media_entity_get_name(struct media_entity *entity)
+{
+ return entity->info.name ? entity->info.name : NULL;
You could simply return entity->info.name.
Right.
+}
+
struct media_entity *media_get_default_entity(struct media_device *media,
unsigned int type)
{
@@ -177,6 +205,152 @@ const struct media_entity_desc
*media_entity_get_info(struct media_entity *entit
return &entity->info;
}
+int media_get_link_by_sink_pad(struct media_device *media,
+ struct media_pad *pad,
+ struct media_link **link)
+{
+ struct media_link *cur_link = NULL;
+ int i, j;
+
+ if (pad == NULL || link == NULL)
+ return -EINVAL;
+
+ for (i = 0; i < media->entities_count; ++i) {
+ for (j = 0; j < media->entities[i].num_links; ++j) {
+ cur_link = &media->entities[i].links[j];
+ if ((cur_link->flags & MEDIA_LNK_FL_ENABLED) &&
+ /* check if cur_link's sink entity matches the pad
parent entity */
+ (cur_link->sink->entity->info.id == pad->entity->info.id)
&&
Hmm. This looks harder than it should be. Would it be possible loop over the
array of links in struct media_entity instead, and look for a sink?
I thought that the entity has only outbound links as it is in case of
MEDIA_IOC_ENUM_LINKS ioctl, but it seems that it has also the
inbound ones. Nice.
+ /* check if cur_link's sink pad id matches */
+ (cur_link->sink->index == pad->index)) {
+ *link = cur_link;
+ return 0;
+ }
+ }
+ }
+
+ return -EINVAL;
+}
+
+int media_get_link_by_source_pad(struct media_entity *entity,
+ struct media_pad *pad,
+ struct media_link **link)
+{
+ int i;
+
+ if (entity == NULL || pad == NULL || link == NULL)
+ return -EINVAL;
+
+ for (i = 0; i < entity->num_links; ++i) {
...just like you do it here. :-)
+ if ((entity->links[i].flags & MEDIA_LNK_FL_ENABLED) &&
+ (entity->links[i].source->index == pad->index)) {
+ *link = &entity->links[i];
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+
+int media_get_pads_by_entity(struct media_entity *entity, unsigned int type,
type should be flags, and flags uses __u32 type.
+ struct media_pad **pads, int *num_pads)
+{
+ struct media_pad *entity_pads;
+ int cnt_pads, i;
+
+ if (entity == NULL || pads == NULL || num_pads == NULL)
+ return -EINVAL;
+
Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
Hi Pavel, Thanks for a review. On 11/29/2014 01:58 PM, Pavel Machek wrote: Hi! +Flash LED handling under Linux +== + +Some LED devices support two modes - torch and flash. The modes are +supported by the LED class (see Documentation/leds/leds-class.txt) +and LED Flash class respectively. + +In order to enable support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol +must be defined in the kernel config. A flash LED driver must register +in the LED subsystem with led_classdev_flash_register to gain flash +capabilities. + +Following sysfs attributes are exposed for controlling flash led devices: + + - flash_brightness - flash LED brightness in microamperes (RW) + - max_flash_brightness - maximum available flash LED brightness (RO) + - indicator_brightness - privacy LED brightness in microamperes (RW) + - max_indicator_brightness - maximum privacy LED brightness in +microamperes (RO) + - flash_timeout - flash strobe duration in microseconds (RW) + - max_flash_timeout - maximum available flash strobe duration (RO) + - flash_strobe - flash strobe state (RW) + - flash_sync_strobe - one flash device can control more than one + sub-led; when this atrribute is set to 1 + the flash led will be strobed synchronously + with the other ones controlled by the same + device (RW) This is not really clear. Does flash_timeout or flash_brightness need to be set, first? I would go for inheriting the settings from the led that is strobed explicitly. Limits regarding current, the ones from device tree node, would have to however be preserved in my opinion. A consensus is needed here. Do we really want to have separate indicator brightnesses in uA? Should we maybe reuse existing "brightness" parameter for torch and indication, maybe adding single (RO) indicator_brightness attribute? I forgot to remove the indicator related positions. It has been definitely removed from the LED subsystem related patches. + - flash_fault - bitmask of flash faults that may have occurred, + possible flags are: + * 0x01 - flash controller voltage to the flash LED has exceeded +the limit specific to the flash controller + * 0x02 - the flash strobe was still on when the timeout set by +the user has expired; not all flash controllers may +set this in all such conditions + * 0x04 - the flash controller has overheated + * 0x08 - the short circuit protection of the flash controller +has been triggered + * 0x10 - current in the LED power supply has exceeded the limit +specific to the flash controller + * 0x40 - flash controller voltage to the flash LED has been +below the minimum limit specific to the flash + * 0x80 - the input voltage of the flash controller is below +the limit under which strobing the flash at full +current will not be possible. The condition persists +until this flag is no longer set + * 0x100 - the temperature of the LED has exceeded its allowed + upper limit How are faults cleared? Should it be list of strings, instead of bitmask? We may want to add new fault modes in future... Faults are cleared by reading the attribute. I will add this note. There can be more than one fault at a time. I think that the bitmask is a flexible solution. I don't see any troubles related to adding new fault modes in the future, do you? Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 12/14] leds: Add driver for AAT1290 current regulator
Hi Pavel,
Thanks for a review.
On 11/29/2014 08:05 PM, Pavel Machek wrote:
Hi!
@@ -0,0 +1,472 @@
+/*
+ * LED Flash class driver for the AAT1290
+ * 1.5A Step-Up Current Regulator for Flash LEDs
+ *
+ * Copyright (C) 2014, Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#define AAT1290_MM_TO_FL_1_92 1
+#define AAT1290_MM_TO_FL_3_7 2
+#define AAT1290_MM_TO_FL_5_5 3
+#define AAT1290_MM_TO_FL_7_3 4
+#define AAT1290_MM_TO_FL_9 5
+#define AAT1290_MM_TO_FL_10_7 6
+#define AAT1290_MM_TO_FL_12_4 7
+#define AAT1290_MM_TO_FL_148
+#define AAT1290_MM_TO_FL_15_9 9
+#define AAT1290_MM_TO_FL_17_5 10
+#define AAT1290_MM_TO_FL_19_1 11
+#define AAT1290_MM_TO_FL_20_8 12
+#define AAT1290_MM_TO_FL_22_4 13
+#define AAT1290_MM_TO_FL_2414
+#define AAT1290_MM_TO_FL_25_6 15
+#define AAT1290_MM_TO_FL_OFF 16
Only one of these defines is unused.
The only cost of these macros are lines of code and I think
it is worth of having all the possible settings listed in one place.
+static struct of_device_id aat1290_led_dt_match[] = {
+ {.compatible = "skyworks,aat1290"},
spaces after { and before } ?
I see both styles in kernel, but ok, I will add spaces.
Regards,
Jacek
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 09/14] mfd: max77693: adjust max77693_led_platform_data
Hi Lee,
Thanks for the review.
On 12/01/2014 12:34 PM, Lee Jones wrote:
On Fri, 28 Nov 2014, Jacek Anaszewski wrote:
Add "label" array for Device Tree strings with
the name of a LED device and make flash_timeout
a two element array, for caching the sub-led
related flash timeout.
<->
Please use all of the 75 char buffer.
OK.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Andrzej Hajda
Acked-by: Kyungmin Park
Cc: Lee Jones
Cc: SangYoung Son
Cc: Samuel Ortiz
---
include/linux/mfd/max77693.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
index f0b6585..30fa19ea 100644
--- a/include/linux/mfd/max77693.h
+++ b/include/linux/mfd/max77693.h
@@ -88,14 +88,15 @@ enum max77693_led_boost_mode {
};
struct max77693_led_platform_data {
+ const char *label[2];
u32 fleds[2];
u32 iout_torch[2];
u32 iout_flash[2];
u32 trigger[2];
u32 trigger_type[2];
+ u32 flash_timeout[2];
u32 num_leds;
u32 boost_mode;
- u32 flash_timeout;
u32 boost_vout;
u32 low_vsys;
};
I'm guessing this will effect the other patches in the set?
max77692 flash driver depends on it and it has to be
in synch with the related DT bindings patch.
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693
Hi Pavel, Thanks for the review. On 11/29/2014 08:26 PM, Pavel Machek wrote: Hi! diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 01e9f30..50a8dad 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation/devicetree/bindings/mfd/max77693.txt @@ -41,6 +41,62 @@ Optional properties: To get more informations, please refer to documentaion. [*] refer Documentation/devicetree/bindings/pwm/pwm.txt +- led-flash : the LED submodule device node + +There are two led outputs available - fled1 and fled2. Each of them can +control a separate led or they can be connected together to double +the maximum current for a single connected led. One led is represented +by one child node. + +Required properties: +- compatible : must be "maxim,max77693-flash" + +Optional properties: +- maxim,fleds : array of current outputs in order: fled1, fled2 + Note: both current outputs can be connected to a single led + Possible values: + 0 - the output is left disconnected, + 1 - a diode is connected to the output. Is this one needed? Just ommit child note if it is not there. It is needed because you can have one led connected two both outputs. This allows to describe such a design. +- maxim,trigger-type : Array of trigger types in order: flash, torch + Possible trigger types: + 0 - Rising edge of the signal triggers the flash/torch, + 1 - Signal level controls duration of the flash/torch. +- maxim,trigger : Array of flags indicating which trigger can activate given led + in order: fled1, fled2 + Possible flag values (can be combined): + 1 - FLASH pin of the chip, + 2 - TORCH pin of the chip, + 4 - software via I2C command. Is it good idea to have bitfields like this? Make these required properties of the subnode? This is related to a single property: trigger. I think that splitting it to three properties would make unnecessary noise in the binding. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693
Hi Pavel, On 12/01/2014 02:02 PM, Pavel Machek wrote: Hi! Is this one needed? Just ommit child note if it is not there. It is needed because you can have one led connected two both outputs. This allows to describe such a design. Ok. +- maxim,trigger-type : Array of trigger types in order: flash, torch + Possible trigger types: + 0 - Rising edge of the signal triggers the flash/torch, + 1 - Signal level controls duration of the flash/torch. +- maxim,trigger : Array of flags indicating which trigger can activate given led + in order: fled1, fled2 + Possible flag values (can be combined): + 1 - FLASH pin of the chip, + 2 - TORCH pin of the chip, + 4 - software via I2C command. Is it good idea to have bitfields like this? Make these required properties of the subnode? This is related to a single property: trigger. I think that splitting it to three properties would make unnecessary noise in the binding. Well, maybe it is not that much noise, and you'll have useful names (not a bitfield). I think we'd need an opinion of at least one more person :) Should these properties move to the LED subnode? I would leave them device specific. Regards, Jacek -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
Hi Pavel, On 12/01/2014 02:04 PM, Pavel Machek wrote: Hi! How are faults cleared? Should it be list of strings, instead of bitmask? We may want to add new fault modes in future... Faults are cleared by reading the attribute. I will add this note. There can be more than one fault at a time. I think that the bitmask is a flexible solution. I don't see any troubles related to adding new fault modes in the future, do you? I do not think that "read attribute to clear" is good idea. Normally, you'd want the error attribute world-readable, but you don't want non-root users to clear the errors. This is also V4L2_CID_FLASH_FAULT control semantics. Moreover many devices clear the errors upon reading register. I don't see anything wrong in the fact that an user can clear an error. If the user has a permission to use a device then it also should be allowed to clear the errors. I am not sure if bitmask is good solution. I'd return space-separated strings like "overtemp". That way, there's good chance that other LED drivers would be able to use similar interface... The format of a sysfs attribute should be concise. The error codes are generic and map directly to the V4L2 Flash error codes. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v4 05/11] mediactl: Add media device graph helpers
Hi Sakari, On 12/01/2014 01:30 PM, Sakari Ailus wrote: Hi Jacek, Jacek Anaszewski wrote: ... +int media_get_busy_pads_by_entity(struct media_device *media, +struct media_entity *entity, +unsigned int type, +struct media_pad **busy_pads, +int *num_busy_pads) Are you looking for enabled links that someone else would have configured here? The assumption is made here that there will be no concurrent users of a media device and an entity will have no more than one link connected to its sink pad. If this assumption is not valid than all the links in the pipeline would have to be defined in the media config and the pipeline would have to be only validated not discovered. By pipeline validation I mean checking whether all config links are enabled You do get an error from MEDIA_IOC_LINK_SETUP if enabling a link fails. My intention here was to discuss the situation when there is more than one active link connected to an entity sink pad(s). There are two options: a) more than one active link connected to the same sink pad (I don't know if this has been ever considered a valid arrangement) b) more than one active link connected to separate sink pads if the same entity. In both cases discovering a pipeline will require different approach than in the recent patch set, where there are only configurable links expected in the media config and those fixed aren't taken into account. After the config links are set up, the pipeline is discovered by walking from the sink entity upstream, until the entity with no sink pads is encountered. If more than one link is connected to the sink pad(s) of an entity the situation becomes ambiguous. Therefore I propose to define all the links for the pipeline in the media config. The fixed links could be marked with relevant flags. By validating the pipeline I meant checking whether all links from the media configuration file are active. I think we should have a more generic solution to that. This one still does not guard against concurrent user space processes that attempt to configure the media device. One possibility would be to add IOCTLs to grant and release exclusive write (i.e. change configuration) access to the device. Once streaming is started, exclusive access could be released by the user. I wonder what Laurent would think about that. I think this would be very robust --- one could start with resetting all the links one can, and then configure those that are needed; if this fails, then the pipeline is already used by someone else and streaming cannot taken place on it. No cleanup of the configuration is needed. This approach would preclude having more than one pipeline configured in a media device. That's not true. You can *configure* a single pipeline at once, but once that one is streaming (or write access is allowed from other file handles again), you can configure another one that does no conflict with the first one. OK, I missed that. But this is definitely out of scope of this patchset (also because this is for the user space). Taking into account that there are cases when it would be useful to allow for having more than one active pipelines in a media device I think that we would require changes in the media controller API. I would hide from the user a possibility of reconfiguring the links one by one, but instead provide an ioctl which would accept a definition of a whole pipeline to be linked. Something similar to extended controls. A user space process calling such an ioctl would take the ownership of the all involved sub-devices, and their linkage couldn't be reconfigured until released. That does not mean someone else could reconfigure the links before you attempt to start streaming. Therefore this ioctl should lock media device until VIDIOC_STREAMON on the configured pipeline. I am not sure about other implications and feasibility of such a design though. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 06/14] media: Add registration helpers for V4L2 flash sub-devices
On 11/28/2014 10:17 AM, Jacek Anaszewski wrote:
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Sakari Ailus
Cc: Hans Verkuil
---
drivers/media/v4l2-core/Kconfig | 11 +
drivers/media/v4l2-core/Makefile |2 +
drivers/media/v4l2-core/v4l2-flash.c | 516 ++
include/media/v4l2-flash.h | 138 +
4 files changed, 667 insertions(+)
create mode 100644 drivers/media/v4l2-core/v4l2-flash.c
create mode 100644 include/media/v4l2-flash.h
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index ba7e21a..f034f1a 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -44,6 +44,17 @@ config V4L2_MEM2MEM_DEV
tristate
depends on VIDEOBUF2_CORE
+# Used by LED subsystem flash drivers
+config V4L2_FLASH_LED_CLASS
+ tristate "Enable support for Flash sub-devices"
+ depends on VIDEO_V4L2_SUBDEV_API
+ depends on LEDS_CLASS_FLASH
+ ---help---
+ Say Y here to enable support for Flash sub-devices, which allow
+ to control LED class devices with use of V4L2 Flash controls.
+
+ When in doubt, say N.
+
# Used by drivers that need Videobuf modules
config VIDEOBUF_GEN
tristate
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index 63d29f2..44e858c 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_VIDEO_TUNER) += tuner.o
obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
+obj-$(CONFIG_V4L2_FLASH_LED_CLASS) += v4l2-flash.o
+
obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
obj-$(CONFIG_VIDEOBUF_DMA_CONTIG) += videobuf-dma-contig.o
diff --git a/drivers/media/v4l2-core/v4l2-flash.c
b/drivers/media/v4l2-core/v4l2-flash.c
new file mode 100644
index 000..f5075b0
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-flash.c
@@ -0,0 +1,516 @@
+/*
+ * V4L2 Flash LED sub-device registration helpers.
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation."
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define has_flash_op(v4l2_flash, op) \
+ (v4l2_flash && v4l2_flash->ops->op)
+
+#define call_flash_op(v4l2_flash, op, args...) \
+ (has_flash_op(v4l2_flash, op) ? \
+ v4l2_flash->ops->op(args) : \
+ -EINVAL)
+
+static inline enum led_brightness v4l2_flash_intensity_to_led_brightness(
+ struct v4l2_ctrl *ctrl,
+ s32 intensity)
+{
+ s64 __intensity = intensity - ctrl->minimum;
+
+ do_div(__intensity, ctrl->step);
+
+ return __intensity + 1;
+}
+
+static inline s32 v4l2_flash_led_brightness_to_intensity(
+ struct v4l2_ctrl *ctrl,
+ enum led_brightness brightness)
+{
+ return ((brightness - 1) * ctrl->step) + ctrl->minimum;
+}
+
+static int v4l2_flash_g_volatile_ctrl(struct v4l2_ctrl *c)
+{
+ struct v4l2_flash *v4l2_flash = v4l2_ctrl_to_v4l2_flash(c);
+ struct led_classdev_flash *flash = v4l2_flash->flash;
+ struct led_classdev *led_cdev = &flash->led_cdev;
+ struct v4l2_ctrl **ctrls = v4l2_flash->ctrls;
+ bool is_strobing;
+ int ret;
+
+ switch (c->id) {
+ case V4L2_CID_FLASH_TORCH_INTENSITY:
+ /*
+* Update torch brightness only if in TORCH_MODE.
+* In other modes torch led is turned off, which
+* would spuriously inform the user space that
+* V4L2_CID_FLASH_TORCH_INTENSITY control setting
+* has changed.
+*/
+ if (ctrls[LED_MODE]->val == V4L2_FLASH_LED_MODE_TORCH) {
+ ret = led_update_brightness(led_cdev);
+ if (ret < 0)
+ return ret;
+ c->val = v4l2_flash_led_brightness_to_intensity(
+ ctrls[TORCH_INTENSITY],
+ led_cdev->brightness);
+ }
+ return 0;
+ case
[PATCH/RFC v9 18/19] leds: max77693: add support for V4L2 Flash sub-device
Add support for V4L2 Flash sub-device to the max77693 LED Flash class
driver. The support allows for V4L2 Flash sub-device to take the control
of the LED Flash class device.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
Cc: Sakari Ailus
---
drivers/leds/leds-max77693.c | 133 +-
1 file changed, 132 insertions(+), 1 deletion(-)
diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
index 67a2f8f..e93edbd 100644
--- a/drivers/leds/leds-max77693.c
+++ b/drivers/leds/leds-max77693.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define MODE_OFF 0
#define MODE_FLASH1(1 << 0)
@@ -49,6 +50,7 @@ enum {
struct max77693_sub_led {
struct led_classdev_flash ldev;
struct work_struct work_brightness_set;
+ struct v4l2_flash *v4l2_flash;
unsigned int torch_brightness;
unsigned int flash_timeout;
@@ -602,6 +604,32 @@ unlock:
\
return ret; \
}
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+#define MAX77693_LED_FLASH_EXTERNAL_STROBE_SET(ID) \
+static int max77693_led##ID##_external_strobe_set( \
+ struct v4l2_flash *v4l2_flash, \
+ bool enable)\
+{ \
+ struct max77693_led *led = \
+ ldev##ID##_to_led(v4l2_flash->flash); \
+ int ret;\
+ \
+ mutex_lock(&led->lock); \
+ \
+ if (enable) \
+ ret = max77693_add_mode(led, MODE_FLASH_EXTERNAL##ID); \
+ else\
+ ret = max77693_clear_mode(led, \
+ MODE_FLASH_EXTERNAL##ID); \
+ \
+ mutex_unlock(&led->lock); \
+ \
+ return ret; \
+}
+#else
+#define MAX77693_LED_FLASH_EXTERNAL_STROBE_SET(ID)
+#endif
+
#define MAX77693_LED_FLASH_FAULT_GET(ID) \
static int max77693_led##ID##_flash_fault_get( \
struct led_classdev_flash *flash, \
@@ -670,6 +698,7 @@ MAX77693_LED_TORCH_BRIGHTNESS_SET(1)
MAX77693_LED_FLASH_BRIGHTNESS_SET(1)
MAX77693_LED_FLASH_STROBE_SET(1)
MAX77693_LED_FLASH_STROBE_GET(1)
+MAX77693_LED_FLASH_EXTERNAL_STROBE_SET(1)
MAX77693_LED_FLASH_TIMEOUT_SET(1)
MAX77693_LED_FLASH_FAULT_GET(1)
@@ -679,6 +708,7 @@ MAX77693_LED_TORCH_BRIGHTNESS_SET(2)
MAX77693_LED_FLASH_BRIGHTNESS_SET(2)
MAX77693_LED_FLASH_STROBE_SET(2)
MAX77693_LED_FLASH_STROBE_GET(2)
+MAX77693_LED_FLASH_EXTERNAL_STROBE_SET(2)
MAX77693_LED_FLASH_TIMEOUT_SET(2)
MAX77693_LED_FLASH_FAULT_GET(2)
@@ -838,9 +868,35 @@ static const struct led_flash_ops flash_ops##ID = {
\
.fault_get = max77693_led##ID##_flash_fault_get,
\
}
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+#define MAX77693_LED_V4L2_FLASH_OPS(ID)
\
+static const struct v4l2_flash_ops v4l2_flash##ID##_ops = {
\
+ .external_strobe_set = max77693_led##ID##_external_strobe_set,
\
+}
+
+#define MAX77693_LED_GET_V4L2_FLASH_OPS(ID)
\
+static inline const struct v4l2_flash_ops *get_v4l2_flash##ID##_ops(void)
\
+{
\
+ return &v4l2_flash##ID##_ops;
\
+}
+#else
+#define MAX77693_LED_V4L2_FLASH_OPS(ID)
+
+#define MAX77693_LED_GET_V4L2_FLASH_OPS(ID)
\
+static inline const struct v4l2_flash_ops *get_v4l2_flash##ID##_ops(void)
\
+{
\
+ return NULL;
\
+}
+#endif
+
MAX77693_LED_INIT_FLASH_OPS(1);
MAX77693_LED_INIT_FLASH_OPS(2);
+MAX77693_LED_V4L2_FLASH_OPS(1);
+MAX77693_LED_V4L2_FLASH_OPS(2);
+MAX77693_LED_GET_V4L2_FLASH_OPS(1);
+MAX77693_LED_GET_V4L2_F
[PATCH/RFC v9 19/19] leds: aat1290: add support for V4L2 Flash sub-device
Add support for V4L2 Flash sub-device to the aat1290 LED Flash class
driver. The support allows for V4L2 Flash sub-device to take the control
of the LED Flash class device.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
Cc: Sakari Ailus
---
drivers/leds/leds-aat1290.c | 61 +++
1 file changed, 61 insertions(+)
diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
index 15d969b..81a8f48 100644
--- a/drivers/leds/leds-aat1290.c
+++ b/drivers/leds/leds-aat1290.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#define AAT1290_MOVIE_MODE_CURRENT_ADDR17
@@ -63,6 +64,7 @@ struct aat1290_led {
struct mutex lock;
struct led_classdev_flash ldev;
+ struct v4l2_flash *v4l2_flash;
int flen_gpio;
int en_set_gpio;
@@ -280,11 +282,51 @@ static void aat1290_init_flash_settings(struct
aat1290_led *led,
setting->val = setting->max;
}
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+static void aat1290_init_v4l2_ctrl_config(struct aat1290_led_settings *s,
+ struct v4l2_flash_ctrl_config *config)
+{
+ struct led_flash_setting *setting;
+ struct v4l2_ctrl_config *c;
+
+ c = &config->intensity;
+ setting = &s->torch_brightness;
+ c->min = setting->min;
+ c->max = setting->max;
+ c->step = setting->step;
+ c->def = setting->val;
+
+ c = &config->flash_timeout;
+ setting = &s->flash_timeout;
+ c->min = setting->min;
+ c->max = setting->max;
+ c->step = setting->step;
+ c->def = setting->val;
+
+ config->has_external_strobe = false;
+}
+#else
+#define aat1290_init_v4l2_ctrl_config(s, config)
+#endif
+
static const struct led_flash_ops flash_ops = {
.strobe_set = aat1290_led_flash_strobe_set,
.timeout_set = aat1290_led_flash_timeout_set,
};
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+static const struct v4l2_flash_ops v4l2_flash_ops = {
+ .external_strobe_set = NULL,
+};
+
+static const struct v4l2_flash_ops *get_v4l2_flash_ops(void)
+{
+ return &v4l2_flash_ops;
+}
+#else
+#define get_v4l2_flash_ops() (NULL)
+#endif
+
static int aat1290_led_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -292,6 +334,9 @@ static int aat1290_led_probe(struct platform_device *pdev)
struct aat1290_led *led;
struct led_classdev *led_cdev;
struct led_classdev_flash *flash;
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+ struct v4l2_flash_ctrl_config v4l2_flash_config;
+#endif
struct aat1290_led_settings settings;
int flen_gpio, enset_gpio, ret;
@@ -344,6 +389,9 @@ static int aat1290_led_probe(struct platform_device *pdev)
flash->timeout = settings.flash_timeout;
+ /* Init V4L2 Flash controls basing on initialized settings */
+ aat1290_init_v4l2_ctrl_config(&settings, &v4l2_flash_config);
+
/* Init led class */
led_cdev = &flash->led_cdev;
led_cdev->name = led->label;
@@ -361,8 +409,20 @@ static int aat1290_led_probe(struct platform_device *pdev)
if (ret < 0)
goto error_gpio_en_set;
+ /* Create V4L2 Flash subdev. */
+ led->v4l2_flash = v4l2_flash_init(flash,
+ get_v4l2_flash_ops(),
+ dev_node,
+ &v4l2_flash_config);
+ if (IS_ERR(led->v4l2_flash)) {
+ ret = PTR_ERR(led->v4l2_flash);
+ goto error_v4l2_flash_init;
+ }
+
return 0;
+error_v4l2_flash_init:
+ led_classdev_flash_unregister(flash);
error_gpio_en_set:
if (gpio_is_valid(enset_gpio))
gpio_free(enset_gpio);
@@ -378,6 +438,7 @@ static int aat1290_led_remove(struct platform_device *pdev)
{
struct aat1290_led *led = platform_get_drvdata(pdev);
+ v4l2_flash_release(led->v4l2_flash);
led_classdev_flash_unregister(&led->ldev);
cancel_work_sync(&led->work_brightness_set);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v9 17/19] DT: Add documentation for exynos4-is 'flashes' property
This patch adds a description of 'flashes' property to the samsung-fimc.txt. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Sylwester Nawrocki Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: --- .../devicetree/bindings/media/samsung-fimc.txt |7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt index 922d6f8..22a6b2f 100644 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt @@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera port A must be activated and the port B deactivated and for the state "active-b" it should be the other way around. +Optional properties: + +- flashes - Array of phandles to flash LED devices, or their sub-nodes + representing sub-leds. + (see Documentation/devicetree/bindings/leds/common.txt) + The 'camera' node must include at least one 'fimc' child node. @@ -166,6 +172,7 @@ Example: clock-output-names = "cam_a_clkout", "cam_b_clkout"; pinctrl-names = "default"; pinctrl-0 = <&cam_port_a_clk_active>; + flashes = <&camera_flash>, <&system_torch>; status = "okay"; #address-cells = <1>; #size-cells = <1>; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v9 04/19] mfd: max77693: adjust max77693_led_platform_data
Add "label" array for Device Tree strings with the name of a LED device
and make flash_timeout a two element array, for caching the sub-led
related flash timeout. Added is also an array for caching pointers to the
sub-nodes representing sub-leds.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Chanwoo Choi
Cc: Lee Jones
---
include/linux/mfd/max77693.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
index f0b6585..c80ee99 100644
--- a/include/linux/mfd/max77693.h
+++ b/include/linux/mfd/max77693.h
@@ -88,16 +88,18 @@ enum max77693_led_boost_mode {
};
struct max77693_led_platform_data {
+ const char *label[2];
u32 fleds[2];
u32 iout_torch[2];
u32 iout_flash[2];
u32 trigger[2];
u32 trigger_type[2];
+ u32 flash_timeout[2];
u32 num_leds;
u32 boost_mode;
- u32 flash_timeout;
u32 boost_vout;
u32 low_vsys;
+ struct device_node *sub_nodes[2];
};
/* MAX77693 */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v9 11/19] v4l2-async: change custom.match callback argument type
It is useful to have an access to the async sub-device
being matched, not only to the related struct device.
Change match callback argument from struct device
to struct v4l2_subdev.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Guennadi Liakhovetski
Cc: Laurent Pinchart
Cc: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-async.c | 16
include/media/v4l2-async.h |2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 85a6a34..8140992 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -22,10 +22,10 @@
#include
#include
-static bool match_i2c(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
#if IS_ENABLED(CONFIG_I2C)
- struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_client *client = i2c_verify_client(sd->dev);
return client &&
asd->match.i2c.adapter_id == client->adapter->nr &&
asd->match.i2c.address == client->addr;
@@ -34,14 +34,14 @@ static bool match_i2c(struct device *dev, struct
v4l2_async_subdev *asd)
#endif
}
-static bool match_devname(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_devname(struct v4l2_subdev *sd, struct v4l2_async_subdev
*asd)
{
- return !strcmp(asd->match.device_name.name, dev_name(dev));
+ return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
}
-static bool match_of(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
- return dev->of_node == asd->match.of.node;
+ return sd->dev->of_node == asd->match.of.node;
}
static LIST_HEAD(subdev_list);
@@ -52,7 +52,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier *
struct v4l2_subdev *sd)
{
struct v4l2_async_subdev *asd;
- bool (*match)(struct device *, struct v4l2_async_subdev *);
+ bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
list_for_each_entry(asd, ¬ifier->waiting, list) {
/* bus_type has been verified valid before */
@@ -79,7 +79,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier *
}
/* match cannot be NULL here */
- if (match(sd->dev, asd))
+ if (match(sd, asd))
return asd;
}
diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
index 7683569..1c0b586 100644
--- a/include/media/v4l2-async.h
+++ b/include/media/v4l2-async.h
@@ -51,7 +51,7 @@ struct v4l2_async_subdev {
unsigned short address;
} i2c;
struct {
- bool (*match)(struct device *,
+ bool (*match)(struct v4l2_subdev *,
struct v4l2_async_subdev *);
void *priv;
} custom;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v9 09/19] of: Add Skyworks Solutions, Inc. vendor prefix
Use "skyworks" as the vendor prefix for the Skyworks Solutions, Inc. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index c177cd7..3006825 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -137,6 +137,7 @@ ricoh Ricoh Co. Ltd. rockchip Fuzhou Rockchip Electronics Co., Ltd samsungSamsung Semiconductor sandiskSandisk Corporation +skyworks Skyworks Solutions, Inc. sbsSmart Battery System schindler Schindler seagateSeagate Technology PLC -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
This patch adds device tree binding documentation for
the flash cell of the Maxim max77693 multifunctional device.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Andrzej Hajda
Acked-by: Kyungmin Park
Cc: Lee Jones
Cc: Chanwoo Choi
Cc: Bryan Wu
Cc: Richard Purdie
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc:
---
Documentation/devicetree/bindings/mfd/max77693.txt | 89
1 file changed, 89 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
b/Documentation/devicetree/bindings/mfd/max77693.txt
index 01e9f30..25a6e78 100644
--- a/Documentation/devicetree/bindings/mfd/max77693.txt
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -41,7 +41,66 @@ Optional properties:
To get more informations, please refer to documentaion.
[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
+- led : the LED submodule device node
+
+There are two led outputs available - fled1 and fled2. Each of them can
+control a separate led or they can be connected together to double
+the maximum current for a single connected led. One led is represented
+by one child node.
+
+Required properties:
+- compatible : Must be "maxim,max77693-led".
+
+Optional properties:
+- maxim,fleds : Array of current outputs in order: fled1, fled2.
+ Note: both current outputs can be connected to a single led
+ Possible values:
+ MAX77693_LED_FLED_UNUSED - the output is left disconnected,
+ MAX77693_LED_FLED_USED - a diode is connected to the output.
+- maxim,trigger-type : Array of trigger types in order: flash, torch.
+ Possible trigger types:
+ MAX77693_LED_TRIG_TYPE_EDGE - Rising edge of the signal triggers
+ the flash/torch,
+ MAX77693_LED_TRIG_TYPE_LEVEL - Signal level controls duration of
+ the flash/torch.
+- maxim,trigger : Array of flags indicating which trigger can activate given
led
+ in order: fled1, fled2.
+ Possible flag values (can be combined):
+ MAX77693_LED_TRIG_FLASHEN - FLASHEN pin of the chip,
+ MAX77693_LED_TRIG_TORCHEN - TORCHEN pin of the chip,
+ MAX77693_LED_TRIG_SOFTWARE - software via I2C command.
+- maxim,boost-mode :
+ In boost mode the device can produce up to 1.2A of total current
+ on both outputs. The maximum current on each output is reduced
+ to 625mA then. If there are two child led nodes defined then boost
+ is enabled by default.
+ Possible values:
+ MAX77693_LED_BOOST_OFF - no boost,
+ MAX77693_LED_BOOST_ADAPTIVE - adaptive mode,
+ MAX77693_LED_BOOST_FIXED - fixed mode.
+- maxim,boost-vout : Output voltage of the boost module in millivolts.
+- maxim,vsys-min : Low input voltage level in millivolts. Flash is not fired
+ if chip estimates that system voltage could drop below this level due
+ to flash power consumption.
+
+Required properties of the LED child node:
+- label : see Documentation/devicetree/bindings/leds/common.txt
+- maxim,fled_id : Identifier of the fled output the led is connected to;
+ MAX77693_LED_FLED1 - FLED1 output of the device - it has to be
+ used also if a single LED is connected to both outputs,
+ MAX77693_LED_FLED2 - FLED2 output of the device.
+
+Optional properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+ Range: 15625 - 25
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+ Range: 15625 - 100
+- flash-timeout-microsec : see
Documentation/devicetree/bindings/leds/common.txt
+ Range: 62500 - 100
+
Example:
+#include
+
max77693@66 {
compatible = "maxim,max77693";
reg = <0x66>;
@@ -73,4 +132,34 @@ Example:
pwms = <&pwm 0 4 0>;
pwm-names = "haptic";
};
+
+ led {
+ compatible = "maxim,max77693-led";
+ maxim,fleds = ;
+ maxim,trigger = ;
+ maxim,trigger-type = ;
+ maxim,boost-mode = ;
+ maxim,boost-vout = <5000>;
+ maxim,vsys-min = <2400>;
+
+ camera1_flash: led1 {
+ maxim,fled_id = ;
+ label = "max77693-flash1";
+ max-microamp = <25>;
+ flash-max-microamp = <625000>;
+ flash-timeout-microsec = <100>;
+ };
+
+ camera2_flash: led2 {
+
[PATCH/RFC v9 03/19] mfd: max77693: Modify flash cell name identifiers
Change flash cell identifiers from max77693-flash to max77693-led
to avoid confusion with NOR/NAND Flash.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Chanwoo Choi
Cc: Lee Jones
---
drivers/mfd/max77693.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index a159593..cb14afa 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -53,8 +53,8 @@ static const struct mfd_cell max77693_devs[] = {
.of_compatible = "maxim,max77693-haptic",
},
{
- .name = "max77693-flash",
- .of_compatible = "maxim,max77693-flash",
+ .name = "max77693-led",
+ .of_compatible = "maxim,max77693-led",
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v9 14/19] media: Add registration helpers for V4L2 flash sub-devices
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Sakari Ailus
Cc: Hans Verkuil
---
drivers/media/v4l2-core/Kconfig | 11 +
drivers/media/v4l2-core/Makefile |2 +
drivers/media/v4l2-core/v4l2-flash.c | 546 ++
include/media/v4l2-flash.h | 139 +
4 files changed, 698 insertions(+)
create mode 100644 drivers/media/v4l2-core/v4l2-flash.c
create mode 100644 include/media/v4l2-flash.h
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index ba7e21a..f034f1a 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -44,6 +44,17 @@ config V4L2_MEM2MEM_DEV
tristate
depends on VIDEOBUF2_CORE
+# Used by LED subsystem flash drivers
+config V4L2_FLASH_LED_CLASS
+ tristate "Enable support for Flash sub-devices"
+ depends on VIDEO_V4L2_SUBDEV_API
+ depends on LEDS_CLASS_FLASH
+ ---help---
+ Say Y here to enable support for Flash sub-devices, which allow
+ to control LED class devices with use of V4L2 Flash controls.
+
+ When in doubt, say N.
+
# Used by drivers that need Videobuf modules
config VIDEOBUF_GEN
tristate
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index 63d29f2..44e858c 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_VIDEO_TUNER) += tuner.o
obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
+obj-$(CONFIG_V4L2_FLASH_LED_CLASS) += v4l2-flash.o
+
obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
obj-$(CONFIG_VIDEOBUF_DMA_CONTIG) += videobuf-dma-contig.o
diff --git a/drivers/media/v4l2-core/v4l2-flash.c
b/drivers/media/v4l2-core/v4l2-flash.c
new file mode 100644
index 000..beff400
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-flash.c
@@ -0,0 +1,546 @@
+/*
+ * V4L2 Flash LED sub-device registration helpers.
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation."
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define has_flash_op(v4l2_flash, op) \
+ (v4l2_flash && v4l2_flash->ops->op)
+
+#define call_flash_op(v4l2_flash, op, args...) \
+ (has_flash_op(v4l2_flash, op) ? \
+ v4l2_flash->ops->op(args) : \
+ -EINVAL)
+
+static inline enum led_brightness v4l2_flash_intensity_to_led_brightness(
+ struct v4l2_ctrl **ctrls,
+ enum ctrl_init_data_id cdata_id,
+ s32 intensity)
+{
+ struct v4l2_ctrl *ctrl = ctrls[cdata_id];
+ s64 __intensity = intensity - ctrl->minimum;
+
+ do_div(__intensity, ctrl->step);
+
+ /*
+* Indicator leds, unlike torch leds, are turned on/off basing on
+* the state of V4L2_CID_FLASH_INDICATOR_INTENSITY control only.
+* Therefore it must be possible to set it to 0 level which in
+* the LED subsystem reflects LED_OFF state.
+*/
+ if (cdata_id != INDICATOR_INTENSITY)
+ ++__intensity;
+
+ return __intensity;
+}
+
+static inline s32 v4l2_flash_led_brightness_to_intensity(
+ struct v4l2_ctrl **ctrls,
+ enum ctrl_init_data_id cdata_id,
+ enum led_brightness brightness)
+{
+ struct v4l2_ctrl *ctrl = ctrls[cdata_id];
+
+ /*
+* Indicator leds, unlike torch leds, are turned on/off basing on
+* the state of V4L2_CID_FLASH_INDICATOR_INTENSITY control only.
+* Do not decrement brightness read from the LED subsystem for
+* indicator led as it may equal 0. For torch leds this function
+* is called only when V4L2_FLASH_LED_MODE_TORCH is set and the
+* brightness read is guaranteed to be greater than 0. In other
+* cases the cached torch intensity value is used.
+*/
+ if (cdata_id != INDICATOR_INTENSITY)
+ --brightness;
+
+ return (brightness * ctrl->step) + ctrl->minimum;
+}
+
+static int v4l2_flash_g_volatile_ctrl(struct v4l2_ctrl *c)
+{
+ struct v4l2_flash *v4l2_flash = v4l2_ctrl_to_v4l2_flash(c);
+
[PATCH/RFC v9 15/19] Documentation: leds: Add description of v4l2-flash sub-device
This patch extends LED Flash class documention by the description of interactions with v4l2-flash sub-device. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Acked-by: Sakari Ailus Cc: Bryan Wu Cc: Richard Purdie --- Documentation/leds/leds-class-flash.txt | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/leds/leds-class-flash.txt b/Documentation/leds/leds-class-flash.txt index 82e58b1..bc3855b 100644 --- a/Documentation/leds/leds-class-flash.txt +++ b/Documentation/leds/leds-class-flash.txt @@ -48,3 +48,16 @@ Following sysfs attributes are exposed for controlling flash led devices: upper limit Flash faults are cleared by reading the attribute. + +A LED subsystem driver can be controlled also from the level of VideoForLinux2 +subsystem. In order to enable this CONFIG_V4L2_FLASH_LED_CLASS symbol has to +be defined in the kernel config. The driver must call the v4l2_flash_init +function to get registered in the V4L2 subsystem. On remove the +v4l2_flash_release function has to be called (see ). + +After proper initialization a V4L2 Flash sub-device is created. The sub-device +exposes a number of V4L2 controls, which allow for controlling a LED Flash class +device with use of its internal kernel API. +Opening the V4L2 Flash sub-device makes the LED subsystem sysfs interface +unavailable. The interface is re-enabled after the V4L2 Flash sub-device +is closed. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v9 07/19] dt-binding: mfd: max77693: Add DT binding related macros
Add macros for max77693 led part related binding. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Lee Jones Cc: Chanwoo Choi --- include/dt-bindings/mfd/max77693.h | 38 1 file changed, 38 insertions(+) create mode 100644 include/dt-bindings/mfd/max77693.h diff --git a/include/dt-bindings/mfd/max77693.h b/include/dt-bindings/mfd/max77693.h new file mode 100644 index 000..4011cb47 --- /dev/null +++ b/include/dt-bindings/mfd/max77693.h @@ -0,0 +1,38 @@ +/* + * This header provides macros for MAX77693 device binding + * + * Copyright (C) 2014, Samsung Electronics Co., Ltd. + * + * Author: Jacek Anaszewski + */ + +#ifndef __DT_BINDINGS_MAX77693_H__ +#define __DT_BINDINGS_MAX77693_H + +/* External control pins */ +#define MAX77693_LED_FLED_UNUSED 0 +#define MAX77693_LED_FLED_USED 1 + +/* FLED pins */ +#define MAX77693_LED_FLED1 1 +#define MAX77693_LED_FLED2 2 + +/* External trigger type */ +#define MAX77693_LED_TRIG_TYPE_EDGE0 +#define MAX77693_LED_TRIG_TYPE_LEVEL 1 + +/* Trigger flags */ +#define MAX77693_LED_TRIG_FLASHEN (1 << 0) +#define MAX77693_LED_TRIG_TORCHEN (1 << 1) +#define MAX77693_LED_TRIG_SOFTWARE (1 << 2) + +#define MAX77693_LED_TRIG_ALL (MAX77693_LED_TRIG_FLASHEN | \ +MAX77693_LED_TRIG_TORCHEN | \ +MAX77693_LED_TRIG_SOFTWARE) + +/* Boost modes */ +#define MAX77693_LED_BOOST_OFF 0 +#define MAX77693_LED_BOOST_ADAPTIVE1 +#define MAX77693_LED_BOOST_FIXED 2 + +#endif /* __DT_BINDINGS_MAX77693_H */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v9 16/19] exynos4-is: Add support for v4l2-flash subdevs
This patch adds suppport for external v4l2-flash devices.
The support includes parsing camera-flash DT property
and asynchronous subdevice registration.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Sylwester Nawrocki
---
drivers/media/platform/exynos4-is/media-dev.c | 42 +++--
drivers/media/platform/exynos4-is/media-dev.h | 13 +++-
2 files changed, 52 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index f315ef9..b422d2e 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -451,6 +451,25 @@ rpm_put:
return ret;
}
+static void fimc_md_register_flash_entities(struct fimc_md *fmd)
+{
+ struct device_node *parent = fmd->pdev->dev.of_node;
+ struct device_node *np;
+ int i = 0;
+
+ do {
+ np = of_parse_phandle(parent, "flashes", i);
+ if (np) {
+ fmd->flash[fmd->num_flashes].asd.match_type =
+
V4L2_ASYNC_MATCH_CUSTOM_OF;
+ fmd->flash[fmd->num_flashes].asd.match.of.node = np;
+ fmd->num_flashes++;
+ fmd->async_subdevs[fmd->num_sensors + i] =
+ &fmd->flash[i].asd;
+ }
+ } while (np && (++i < FIMC_MAX_FLASHES));
+}
+
static int __of_get_csis_id(struct device_node *np)
{
u32 reg = 0;
@@ -1272,9 +1291,24 @@ static int subdev_notifier_bound(struct
v4l2_async_notifier *notifier,
struct v4l2_async_subdev *asd)
{
struct fimc_md *fmd = notifier_to_fimc_md(notifier);
+ struct device_node *node;
struct fimc_sensor_info *si = NULL;
int i;
+ node = v4l2_async_get_of_node_by_subdev(subdev);
+ if (node) {
+ /* Register flash subdev if detected any */
+ for (i = 0; i < ARRAY_SIZE(fmd->flash); i++) {
+ if (fmd->flash[i].asd.match.of.node == node) {
+ fmd->flash[i].subdev = subdev;
+ fmd->num_flashes++;
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+ }
+
/* Find platform data for this sensor subdev */
for (i = 0; i < ARRAY_SIZE(fmd->sensor); i++)
if (fmd->sensor[i].asd.match.of.node == subdev->dev->of_node)
@@ -1385,6 +1419,8 @@ static int fimc_md_probe(struct platform_device *pdev)
goto err_m_ent;
}
+ fimc_md_register_flash_entities(fmd);
+
mutex_unlock(&fmd->media_dev.graph_mutex);
ret = device_create_file(&pdev->dev, &dev_attr_subdev_conf_mode);
@@ -1401,12 +1437,14 @@ static int fimc_md_probe(struct platform_device *pdev)
goto err_attr;
}
- if (fmd->num_sensors > 0) {
+ if (fmd->num_sensors > 0 || fmd->num_flashes > 0) {
fmd->subdev_notifier.subdevs = fmd->async_subdevs;
- fmd->subdev_notifier.num_subdevs = fmd->num_sensors;
+ fmd->subdev_notifier.num_subdevs = fmd->num_sensors +
+ fmd->num_flashes;
fmd->subdev_notifier.bound = subdev_notifier_bound;
fmd->subdev_notifier.complete = subdev_notifier_complete;
fmd->num_sensors = 0;
+ fmd->num_flashes = 0;
ret = v4l2_async_notifier_register(&fmd->v4l2_dev,
&fmd->subdev_notifier);
diff --git a/drivers/media/platform/exynos4-is/media-dev.h
b/drivers/media/platform/exynos4-is/media-dev.h
index 0321454..feff9c8 100644
--- a/drivers/media/platform/exynos4-is/media-dev.h
+++ b/drivers/media/platform/exynos4-is/media-dev.h
@@ -34,6 +34,8 @@
#define FIMC_MAX_SENSORS 4
#define FIMC_MAX_CAMCLKS 2
+#define FIMC_MAX_FLASHES 2
+#define FIMC_MAX_ASYNC_SUBDEVS (FIMC_MAX_SENSORS + FIMC_MAX_FLASHES)
#define DEFAULT_SENSOR_CLK_FREQ2400U
/* LCD/ISP Writeback clocks (PIXELASYNCMx) */
@@ -93,6 +95,11 @@ struct fimc_sensor_info {
struct fimc_dev *host;
};
+struct fimc_flash_info {
+ struct v4l2_subdev *subdev;
+ struct v4l2_async_subdev asd;
+};
+
struct cam_clk {
struct clk_hw hw;
struct fimc_md *fmd;
@@ -104,6 +111,8 @@ struct cam_clk {
* @csis: MIPI CSIS subdevs data
* @sensor: array of registered sensor subdevs
* @num_sensors: actual number of registered sensors
+ * @flash: array of registered flash subdevs
+ * @num_flashes: actual number of registered fl
[PATCH/RFC v9 13/19] v4l2-ctrls: Add V4L2_CID_FLASH_SYNC_STROBE control
Add V4L2_CID_FLASH_SYNC_STROBE control for determining
whether a flash device strobe has to be synchronized
with other flash leds controller by the same device.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Sakari Ailus
Cc: Hans Verkuil
---
Documentation/DocBook/media/v4l/controls.xml | 11 +++
drivers/media/v4l2-core/v4l2-ctrls.c |2 ++
include/uapi/linux/v4l2-controls.h |1 +
3 files changed, 14 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index e013e4b..20179ab 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -4563,6 +4563,17 @@ interface and may change in the future.
after strobe during which another strobe will not be
possible. This is a read-only control.
+
+ V4L2_CID_FLASH_SYNC_STROBE
+ boolean
+
+
+ Synchronized strobe: whether the flash
+ should be strobed synchronously with the other one controlled
+ by the same device. Flash timeout setting is inherited from the
+ LED being strobed explicitly and flash intensity setting of a LED
+ being synchronized is used.
+
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 45c5b47..a7cca8c 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -846,6 +846,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_FLASH_FAULT: return "Faults";
case V4L2_CID_FLASH_CHARGE: return "Charge";
case V4L2_CID_FLASH_READY: return "Ready to Strobe";
+ case V4L2_CID_FLASH_SYNC_STROBE:return "Synchronize Strobe";
/* JPEG encoder controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -949,6 +950,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_FLASH_STROBE_STATUS:
case V4L2_CID_FLASH_CHARGE:
case V4L2_CID_FLASH_READY:
+ case V4L2_CID_FLASH_SYNC_STROBE:
case V4L2_CID_MPEG_VIDEO_DECODER_MPEG4_DEBLOCK_FILTER:
case V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE:
case V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 661f119..5bce13d 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -833,6 +833,7 @@ enum v4l2_flash_strobe_source {
#define V4L2_CID_FLASH_CHARGE (V4L2_CID_FLASH_CLASS_BASE + 11)
#define V4L2_CID_FLASH_READY (V4L2_CID_FLASH_CLASS_BASE + 12)
+#define V4L2_CID_FLASH_SYNC_STROBE (V4L2_CID_FLASH_CLASS_BASE + 13)
/* JPEG-class control IDs */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v9 10/19] DT: Add documentation for the Skyworks AAT1290
This patch adds device tree binding documentation for
1.5A Step-Up Current Regulator for Flash LEDs.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc:
---
.../devicetree/bindings/leds/leds-aat1290.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-aat1290.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-aat1290.txt
b/Documentation/devicetree/bindings/leds/leds-aat1290.txt
new file mode 100644
index 000..17b8f05
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-aat1290.txt
@@ -0,0 +1,17 @@
+* Skyworks Solutions, Inc. AAT1290 Current Regulator for Flash LEDs
+
+Required properties:
+
+- compatible : Must be "skyworks,aat1290".
+- gpios : Two gpio pins in order FLEN, EN/SET.
+- flash-timeout-microsec : Maximum flash timeout in microseconds -
+ it can be calculated using following formula:
+ T = 8.82 * 10^9 * Ct.
+
+Example:
+
+flash_led: led {
+ compatible = "skyworks,aat1290";
+ gpios = <&gpj1 1 0>, <&gpj1 2 0>;
+ flash-timeout-microsec = <194>;
+}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v9 05/19] leds: Add support for max77693 mfd flash cell
This patch adds led-flash support to Maxim max77693 chipset.
A device can be exposed to user space through LED subsystem
sysfs interface. Device supports up to two leds which can
work in flash and torch mode. The leds can be triggered
externally or by software.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Andrzej Hajda
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
Cc: Lee Jones
Cc: Chanwoo Choi
---
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile|1 +
drivers/leds/leds-max77693.c | 1023 ++
3 files changed, 1034 insertions(+)
create mode 100644 drivers/leds/leds-max77693.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index fa8021e..2e66d55 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -463,6 +463,16 @@ config LEDS_TCA6507
LED driver chips accessed via the I2C bus.
Driver support brightness control and hardware-assisted blinking.
+config LEDS_MAX77693
+ tristate "LED support for MAX77693 Flash"
+ depends on LEDS_CLASS_FLASH
+ depends on MFD_MAX77693
+ depends on OF
+ help
+ This option enables support for the flash part of the MAX77693
+ multifunction device. It has build in control for two leds in flash
+ and torch mode.
+
config LEDS_MAX8997
tristate "LED support for MAX8997 PMIC"
depends on LEDS_CLASS && MFD_MAX8997
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index cbba921..57ca62b 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_LEDS_MC13783)+= leds-mc13783.o
obj-$(CONFIG_LEDS_NS2) += leds-ns2.o
obj-$(CONFIG_LEDS_NETXBIG) += leds-netxbig.o
obj-$(CONFIG_LEDS_ASIC3) += leds-asic3.o
+obj-$(CONFIG_LEDS_MAX77693)+= leds-max77693.o
obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
new file mode 100644
index 000..67a2f8f
--- /dev/null
+++ b/drivers/leds/leds-max77693.c
@@ -0,0 +1,1023 @@
+/*
+ * LED Flash class driver for the flash cell of max77693 mfd.
+ *
+ * Copyright (C) 2014, Samsung Electronics Co., Ltd.
+ *
+ * Authors: Jacek Anaszewski
+ * Andrzej Hajda
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MODE_OFF 0
+#define MODE_FLASH1(1 << 0)
+#define MODE_FLASH2(1 << 1)
+#define MODE_TORCH1(1 << 2)
+#define MODE_TORCH2(1 << 3)
+#define MODE_FLASH_EXTERNAL1 (1 << 4)
+#define MODE_FLASH_EXTERNAL2 (1 << 5)
+
+#define MODE_FLASH (MODE_FLASH1 | MODE_FLASH2 | \
+MODE_FLASH_EXTERNAL1 | MODE_FLASH_EXTERNAL2)
+
+#define FLED1_IOUT (1 << 0)
+#define FLED2_IOUT (1 << 1)
+
+enum {
+ FLED1,
+ FLED2
+};
+
+enum {
+ FLASH,
+ TORCH
+};
+
+struct max77693_sub_led {
+ struct led_classdev_flash ldev;
+ struct work_struct work_brightness_set;
+
+ unsigned int torch_brightness;
+ unsigned int flash_timeout;
+};
+
+struct max77693_led {
+ struct regmap *regmap;
+ struct platform_device *pdev;
+ struct max77693_led_platform_data *pdata;
+ struct mutex lock;
+
+ struct max77693_sub_led sub_leds[2];
+
+ unsigned int current_flash_timeout;
+ unsigned int mode_flags;
+ u8 torch_iout_reg;
+ bool iout_joint;
+ int strobing_sub_led_id;
+};
+
+struct max77693_led_settings {
+ struct led_flash_setting torch_brightness;
+ struct led_flash_setting flash_brightness;
+ struct led_flash_setting flash_timeout;
+};
+
+static u8 max77693_led_iout_to_reg(u32 ua)
+{
+ if (ua < FLASH_IOUT_MIN)
+ ua = FLASH_IOUT_MIN;
+ return (ua - FLASH_IOUT_MIN) / FLASH_IOUT_STEP;
+}
+
+static u8 max77693_flash_timeout_to_reg(u32 us)
+{
+ return (us - FLASH_TIMEOUT_MIN) / FLASH_TIMEOUT_STEP;
+}
+
+static inline struct max77693_led *ldev1_to_led(
+ struct led_classdev_flash *ldev)
+{
+ struct max77693_sub_led *sub_led = container_of(ldev,
+ struct max77693_sub_led,
+ ldev);
+ return container_of(sub_led, struct max77693_led, sub_leds[0]);
+}
+
+static inline struct max77693_led *ldev2_to_led(
+
[PATCH/RFC v9 08/19] leds: Add driver for AAT1290 current regulator
This patch adds a driver for the 1.5A Step-Up Current Regulator
for Flash LEDs. The device is programmed through a Skyworks proprietary
AS2Cwire serial digital interface.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/Kconfig|7 +
drivers/leds/Makefile |1 +
drivers/leds/leds-aat1290.c | 413 +++
3 files changed, 421 insertions(+)
create mode 100644 drivers/leds/leds-aat1290.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2e66d55..ec4b78c 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -39,6 +39,13 @@ config LEDS_88PM860X
This option enables support for on-chip LED drivers found on Marvell
Semiconductor 88PM8606 PMIC.
+config LEDS_AAT1290
+ tristate "LED support for the AAT1290"
+ depends on LEDS_CLASS_FLASH
+ depends on OF
+ help
+This option enables support for the LEDs on the AAT1290.
+
config LEDS_LM3530
tristate "LCD Backlight driver for LM3530"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 57ca62b..b802251 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
# LED Platform Drivers
obj-$(CONFIG_LEDS_88PM860X)+= leds-88pm860x.o
+obj-$(CONFIG_LEDS_AAT1290) += leds-aat1290.o
obj-$(CONFIG_LEDS_BD2802) += leds-bd2802.o
obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
new file mode 100644
index 000..15d969b
--- /dev/null
+++ b/drivers/leds/leds-aat1290.c
@@ -0,0 +1,413 @@
+/*
+ * LED Flash class driver for the AAT1290
+ * 1.5A Step-Up Current Regulator for Flash LEDs
+ *
+ * Copyright (C) 2014, Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define AAT1290_MOVIE_MODE_CURRENT_ADDR17
+#define AAT1290_FLASH_SAFETY_TIMER_ADDR18
+#define AAT1290_MOVIE_MODE_CONFIG_ADDR 19
+#define AAT1290_MM_CURRENT_RATIO_ADDR 20
+#define AAT1290_LATCH_TIME_US 500
+#define AAT1290_EN_SET_TICK_TIME_US1
+#define AAT1290_MOVIE_MODE_OFF 1
+#define AAT1290_MOVIE_MODE_ON 3
+#define AAT1290_MAX_MM_CURR_PERCENT_0 16
+#define AAT1290_MAX_MM_CURR_PERCENT_100 1
+#define AAT1290_FLASH_TM_NUM_LEVELS16
+
+#define AAT1290_MM_TO_FL_1_92 1
+#define AAT1290_MM_TO_FL_3_7 2
+#define AAT1290_MM_TO_FL_5_5 3
+#define AAT1290_MM_TO_FL_7_3 4
+#define AAT1290_MM_TO_FL_9 5
+#define AAT1290_MM_TO_FL_10_7 6
+#define AAT1290_MM_TO_FL_12_4 7
+#define AAT1290_MM_TO_FL_148
+#define AAT1290_MM_TO_FL_15_9 9
+#define AAT1290_MM_TO_FL_17_5 10
+#define AAT1290_MM_TO_FL_19_1 11
+#define AAT1290_MM_TO_FL_20_8 12
+#define AAT1290_MM_TO_FL_22_4 13
+#define AAT1290_MM_TO_FL_2414
+#define AAT1290_MM_TO_FL_25_6 15
+#define AAT1290_MM_TO_FL_OFF 16
+
+struct aat1290_led_settings {
+ struct led_flash_setting torch_brightness;
+ struct led_flash_setting flash_brightness;
+ struct led_flash_setting flash_timeout;
+};
+
+struct aat1290_led {
+ struct platform_device *pdev;
+ struct mutex lock;
+
+ struct led_classdev_flash ldev;
+
+ int flen_gpio;
+ int en_set_gpio;
+
+ u32 max_flash_tm;
+ bool movie_mode;
+
+ char *label;
+ unsigned int torch_brightness;
+ unsigned int flash_timeout;
+ struct work_struct work_brightness_set;
+};
+
+static struct aat1290_led *ldev_to_led(struct led_classdev_flash *ldev)
+{
+ return container_of(ldev, struct aat1290_led, ldev);
+}
+
+static void aat1290_as2cwire_write(struct aat1290_led *led, int addr, int
value)
+{
+ int i;
+
+ gpio_set_value(led->flen_gpio, 0);
+ gpio_set_value(led->en_set_gpio, 0);
+
+ udelay(10);
+
+ /* write address */
+ for (i = 0; i < addr; ++i) {
+ udelay(AAT1290_EN_SET_TICK_TIME_US);
+ gpio_set_value(led->en_set_gpio, 0);
+ udelay(AAT1290_EN_SET_TICK_TIME_US);
+ gpio_set_value(led->en_set_gpio, 1);
+ }
+
+ udelay(AAT1290_LATCH_TIME_US);
+
+ /* write data */
+ for (i = 0; i < value; ++i) {
+ udelay(AAT1290_EN_SET_TICK_TIME_US);
+ gpio_set_value(led->en_set_gpio, 0);
+ udelay(AAT1290_EN_SET_TICK_TIME_US);
+ gpio_set_value(led->en_set_gpio, 1);
+
[PATCH/RFC v9 12/19] v4l2-async: add V4L2_ASYNC_MATCH_CUSTOM_OF matching type
There are cases where a v4l2 sub-device is not related to the
main Device Tree node of a device, but to its child node.
Add v4l2_async_get_of_node_by_subdev function to facilitate
associating a sub-device with different Device Tree node
than the one from the related struct device. Added is also
V4L2_ASYNC_MATCH_CUSTOM_OF matching type to declare this
type of matching.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Guennadi Liakhovetski
Cc: Laurent Pinchart
Cc: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-async.c | 106 ++
include/media/v4l2-async.h |4 ++
2 files changed, 98 insertions(+), 12 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 8140992..faa16484 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -22,6 +22,17 @@
#include
#include
+static LIST_HEAD(subdev_list);
+static LIST_HEAD(notifier_list);
+static LIST_HEAD(custom_of_list);
+static DEFINE_MUTEX(list_lock);
+
+struct v4l2_subdev_to_of_node {
+ struct v4l2_subdev *sd;
+ struct device_node *node;
+ struct list_head list;
+};
+
static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
#if IS_ENABLED(CONFIG_I2C)
@@ -44,9 +55,17 @@ static bool match_of(struct v4l2_subdev *sd, struct
v4l2_async_subdev *asd)
return sd->dev->of_node == asd->match.of.node;
}
-static LIST_HEAD(subdev_list);
-static LIST_HEAD(notifier_list);
-static DEFINE_MUTEX(list_lock);
+static bool match_custom_of(struct v4l2_subdev *sd, struct v4l2_async_subdev
*asd)
+{
+ struct v4l2_subdev_to_of_node *sd_to_of;
+
+ list_for_each_entry(sd_to_of, &custom_of_list, list)
+ if ((sd_to_of->sd == sd) &&
+ (sd_to_of->node == asd->match.of.node))
+ return true;
+
+ return false;
+}
static struct v4l2_async_subdev *v4l2_async_belongs(struct v4l2_async_notifier
*notifier,
struct v4l2_subdev *sd)
@@ -72,6 +91,9 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier *
case V4L2_ASYNC_MATCH_OF:
match = match_of;
break;
+ case V4L2_ASYNC_MATCH_CUSTOM_OF:
+ match = match_custom_of;
+ break;
default:
/* Cannot happen, unless someone breaks us */
WARN_ON(true);
@@ -120,9 +142,19 @@ static int v4l2_async_test_notify(struct
v4l2_async_notifier *notifier,
static void v4l2_async_cleanup(struct v4l2_subdev *sd)
{
+ struct v4l2_subdev_to_of_node *sd_to_of, *tmp;
+
v4l2_device_unregister_subdev(sd);
/* Subdevice driver will reprobe and put the subdev back onto the list
*/
list_del_init(&sd->async_list);
+
+ list_for_each_entry_safe(sd_to_of, tmp, &custom_of_list, list) {
+ if (sd_to_of->sd == sd) {
+ list_del(&sd_to_of->list);
+ kfree (sd_to_of);
+ }
+ }
+
sd->asd = NULL;
sd->dev = NULL;
}
@@ -149,6 +181,7 @@ int v4l2_async_notifier_register(struct v4l2_device
*v4l2_dev,
case V4L2_ASYNC_MATCH_DEVNAME:
case V4L2_ASYNC_MATCH_I2C:
case V4L2_ASYNC_MATCH_OF:
+ case V4L2_ASYNC_MATCH_CUSTOM_OF:
break;
default:
dev_err(notifier->v4l2_dev ? notifier->v4l2_dev->dev :
NULL,
@@ -262,32 +295,65 @@ void v4l2_async_notifier_unregister(struct
v4l2_async_notifier *notifier)
}
EXPORT_SYMBOL(v4l2_async_notifier_unregister);
-int v4l2_async_register_subdev(struct v4l2_subdev *sd)
+static int __v4l2_async_register_subdev(struct v4l2_subdev *sd)
{
struct v4l2_async_notifier *notifier;
- mutex_lock(&list_lock);
-
INIT_LIST_HEAD(&sd->async_list);
list_for_each_entry(notifier, ¬ifier_list, list) {
struct v4l2_async_subdev *asd = v4l2_async_belongs(notifier,
sd);
- if (asd) {
- int ret = v4l2_async_test_notify(notifier, sd, asd);
- mutex_unlock(&list_lock);
- return ret;
- }
+ if (asd)
+ return v4l2_async_test_notify(notifier, sd, asd);
}
/* None matched, wait for hot-plugging */
list_add(&sd->async_list, &subdev_list);
+ return 0;
+}
+
+int v4l2_async_register_subdev(struct v4l2_subdev *sd)
+{
+ int ret;
+
+ mutex_lock(&list_lock);
+
+ ret = __v4l2_async_register_subdev(sd);
+
mutex_unlock(&list_lock);
- return 0;
+ return ret;
}
EXPORT_
[PATCH/RFC v9 02/19] Documentation: leds: Add description of LED Flash class extension
The documentation being added contains overall description of the LED Flash Class and the related sysfs attributes. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Bryan Wu Cc: Richard Purdie --- Documentation/leds/leds-class-flash.txt | 50 +++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/leds/leds-class-flash.txt diff --git a/Documentation/leds/leds-class-flash.txt b/Documentation/leds/leds-class-flash.txt new file mode 100644 index 000..82e58b1 --- /dev/null +++ b/Documentation/leds/leds-class-flash.txt @@ -0,0 +1,50 @@ + +Flash LED handling under Linux +== + +Some LED devices support two modes - torch and flash. The modes are +supported by the LED class (see Documentation/leds/leds-class.txt) +and LED Flash class respectively. + +In order to enable support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol +must be defined in the kernel config. A flash LED driver must register +in the LED subsystem with led_classdev_flash_register to gain flash +capabilities. + +Following sysfs attributes are exposed for controlling flash led devices: + + - flash_brightness - flash LED brightness in microamperes (RW) + - max_flash_brightness - maximum available flash LED brightness (RO) + - flash_timeout - flash strobe duration in microseconds (RW) + - max_flash_timeout - maximum available flash strobe duration (RO) + - flash_strobe - flash strobe state (RW) + - flash_sync_strobe - one flash device can control more than one + sub-led; when this atrribute is set to 1 + the flash led will be strobed synchronously + with the other one controlled by the same + device; flash timeout setting is inherited + from the led being strobed explicitly and + flash brightness setting of a sub-led's + being synchronized is used (RW) + - flash_fault - bitmask of flash faults that may have occurred + possible flags are: + * 0x01 - flash controller voltage to the flash LED has exceeded +the limit specific to the flash controller + * 0x02 - the flash strobe was still on when the timeout set by +the user has expired; not all flash controllers may +set this in all such conditions + * 0x04 - the flash controller has overheated + * 0x08 - the short circuit protection of the flash controller +has been triggered + * 0x10 - current in the LED power supply has exceeded the limit +specific to the flash controller + * 0x40 - flash controller voltage to the flash LED has been +below the minimum limit specific to the flash + * 0x80 - the input voltage of the flash controller is below +the limit under which strobing the flash at full +current will not be possible. The condition persists +until this flag is no longer set + * 0x100 - the temperature of the LED has exceeded its allowed + upper limit + + Flash faults are cleared by reading the attribute. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v9 00/19] LED / flash API integration
This patch set is a follow-up of the LED / flash API integration series [1]. Changes since version 8: - added a new way of registering async sub-device - switched to matching flash leds by DT phandles - improved Device Tree bindings documentation - split the drivers patches to LED Flash class and V4L2 Flash part - fixed indicator leds handling in v4l2-flash - applied various fixes an cleanups Changes since version 7: - removed explicit support for indicator leds from LED Flash class - indicator leds will be registered as a separate LED Flash class devices - added flash_sync_strobe sysfs attribute and related V4L2_CID_FLASH_SYNC_STROBE control - changed the way of matching V4L2 Flash sub-devices in a media device, which entailed modification in v4l2-async driver - modified max77693 DT bindings documentation - applied various fixes an cleanups Changes since version 6: - removed addition of public LED subsystem API for setting torch brightness in favour of internal API for synchronous and asynchronous led brightness level setting - fixed possible race condition upon creating LED Flash class related sysfs attributes Changes since version 5: - removed flash manager framework - its implementation needs further thorough discussion. - removed external strobe facilities from the LED Flash Class and provided external_strobe_set op in v4l2-flash. LED subsystem should be strobe provider agnostic. Thanks, Jacek Anaszewski Jacek Anaszewski (19): leds: Add LED Flash class extension to the LED subsystem Documentation: leds: Add description of LED Flash class extension mfd: max77693: Modify flash cell name identifiers mfd: max77693: adjust max77693_led_platform_data leds: Add support for max77693 mfd flash cell DT: Add documentation for the mfd Maxim max77693 dt-binding: mfd: max77693: Add DT binding related macros leds: Add driver for AAT1290 current regulator of: Add Skyworks Solutions, Inc. vendor prefix DT: Add documentation for the Skyworks AAT1290 v4l2-async: change custom.match callback argument type v4l2-async: add V4L2_ASYNC_MATCH_CUSTOM_OF matching type v4l2-ctrls: Add V4L2_CID_FLASH_SYNC_STROBE control media: Add registration helpers for V4L2 flash sub-devices Documentation: leds: Add description of v4l2-flash sub-device exynos4-is: Add support for v4l2-flash subdevs DT: Add documentation for exynos4-is 'flashes' property leds: max77693: add support for V4L2 Flash sub-device leds: aat1290: add support for V4L2 Flash sub-device Documentation/DocBook/media/v4l/controls.xml | 11 + .../devicetree/bindings/leds/leds-aat1290.txt | 17 + .../devicetree/bindings/media/samsung-fimc.txt |7 + Documentation/devicetree/bindings/mfd/max77693.txt | 89 ++ .../devicetree/bindings/vendor-prefixes.txt|1 + Documentation/leds/leds-class-flash.txt| 63 ++ drivers/leds/Kconfig | 27 + drivers/leds/Makefile |3 + drivers/leds/led-class-flash.c | 446 drivers/leds/led-class.c |4 + drivers/leds/leds-aat1290.c| 474 drivers/leds/leds-max77693.c | 1154 drivers/media/platform/exynos4-is/media-dev.c | 42 +- drivers/media/platform/exynos4-is/media-dev.h | 13 +- drivers/media/v4l2-core/Kconfig| 11 + drivers/media/v4l2-core/Makefile |2 + drivers/media/v4l2-core/v4l2-async.c | 122 ++- drivers/media/v4l2-core/v4l2-ctrls.c |2 + drivers/media/v4l2-core/v4l2-flash.c | 546 + drivers/mfd/max77693.c |4 +- include/dt-bindings/mfd/max77693.h | 38 + include/linux/led-class-flash.h| 186 include/linux/leds.h |3 + include/linux/mfd/max77693.h |4 +- include/media/v4l2-async.h |6 +- include/media/v4l2-flash.h | 139 +++ include/uapi/linux/v4l2-controls.h |1 + 27 files changed, 3388 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/leds-aat1290.txt create mode 100644 Documentation/leds/leds-class-flash.txt create mode 100644 drivers/leds/led-class-flash.c create mode 100644 drivers/leds/leds-aat1290.c create mode 100644 drivers/leds/leds-max77693.c create mode 100644 drivers/media/v4l2-core/v4l2-flash.c create mode 100644 include/dt-bindings/mfd/max77693.h create mode 100644 include/linux/led-class-flash.h create mode 100644 include/media/v4
[PATCH/RFC v9 01/19] leds: Add LED Flash class extension to the LED subsystem
Some LED devices support two operation modes - torch and flash.
This patch provides support for flash LED devices in the LED subsystem
by introducing new sysfs attributes and kernel internal interface.
The attributes being introduced are: flash_brightness, flash_strobe,
flash_timeout, max_flash_timeout, max_flash_brightness, flash_fault
and flash_sync_strobe. All the flash related features are placed
in a separate module. Torch mode is supported by the LED class
interface.
The modifications aim to be compatible with V4L2 framework requirements
related to the flash devices management. The design assumes that V4L2
sub-device can take of the LED class device control and communicate
with it through the kernel internal interface. When V4L2 Flash sub-device
file is opened, the LED class device sysfs interface is made
unavailable.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/Kconfig| 10 +
drivers/leds/Makefile |1 +
drivers/leds/led-class-flash.c | 446 +++
drivers/leds/led-class.c|4 +
include/linux/led-class-flash.h | 186
include/linux/leds.h|3 +
6 files changed, 650 insertions(+)
create mode 100644 drivers/leds/led-class-flash.c
create mode 100644 include/linux/led-class-flash.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b3c0d8a..fa8021e 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -19,6 +19,16 @@ config LEDS_CLASS
This option enables the led sysfs class in /sys/class/leds. You'll
need this to do anything useful with LEDs. If unsure, say N.
+config LEDS_CLASS_FLASH
+ tristate "LED Flash Class Support"
+ depends on LEDS_CLASS
+ help
+ This option enables the flash led sysfs class in /sys/class/leds.
+ It wrapps LED Class and adds flash LEDs specific sysfs attributes
+ and kernel internal API to it. You'll need this to provide support
+ for the flash related features of a LED device. It can be built
+ as a module.
+
comment "LED drivers"
config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1c65a19..cbba921 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -2,6 +2,7 @@
# LED Core
obj-$(CONFIG_NEW_LEDS) += led-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
+obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
obj-$(CONFIG_LEDS_TRIGGERS)+= led-triggers.o
# LED Platform Drivers
diff --git a/drivers/leds/led-class-flash.c b/drivers/leds/led-class-flash.c
new file mode 100644
index 000..219b414
--- /dev/null
+++ b/drivers/leds/led-class-flash.c
@@ -0,0 +1,446 @@
+/*
+ * LED Flash class interface
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "leds.h"
+
+#define has_flash_op(flash, op)\
+ (flash && flash->ops->op)
+
+#define call_flash_op(flash, op, args...) \
+ ((has_flash_op(flash, op)) ?\
+ (flash->ops->op(flash, args)) : \
+ -EINVAL)
+
+static ssize_t flash_brightness_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_flash *flash = lcdev_to_flash(led_cdev);
+ unsigned long state;
+ ssize_t ret;
+
+ mutex_lock(&led_cdev->led_access);
+
+ if (led_sysfs_is_disabled(led_cdev)) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ ret = kstrtoul(buf, 10, &state);
+ if (ret)
+ goto unlock;
+
+ ret = led_set_flash_brightness(flash, state);
+ if (ret < 0)
+ goto unlock;
+
+ ret = size;
+unlock:
+ mutex_unlock(&led_cdev->led_access);
+ return ret;
+}
+
+static ssize_t flash_brightness_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_flash *flash = lcdev_to_flash(led_cdev);
+
+ /* no lock needed for this */
+ led_update_flash_brightness(flash);
+
+ return sprintf(buf, "%u\n", flash->brightness.val);
+}
+static DEVICE_ATTR_RW(flash_brightness);
+
+static ssize_t max_flash_brightness_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classd
Re: [PATCH/RFC v9 01/19] leds: Add LED Flash class extension to the LED subsystem
Hi Sakari,
Thanks for the review.
On 12/03/2014 05:50 PM, Sakari Ailus wrote:
Hi Jacek,
Thanks for the update. A few comments below.
On Wed, Dec 03, 2014 at 05:06:36PM +0100, Jacek Anaszewski wrote:
Some LED devices support two operation modes - torch and flash.
This patch provides support for flash LED devices in the LED subsystem
by introducing new sysfs attributes and kernel internal interface.
The attributes being introduced are: flash_brightness, flash_strobe,
flash_timeout, max_flash_timeout, max_flash_brightness, flash_fault
and flash_sync_strobe. All the flash related features are placed
in a separate module. Torch mode is supported by the LED class
interface.
The modifications aim to be compatible with V4L2 framework requirements
related to the flash devices management. The design assumes that V4L2
sub-device can take of the LED class device control and communicate
with it through the kernel internal interface. When V4L2 Flash sub-device
file is opened, the LED class device sysfs interface is made
unavailable.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/Kconfig| 10 +
drivers/leds/Makefile |1 +
drivers/leds/led-class-flash.c | 446 +++
drivers/leds/led-class.c|4 +
include/linux/led-class-flash.h | 186
include/linux/leds.h|3 +
6 files changed, 650 insertions(+)
create mode 100644 drivers/leds/led-class-flash.c
create mode 100644 include/linux/led-class-flash.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b3c0d8a..fa8021e 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -19,6 +19,16 @@ config LEDS_CLASS
This option enables the led sysfs class in /sys/class/leds. You'll
need this to do anything useful with LEDs. If unsure, say N.
+config LEDS_CLASS_FLASH
+ tristate "LED Flash Class Support"
+ depends on LEDS_CLASS
+ help
+ This option enables the flash led sysfs class in /sys/class/leds.
+ It wrapps LED Class and adds flash LEDs specific sysfs attributes
+ and kernel internal API to it. You'll need this to provide support
+ for the flash related features of a LED device. It can be built
+ as a module.
+
comment "LED drivers"
config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1c65a19..cbba921 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -2,6 +2,7 @@
# LED Core
obj-$(CONFIG_NEW_LEDS)+= led-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
+obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
# LED Platform Drivers
diff --git a/drivers/leds/led-class-flash.c b/drivers/leds/led-class-flash.c
new file mode 100644
index 000..219b414
--- /dev/null
+++ b/drivers/leds/led-class-flash.c
@@ -0,0 +1,446 @@
+/*
+ * LED Flash class interface
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "leds.h"
+
+#define has_flash_op(flash, op)\
+ (flash && flash->ops->op)
+
+#define call_flash_op(flash, op, args...) \
+ ((has_flash_op(flash, op)) ?\
+ (flash->ops->op(flash, args)) : \
+ -EINVAL)
+
+static ssize_t flash_brightness_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_flash *flash = lcdev_to_flash(led_cdev);
+ unsigned long state;
+ ssize_t ret;
+
+ mutex_lock(&led_cdev->led_access);
+
+ if (led_sysfs_is_disabled(led_cdev)) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ ret = kstrtoul(buf, 10, &state);
+ if (ret)
+ goto unlock;
+
+ ret = led_set_flash_brightness(flash, state);
+ if (ret < 0)
+ goto unlock;
+
+ ret = size;
+unlock:
+ mutex_unlock(&led_cdev->led_access);
+ return ret;
+}
+
+static ssize_t flash_brightness_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_flash *flash = lcdev_to_flash(led_cdev);
+
+ /* no lock needed for this */
+ led_update_flash_brightness(flash);
+
+ return sprintf(buf, "%u\n&qu
Re: [PATCH/RFC v9 02/19] Documentation: leds: Add description of LED Flash class extension
Hi Sakari, Thanks for the review. On 12/03/2014 06:08 PM, Sakari Ailus wrote: Hi Jacek, On Wed, Dec 03, 2014 at 05:06:37PM +0100, Jacek Anaszewski wrote: The documentation being added contains overall description of the LED Flash Class and the related sysfs attributes. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Bryan Wu Cc: Richard Purdie --- Documentation/leds/leds-class-flash.txt | 50 +++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/leds/leds-class-flash.txt diff --git a/Documentation/leds/leds-class-flash.txt b/Documentation/leds/leds-class-flash.txt new file mode 100644 index 000..82e58b1 --- /dev/null +++ b/Documentation/leds/leds-class-flash.txt @@ -0,0 +1,50 @@ + +Flash LED handling under Linux +== + +Some LED devices support two modes - torch and flash. The modes are +supported by the LED class (see Documentation/leds/leds-class.txt) +and LED Flash class respectively. + +In order to enable support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol +must be defined in the kernel config. A flash LED driver must register +in the LED subsystem with led_classdev_flash_register to gain flash +capabilities. + +Following sysfs attributes are exposed for controlling flash led devices: + + - flash_brightness - flash LED brightness in microamperes (RW) + - max_flash_brightness - maximum available flash LED brightness (RO) + - flash_timeout - flash strobe duration in microseconds (RW) + - max_flash_timeout - maximum available flash strobe duration (RO) + - flash_strobe - flash strobe state (RW) + - flash_sync_strobe - one flash device can control more than one + sub-led; when this atrribute is set to 1 s/atrribute/attribute/ + the flash led will be strobed synchronously + with the other one controlled by the same + device; flash timeout setting is inherited + from the led being strobed explicitly and + flash brightness setting of a sub-led's + being synchronized is used (RW) The flash brightness shouldn't be determined by the strobed LED. If this is a property of the hardware, then be it, but in general no, it it shouldn't be an interface requirement. I think this should just say that the strobe is synchronised. I intended this to sound exactly as you laid it out above, but maybe it is obscure English. "and flash brightness setting of a sub-led >>>being synchronized<<< is used" - from my point of view the led being synchronized is the one that isn't strobed explicitly. But I'm ok with confining ourselves only to saying that strobe is synchronized. How does the user btw. figure out which flash LEDs may be strobed synchronously using the LED flash interface? The flash_sync_strobe argument is absent if synchronized strobe is not available for a LED. The driver defines this by setting newly added LED_DEV_CAP_COMPOUND flag. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 05/19] leds: Add support for max77693 mfd flash cell
Hi Sakari,
Thanks for the review.
On 12/04/2014 10:39 AM, Sakari Ailus wrote:
Hi Jacek,
On Wed, Dec 03, 2014 at 05:06:40PM +0100, Jacek Anaszewski wrote:
This patch adds led-flash support to Maxim max77693 chipset.
A device can be exposed to user space through LED subsystem
sysfs interface. Device supports up to two leds which can
work in flash and torch mode. The leds can be triggered
externally or by software.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Andrzej Hajda
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
Cc: Lee Jones
Cc: Chanwoo Choi
---
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile|1 +
drivers/leds/leds-max77693.c | 1023 ++
3 files changed, 1034 insertions(+)
create mode 100644 drivers/leds/leds-max77693.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index fa8021e..2e66d55 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -463,6 +463,16 @@ config LEDS_TCA6507
LED driver chips accessed via the I2C bus.
Driver support brightness control and hardware-assisted blinking.
+config LEDS_MAX77693
+ tristate "LED support for MAX77693 Flash"
+ depends on LEDS_CLASS_FLASH
+ depends on MFD_MAX77693
+ depends on OF
+ help
+ This option enables support for the flash part of the MAX77693
+ multifunction device. It has build in control for two leds in flash
+ and torch mode.
+
config LEDS_MAX8997
tristate "LED support for MAX8997 PMIC"
depends on LEDS_CLASS && MFD_MAX8997
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index cbba921..57ca62b 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_LEDS_MC13783)+= leds-mc13783.o
obj-$(CONFIG_LEDS_NS2)+= leds-ns2.o
obj-$(CONFIG_LEDS_NETXBIG)+= leds-netxbig.o
obj-$(CONFIG_LEDS_ASIC3) += leds-asic3.o
+obj-$(CONFIG_LEDS_MAX77693)+= leds-max77693.o
obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
new file mode 100644
index 000..67a2f8f
--- /dev/null
+++ b/drivers/leds/leds-max77693.c
@@ -0,0 +1,1023 @@
+/*
+ * LED Flash class driver for the flash cell of max77693 mfd.
+ *
+ * Copyright (C) 2014, Samsung Electronics Co., Ltd.
+ *
+ * Authors: Jacek Anaszewski
+ * Andrzej Hajda
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MODE_OFF 0
+#define MODE_FLASH1(1 << 0)
+#define MODE_FLASH2(1 << 1)
+#define MODE_TORCH1(1 << 2)
+#define MODE_TORCH2(1 << 3)
+#define MODE_FLASH_EXTERNAL1 (1 << 4)
+#define MODE_FLASH_EXTERNAL2 (1 << 5)
You could do this based on an argument (led number). E.g.
#define MODE_FLASH_EXTERNAL(a) (1 << (4 + a))
OK.
+#define MODE_FLASH (MODE_FLASH1 | MODE_FLASH2 | \
+MODE_FLASH_EXTERNAL1 | MODE_FLASH_EXTERNAL2)
+
+#define FLED1_IOUT (1 << 0)
+#define FLED2_IOUT (1 << 1)
+
+enum {
+ FLED1,
+ FLED2
+};
+
+enum {
+ FLASH,
+ TORCH
+};
+
+struct max77693_sub_led {
+ struct led_classdev_flash ldev;
+ struct work_struct work_brightness_set;
+
+ unsigned int torch_brightness;
+ unsigned int flash_timeout;
+};
+
+struct max77693_led {
As this does not refer to a device, how about struct max77693_device, for
instance?
OK.
+ struct regmap *regmap;
+ struct platform_device *pdev;
+ struct max77693_led_platform_data *pdata;
+ struct mutex lock;
+
+ struct max77693_sub_led sub_leds[2];
+
+ unsigned int current_flash_timeout;
+ unsigned int mode_flags;
+ u8 torch_iout_reg;
+ bool iout_joint;
+ int strobing_sub_led_id;
+};
+
+struct max77693_led_settings {
+ struct led_flash_setting torch_brightness;
+ struct led_flash_setting flash_brightness;
+ struct led_flash_setting flash_timeout;
+};
+
+static u8 max77693_led_iout_to_reg(u32 ua)
+{
+ if (ua < FLASH_IOUT_MIN)
+ ua = FLASH_IOUT_MIN;
+ return (ua - FLASH_IOUT_MIN) / FLASH_IOUT_STEP;
+}
+
+static u8 max77693_flash_timeout_to_reg(u32 us)
+{
+ return (us - FLASH_TIMEOUT_MIN) / FLASH_TIMEOUT_STEP;
+}
+
+static inline struct max77693_led *ldev1_to_led(
+ struct led_
Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
Hi Sakari,
Thanks for the review.
On 12/04/2014 11:07 AM, Sakari Ailus wrote:
Hi Jacek,
On Wed, Dec 03, 2014 at 05:06:41PM +0100, Jacek Anaszewski wrote:
This patch adds device tree binding documentation for
the flash cell of the Maxim max77693 multifunctional device.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Andrzej Hajda
Acked-by: Kyungmin Park
Cc: Lee Jones
Cc: Chanwoo Choi
Cc: Bryan Wu
Cc: Richard Purdie
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc:
---
Documentation/devicetree/bindings/mfd/max77693.txt | 89
1 file changed, 89 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
b/Documentation/devicetree/bindings/mfd/max77693.txt
index 01e9f30..25a6e78 100644
--- a/Documentation/devicetree/bindings/mfd/max77693.txt
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -41,7 +41,66 @@ Optional properties:
To get more informations, please refer to documentaion.
[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
+- led : the LED submodule device node
+
+There are two led outputs available - fled1 and fled2. Each of them can
+control a separate led or they can be connected together to double
+the maximum current for a single connected led. One led is represented
+by one child node.
+
+Required properties:
+- compatible : Must be "maxim,max77693-led".
+
+Optional properties:
+- maxim,fleds : Array of current outputs in order: fled1, fled2.
+ Note: both current outputs can be connected to a single led
+ Possible values:
+ MAX77693_LED_FLED_UNUSED - the output is left disconnected,
+ MAX77693_LED_FLED_USED - a diode is connected to the output.
As you have a LED sub-nodes for each LED already, isn't this redundant?
Well, it seems so :)
+- maxim,trigger-type : Array of trigger types in order: flash, torch.
+ Possible trigger types:
+ MAX77693_LED_TRIG_TYPE_EDGE - Rising edge of the signal triggers
+ the flash/torch,
+ MAX77693_LED_TRIG_TYPE_LEVEL - Signal level controls duration of
How about: "Strobe pulse length ..."?
OK, it will be more clear.
How long does the torch stay on if you use edge trigger for it? I've always
thought the torch enable pin was a practical joke. :-)
There is a torch timer available but I don't expose it to the user.
If you need it this for torch as well, I'd use separate properties for the
purpose, i.e. trigger-type-flash and trigger-type-torch.
OK.
+ the flash/torch.
+- maxim,trigger : Array of flags indicating which trigger can activate given
led
+ in order: fled1, fled2.
+ Possible flag values (can be combined):
+ MAX77693_LED_TRIG_FLASHEN - FLASHEN pin of the chip,
+ MAX77693_LED_TRIG_TORCHEN - TORCHEN pin of the chip,
+ MAX77693_LED_TRIG_SOFTWARE - software via I2C command.
Is there a need to prevent strobing using a certain method? Just wondering.
In some cases it could be convenient to prevent some options through
device tree.
+- maxim,boost-mode :
+ In boost mode the device can produce up to 1.2A of total current
+ on both outputs. The maximum current on each output is reduced
+ to 625mA then. If there are two child led nodes defined then boost
+ is enabled by default.
+ Possible values:
+ MAX77693_LED_BOOST_OFF - no boost,
+ MAX77693_LED_BOOST_ADAPTIVE - adaptive mode,
+ MAX77693_LED_BOOST_FIXED - fixed mode.
+- maxim,boost-vout : Output voltage of the boost module in millivolts.
+- maxim,vsys-min : Low input voltage level in millivolts. Flash is not fired
+ if chip estimates that system voltage could drop below this level due
+ to flash power consumption.
+
+Required properties of the LED child node:
+- label : see Documentation/devicetree/bindings/leds/common.txt
+- maxim,fled_id : Identifier of the fled output the led is connected to;
I'm pretty sure this will be needed for about every chip that can drive
multiple LEDs. Shouldn't it be documented in the generic documentation?
OK.
+ MAX77693_LED_FLED1 - FLED1 output of the device - it has to be
+ used also if a single LED is connected to both outputs,
+ MAX77693_LED_FLED2 - FLED2 output of the device.
+
+Optional properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+ Range: 15625 - 25
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+ Range: 15625 - 100
+- flash-timeout-microsec : see
Documentation/devicetree/bindings/leds/common.txt
+ Range: 62500 - 100
+
Example:
+#include
+
max77693@66 {
compatible = "maxim,max77693"
Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
Hi Pavel, On 12/04/2014 05:12 PM, Pavel Machek wrote: Hi! +- maxim,boost-mode : + In boost mode the device can produce up to 1.2A of total current + on both outputs. The maximum current on each output is reduced + to 625mA then. If there are two child led nodes defined then boost + is enabled by default. + Possible values: + MAX77693_LED_BOOST_OFF - no boost, + MAX77693_LED_BOOST_ADAPTIVE - adaptive mode, + MAX77693_LED_BOOST_FIXED - fixed mode. +- maxim,boost-vout : Output voltage of the boost module in millivolts. +- maxim,vsys-min : Low input voltage level in millivolts. Flash is not fired + if chip estimates that system voltage could drop below this level due + to flash power consumption. + +Required properties of the LED child node: +- label : see Documentation/devicetree/bindings/leds/common.txt +- maxim,fled_id : Identifier of the fled output the led is connected to; I'm pretty sure this will be needed for about every chip that can drive multiple LEDs. Shouldn't it be documented in the generic documentation? OK. Well... "fled_id" is not exactly suitable name. On other busses, it would be "reg = <1>"? I'm ok with "reg". This scheme is used for pca963x.txt and is described as "number of LED line". We could define it similarly in the common.txt. A device would have to specify the range of allowed values though. I would add such a note to the generic binding. Regards, Jacek -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
On 12/06/2014 01:43 PM, Pavel Machek wrote: The format of a sysfs attribute should be concise. The error codes are generic and map directly to the V4L2 Flash error codes. Actually I'd like to see those flash fault code defined in LED subsystem. And V4L2 will just include LED flash header file to use it. Because flash fault code is not for V4L2 specific but it's a feature of LED flash devices. For clearing error code of flash devices, I think it depends on the hardware. If most of our LED flash is using reading to clear error code, we probably can make it simple as this now. But what if some other LED flash devices are using writing to clear error code? we should provide a API to that? Actually, we should provide API that makes sense, and that is easy to use by userspace. I believe "read" is called read because it does not change anything, and it should stay that way in /sysfs. You may want to talk to sysfs maintainers if you plan on doing another semantics. How would you proceed in case of devices which clear their fault register upon I2C readout (e.g. AS3645)? In this case read does have a side effect. For such devices attribute semantics would have to be different than for the devices which don't clear faults on readout. In case of devices which use writing to clear error code - I'd do that after reading flash_fault attribute, in the same callback. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 01/14] leds: Add LED Flash class extension to the LED subsystem
On 12/05/2014 08:27 PM, Bryan Wu wrote:
On Fri, Nov 28, 2014 at 1:17 AM, Jacek Anaszewski
wrote:
Some LED devices support two operation modes - torch and flash.
This patch provides support for flash LED devices in the LED subsystem
by introducing new sysfs attributes and kernel internal interface.
The attributes being introduced are: flash_brightness, flash_strobe,
flash_timeout, max_flash_timeout, max_flash_brightness, flash_fault
and flash_sync_strobe. All the flash related features are placed
in a separate module. Torch mode is supported by the LED class
interface.
The modifications aim to be compatible with V4L2 framework requirements
related to the flash devices management. The design assumes that V4L2
sub-device can take of the LED class device control and communicate
with it through the kernel internal interface. When V4L2 Flash sub-device
file is opened, the LED class device sysfs interface is made
unavailable.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/Kconfig| 10 +
drivers/leds/Makefile |1 +
drivers/leds/led-class-flash.c | 446 +++
drivers/leds/led-class.c|4 +
include/linux/led-class-flash.h | 198 +
include/linux/leds.h|3 +
6 files changed, 662 insertions(+)
create mode 100644 drivers/leds/led-class-flash.c
create mode 100644 include/linux/led-class-flash.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b3c0d8a..fa8021e 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -19,6 +19,16 @@ config LEDS_CLASS
This option enables the led sysfs class in /sys/class/leds. You'll
need this to do anything useful with LEDs. If unsure, say N.
+config LEDS_CLASS_FLASH
+ tristate "LED Flash Class Support"
+ depends on LEDS_CLASS
Looks like it requires V4L2, so probably add depends on V4L2 or similar.
But actually I want to see LED Flash class doesn't depends on V4L2. Is
that possible to do that?
For example a non-V4L2 application want to control the LED as a flash?
It doesn't require V4L2. It only used v4l2-controls.h for error code
macros, but this is also going to be changed.
Other than this main concern, I'm good with this patch now.
-Bryan
+ help
+ This option enables the flash led sysfs class in /sys/class/leds.
+ It wrapps LED Class and adds flash LEDs specific sysfs attributes
+ and kernel internal API to it. You'll need this to provide support
+ for the flash related features of a LED device. It can be built
+ as a module.
+
comment "LED drivers"
config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1c65a19..cbba921 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -2,6 +2,7 @@
# LED Core
obj-$(CONFIG_NEW_LEDS) += led-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
+obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
obj-$(CONFIG_LEDS_TRIGGERS)+= led-triggers.o
# LED Platform Drivers
diff --git a/drivers/leds/led-class-flash.c b/drivers/leds/led-class-flash.c
new file mode 100644
index 000..219b414
--- /dev/null
+++ b/drivers/leds/led-class-flash.c
@@ -0,0 +1,446 @@
+/*
+ * LED Flash class interface
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "leds.h"
+
+#define has_flash_op(flash, op)\
+ (flash && flash->ops->op)
+
+#define call_flash_op(flash, op, args...) \
+ ((has_flash_op(flash, op)) ?\
+ (flash->ops->op(flash, args)) : \
+ -EINVAL)
+
+static ssize_t flash_brightness_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_flash *flash = lcdev_to_flash(led_cdev);
+ unsigned long state;
+ ssize_t ret;
+
+ mutex_lock(&led_cdev->led_access);
+
+ if (led_sysfs_is_disabled(led_cdev)) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ ret = kstrtoul(buf, 10, &state);
+ if (ret)
+ goto unlock;
+
+ ret = led_set_flash_brightness(flash, state);
+ if (ret < 0)
+ goto unlock;
+
+ ret = size;
+unlock:
+ mutex_unlock(&led_cdev->led_access);
+ return ret;
+}
+
+static ssize_t flash_brightness_show
Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
Hi Pavel, On 12/08/2014 09:18 PM, Pavel Machek wrote: On Mon 2014-12-08 17:55:20, Jacek Anaszewski wrote: On 12/06/2014 01:43 PM, Pavel Machek wrote: The format of a sysfs attribute should be concise. The error codes are generic and map directly to the V4L2 Flash error codes. Actually I'd like to see those flash fault code defined in LED subsystem. And V4L2 will just include LED flash header file to use it. Because flash fault code is not for V4L2 specific but it's a feature of LED flash devices. For clearing error code of flash devices, I think it depends on the hardware. If most of our LED flash is using reading to clear error code, we probably can make it simple as this now. But what if some other LED flash devices are using writing to clear error code? we should provide a API to that? Actually, we should provide API that makes sense, and that is easy to use by userspace. I believe "read" is called read because it does not change anything, and it should stay that way in /sysfs. You may want to talk to sysfs maintainers if you plan on doing another semantics. How would you proceed in case of devices which clear their fault register upon I2C readout (e.g. AS3645)? In this case read does have a side effect. For such devices attribute semantics would have to be different than for the devices which don't clear faults on readout. No, semantics should be same for all devices. If device clears fault register during I2C readout, kernel will simply gather faults in an variable, and clear them upon write to sysfs file. This approach would require implementing additional mechanisms on both sides: LED Flash class core and a LED Flash class driver. In the former the sysfs attribute write permissions would have to be decided in the runtime and in the latter caching mechanism would have to be implemented per driver. We would have to also consider how to approach the issue in case of sub-leds. The only reason for this overhead is trying to avoid side effects on reading sysfs attribute. After weighing the pros and cons, I am not sure if it is worthwhile. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 04/19] mfd: max77693: adjust max77693_led_platform_data
On 12/09/2014 09:50 AM, Lee Jones wrote:
On Wed, 03 Dec 2014, Jacek Anaszewski wrote:
Add "label" array for Device Tree strings with the name of a LED device
and make flash_timeout a two element array, for caching the sub-led
related flash timeout. Added is also an array for caching pointers to the
sub-nodes representing sub-leds.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Chanwoo Choi
Cc: Lee Jones
---
include/linux/mfd/max77693.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
index f0b6585..c80ee99 100644
--- a/include/linux/mfd/max77693.h
+++ b/include/linux/mfd/max77693.h
@@ -88,16 +88,18 @@ enum max77693_led_boost_mode {
};
struct max77693_led_platform_data {
+ const char *label[2];
u32 fleds[2];
u32 iout_torch[2];for_each_available_child_of_node
u32 iout_flash[2];
u32 trigger[2];
u32 trigger_type[2];
+ u32 flash_timeout[2];
u32 num_leds;
u32 boost_mode;
- u32 flash_timeout;
u32 boost_vout;
u32 low_vsys;
+ struct device_node *sub_nodes[2];
I haven't seen anyone do this before. Why can't you use the provided
OF functions to traverse through your tree?
I use for_each_available_child_of_node when parsing DT node, but I
need to cache the pointer to sub-node to be able to use it later
when it needs to be passed to V4L2 sub-device which is then
asynchronously matched by the phandle to sub-node.
If it is not well seen to cache it in the platform data then
I will find different way to accomplish this.
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 03/19] mfd: max77693: Modify flash cell name identifiers
On 12/09/2014 09:52 AM, Lee Jones wrote:
On Wed, 03 Dec 2014, Jacek Anaszewski wrote:
Change flash cell identifiers from max77693-flash to max77693-led
to avoid confusion with NOR/NAND Flash.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Chanwoo Choi
Cc: Lee Jones
---
drivers/mfd/max77693.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index a159593..cb14afa 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -53,8 +53,8 @@ static const struct mfd_cell max77693_devs[] = {
.of_compatible = "maxim,max77693-haptic",
},
{
- .name = "max77693-flash",
- .of_compatible = "maxim,max77693-flash",
+ .name = "max77693-led",
+ .of_compatible = "maxim,max77693-led",
This is fine by me, so long as you've been through the usual
deprecation procedures or this platform is still WiP.
It was me who added of_compatible for max77693-flash, but the
related led driver has not been yet merged and there are no
other drivers depending on it.
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 04/19] mfd: max77693: adjust max77693_led_platform_data
On 12/09/2014 11:04 AM, Lee Jones wrote:
On Tue, 09 Dec 2014, Jacek Anaszewski wrote:
On 12/09/2014 09:50 AM, Lee Jones wrote:
On Wed, 03 Dec 2014, Jacek Anaszewski wrote:
Add "label" array for Device Tree strings with the name of a LED device
and make flash_timeout a two element array, for caching the sub-led
related flash timeout. Added is also an array for caching pointers to the
sub-nodes representing sub-leds.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Chanwoo Choi
Cc: Lee Jones
---
include/linux/mfd/max77693.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
index f0b6585..c80ee99 100644
--- a/include/linux/mfd/max77693.h
+++ b/include/linux/mfd/max77693.h
@@ -88,16 +88,18 @@ enum max77693_led_boost_mode {
};
struct max77693_led_platform_data {
+ const char *label[2];
u32 fleds[2];
u32 iout_torch[2];for_each_available_child_of_node
u32 iout_flash[2];
u32 trigger[2];
u32 trigger_type[2];
+ u32 flash_timeout[2];
u32 num_leds;
u32 boost_mode;
- u32 flash_timeout;
u32 boost_vout;
u32 low_vsys;
+ struct device_node *sub_nodes[2];
I haven't seen anyone do this before. Why can't you use the provided
OF functions to traverse through your tree?
I use for_each_available_child_of_node when parsing DT node, but I
need to cache the pointer to sub-node to be able to use it later
when it needs to be passed to V4L2 sub-device which is then
asynchronously matched by the phandle to sub-node.
If it is not well seen to cache it in the platform data then
I will find different way to accomplish this.
I haven't seen the end-driver for this, but why can't you use that
device's of_node pointer?
Maybe it is indeed a good idea. I could pass the of_node pointer
and the sub-led identifier to the V4L2 sub-device and there look
for the sub-node containing relevant identifier. The downside
would be only that for_each_available_child_of_node would
have to be called twice - in the led driver and in the V4L2 sub-device.
I think that we can live with it.
Thanks for the hint.
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 01/19] leds: Add LED Flash class extension to the LED subsystem
Hi Sakari,
On 12/09/2014 01:36 PM, Sakari Ailus wrote:
Hi Jacek,
On Thu, Dec 04, 2014 at 10:29:10AM +0100, Jacek Anaszewski wrote:
...
+static struct attribute *led_flash_strobe_attrs[] = {
+ &dev_attr_flash_strobe.attr,
+ NULL,
+};
+
+static struct attribute *led_flash_timeout_attrs[] = {
+ &dev_attr_flash_timeout.attr,
+ &dev_attr_max_flash_timeout.attr,
+ NULL,
+};
+
+static struct attribute *led_flash_brightness_attrs[] = {
+ &dev_attr_flash_brightness.attr,
+ &dev_attr_max_flash_brightness.attr,
+ NULL,
+};
+
+static struct attribute *led_flash_fault_attrs[] = {
+ &dev_attr_flash_fault.attr,
+ NULL,
+};
+
+static struct attribute *led_flash_sync_strobe_attrs[] = {
+ &dev_attr_flash_sync_strobe.attr,
+ NULL,
+};
+
+static const struct attribute_group led_flash_strobe_group = {
+ .attrs = led_flash_strobe_attrs,
+};
+
+static const struct attribute_group led_flash_timeout_group = {
+ .attrs = led_flash_timeout_attrs,
+};
+
+static const struct attribute_group led_flash_brightness_group = {
+ .attrs = led_flash_brightness_attrs,
+};
+
+static const struct attribute_group led_flash_fault_group = {
+ .attrs = led_flash_fault_attrs,
+};
+
+static const struct attribute_group led_flash_sync_strobe_group = {
+ .attrs = led_flash_sync_strobe_attrs,
+};
+
+static const struct attribute_group *flash_groups[] = {
+ &led_flash_strobe_group,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL
+};
+
+static void led_flash_resume(struct led_classdev *led_cdev)
+{
+ struct led_classdev_flash *flash = lcdev_to_flash(led_cdev);
+
+ call_flash_op(flash, flash_brightness_set, flash->brightness.val);
+ call_flash_op(flash, timeout_set, flash->timeout.val);
+}
+
+static void led_flash_init_sysfs_groups(struct led_classdev_flash *flash)
+{
+ struct led_classdev *led_cdev = &flash->led_cdev;
+ const struct led_flash_ops *ops = flash->ops;
+ int num_sysfs_groups = 1;
+
+ if (ops->flash_brightness_set)
+ flash_groups[num_sysfs_groups++] = &led_flash_brightness_group;
+
+ if (ops->timeout_set)
+ flash_groups[num_sysfs_groups++] = &led_flash_timeout_group;
+
+ if (ops->fault_get)
+ flash_groups[num_sysfs_groups++] = &led_flash_fault_group;
+
+ if (led_cdev->flags & LED_DEV_CAP_COMPOUND)
+ flash_groups[num_sysfs_groups++] = &led_flash_sync_strobe_group;
+
+ led_cdev->groups = flash_groups;
Shouldn't you have groups local to the device instead? If you register
another flash device bad things will happen if the ops the device supports
are different.
The groups are local to the device. A LED class device is registered
with device_create_with_groups called from led_classdev_register
function. It is passed led_cdev->groups in the fifth argument.
The groups pointer will be stored in struct device. If you have another
driver using different groups, it will affect the groups for all flash
devices that use the same groups pointer. I'm not sure what exactly would
follow from that but I'd rather not change them once the device is created.
I had to take another look at this to understand the problem.
I think that the best option will be making flash_groups array
a member of struct led_classdev_flash.
+}
+
+int led_classdev_flash_register(struct device *parent,
+ struct led_classdev_flash *flash)
+{
+ struct led_classdev *led_cdev;
+ const struct led_flash_ops *ops;
+ int ret;
+
+ if (!flash)
Do you have a use case for this?
This is just a guard against NULL pointer dereference. Maybe it is
indeed redundant, as the driver developer can easily check its
origin during implementation.
Fine for me.
Fine regarding my explanation or you agree that it is redundant?
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 02/19] Documentation: leds: Add description of LED Flash class extension
Hi Sakari, On 12/09/2014 01:38 PM, Sakari Ailus wrote: [...] How does the user btw. figure out which flash LEDs may be strobed synchronously using the LED flash interface? The flash_sync_strobe argument is absent if synchronized strobe is not available for a LED. The driver defines this by setting newly added LED_DEV_CAP_COMPOUND flag. I meant that how does the user figure out which LEDs may be strobed synchronously, together. Say, if you have two of these chips and four LEDs, then how does it work? :-) User can figure it out by checking the existence of the flash_sync_strobe attribute. Sub-leds can by synchronized only when are driven by common chip. It is assumed that sub-leds of one chip will have common segment in their name, defined in DT 'label' property. Maybe we should enforce it by adding another property to the leds/common.txt DT binding, e.g. 'device-prefix'? Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 04/19] mfd: max77693: adjust max77693_led_platform_data
On 12/09/2014 02:50 PM, Lee Jones wrote:
On Tue, 09 Dec 2014, Jacek Anaszewski wrote:
On 12/09/2014 11:04 AM, Lee Jones wrote:
On Tue, 09 Dec 2014, Jacek Anaszewski wrote:
On 12/09/2014 09:50 AM, Lee Jones wrote:
On Wed, 03 Dec 2014, Jacek Anaszewski wrote:
Add "label" array for Device Tree strings with the name of a LED device
and make flash_timeout a two element array, for caching the sub-led
related flash timeout. Added is also an array for caching pointers to the
sub-nodes representing sub-leds.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Chanwoo Choi
Cc: Lee Jones
---
include/linux/mfd/max77693.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
index f0b6585..c80ee99 100644
--- a/include/linux/mfd/max77693.h
+++ b/include/linux/mfd/max77693.h
@@ -88,16 +88,18 @@ enum max77693_led_boost_mode {
};
struct max77693_led_platform_data {
+ const char *label[2];
u32 fleds[2];
u32 iout_torch[2];for_each_available_child_of_node
u32 iout_flash[2];
u32 trigger[2];
u32 trigger_type[2];
+ u32 flash_timeout[2];
u32 num_leds;
u32 boost_mode;
- u32 flash_timeout;
u32 boost_vout;
u32 low_vsys;
+ struct device_node *sub_nodes[2];
I haven't seen anyone do this before. Why can't you use the provided
OF functions to traverse through your tree?
I use for_each_available_child_of_node when parsing DT node, but I
need to cache the pointer to sub-node to be able to use it later
when it needs to be passed to V4L2 sub-device which is then
asynchronously matched by the phandle to sub-node.
If it is not well seen to cache it in the platform data then
I will find different way to accomplish this.
I haven't seen the end-driver for this, but why can't you use that
device's of_node pointer?
Maybe it is indeed a good idea. I could pass the of_node pointer
and the sub-led identifier to the V4L2 sub-device and there look
for the sub-node containing relevant identifier. The downside
would be only that for_each_available_child_of_node would
have to be called twice - in the led driver and in the V4L2 sub-device.
I think that we can live with it.
Are the LED and V4L2 drivers children of this MFD? If so, you can use
the of_compatible attribute in struct mfd_cell to populate the each
child's of_node dynamically i.e. the MFD core will do that for you.
V4L2 driver wraps LED driver. This way the LED device can be
controlled with use of two interfaces - LED subsystem sysfs
and V4L2 Flash. This is the aim of the whole patch set.
I've thought it over again and it seems that I will need to cache
somewhere these sub_nodes pointers. They have to be easily accessible
for the V4L2 sub-device as it can be asynchronously registered
or unregistered within V4L2 media device. Sub-devices are matched
basing on the sub-node phandle.
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
Hi Sakari, On 12/09/2014 03:09 PM, Sakari Ailus wrote: Hi Jacek, On Thu, Dec 04, 2014 at 12:40:48PM +0100, Jacek Anaszewski wrote: + the flash/torch. +- maxim,trigger : Array of flags indicating which trigger can activate given led + in order: fled1, fled2. + Possible flag values (can be combined): + MAX77693_LED_TRIG_FLASHEN - FLASHEN pin of the chip, + MAX77693_LED_TRIG_TORCHEN - TORCHEN pin of the chip, + MAX77693_LED_TRIG_SOFTWARE - software via I2C command. Is there a need to prevent strobing using a certain method? Just wondering. In some cases it could be convenient to prevent some options through device tree. Do you have that need now? If not, I'd propose to postpone this and add it only if there ever is one. No, I don't. So let's postpone it. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
Hi Sakari, On 12/04/2014 12:40 PM, Jacek Anaszewski wrote: On 12/04/2014 11:07 AM, Sakari Ailus wrote: Hi Jacek, On Wed, Dec 03, 2014 at 05:06:41PM +0100, Jacek Anaszewski wrote: This patch adds device tree binding documentation for the flash cell of the Maxim max77693 multifunctional device. Signed-off-by: Jacek Anaszewski Signed-off-by: Andrzej Hajda Acked-by: Kyungmin Park Cc: Lee Jones Cc: Chanwoo Choi Cc: Bryan Wu Cc: Richard Purdie Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: --- Documentation/devicetree/bindings/mfd/max77693.txt | 89 1 file changed, 89 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 01e9f30..25a6e78 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation/devicetree/bindings/mfd/max77693.txt @@ -41,7 +41,66 @@ Optional properties: To get more informations, please refer to documentaion. [*] refer Documentation/devicetree/bindings/pwm/pwm.txt +- led : the LED submodule device node + +There are two led outputs available - fled1 and fled2. Each of them can +control a separate led or they can be connected together to double +the maximum current for a single connected led. One led is represented +by one child node. + +Required properties: +- compatible : Must be "maxim,max77693-led". + +Optional properties: +- maxim,fleds : Array of current outputs in order: fled1, fled2. +Note: both current outputs can be connected to a single led +Possible values: +MAX77693_LED_FLED_UNUSED - the output is left disconnected, +MAX77693_LED_FLED_USED - a diode is connected to the output. As you have a LED sub-nodes for each LED already, isn't this redundant? Well, it seems so :) I agreed here recklessly. This property allows to describe the situation when one LED is connected to both outputs. Single sub-node can describe two type of designs: one LED connected to a single output or one LED connected to both outputs. Therefore additional property is needed to assess what is the actual case. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 04/19] mfd: max77693: adjust max77693_led_platform_data
On 12/09/2014 03:41 PM, Lee Jones wrote:
On Tue, 09 Dec 2014, Jacek Anaszewski wrote:
On 12/09/2014 02:50 PM, Lee Jones wrote:
On Tue, 09 Dec 2014, Jacek Anaszewski wrote:
On 12/09/2014 11:04 AM, Lee Jones wrote:
On Tue, 09 Dec 2014, Jacek Anaszewski wrote:
On 12/09/2014 09:50 AM, Lee Jones wrote:
On Wed, 03 Dec 2014, Jacek Anaszewski wrote:
Add "label" array for Device Tree strings with the name of a LED device
and make flash_timeout a two element array, for caching the sub-led
related flash timeout. Added is also an array for caching pointers to the
sub-nodes representing sub-leds.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Chanwoo Choi
Cc: Lee Jones
---
include/linux/mfd/max77693.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
index f0b6585..c80ee99 100644
--- a/include/linux/mfd/max77693.h
+++ b/include/linux/mfd/max77693.h
@@ -88,16 +88,18 @@ enum max77693_led_boost_mode {
};
struct max77693_led_platform_data {
+ const char *label[2];
u32 fleds[2];
u32 iout_torch[2];for_each_available_child_of_node
u32 iout_flash[2];
u32 trigger[2];
u32 trigger_type[2];
+ u32 flash_timeout[2];
u32 num_leds;
u32 boost_mode;
- u32 flash_timeout;
u32 boost_vout;
u32 low_vsys;
+ struct device_node *sub_nodes[2];
I haven't seen anyone do this before. Why can't you use the provided
OF functions to traverse through your tree?
I use for_each_available_child_of_node when parsing DT node, but I
need to cache the pointer to sub-node to be able to use it later
when it needs to be passed to V4L2 sub-device which is then
asynchronously matched by the phandle to sub-node.
If it is not well seen to cache it in the platform data then
I will find different way to accomplish this.
I haven't seen the end-driver for this, but why can't you use that
device's of_node pointer?
Maybe it is indeed a good idea. I could pass the of_node pointer
and the sub-led identifier to the V4L2 sub-device and there look
for the sub-node containing relevant identifier. The downside
would be only that for_each_available_child_of_node would
have to be called twice - in the led driver and in the V4L2 sub-device.
I think that we can live with it.
Are the LED and V4L2 drivers children of this MFD? If so, you can use
the of_compatible attribute in struct mfd_cell to populate the each
child's of_node dynamically i.e. the MFD core will do that for you.
V4L2 driver wraps LED driver. This way the LED device can be
controlled with use of two interfaces - LED subsystem sysfs
and V4L2 Flash. This is the aim of the whole patch set.
I've thought it over again and it seems that I will need to cache
somewhere these sub_nodes pointers. They have to be easily accessible
for the V4L2 sub-device as it can be asynchronously registered
or unregistered within V4L2 media device. Sub-devices are matched
basing on the sub-node phandle.
Not quite getting this. Can you explain this in another way please?
It turned out that it is possible to store the sub-node pointer in the
struct device returned by device_create_with_groups, while creating LED
class device. Its of_node property is uninitialized.
Regardless of it - there will be next version of this patch.
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
On 12/10/2014 01:20 PM, Sylwester Nawrocki wrote:
Hi,
On 04/12/14 17:12, Pavel Machek wrote:
+- maxim,boost-mode :
+ In boost mode the device can produce up to 1.2A of total current
+ on both outputs. The maximum current on each output is reduced
+ to 625mA then. If there are two child led nodes defined then boost
+ is enabled by default.
+ Possible values:
+ MAX77693_LED_BOOST_OFF - no boost,
+ MAX77693_LED_BOOST_ADAPTIVE - adaptive mode,
+ MAX77693_LED_BOOST_FIXED - fixed mode.
+- maxim,boost-vout : Output voltage of the boost module in millivolts.
+- maxim,vsys-min : Low input voltage level in millivolts. Flash is not fired
+ if chip estimates that system voltage could drop below this level due
+ to flash power consumption.
+
+Required properties of the LED child node:
+- label : see Documentation/devicetree/bindings/leds/common.txt
+- maxim,fled_id : Identifier of the fled output the led is connected to;
I'm pretty sure this will be needed for about every chip that can drive
multiple LEDs. Shouldn't it be documented in the generic documentation?
OK.
Well... "fled_id" is not exactly suitable name. On other busses, it
would be "reg = <1>"?
I think we need to clarify what the LED device node subnodes really mean.
I thought initially they describe a physical current output of the LED
controller, but it turns out the subnode corresponds to a LED attached
to the LED controller. Since a LED can be connected to multiple outputs
of the LED controller I think 'reg' property doesn't make sense here.
Then presumably we should use a property in each subnode, telling which
LED controller outputs a LED is connected to?
For instance, if we assign numbers 0, 1 to FLED1, FLED2 outputs of
MAX77693 and there is just one LED connected to those outputs we would
have something like:
max77693: led {
compatible = "maxim,max77693-led";
...
led1 {
maxim,fled-sources = <0 1>;
...
};
};
Feel free to propose better name for the property, I guess we need to
avoid "maxim,current-sources" due to ambiguity of the word "current".
For me this sounds reasonable. Moreover we will avoid the need for
address-cells and size-cells properties in the parent node.
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
On 12/09/2014 04:50 PM, Pavel Machek wrote: On Tue 2014-12-09 09:54:06, Jacek Anaszewski wrote: Hi Pavel, On 12/08/2014 09:18 PM, Pavel Machek wrote: On Mon 2014-12-08 17:55:20, Jacek Anaszewski wrote: On 12/06/2014 01:43 PM, Pavel Machek wrote: The format of a sysfs attribute should be concise. The error codes are generic and map directly to the V4L2 Flash error codes. Actually I'd like to see those flash fault code defined in LED subsystem. And V4L2 will just include LED flash header file to use it. Because flash fault code is not for V4L2 specific but it's a feature of LED flash devices. For clearing error code of flash devices, I think it depends on the hardware. If most of our LED flash is using reading to clear error code, we probably can make it simple as this now. But what if some other LED flash devices are using writing to clear error code? we should provide a API to that? Actually, we should provide API that makes sense, and that is easy to use by userspace. I believe "read" is called read because it does not change anything, and it should stay that way in /sysfs. You may want to talk to sysfs maintainers if you plan on doing another semantics. How would you proceed in case of devices which clear their fault register upon I2C readout (e.g. AS3645)? In this case read does have a side effect. For such devices attribute semantics would have to be different than for the devices which don't clear faults on readout. No, semantics should be same for all devices. If device clears fault register during I2C readout, kernel will simply gather faults in an variable, and clear them upon write to sysfs file. This approach would require implementing additional mechanisms on both sides: LED Flash class core and a LED Flash class driver. In the former the sysfs attribute write permissions would have to be decided in the runtime and in the latter caching mechanism Write attributes at runtime? Why? We can emulate sane and consistent behaviour for all the controllers: read gives you list of faults, write clears it. We can do it for all the controllers. I don't like the idea of listing the faults in the form of strings. I'd like to see the third opinion :) Only cost is few lines of code in the drivers where hardware clears faults at read. As above - the third opinion would be appreciated. would have to be implemented per driver. We would have to also consider how to approach the issue in case of sub-leds. Actually.. sub-leds. That is one physical LED being connected to two current sources at the same time, right? There are possible designs with two separate LEDs. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 05/19] leds: Add support for max77693 mfd flash cell
Hi Sakari,
On 12/09/2014 02:11 PM, Sakari Ailus wrote:
Hi Jacek,
On Thu, Dec 04, 2014 at 12:06:59PM +0100, Jacek Anaszewski wrote:
Hi Sakari,
Thanks for the review.
You're welcome! :-)
On 12/04/2014 10:39 AM, Sakari Ailus wrote:
Hi Jacek,
On Wed, Dec 03, 2014 at 05:06:40PM +0100, Jacek Anaszewski wrote:
This patch adds led-flash support to Maxim max77693 chipset.
A device can be exposed to user space through LED subsystem
sysfs interface. Device supports up to two leds which can
work in flash and torch mode. The leds can be triggered
externally or by software.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Andrzej Hajda
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
Cc: Lee Jones
Cc: Chanwoo Choi
---
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile|1 +
drivers/leds/leds-max77693.c | 1023 ++
3 files changed, 1034 insertions(+)
create mode 100644 drivers/leds/leds-max77693.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index fa8021e..2e66d55 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -463,6 +463,16 @@ config LEDS_TCA6507
LED driver chips accessed via the I2C bus.
Driver support brightness control and hardware-assisted blinking.
+config LEDS_MAX77693
+ tristate "LED support for MAX77693 Flash"
+ depends on LEDS_CLASS_FLASH
+ depends on MFD_MAX77693
+ depends on OF
+ help
+ This option enables support for the flash part of the MAX77693
+ multifunction device. It has build in control for two leds in flash
+ and torch mode.
+
config LEDS_MAX8997
tristate "LED support for MAX8997 PMIC"
depends on LEDS_CLASS && MFD_MAX8997
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index cbba921..57ca62b 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_LEDS_MC13783)+= leds-mc13783.o
obj-$(CONFIG_LEDS_NS2)+= leds-ns2.o
obj-$(CONFIG_LEDS_NETXBIG)+= leds-netxbig.o
obj-$(CONFIG_LEDS_ASIC3) += leds-asic3.o
+obj-$(CONFIG_LEDS_MAX77693)+= leds-max77693.o
obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
new file mode 100644
index 000..67a2f8f
--- /dev/null
+++ b/drivers/leds/leds-max77693.c
@@ -0,0 +1,1023 @@
+/*
+ * LED Flash class driver for the flash cell of max77693 mfd.
+ *
+ * Copyright (C) 2014, Samsung Electronics Co., Ltd.
+ *
+ * Authors: Jacek Anaszewski
+ * Andrzej Hajda
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MODE_OFF 0
+#define MODE_FLASH1(1 << 0)
+#define MODE_FLASH2(1 << 1)
+#define MODE_TORCH1(1 << 2)
+#define MODE_TORCH2(1 << 3)
+#define MODE_FLASH_EXTERNAL1 (1 << 4)
+#define MODE_FLASH_EXTERNAL2 (1 << 5)
You could do this based on an argument (led number). E.g.
#define MODE_FLASH_EXTERNAL(a) (1 << (4 + a))
OK.
+#define MODE_FLASH (MODE_FLASH1 | MODE_FLASH2 | \
+MODE_FLASH_EXTERNAL1 | MODE_FLASH_EXTERNAL2)
+
+#define FLED1_IOUT (1 << 0)
+#define FLED2_IOUT (1 << 1)
+
+enum {
+ FLED1,
+ FLED2
+};
+
+enum {
+ FLASH,
+ TORCH
+};
+
+struct max77693_sub_led {
This could then be renamed as "max77693_led"; up to you.
It will be better to rename the max77693_led structure to
max77693_led_device instead of max77693_device like you proposed. This
is because there is already max77693_dev structure in the mfd driver
for max77693 and this is only a driver for the led part of a device.
Taking above into account I'd rather leave struct max77693_sub_led
name unchanged.
+ struct led_classdev_flash ldev;
+ struct work_struct work_brightness_set;
+
+ unsigned int torch_brightness;
+ unsigned int flash_timeout;
+};
+
+struct max77693_led {
As this does not refer to a device, how about struct max77693_device, for
instance?
OK.
+ struct regmap *regmap;
+ struct platform_device *pdev;
+ struct max77693_led_platform_data *pdata;
+ struct mutex lock;
+
+ struct max77693_sub_led sub_leds[2];
+
+ unsigned int current_flash_timeout;
+ unsigned int mode_flags;
+ u8 torch_iout_reg;
+ bool iout_joint;
+ int strobing_sub_led_id;
+
Re: [PATCH/RFC v9 08/19] leds: Add driver for AAT1290 current regulator
Hi Sakari,
Thanks for the review.
On 12/11/2014 03:16 PM, Sakari Ailus wrote:
Hi Jacek,
On Wed, Dec 03, 2014 at 05:06:43PM +0100, Jacek Anaszewski wrote:
This patch adds a driver for the 1.5A Step-Up Current Regulator
for Flash LEDs. The device is programmed through a Skyworks proprietary
AS2Cwire serial digital interface.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/Kconfig|7 +
drivers/leds/Makefile |1 +
drivers/leds/leds-aat1290.c | 413 +++
3 files changed, 421 insertions(+)
create mode 100644 drivers/leds/leds-aat1290.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2e66d55..ec4b78c 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -39,6 +39,13 @@ config LEDS_88PM860X
This option enables support for on-chip LED drivers found on Marvell
Semiconductor 88PM8606 PMIC.
+config LEDS_AAT1290
+ tristate "LED support for the AAT1290"
+ depends on LEDS_CLASS_FLASH
+ depends on OF
+ help
+This option enables support for the LEDs on the AAT1290.
+
config LEDS_LM3530
tristate "LCD Backlight driver for LM3530"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 57ca62b..b802251 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
# LED Platform Drivers
obj-$(CONFIG_LEDS_88PM860X) += leds-88pm860x.o
+obj-$(CONFIG_LEDS_AAT1290) += leds-aat1290.o
obj-$(CONFIG_LEDS_BD2802) += leds-bd2802.o
obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
new file mode 100644
index 000..15d969b
--- /dev/null
+++ b/drivers/leds/leds-aat1290.c
@@ -0,0 +1,413 @@
+/*
+ * LED Flash class driver for the AAT1290
+ * 1.5A Step-Up Current Regulator for Flash LEDs
+ *
+ * Copyright (C) 2014, Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
Alphabetic order, please.
Oops, I missed that.
+
+#define AAT1290_MOVIE_MODE_CURRENT_ADDR17
+#define AAT1290_FLASH_SAFETY_TIMER_ADDR18
+#define AAT1290_MOVIE_MODE_CONFIG_ADDR 19
+#define AAT1290_MM_CURRENT_RATIO_ADDR 20
+#define AAT1290_LATCH_TIME_US 500
+#define AAT1290_EN_SET_TICK_TIME_US1
+#define AAT1290_MOVIE_MODE_OFF 1
+#define AAT1290_MOVIE_MODE_ON 3
+#define AAT1290_MAX_MM_CURR_PERCENT_0 16
+#define AAT1290_MAX_MM_CURR_PERCENT_100 1
+#define AAT1290_FLASH_TM_NUM_LEVELS16
It'd be nice to arrange register bit definitions next to the register
address they're related to. That makes this a lot more readable. Timeouts
separately as well.
Please also align the values on the right to the same column. I think they
mostly are, but at least AAT1290_MAX_MM_CURR_PERCENT_100 uses space instead
of a tab.
OK.
+#define AAT1290_MM_TO_FL_1_92 1
+#define AAT1290_MM_TO_FL_3_7 2
+#define AAT1290_MM_TO_FL_5_5 3
+#define AAT1290_MM_TO_FL_7_3 4
+#define AAT1290_MM_TO_FL_9 5
+#define AAT1290_MM_TO_FL_10_7 6
+#define AAT1290_MM_TO_FL_12_4 7
+#define AAT1290_MM_TO_FL_148
+#define AAT1290_MM_TO_FL_15_9 9
+#define AAT1290_MM_TO_FL_17_5 10
+#define AAT1290_MM_TO_FL_19_1 11
+#define AAT1290_MM_TO_FL_20_8 12
+#define AAT1290_MM_TO_FL_22_4 13
+#define AAT1290_MM_TO_FL_2414
+#define AAT1290_MM_TO_FL_25_6 15
+#define AAT1290_MM_TO_FL_OFF 16
+
+struct aat1290_led_settings {
+ struct led_flash_setting torch_brightness;
+ struct led_flash_setting flash_brightness;
+ struct led_flash_setting flash_timeout;
+};
+
+struct aat1290_led {
+ struct platform_device *pdev;
+ struct mutex lock;
+
+ struct led_classdev_flash ldev;
+
+ int flen_gpio;
+ int en_set_gpio;
+
+ u32 max_flash_tm;
+ bool movie_mode;
+
+ char *label;
+ unsigned int torch_brightness;
+ unsigned int flash_timeout;
+ struct work_struct work_brightness_set;
+};
+
+static struct aat1290_led *ldev_to_led(struct led_classdev_flash *ldev)
+{
+ return container_of(ldev, struct aat1290_led, ldev);
+}
+
+static void aat1290_as2cwire_write(struct aat1290_led *led, int addr, int
value)
+{
+ int i;
+
+ gpio_set_value(led->flen_gpio, 0);
+ gpio_set_value(led->en_set_gpio, 0);
+
+ udelay(10);
Could you use a #define for this as you are using for the rest
Re: [PATCH] [media] s5p-jpeg: Adding Exynos7 Jpeg variant support
@@ -15,10 +15,12 @@ void exynos4_jpeg_sw_reset(void __iomem *base); void exynos4_jpeg_set_enc_dec_mode(void __iomem *base, unsigned int mode); -void exynos4_jpeg_set_img_fmt(void __iomem *base, unsigned int img_fmt); -void exynos4_jpeg_set_enc_out_fmt(void __iomem *base, unsigned int out_fmt); +void exynos4_jpeg_set_img_fmt(void __iomem *base, unsigned int img_fmt, + unsigned int shift); +void exynos4_jpeg_set_enc_out_fmt(void __iomem *base, unsigned int out_fmt, + unsigned int mask); void exynos4_jpeg_set_enc_tbl(void __iomem *base); -void exynos4_jpeg_set_interrupt(void __iomem *base); +void exynos4_jpeg_set_interrupt(void __iomem *base, unsigned int variant); unsigned int exynos4_jpeg_get_int_status(void __iomem *base); void exynos4_jpeg_set_huf_table_enable(void __iomem *base, int value); void exynos4_jpeg_set_sys_int_enable(void __iomem *base, int value); diff --git a/drivers/media/platform/s5p-jpeg/jpeg-regs.h b/drivers/media/platform/s5p-jpeg/jpeg-regs.h index 050fc44..08bef4e 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-regs.h +++ b/drivers/media/platform/s5p-jpeg/jpeg-regs.h @@ -230,13 +230,15 @@ #define EXYNOS4_SOFT_RESET_HI (1 << 29) /* JPEG INT Register bit */ -#define EXYNOS4_INT_EN_MASK(0x1f << 0) +#define EXYNOS4_INT_EN_MASK(version) (((version) == SJPEG_EXYNOS7) \ + ? (0x1ff << 0) : (0x1f << 0)) #define EXYNOS4_PROT_ERR_INT_EN (1 << 0) #define EXYNOS4_IMG_COMPLETION_INT_EN (1 << 1) #define EXYNOS4_DEC_INVALID_FORMAT_EN (1 << 2) #define EXYNOS4_MULTI_SCAN_ERROR_EN (1 << 3) #define EXYNOS4_FRAME_ERR_EN (1 << 4) -#define EXYNOS4_INT_EN_ALL (0x1f << 0) +#define EXYNOS4_INT_EN_ALL(version)(((version) == SJPEG_EXYNOS7) \ + ? (0x1b6 << 0) : (0x1f << 0)) #define EXYNOS4_MOD_REG_PROC_ENC (0 << 3) #define EXYNOS4_MOD_REG_PROC_DEC (1 << 3) @@ -294,8 +296,11 @@ #define EXYNOS4_YUV_420_IP_YUV_420_2P_IMG (4 << EXYNOS4_YUV_420_IP_SHIFT) #define EXYNOS4_YUV_420_IP_YUV_420_3P_IMG (5 << EXYNOS4_YUV_420_IP_SHIFT) +#define EXYNOS4_ENC_FMT_MASK 3 +#define EXYNOS7_ENC_FMT_MASK 7 #define EXYNOS4_ENC_FMT_SHIFT 24 -#define EXYNOS4_ENC_FMT_MASK (3 << EXYNOS4_ENC_FMT_SHIFT) +#define EXYNOS_ENC_FMT_MASK(mask) ((mask) \ + << EXYNOS4_ENC_FMT_SHIFT) #define EXYNOS4_ENC_FMT_GRAY (0 << EXYNOS4_ENC_FMT_SHIFT) #define EXYNOS4_ENC_FMT_YUV_444 (1 << EXYNOS4_ENC_FMT_SHIFT) #define EXYNOS4_ENC_FMT_YUV_422 (2 << EXYNOS4_ENC_FMT_SHIFT) @@ -303,8 +308,10 @@ #define EXYNOS4_JPEG_DECODED_IMG_FMT_MASK 0x03 -#define EXYNOS4_SWAP_CHROMA_CRCB (1 << 26) -#define EXYNOS4_SWAP_CHROMA_CBCR (0 << 26) +#define EXYNOS7_SWAP_CHROMA_SHIFT 27 +#define EXYNOS4_SWAP_CHROMA_SHIFT 26 +#define EXYNOS_SWAP_CHROMA_CRCB(shift) (1 << (shift)) +#define EXYNOS_SWAP_CHROMA_CBCR(shift) (0 << (shift)) /* JPEG HUFF count Register bit */ #define EXYNOS4_HUFF_COUNT_MASK 0x -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v6 1/2] media: Add registration helpers for V4L2 flash
This patch adds helper functions for registering/unregistering
LED class flash devices as V4L2 subdevs. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Sakari Ailus
Cc: Hans Verkuil
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/media/v4l2-core/Kconfig | 11 +
drivers/media/v4l2-core/Makefile |2 +
drivers/media/v4l2-core/v4l2-flash.c | 502 ++
include/media/v4l2-flash.h | 135 +
4 files changed, 650 insertions(+)
create mode 100644 drivers/media/v4l2-core/v4l2-flash.c
create mode 100644 include/media/v4l2-flash.h
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index 9ca0f8d..7e0c42f 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -35,6 +35,17 @@ config V4L2_MEM2MEM_DEV
tristate
depends on VIDEOBUF2_CORE
+# Used by LED subsystem flash drivers
+config V4L2_FLASH_LED_CLASS
+ tristate "Enable support for Flash sub-devices"
+ depends on VIDEO_V4L2_SUBDEV_API
+ depends on LEDS_CLASS_FLASH
+ ---help---
+ Say Y here to enable support for Flash sub-devices, which allow
+ to control LED class devices with use of V4L2 Flash controls.
+
+ When in doubt, say N.
+
# Used by drivers that need Videobuf modules
config VIDEOBUF_GEN
tristate
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index 63d29f2..44e858c 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_VIDEO_TUNER) += tuner.o
obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
+obj-$(CONFIG_V4L2_FLASH_LED_CLASS) += v4l2-flash.o
+
obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
obj-$(CONFIG_VIDEOBUF_DMA_CONTIG) += videobuf-dma-contig.o
diff --git a/drivers/media/v4l2-core/v4l2-flash.c
b/drivers/media/v4l2-core/v4l2-flash.c
new file mode 100644
index 000..2236f8b
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-flash.c
@@ -0,0 +1,502 @@
+/*
+ * V4L2 Flash LED sub-device registration helpers.
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation."
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define has_flash_op(v4l2_flash, op) \
+ (v4l2_flash && v4l2_flash->ops->op)
+
+#define call_flash_op(v4l2_flash, op, args...) \
+ (has_flash_op(v4l2_flash, op) ? \
+ v4l2_flash->ops->op(args) : \
+ -EINVAL)
+
+static inline enum led_brightness v4l2_flash_intensity_to_led_brightness(
+ struct v4l2_ctrl *ctrl,
+ s32 intensity)
+{
+ s64 __intensity = intensity - ctrl->minimum;
+
+ do_div(__intensity, ctrl->step);
+
+ return __intensity + 1;
+}
+
+static inline s32 v4l2_flash_led_brightness_to_intensity(
+ struct v4l2_ctrl *ctrl,
+ enum led_brightness brightness)
+{
+ return ((brightness - 1) * ctrl->step) + ctrl->minimum;
+}
+
+static int v4l2_flash_g_volatile_ctrl(struct v4l2_ctrl *c)
+{
+ struct v4l2_flash *v4l2_flash = v4l2_ctrl_to_v4l2_flash(c);
+ struct led_classdev_flash *flash = v4l2_flash->flash;
+ struct led_classdev *led_cdev = &flash->led_cdev;
+ struct v4l2_ctrl **ctrls = v4l2_flash->ctrls;
+ bool is_strobing;
+ int ret;
+
+ switch (c->id) {
+ case V4L2_CID_FLASH_TORCH_INTENSITY:
+ /*
+* Update torch brightness only if in TORCH_MODE,
+* as otherwise brightness_update op returns 0,
+* which would spuriously inform user space that
+* V4L2_CID_FLASH_TORCH_INTENSITY control value
+* has changed.
+*/
+ if (ctrls[LED_MODE]->val == V4L2_FLASH_LED_MODE_TORCH) {
+ ret = led_update_brightness(led_cdev);
+ if (ret < 0)
+ return ret;
+ ctrls[TORCH_INTENSITY]->val =
+ v4l2_flash_led_brightness_to_intensity(
+ ctrls[TORCH_INTENSITY],
+ led_cdev->brightness);
+ }
+ return 0;
+ case V
[PATCH/RFC v6 2/2] exynos4-is: Add support for v4l2-flash subdevs
This patch adds suppport for external v4l2-flash devices.
The support includes parsing camera-flash DT property
and asynchronous subdevice registration.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Sylwester Nawrocki
---
drivers/media/platform/exynos4-is/media-dev.c | 36 +++--
drivers/media/platform/exynos4-is/media-dev.h | 13 -
2 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index 344718d..9758b59 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -451,6 +451,25 @@ rpm_put:
return ret;
}
+static void fimc_md_register_flash_entities(struct fimc_md *fmd)
+{
+ struct device_node *parent = fmd->pdev->dev.of_node;
+ struct device_node *np;
+ int i = 0;
+
+ do {
+ np = of_parse_phandle(parent, "flashes", i);
+ if (np) {
+ fmd->flash[fmd->num_flashes].asd.match_type =
+ V4L2_ASYNC_MATCH_OF;
+ fmd->flash[fmd->num_flashes].asd.match.of.node = np;
+ fmd->num_flashes++;
+ fmd->async_subdevs[fmd->num_sensors + i] =
+ &fmd->flash[i].asd;
+ }
+ } while (np && (++i < FIMC_MAX_FLASHES));
+}
+
static int __of_get_csis_id(struct device_node *np)
{
u32 reg = 0;
@@ -1273,6 +1292,15 @@ static int subdev_notifier_bound(struct
v4l2_async_notifier *notifier,
struct fimc_sensor_info *si = NULL;
int i;
+ /* Register flash subdev if detected any */
+ for (i = 0; i < ARRAY_SIZE(fmd->flash); i++) {
+ if (fmd->flash[i].asd.match.of.node == subdev->dev->of_node) {
+ fmd->flash[i].subdev = subdev;
+ fmd->num_flashes++;
+ return 0;
+ }
+ }
+
/* Find platform data for this sensor subdev */
for (i = 0; i < ARRAY_SIZE(fmd->sensor); i++)
if (fmd->sensor[i].asd.match.of.node == subdev->dev->of_node)
@@ -1383,6 +1411,8 @@ static int fimc_md_probe(struct platform_device *pdev)
goto err_m_ent;
}
+ fimc_md_register_flash_entities(fmd);
+
mutex_unlock(&fmd->media_dev.graph_mutex);
ret = device_create_file(&pdev->dev, &dev_attr_subdev_conf_mode);
@@ -1399,12 +1429,14 @@ static int fimc_md_probe(struct platform_device *pdev)
goto err_attr;
}
- if (fmd->num_sensors > 0) {
+ if (fmd->num_sensors > 0 || fmd->num_flashes > 0) {
fmd->subdev_notifier.subdevs = fmd->async_subdevs;
- fmd->subdev_notifier.num_subdevs = fmd->num_sensors;
+ fmd->subdev_notifier.num_subdevs = fmd->num_sensors +
+ fmd->num_flashes;
fmd->subdev_notifier.bound = subdev_notifier_bound;
fmd->subdev_notifier.complete = subdev_notifier_complete;
fmd->num_sensors = 0;
+ fmd->num_flashes = 0;
ret = v4l2_async_notifier_register(&fmd->v4l2_dev,
&fmd->subdev_notifier);
diff --git a/drivers/media/platform/exynos4-is/media-dev.h
b/drivers/media/platform/exynos4-is/media-dev.h
index 0321454..feff9c8 100644
--- a/drivers/media/platform/exynos4-is/media-dev.h
+++ b/drivers/media/platform/exynos4-is/media-dev.h
@@ -34,6 +34,8 @@
#define FIMC_MAX_SENSORS 4
#define FIMC_MAX_CAMCLKS 2
+#define FIMC_MAX_FLASHES 2
+#define FIMC_MAX_ASYNC_SUBDEVS (FIMC_MAX_SENSORS + FIMC_MAX_FLASHES)
#define DEFAULT_SENSOR_CLK_FREQ2400U
/* LCD/ISP Writeback clocks (PIXELASYNCMx) */
@@ -93,6 +95,11 @@ struct fimc_sensor_info {
struct fimc_dev *host;
};
+struct fimc_flash_info {
+ struct v4l2_subdev *subdev;
+ struct v4l2_async_subdev asd;
+};
+
struct cam_clk {
struct clk_hw hw;
struct fimc_md *fmd;
@@ -104,6 +111,8 @@ struct cam_clk {
* @csis: MIPI CSIS subdevs data
* @sensor: array of registered sensor subdevs
* @num_sensors: actual number of registered sensors
+ * @flash: array of registered flash subdevs
+ * @num_flashes: actual number of registered flashes
* @camclk: external sensor clock information
* @fimc: array of registered fimc devices
* @fimc_is: fimc-is data structure
@@ -123,6 +132,8 @@ struct fimc_md {
struct fimc_csis_info csis[CSIS_MAX_ENTITIES];
struct fimc_sensor_info sensor[FIMC_MAX_SENSORS];
int num_sensors;
+ struct fimc_flash_info fl
[PATCH/RFC v6 1/3] leds: implement sysfs interface locking mechanism
Add a mechanism for locking LED subsystem sysfs interface.
This patch prepares ground for addition of LED Flash Class
extension, whose API will be integrated with V4L2 Flash API.
Such a fusion enforces introducing a locking scheme, which
will secure consistent access to the LED Flash Class device.
The mechanism being introduced allows for disabling LED
subsystem sysfs interface by calling led_sysfs_disable function
and enabling it by calling led_sysfs_enable. The functions
alter the LED_SYSFS_DISABLE flag state and must be called
under mutex lock. The state of the lock is checked with use
of led_sysfs_is_disabled function. Such a design allows for
providing immediate feedback to the user space on whether
the LED Flash Class device is available or is under V4L2 Flash
sub-device control.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/led-class.c| 19 ---
drivers/leds/led-core.c | 18 ++
drivers/leds/led-triggers.c | 16 +---
include/linux/leds.h| 32
4 files changed, 79 insertions(+), 6 deletions(-)
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 2e124aa2..a39ca8f 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -39,17 +39,27 @@ static ssize_t brightness_store(struct device *dev,
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
unsigned long state;
- ssize_t ret = -EINVAL;
+ ssize_t ret;
+
+ mutex_lock(&led_cdev->led_access);
+
+ if (led_sysfs_is_disabled(led_cdev)) {
+ ret = -EBUSY;
+ goto unlock;
+ }
ret = kstrtoul(buf, 10, &state);
if (ret)
- return ret;
+ goto unlock;
if (state == LED_OFF)
led_trigger_remove(led_cdev);
__led_set_brightness(led_cdev, state);
- return size;
+ ret = size;
+unlock:
+ mutex_unlock(&led_cdev->led_access);
+ return ret;
}
static DEVICE_ATTR_RW(brightness);
@@ -213,6 +223,7 @@ int led_classdev_register(struct device *parent, struct
led_classdev *led_cdev)
#ifdef CONFIG_LEDS_TRIGGERS
init_rwsem(&led_cdev->trigger_lock);
#endif
+ mutex_init(&led_cdev->led_access);
/* add to the list of leds */
down_write(&leds_list_lock);
list_add_tail(&led_cdev->node, &leds_list);
@@ -266,6 +277,8 @@ void led_classdev_unregister(struct led_classdev *led_cdev)
down_write(&leds_list_lock);
list_del(&led_cdev->node);
up_write(&leds_list_lock);
+
+ mutex_destroy(&led_cdev->led_access);
}
EXPORT_SYMBOL_GPL(led_classdev_unregister);
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 0d15aa9..cca86ab 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -142,3 +142,21 @@ int led_update_brightness(struct led_classdev *led_cdev)
return ret;
}
EXPORT_SYMBOL(led_update_brightness);
+
+/* Caller must ensure led_cdev->led_access held */
+void led_sysfs_disable(struct led_classdev *led_cdev)
+{
+ lockdep_assert_held(&led_cdev->led_access);
+
+ led_cdev->flags |= LED_SYSFS_DISABLE;
+}
+EXPORT_SYMBOL_GPL(led_sysfs_disable);
+
+/* Caller must ensure led_cdev->led_access held */
+void led_sysfs_enable(struct led_classdev *led_cdev)
+{
+ lockdep_assert_held(&led_cdev->led_access);
+
+ led_cdev->flags &= ~LED_SYSFS_DISABLE;
+}
+EXPORT_SYMBOL_GPL(led_sysfs_enable);
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index c3734f1..e8b1120 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -37,6 +37,14 @@ ssize_t led_trigger_store(struct device *dev, struct
device_attribute *attr,
char trigger_name[TRIG_NAME_MAX];
struct led_trigger *trig;
size_t len;
+ int ret = count;
+
+ mutex_lock(&led_cdev->led_access);
+
+ if (led_sysfs_is_disabled(led_cdev)) {
+ ret = -EBUSY;
+ goto unlock;
+ }
trigger_name[sizeof(trigger_name) - 1] = '\0';
strncpy(trigger_name, buf, sizeof(trigger_name) - 1);
@@ -47,7 +55,7 @@ ssize_t led_trigger_store(struct device *dev, struct
device_attribute *attr,
if (!strcmp(trigger_name, "none")) {
led_trigger_remove(led_cdev);
- return count;
+ goto unlock;
}
down_read(&triggers_list_lock);
@@ -58,12 +66,14 @@ ssize_t led_trigger_store(struct device *dev, struct
device_attribute *attr,
up_write(&led_cdev->trigger_lock);
up_read(&triggers_list_lock);
- return count;
+ goto unlock;
}
[PATCH/RFC v6 2/3] leds: add API for setting torch brightness
This patch prepares ground for addition of LED Flash Class extension to
the LED subsystem. Since turning the torch on must have guaranteed
immediate effect the brightness_set op can't be used for it. Drivers must
schedule a work queue task in this op to be compatible with led-triggers,
which call brightess_set from timer irqs. In order to address this
limitation a torch_brightness_set op and led_set_torch_brightness API
is introduced. Setting brightness sysfs attribute will result in calling
brightness_set op for LED Class devices and torch_brightness_set op for
LED Flash Class devices, whereas triggers will still call brightness
op in both cases.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/led-class.c |9 +++--
drivers/leds/led-core.c | 14 ++
include/linux/leds.h | 21 +
3 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index a39ca8f..5a11a07 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -54,9 +54,14 @@ static ssize_t brightness_store(struct device *dev,
if (state == LED_OFF)
led_trigger_remove(led_cdev);
- __led_set_brightness(led_cdev, state);
- ret = size;
+ if (led_cdev->flags & LED_DEV_CAP_TORCH)
+ ret = led_set_torch_brightness(led_cdev, state);
+ else
+ __led_set_brightness(led_cdev, state);
+
+ if (!ret)
+ ret = size;
unlock:
mutex_unlock(&led_cdev->led_access);
return ret;
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index cca86ab..c6d8288 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -143,6 +143,20 @@ int led_update_brightness(struct led_classdev *led_cdev)
}
EXPORT_SYMBOL(led_update_brightness);
+int led_set_torch_brightness(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ int ret = 0;
+
+ led_cdev->brightness = min(brightness, led_cdev->max_brightness);
+
+ if (!(led_cdev->flags & LED_SUSPENDED))
+ ret = led_cdev->torch_brightness_set(led_cdev,
+led_cdev->brightness);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(led_set_torch_brightness);
+
/* Caller must ensure led_cdev->led_access held */
void led_sysfs_disable(struct led_classdev *led_cdev)
{
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 44c8a98..bc2a570 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -44,11 +44,21 @@ struct led_classdev {
#define LED_BLINK_ONESHOT_STOP (1 << 18)
#define LED_BLINK_INVERT (1 << 19)
#define LED_SYSFS_DISABLE (1 << 20)
+#define LED_DEV_CAP_TORCH (1 << 21)
/* Set LED brightness level */
/* Must not sleep, use a workqueue if needed */
void(*brightness_set)(struct led_classdev *led_cdev,
enum led_brightness brightness);
+ /*
+* Set LED brightness immediately - it is required for flash led
+* devices as they require setting torch brightness to have immediate
+* effect. brightness_set op cannot be used for this purpose because
+* the led drivers schedule a work queue task in it to allow for
+* being called from led-triggers, i.e. from the timer irq context.
+*/
+ int (*torch_brightness_set)(struct led_classdev *led_cdev,
+ enum led_brightness brightness);
/* Get LED brightness level */
enum led_brightness (*brightness_get)(struct led_classdev *led_cdev);
@@ -157,6 +167,17 @@ extern void led_set_brightness(struct led_classdev
*led_cdev,
extern int led_update_brightness(struct led_classdev *led_cdev);
/**
+ * led_set_torch_brightness - set torch LED brightness
+ * @led_cdev: the LED to set
+ * @brightness: the brightness to set it to
+ *
+ * Returns: 0 on success or negative error value on failure
+ *
+ * Set a torch LED's brightness.
+ */
+extern int led_set_torch_brightness(struct led_classdev *led_cdev,
+ enum led_brightness brightness);
+/**
* led_sysfs_disable - disable LED sysfs interface
* @led_cdev: the LED to set
*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v6 0/3] LED / flash API integration - LED Flash Class
This patch set is the follow-up of the LED / flash API integration series [1]. For clarity reasons the patchset has been split into four subsets: - LED Flash Class - V4L2 Flash - LED Flash Class drivers - Documentation Changes since version 5: - removed flash manager framework - its implementation needs further thorough discussion. - removed external strobe facilities from the LED Flash Class and provided external_strobe_set op in v4l2-flash. LED subsystem should be strobe provider agnostic. Thanks, Jacek Anaszewski [1] https://lkml.org/lkml/2014/7/11/914 Jacek Anaszewski (3): leds: implement sysfs interface locking mechanism leds: add API for setting torch brightness leds: Add LED Flash Class wrapper to LED subsystem drivers/leds/Kconfig| 11 + drivers/leds/Makefile |1 + drivers/leds/led-class-flash.c | 557 +++ drivers/leds/led-class.c| 30 ++- drivers/leds/led-core.c | 32 +++ drivers/leds/led-triggers.c | 16 +- include/linux/led-class-flash.h | 238 + include/linux/leds.h| 56 8 files changed, 934 insertions(+), 7 deletions(-) create mode 100644 drivers/leds/led-class-flash.c create mode 100644 include/linux/led-class-flash.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v6 0/2] LED / flash API integration - V4L2 Flash
This patch set is the follow-up of the LED / flash API integration series [1]. For clarity reasons the patchset has been split into four subsets: - LED Flash Class - V4L2 Flash - LED Flash Class drivers - Documentation Changes since version 5: - removed flash manager framework - its implementation needs further thorough discussion. - removed external strobe facilities from the LED Flash Class and provided external_strobe_set op in v4l2-flash. LED subsystem should be strobe provider agnostic. Thanks, Jacek Anaszewski [1] https://lkml.org/lkml/2014/7/11/914 Jacek Anaszewski (2): media: Add registration helpers for V4L2 flash exynos4-is: Add support for v4l2-flash subdevs drivers/media/platform/exynos4-is/media-dev.c | 36 +- drivers/media/platform/exynos4-is/media-dev.h | 13 +- drivers/media/v4l2-core/Kconfig | 11 + drivers/media/v4l2-core/Makefile |2 + drivers/media/v4l2-core/v4l2-flash.c | 502 + include/media/v4l2-flash.h| 135 +++ 6 files changed, 696 insertions(+), 3 deletions(-) create mode 100644 drivers/media/v4l2-core/v4l2-flash.c create mode 100644 include/media/v4l2-flash.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v6 3/3] leds: Add LED Flash Class wrapper to LED subsystem
Some LED devices support two operation modes - torch and flash.
This patch provides support for flash LED devices in the LED subsystem
by introducing new sysfs attributes and kernel internal interface.
The attributes being introduced are: flash_brightness, flash_strobe,
flash_timeout, max_flash_timeout, max_flash_brightness, flash_fault,
indicator_brightness and max_indicator_brightness. All the flash
related features are placed in a separate module.
The modifications aim to be compatible with V4L2 framework requirements
related to the flash devices management. The design assumes that V4L2
sub-device can take of the LED class device control and communicate
with it through the kernel internal interface. When V4L2 Flash sub-device
file is opened, the LED class device sysfs interface is made
unavailable.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/Kconfig| 11 +
drivers/leds/Makefile |1 +
drivers/leds/led-class-flash.c | 557 +++
drivers/leds/led-class.c|4 +
include/linux/led-class-flash.h | 238 +
include/linux/leds.h|3 +
6 files changed, 814 insertions(+)
create mode 100644 drivers/leds/led-class-flash.c
create mode 100644 include/linux/led-class-flash.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 8c96e2d..3c58021 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -22,6 +22,17 @@ config LEDS_CLASS
This option enables the led sysfs class in /sys/class/leds. You'll
need this to do anything useful with LEDs. If unsure, say N.
+config LEDS_CLASS_FLASH
+ tristate "LED Flash Class Support"
+ depends on LEDS_CLASS
+ depends on OF
+ help
+ This option enables the flash led sysfs class in /sys/class/leds.
+ It wrapps LED Class and adds flash LEDs specific sysfs attributes
+ and kernel internal API to it. You'll need this to provide support
+ for the flash related features of a LED device. It can be built
+ as a module.
+
comment "LED drivers"
config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index d8cc5f2..9238b8a 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -2,6 +2,7 @@
# LED Core
obj-$(CONFIG_NEW_LEDS) += led-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
+obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
obj-$(CONFIG_LEDS_TRIGGERS)+= led-triggers.o
# LED Platform Drivers
diff --git a/drivers/leds/led-class-flash.c b/drivers/leds/led-class-flash.c
new file mode 100644
index 000..f1ba539
--- /dev/null
+++ b/drivers/leds/led-class-flash.c
@@ -0,0 +1,557 @@
+/*
+ * LED Flash Class interface
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "leds.h"
+
+#define has_flash_op(flash, op)\
+ (flash && flash->ops->op)
+
+#define call_flash_op(flash, op, args...) \
+ ((has_flash_op(flash, op)) ?\
+ (flash->ops->op(flash, args)) : \
+ -EINVAL)
+
+static ssize_t flash_brightness_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_flash *flash = lcdev_to_flash(led_cdev);
+ unsigned long state;
+ ssize_t ret;
+
+ mutex_lock(&led_cdev->led_access);
+
+ if (led_sysfs_is_disabled(led_cdev)) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ ret = kstrtoul(buf, 10, &state);
+ if (ret)
+ goto unlock;
+
+ ret = led_set_flash_brightness(flash, state);
+ if (ret < 0)
+ goto unlock;
+
+ ret = size;
+unlock:
+ mutex_unlock(&led_cdev->led_access);
+ return ret;
+}
+
+static ssize_t flash_brightness_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_flash *flash = lcdev_to_flash(led_cdev);
+
+ /* no lock needed for this */
+ led_update_flash_brightness(flash);
+
+ return sprintf(buf, "%u\n", flash->brightness.val);
+}
+static DEVICE_ATTR_RW(flash_brightness);
+
+static ssize_t max_flash_brightness_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classd
[PATCH/RFC v6 2/2] leds: Add driver for AAT1290 current regulator
This patch adds a driver for the 1.5A Step-Up
Current Regulator for Flash LEDs. The device is
programmed through a Skyworks' proprietary AS2Cwire
serial digital interface.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/Kconfig|6 +
drivers/leds/Makefile |1 +
drivers/leds/leds-aat1290.c | 460 +++
3 files changed, 467 insertions(+)
create mode 100644 drivers/leds/leds-aat1290.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index c654f74..2a158fc 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -43,6 +43,12 @@ config LEDS_88PM860X
This option enables support for on-chip LED drivers found on Marvell
Semiconductor 88PM8606 PMIC.
+config LEDS_AAT1290
+ tristate "LED support for the AAT1290"
+ depends on LEDS_CLASS_FLASH
+ help
+This option enables support for the LEDs on the AAT1290.
+
config LEDS_LM3530
tristate "LCD Backlight driver for LM3530"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1178426..1675ef9 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
# LED Platform Drivers
obj-$(CONFIG_LEDS_88PM860X)+= leds-88pm860x.o
+obj-$(CONFIG_LEDS_AAT1290) += leds-aat1290.o
obj-$(CONFIG_LEDS_BD2802) += leds-bd2802.o
obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
new file mode 100644
index 000..35ee4d5
--- /dev/null
+++ b/drivers/leds/leds-aat1290.c
@@ -0,0 +1,460 @@
+/*
+ * LED Flash Class driver for the AAT1290
+ * 1.5A Step-Up Current Regulator for Flash LEDs
+ *
+ * Copyright (C) 2014, Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define AAT1290_LED_NAME "aat1290"
+#define AAT1290_MOVIE_MODE_CURRENT_ADDR17
+#define AAT1290_FLASH_SAFETY_TIMER_ADDR18
+#define AAT1290_MOVIE_MODE_CONFIG_ADDR 19
+#define AAT1290_MM_CURRENT_RATIO_ADDR 20
+#define AAT1290_LATCH_TIME_US 500
+#define AAT1290_EN_SET_TICK_TIME_US1
+#define AAT1290_MOVIE_MODE_OFF 1
+#define AAT1290_MOVIE_MODE_ON 3
+#define AAT1290_MAX_MM_CURR_PERCENT_0 16
+#define AAT1290_MAX_MM_CURR_PERCENT_100 1
+#define AAT1290_FLASH_TM_NUM_LEVELS16
+
+#define AAT1290_MM_TO_FL_1_92 1
+#define AAT1290_MM_TO_FL_3_7 2
+#define AAT1290_MM_TO_FL_5_5 3
+#define AAT1290_MM_TO_FL_7_3 4
+#define AAT1290_MM_TO_FL_9 5
+#define AAT1290_MM_TO_FL_10_7 6
+#define AAT1290_MM_TO_FL_12_4 7
+#define AAT1290_MM_TO_FL_148
+#define AAT1290_MM_TO_FL_15_9 9
+#define AAT1290_MM_TO_FL_17_5 10
+#define AAT1290_MM_TO_FL_19_1 11
+#define AAT1290_MM_TO_FL_20_8 12
+#define AAT1290_MM_TO_FL_22_4 13
+#define AAT1290_MM_TO_FL_2414
+#define AAT1290_MM_TO_FL_25_6 15
+#define AAT1290_MM_TO_FL_OFF 16
+
+struct aat1290_led_settings {
+ struct led_flash_setting torch_brightness;
+ struct led_flash_setting flash_brightness;
+ struct led_flash_setting flash_timeout;
+};
+
+struct aat1290_led {
+ struct platform_device *pdev;
+ struct mutex lock;
+
+ struct led_classdev_flash ldev;
+ struct v4l2_flash *v4l2_flash;
+
+ int flen_gpio;
+ int en_set_gpio;
+
+ u32 max_flash_tm;
+ bool movie_mode;
+
+ unsigned int torch_brightness;
+ unsigned int flash_timeout;
+ struct work_struct work_brightness_set;
+};
+
+static struct aat1290_led *ldev_to_led(struct led_classdev_flash *ldev)
+{
+ return container_of(ldev, struct aat1290_led, ldev);
+}
+
+static void aat1290_as2cwire_write(struct aat1290_led *led, int addr, int
value)
+{
+ int i;
+
+ gpio_set_value(led->flen_gpio, 0);
+ gpio_set_value(led->en_set_gpio, 0);
+
+ udelay(10);
+
+ /* write address */
+ for (i = 0; i < addr; ++i) {
+ udelay(AAT1290_EN_SET_TICK_TIME_US);
+ gpio_set_value(led->en_set_gpio, 0);
+ udelay(AAT1290_EN_SET_TICK_TIME_US);
+ gpio_set_value(led->en_set_gpio, 1);
+ }
+
+ udelay(AAT1290_LATCH_TIME_US);
+
+ /* write data */
+ for (i = 0; i < value; ++i) {
+ udelay(AAT1290_EN_SET_TICK_TIME_US);
+ gpio_set_value(led->en_set_gpio, 0);
+ udelay(AAT1290_EN_SET_TICK_TIME
[PATCH/RFC v6 1/2] leds: Add support for max77693 mfd flash cell
This patch adds led-flash support to Maxim max77693 chipset.
A device can be exposed to user space through LED subsystem
sysfs interface or through V4L2 subdevice when the support
for V4L2 Flash sub-devices is enabled. Device supports up to
two leds which can work in flash and torch mode. Leds can
be triggered externally or by software.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Andrzej Hajda
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
Cc: SangYoung Son
Cc: Samuel Ortiz
---
drivers/leds/Kconfig |9 +
drivers/leds/Makefile|1 +
drivers/leds/leds-max77693.c | 1083 ++
3 files changed, 1093 insertions(+)
create mode 100644 drivers/leds/leds-max77693.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 3c58021..c654f74 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -457,6 +457,15 @@ config LEDS_TCA6507
LED driver chips accessed via the I2C bus.
Driver support brightness control and hardware-assisted blinking.
+config LEDS_MAX77693
+ tristate "LED support for MAX77693 Flash"
+ depends on LEDS_CLASS_FLASH
+ depends on MFD_MAX77693
+ help
+ This option enables support for the flash part of the MAX77693
+ multifunction device. It has build in control for two leds in flash
+ and torch mode.
+
config LEDS_MAX8997
tristate "LED support for MAX8997 PMIC"
depends on LEDS_CLASS && MFD_MAX8997
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 9238b8a..1178426 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_LEDS_MC13783)+= leds-mc13783.o
obj-$(CONFIG_LEDS_NS2) += leds-ns2.o
obj-$(CONFIG_LEDS_NETXBIG) += leds-netxbig.o
obj-$(CONFIG_LEDS_ASIC3) += leds-asic3.o
+obj-$(CONFIG_LEDS_MAX77693)+= leds-max77693.o
obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
new file mode 100644
index 000..f1e6e79
--- /dev/null
+++ b/drivers/leds/leds-max77693.c
@@ -0,0 +1,1083 @@
+/*
+ * LED Flash Class driver for the flash cell of max77693 mfd.
+ *
+ * Copyright (C) 2014, Samsung Electronics Co., Ltd.
+ *
+ * Authors: Jacek Anaszewski
+ * Andrzej Hajda
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MAX77693_LED_NAME_1"max77693-flash_1"
+#define MAX77693_LED_NAME_2"max77693-flash_2"
+
+#define MODE_OFF 0
+#define MODE_FLASH1(1 << 0)
+#define MODE_FLASH2(1 << 1)
+#define MODE_TORCH1(1 << 2)
+#define MODE_TORCH2(1 << 3)
+#define MODE_FLASH_EXTERNAL1 (1 << 4)
+#define MODE_FLASH_EXTERNAL2 (1 << 5)
+
+enum {
+ FLED1,
+ FLED2
+};
+
+enum {
+ FLASH,
+ TORCH
+};
+
+struct max77693_sub_led {
+ struct led_classdev_flash ldev;
+ struct work_struct work_brightness_set;
+ struct v4l2_flash *v4l2_flash;
+
+ unsigned int torch_brightness;
+ unsigned int flash_timeout;
+};
+
+struct max77693_led {
+ struct regmap *regmap;
+ struct platform_device *pdev;
+ struct max77693_led_platform_data *pdata;
+ struct mutex lock;
+
+ struct max77693_sub_led sub_leds[2];
+
+ unsigned int current_flash_timeout;
+ unsigned int mode_flags;
+ u8 torch_iout_reg;
+ bool iout_joint;
+ int strobing_sub_led_id;
+};
+
+struct max77693_led_settings {
+ struct led_flash_setting torch_brightness;
+ struct led_flash_setting flash_brightness;
+ struct led_flash_setting flash_timeout;
+};
+
+static u8 max77693_led_iout_to_reg(u32 ua)
+{
+ if (ua < FLASH_IOUT_MIN)
+ ua = FLASH_IOUT_MIN;
+ return (ua - FLASH_IOUT_MIN) / FLASH_IOUT_STEP;
+}
+
+static u8 max77693_flash_timeout_to_reg(u32 us)
+{
+ return (us - FLASH_TIMEOUT_MIN) / FLASH_TIMEOUT_STEP;
+}
+
+static inline struct max77693_led *ldev1_to_led(
+ struct led_classdev_flash *ldev)
+{
+ struct max77693_sub_led *sub_led = container_of(ldev,
+ struct max77693_sub_led,
+ ldev);
+ return container_of(sub_led, struct max77693_led, sub_leds[0]);
+}
+
+static inline struct max77693_led *ldev2_to_led(
+
[PATCH/RFC v6 0/6] LED / flash API integration - Documentation
This patch set is the follow-up of the LED / flash API integration series [1]. For clarity reasons the patchset has been split into four subsets: - LED Flash Class - V4L2 Flash - LED Flash Class drivers - Documentation Changes since version 5: - removed flash manager framework - its implementation needs further thorough discussion. - removed external strobe facilities from the LED Flash Class and provided external_strobe_set op in v4l2-flash. LED subsystem should be strobe provider agnostic. Thanks, Jacek Anaszewski [1] https://lkml.org/lkml/2014/7/11/914 Jacek Anaszewski (6): Documentation: leds: Add description of LED Flash Class extension DT: leds: Add flash led devices related properties DT: Add documentation for exynos4-is 'flashes' property DT: Add documentation for the mfd Maxim max77693 of: Add Skyworks Solutions, Inc. vendor prefix DT: Add documentation for the Skyworks AAT1290 Documentation/devicetree/bindings/leds/common.txt | 16 + .../devicetree/bindings/leds/leds-aat1290.txt | 17 ++ .../devicetree/bindings/media/samsung-fimc.txt |5 ++ Documentation/devicetree/bindings/mfd/max77693.txt | 62 .../devicetree/bindings/vendor-prefixes.txt|1 + Documentation/leds/leds-class-flash.txt| 51 6 files changed, 152 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-aat1290.txt create mode 100644 Documentation/leds/leds-class-flash.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v6 0/2] LED / flash API integration - LED Flash Class drivers
This patch set is the follow-up of the LED / flash API integration series [1]. For clarity reasons the patchset has been split into four subsets: - LED Flash Class - V4L2 Flash - LED Flash Class drivers - Documentation Changes since version 5: - removed flash manager framework - its implementation needs further thorough discussion. - removed external strobe facilities from the LED Flash Class and provided external_strobe_set op in v4l2-flash. LED subsystem should be strobe provider agnostic. Thanks, Jacek Anaszewski [1] https://lkml.org/lkml/2014/7/11/914 Jacek Anaszewski (2): leds: Add support for max77693 mfd flash cell leds: Add driver for AAT1290 current regulator drivers/leds/Kconfig | 15 + drivers/leds/Makefile|2 + drivers/leds/leds-aat1290.c | 460 ++ drivers/leds/leds-max77693.c | 1083 ++ 4 files changed, 1560 insertions(+) create mode 100644 drivers/leds/leds-aat1290.c create mode 100644 drivers/leds/leds-max77693.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v6 1/6] Documentation: leds: Add description of LED Flash Class extension
The documentation being added contains overall description of the LED Flash Class and the related sysfs attributes. There are also chapters devoted specifically to the Flash Manager feature. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Bryan Wu Cc: Richard Purdie --- Documentation/leds/leds-class-flash.txt | 51 +++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/leds/leds-class-flash.txt diff --git a/Documentation/leds/leds-class-flash.txt b/Documentation/leds/leds-class-flash.txt new file mode 100644 index 000..0cf5449a --- /dev/null +++ b/Documentation/leds/leds-class-flash.txt @@ -0,0 +1,51 @@ + +Flash LED handling under Linux +== + +Some LED devices support two modes - torch and flash. In order to enable +support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol must be defined +in the kernel config. A flash LED driver must register in the LED subsystem +with led_classdev_flash_register to gain flash capabilities. + +Following sysfs attributes are exposed for controlling flash led devices: + + - flash_brightness - flash LED brightness in microamperes (RW) + - max_flash_brightness - maximum available flash LED brightness (RO) + - indicator_brightness - privacy LED brightness in microamperes (RW) + - max_indicator_brightness - maximum privacy LED brightness in +microamperes (RO) + - flash_timeout - flash strobe duration in microseconds (RW) + - max_flash_timeout - maximum available flash strobe duration (RO) + - flash_strobe - flash strobe state (RW) + - flash_fault - bitmask of flash faults that may have occurred, + possible flags are: + * 0x01 - flash controller voltage to the flash LED has exceeded +the limit specific to the flash controller + * 0x02 - the flash strobe was still on when the timeout set by +the user has expired; not all flash controllers may +set this in all such conditions + * 0x04 - the flash controller has overheated + * 0x08 - the short circuit protection of the flash controller +has been triggered + * 0x10 - current in the LED power supply has exceeded the limit +specific to the flash controller + * 0x40 - flash controller voltage to the flash LED has been +below the minimum limit specific to the flash + * 0x80 - the input voltage of the flash controller is below +the limit under which strobing the flash at full +current will not be possible. The condition persists +until this flag is no longer set + * 0x100 - the temperature of the LED has exceeded its allowed + upper limit + +A LED subsystem driver can be controlled also from the level of VideoForLinux2 +subsystem. In order to enable this CONFIG_V4L2_FLASH_LED_CLASS symbol has to +be defined in the kernel config. The driver must call v4l2_flash_init function +to get registered in the V4L2 subsystem. On remove v4l2_flash_release function +has to be called (see ). + +After proper initialization V4L2 Flash sub-device is created. The sub-device +exposes a number of V4L2 controls. When the V4L2_CID_FLASH_LED_MODE control +is set to V4L2_FLASH_LED_MODE_TORCH or V4L2_FLASH_LED_MODE_FLASH the +LED subsystem sysfs interface becomes unavailable. The interface can be +unlocked by setting the mode back to V4L2_FLASH_LED_MODE_NONE. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v6 2/6] DT: leds: Add flash led devices related properties
Addition of a LED Flash Class extension entails the need for flash led
specific device tree properties. The properties being added are:
iout-torch, iout-flash, iout-indicator and flash-timeout.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Stephen Warren
Cc: Grant Likely
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
Documentation/devicetree/bindings/leds/common.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index 2d88816..40f4b9a 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -3,6 +3,17 @@ Common leds properties.
Optional properties for child nodes:
- label : The label for this LED. If omitted, the label is
taken from the node name (excluding the unit address).
+- iout-torch : Array of maximum intensities in microamperes of the torch
+ led currents in order from sub-led 0 to N-1, where N is the number
+ of torch sub-leds exposed by the device
+- iout-flash : Array of maximum intensities in microamperes of the flash
+ led currents in order from sub-led 0 to N-1, where N is the number
+ of flash sub-leds exposed by the device
+- iout-indicator : Array of maximum intensities in microamperes of
+ the indicator led currents in order from sub-led 0 to N-1,
+ where N is the number of indicator sub-leds exposed by the device
+- flash-timeout : timeout in microseconds after which flash led
+ is turned off
- linux,default-trigger : This parameter, if present, is a
string defining the trigger assigned to the LED. Current triggers are:
@@ -19,5 +30,10 @@ Examples:
system-status {
label = "Status";
linux,default-trigger = "heartbeat";
+ iout-torch = <500 500>;
+ iout-flash = <1000 1000>;
+ iout-indicator = <100 100>;
+ flash-timeout = <1000>;
+
...
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v6 4/6] DT: Add documentation for the mfd Maxim max77693
This patch adds device tree binding documentation for
the flash cell of the Maxim max77693 multifunctional device.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Andrzej Hajda
Acked-by: Kyungmin Park
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
Documentation/devicetree/bindings/mfd/max77693.txt | 62
1 file changed, 62 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
b/Documentation/devicetree/bindings/mfd/max77693.txt
index 11921cc..0c3db3d 100644
--- a/Documentation/devicetree/bindings/mfd/max77693.txt
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -27,6 +27,55 @@ Optional properties:
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+Optional node:
+- led-flash : the LED submodule device node
+
+Required properties of "led-flash" node:
+- compatible : must be "maxim,max77693-flash"
+- maxim,num-leds : number of connected leds
+ Possible values: 1 or 2.
+- maxim,fleds : array of current outputs in order: fled1, fled2
+ Note: both current outputs can be connected to a single led
+ Possible values:
+ 0 - the output is left disconnected,
+ 1 - a diode is connected to the output.
+
+Optional properties of "led-flash" node:
+- maxim,boost-mode :
+ In boost mode the device can produce up to 1.2A of total current
+ on both outputs. The maximum current on each output is reduced
+ to 625mA then. If maxim,num-leds == <2> boost must be enabled
+ (it defaults to 1 if not set):
+ Possible values:
+ 0 - no boost,
+ 1 - adaptive mode,
+ 2 - fixed mode.
+- iout-torch : Array of maximum intensities in microamperes of the torch
+ led currents in order: fled1, fled2.
+ 15625 - 25
+- iout-flash : Array of maximum intensities in microamperes of the flash
+ led currents in order: fled1, fled2.
+ Range:
+ 15625 - 100 (max 625000 if boost mode is enabled)
+- flash-timeout : timeout in microseconds after which flash led
+ is turned off
+ Range:
+ 62500 - 100
+- maxim,trigger : Array of flags indicating which trigger can activate given
led
+ in order: fled1, fled2
+ Possible flag values (can be combined):
+ 1 - FLASH pin of the chip,
+ 2 - TORCH pin of the chip,
+ 4 - software via I2C command.
+- maxim,trigger-type : Array of trigger types in order: flash, torch.
+ Possible trigger types:
+ 0 - Rising edge of the signal triggers the flash/torch,
+ 1 - Signal level controls duration of the flash/torch.
+- maxim,boost-vout : Output voltage of the boost module in millivolts.
+- maxim,vsys-min : Low input voltage level in millivolts. Flash is not fired
+ if chip estimates that system voltage could drop below this level due
+ to flash power consumption.
+
Example:
max77693@66 {
compatible = "maxim,max77693";
@@ -52,4 +101,17 @@ Example:
regulator-boot-on;
};
};
+ led_flash: led-flash {
+ compatible = "maxim,max77693-flash";
+ iout-torch = <50 0>;
+ iout-flash = <125 0>;
+ flash-timeout = <100 100>;
+ maxim,num-leds = <1>;
+ maxim,fleds = <1 1>;
+ maxim,trigger = <7 7>;
+ maxim,trigger-type = <0 1>;
+ maxim,boost-mode = <1>;
+ maxim,boost-vout = <5000>;
+ maxim,vsys-min = <2400>;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v6 6/6] DT: Add documentation for the Skyworks AAT1290
This patch adds device tree binding documentation for
1.5A Step-Up Current Regulator for Flash LEDs.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
.../devicetree/bindings/leds/leds-aat1290.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-aat1290.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-aat1290.txt
b/Documentation/devicetree/bindings/leds/leds-aat1290.txt
new file mode 100644
index 000..9a9ad15
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-aat1290.txt
@@ -0,0 +1,17 @@
+* Skyworks Solutions, Inc. AAT1290 Current Regulator for Flash LEDs
+
+Required properties:
+
+- compatible : should be "skyworks,aat1290"
+- gpios : two gpio pins in order FLEN, EN/SET
+- skyworks,flash-timeout : maximum flash timeout in microseconds -
+ it can be calculated using following formula:
+ T = 8.82 * 10^9 * Ct
+
+Example:
+
+flash_led: flash-led {
+ compatible = "skyworks,aat1290";
+ gpios = <&gpj1 1 0>, <&gpj1 2 0>;
+ flash-timeout = <194>;
+}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v6 5/6] of: Add Skyworks Solutions, Inc. vendor prefix
Use "skyworks" as the vendor prefix for the Skyworks Solutions, Inc. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ac7269f..9d5b3f6 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -117,6 +117,7 @@ renesas Renesas Electronics Corporation ricoh Ricoh Co. Ltd. rockchip Fuzhou Rockchip Electronics Co., Ltd samsungSamsung Semiconductor +skyworks Skyworks Solutions, Inc. sbsSmart Battery System schindler Schindler seagateSeagate Technology PLC -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v6 3/6] DT: Add documentation for exynos4-is 'flashes' property
This patch adds a description of 'flashes' property to the samsung-fimc.txt. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala --- .../devicetree/bindings/media/samsung-fimc.txt |5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt index 922d6f8..387ef3b 100644 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt @@ -40,6 +40,10 @@ should be inactive. For the "active-a" state the camera port A must be activated and the port B deactivated and for the state "active-b" it should be the other way around. +Optional properties: + +- flashes - array of phandles to the available flash led devices + The 'camera' node must include at least one 'fimc' child node. @@ -166,6 +170,7 @@ Example: clock-output-names = "cam_a_clkout", "cam_b_clkout"; pinctrl-names = "default"; pinctrl-0 = <&cam_port_a_clk_active>; + flashes = <&max77693-flash>, <&aat1290>; status = "okay"; #address-cells = <1>; #size-cells = <1>; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 1/1] Add a libv4l plugin for Exynos4 camera
The plugin provides support for the media device on Exynos4 SoC.
Added is also a media device configuration file parser.
The media configuration file is used for conveying information
about media device links that need to be established as well
as V4L2 user control ioctls redirection to a particular
sub-device.
The plugin performs single plane <-> multi plane API conversion,
video pipeline linking and takes care of automatic data format
negotiation for the whole pipeline, after intercepting
VIDIOC_S_FMT or VIDIOC_TRY_FMT ioctls.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
---
configure.ac |1 +
lib/Makefile.am|5 +-
lib/libv4l-exynos4-camera/Makefile.am |7 +
.../libv4l-devconfig-parser.h | 145 ++
lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c | 2486
5 files changed, 2642 insertions(+), 2 deletions(-)
create mode 100644 lib/libv4l-exynos4-camera/Makefile.am
create mode 100644 lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h
create mode 100644 lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
diff --git a/configure.ac b/configure.ac
index c9b0524..ae653b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,7 @@ AC_CONFIG_FILES([Makefile
lib/libdvbv5/Makefile
lib/libv4l2rds/Makefile
lib/libv4l-mplane/Makefile
+ lib/libv4l-exynos4-camera/Makefile
utils/Makefile
utils/libv4l2util/Makefile
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 3a0e19c..29455ab 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -3,9 +3,10 @@ SUBDIRS = \
libv4l2 \
libv4l1 \
libv4l2rds \
- libv4l-mplane
+ libv4l-mplane \
+ libv4l-exynos4-camera
if LINUX_OS
SUBDIRS += \
libdvbv5
-endif
\ No newline at end of file
+endif
diff --git a/lib/libv4l-exynos4-camera/Makefile.am
b/lib/libv4l-exynos4-camera/Makefile.am
new file mode 100644
index 000..3552ec8
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/Makefile.am
@@ -0,0 +1,7 @@
+if WITH_V4L_PLUGINS
+libv4l2plugin_LTLIBRARIES = libv4l-exynos4-camera.la
+endif
+
+libv4l_exynos4_camera_la_SOURCES = libv4l-exynos4-camera.c
+libv4l_exynos4_camera_la_CPPFLAGS = -fvisibility=hidden -std=gnu99
+libv4l_exynos4_camera_la_LDFLAGS = -avoid-version -module -shared
-export-dynamic -lpthread
diff --git a/lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h
b/lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h
new file mode 100644
index 000..c56a469
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h
@@ -0,0 +1,145 @@
+/*
+ * Parser of media device configuration file.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Jacek Anaszewski
+ *
+ * The configuration file has to comply with following format:
+ *
+ * Link description entry format:
+ *
+ * link {
+ * source_entity:
+ * source_pad:
+ * sink_entity:
+ * sink_pad:
+ * }
+ *
+ * The V4L2 control group format:
+ *
+ * v4l2-controls {
+ * :
+ * :
+ * ...
+ * :
+ * }
+ *
+ * Example:
+ *
+ * link {
+ * source_entity: s5p-mipi-csis.0
+ * source_pad: 1
+ * sink_entity: FIMC.0
+ * sink_pad: 0
+ * }
+ *
+ * v4l2-controls {
+ * Color Effects: S5C73M3
+ * Saturation: S5C73M3
+ * }
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ */
+
+#ifndef LIBV4L_DEVCONFIG_PARSER_H
+ #define LIBV4L_DEVCONFIG_PARSER_H
+
+#include
+
+#ifdef DEBUG
+#define V4L2_DEVCFG_PARSER_DBG(format, ARG...)\
+ printf("[%s:%d] [%s] " format " \n", __FILE__, __LINE__, __func__,
##ARG)
+#else
+#define V4L2_DEVCFG_PARSER_DBG(format, ARG...)
+#endif
+
+#define V4L2_DEVCFG_PARSER_ERR(format, ARG...)\
+ fprintf(stderr, "Libv4l device config parser: "format "\n", ##ARG)
+
+#define V4L2_DEVCFG_PARSER_LOG(format, ARG...)\
+ fprintf(stdout, "Libv4l device config parser: "format "\n", ##ARG)
+
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+
+/*
+ * struct libv4l_media_link_conf - media entity link configuration
+ * @source_entity: source entity of the link
+ * @source_pad:source pad id
+ * @sink_entity: sink entity of the link
+ * @sink_pad: sink pad id
+ * @next: pointer to the next data structure in the list
[PATCH 2/3] exynos4-is: Add support for asynchronous sub-devices power on
From: Sylwester Nawrocki
Schedule sub-devices power up in separate thread to speed up video device
open and to allow some ioctls, like VIDIOC_REQBUFS to be run in parallel.
We synchronize with completion of the power up sequence before starting
streaming on subdevices, as they require to be powered up before being
starting streaming.
Signed-off-by: Sylwester Nawrocki
Acked-by: Kyungmin Park
---
drivers/media/platform/exynos4-is/media-dev.c | 19 +++
include/media/exynos-fimc.h |2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index 344718d..c867c46 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -10,6 +10,7 @@
* or (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -186,6 +187,13 @@ error:
return ret;
}
+static void __fimc_pipeline_power_async(void *data, async_cookie_t cookie)
+{
+ struct fimc_pipeline *p = data;
+
+ WARN_ON(fimc_pipeline_s_power(p, true) < 0);
+}
+
/**
* __fimc_pipeline_open - update the pipeline information, enable power
*of all pipeline subdevs and the sensor clock
@@ -219,14 +227,13 @@ static int __fimc_pipeline_open(struct
exynos_media_pipeline *ep,
return ret;
}
- ret = fimc_pipeline_s_power(p, 1);
- if (!ret)
- return 0;
+ async_schedule_domain(__fimc_pipeline_power_async, p,
+ &ep->async_domain);
if (!IS_ERR(fmd->wbclk[CLK_IDX_WB_B]) && p->subdevs[IDX_IS_ISP])
clk_disable_unprepare(fmd->wbclk[CLK_IDX_WB_B]);
- return ret;
+ return 0;
}
/**
@@ -275,6 +282,9 @@ static int __fimc_pipeline_s_stream(struct
exynos_media_pipeline *ep, bool on)
if (p->subdevs[IDX_SENSOR] == NULL)
return -ENODEV;
+ /* Wait until all devices in the chain are powered up */
+ async_synchronize_full_domain(&ep->async_domain);
+
for (i = 0; i < IDX_MAX; i++) {
unsigned int idx = seq[on][i];
@@ -309,6 +319,7 @@ static struct exynos_media_pipeline
*fimc_md_pipeline_create(
return NULL;
list_add_tail(&p->list, &fmd->pipelines);
+ async_domain_init_exclusive(&p->ep.async_domain);
p->ep.ops = &fimc_pipeline_ops;
return &p->ep;
diff --git a/include/media/exynos-fimc.h b/include/media/exynos-fimc.h
index aa44660..ed779de 100644
--- a/include/media/exynos-fimc.h
+++ b/include/media/exynos-fimc.h
@@ -12,6 +12,7 @@
#ifndef S5P_FIMC_H_
#define S5P_FIMC_H_
+#include
#include
#include
#include
@@ -146,6 +147,7 @@ struct exynos_video_entity {
struct exynos_media_pipeline {
struct media_pipeline mp;
const struct exynos_media_pipeline_ops *ops;
+ struct async_domain async_domain;
};
static inline struct exynos_video_entity *vdev_to_exynos_video_entity(
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 0/1] Libv4l: Add a plugin for the Exynos4 camera
This patch adds a plugin for the Exynos4 camera. I wanted to split
at least the parser part to the separate module but encountered
some problems with autotools configuration and therefore I'd like
to ask for an instruction on how to adjust the Makefile.am files
to achieve this.
I also think that the helper functions for discovering device topology
and setting the links are reusable and should be put to the separate
module. I'm wondering what would be the most suitable place.
The plugin was tested on linux-next-20130927 with patches for
exynos4-is that fix failing open when a sensor sub-device is not
linked. This patch series is being submitted in the separate
thread.
The plugin expects a configuration file:
/var/lib/libv4l/exynos4_capture_conf
Exemplary configuration file:
>>>>>>>>>>>>>>
link {
source_entity: s5p-mipi-csis.0
source_pad: 1
sink_entity: FIMC.0
sink_pad: 0
}
v4l2-controls {
Color Effects: S5C73M3
Saturation: S5C73M3
}
<<<<<<<<<<<<<<
With this settings the plugin can be tested on the exynos4412-trats2 board
using following gstreamer pipeline:
gst-launch-0.10 v4l2src device=/dev/video1 !
video/x-raw-rgb,width=960,height=720,format=\(fourcc\)RGBP ! ffmpegcolorspace !
fbdevsink
In order to avoid fbdevsink element failure the fix [1]
for exynos-drm driver is required.
ffmpegcolorspace element shouldn't be normally required but format
negotiation error is reported by gstreamer without it.
I am investigating the issue.
Thanks,
Jacek Anaszewski
[1] http://www.spinics.net/lists/dri-devel/msg66494.html
Jacek Anaszewski (1):
Add a libv4l plugin for Exynos4 camera
configure.ac |1 +
lib/Makefile.am|5 +-
lib/libv4l-exynos4-camera/Makefile.am |7 +
.../libv4l-devconfig-parser.h | 145 ++
lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c | 2486
5 files changed, 2642 insertions(+), 2 deletions(-)
create mode 100644 lib/libv4l-exynos4-camera/Makefile.am
create mode 100644 lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h
create mode 100644 lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] exynos4-is: Open shouldn't fail when sensor entity is not linked
In order to allow for automatic media device entities linking
from the level of libv4l plugin the open system call shouldn't
fail, as the libv4l plugins can begin their job not until it
succeeds.
This patch allows for leaving the pipeline not linked on
open and postpones verifying it to the moment when streamon
callback is called.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
---
drivers/media/platform/exynos4-is/media-dev.c | 45 ++---
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index c867c46..3732663 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -217,7 +217,7 @@ static int __fimc_pipeline_open(struct
exynos_media_pipeline *ep,
fimc_pipeline_prepare(p, me);
sd = p->subdevs[IDX_SENSOR];
- if (sd == NULL)
+ if (sd == NULL && !fmd->user_subdev_api)
return -EINVAL;
/* Disable PXLASYNC clock if this pipeline includes FIMC-IS */
@@ -277,10 +277,46 @@ static int __fimc_pipeline_s_stream(struct
exynos_media_pipeline *ep, bool on)
{ IDX_CSIS, IDX_FLITE, IDX_FIMC, IDX_SENSOR, IDX_IS_ISP },
};
struct fimc_pipeline *p = to_fimc_pipeline(ep);
- int i, ret = 0;
+ struct fimc_md *fmd =
entity_to_fimc_mdev(&p->subdevs[IDX_CSIS]->entity);
+ enum fimc_subdev_index sd_id;
+ int i = 0, ret = 0;
- if (p->subdevs[IDX_SENSOR] == NULL)
- return -ENODEV;
+ /*
+* Sensor might not be discovered upon device open
+* due to not linked pipeline. User space is expected to
+* link the pipeline prior calling VIDIOC_STREAMON ioctl,
+* when in user_subdev_api mode.
+*/
+ while (p->subdevs[IDX_SENSOR] == NULL) {
+ /*
+* Sensor must be already discovered if
+* we are in non user_subdev_api mode.
+*/
+ if (!fmd->user_subdev_api) {
+ return -ENODEV;
+ } else if (i++ == 0) {
+ /* Determine which entity is last in the pipeline */
+ if (p->subdevs[IDX_FIMC])
+ sd_id = IDX_FIMC;
+ else if (p->subdevs[IDX_IS_ISP])
+ sd_id = IDX_IS_ISP;
+ else if (p->subdevs[IDX_FLITE])
+ sd_id = IDX_FLITE;
+ else
+ return -ENODEV;
+
+ ret = __fimc_pipeline_open(ep,
+ &p->subdevs[sd_id]->entity,
+ true);
+ if (ret < 0)
+ return ret;
+
+ if (p->subdevs[IDX_SENSOR] == NULL)
+ return -ENODEV;
+ } else {
+ return -ENODEV;
+ }
+ }
/* Wait until all devices in the chain are powered up */
async_synchronize_full_domain(&ep->async_domain);
@@ -293,6 +329,7 @@ static int __fimc_pipeline_s_stream(struct
exynos_media_pipeline *ep, bool on)
if (ret < 0 && ret != -ENOIOCTLCMD && ret != -ENODEV)
goto error;
}
+
return 0;
error:
for (; i >= 0; i--) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] async: Add async_domain_init_exclusive() helper
From: Sylwester Nawrocki
Add a helper to allow initialization of struct async_domain at runtime.
Signed-off-by: Sylwester Nawrocki
Acked-by: Kyungmin Park
---
include/linux/async.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/async.h b/include/linux/async.h
index 6b0226b..807e40b 100644
--- a/include/linux/async.h
+++ b/include/linux/async.h
@@ -37,6 +37,12 @@ struct async_domain {
struct async_domain _name = { .pending = LIST_HEAD_INIT(_name.pending),
\
.registered = 0 }
+static inline void async_domain_init_exclusive(struct async_domain *domain)
+{
+ INIT_LIST_HEAD(&domain->pending);
+ domain->registered = 0;
+}
+
extern async_cookie_t async_schedule(async_func_t func, void *data);
extern async_cookie_t async_schedule_domain(async_func_t func, void *data,
struct async_domain *domain);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/1] Add a libv4l plugin for Exynos4 camera
Hi Hans,
On 10/08/2014 02:42 PM, Hans de Goede wrote:
Hi,
On 10/08/2014 10:46 AM, Jacek Anaszewski wrote:
The plugin provides support for the media device on Exynos4 SoC.
Added is also a media device configuration file parser.
The media configuration file is used for conveying information
about media device links that need to be established as well
as V4L2 user control ioctls redirection to a particular
sub-device.
The plugin performs single plane <-> multi plane API conversion,
video pipeline linking and takes care of automatic data format
negotiation for the whole pipeline, after intercepting
VIDIOC_S_FMT or VIDIOC_TRY_FMT ioctls.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
---
configure.ac |1 +
lib/Makefile.am|5 +-
lib/libv4l-exynos4-camera/Makefile.am |7 +
.../libv4l-devconfig-parser.h | 145 ++
lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c | 2486
5 files changed, 2642 insertions(+), 2 deletions(-)
create mode 100644 lib/libv4l-exynos4-camera/Makefile.am
create mode 100644 lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h
create mode 100644 lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
Ugh, that is a big plugin. Can you please split out the parser stuff
into a separate file ?
Yes, I tried to split it, but spent so much time fighting with
autotools, that I decided to submit it in this form and ask
more experienced v4l-utils build system maintainers for the advice.
I mentioned this in the cover letter.
diff --git a/configure.ac b/configure.ac
index c9b0524..ae653b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,7 @@ AC_CONFIG_FILES([Makefile
lib/libdvbv5/Makefile
lib/libv4l2rds/Makefile
lib/libv4l-mplane/Makefile
+ lib/libv4l-exynos4-camera/Makefile
utils/Makefile
utils/libv4l2util/Makefile
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 3a0e19c..29455ab 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -3,9 +3,10 @@ SUBDIRS = \
libv4l2 \
libv4l1 \
libv4l2rds \
- libv4l-mplane
+ libv4l-mplane \
+ libv4l-exynos4-camera
if LINUX_OS
SUBDIRS += \
libdvbv5
-endif
\ No newline at end of file
+endif
diff --git a/lib/libv4l-exynos4-camera/Makefile.am
b/lib/libv4l-exynos4-camera/Makefile.am
new file mode 100644
index 000..3552ec8
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/Makefile.am
@@ -0,0 +1,7 @@
+if WITH_V4L_PLUGINS
+libv4l2plugin_LTLIBRARIES = libv4l-exynos4-camera.la
+endif
+
+libv4l_exynos4_camera_la_SOURCES = libv4l-exynos4-camera.c
+libv4l_exynos4_camera_la_CPPFLAGS = -fvisibility=hidden -std=gnu99
+libv4l_exynos4_camera_la_LDFLAGS = -avoid-version -module -shared
-export-dynamic -lpthread
diff --git a/lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h
b/lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h
new file mode 100644
index 000..c56a469
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h
@@ -0,0 +1,145 @@
+/*
+ * Parser of media device configuration file.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Jacek Anaszewski
+ *
+ * The configuration file has to comply with following format:
+ *
+ * Link description entry format:
+ *
+ * link {
+ * source_entity:
+ * source_pad:
+ * sink_entity:
+ * sink_pad:
+ * }
+ *
+ * The V4L2 control group format:
+ *
+ * v4l2-controls {
+ * :
+ * :
+ * ...
+ * :
+ * }
+ *
+ * Example:
+ *
+ * link {
+ * source_entity: s5p-mipi-csis.0
+ * source_pad: 1
+ * sink_entity: FIMC.0
+ * sink_pad: 0
+ * }
+ *
+ * v4l2-controls {
+ * Color Effects: S5C73M3
+ * Saturation: S5C73M3
+ * }
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ */
+
+#ifndef LIBV4L_DEVCONFIG_PARSER_H
+ #define LIBV4L_DEVCONFIG_PARSER_H
+
+#include
+
+#ifdef DEBUG
+#define V4L2_DEVCFG_PARSER_DBG(format, ARG...)\
+ printf("[%s:%d] [%s] " format " \n", __FILE__, __LINE__, __func__,
##ARG)
+#else
+#define V4L2_DEVCFG_PARSER_DBG(format, ARG...)
+#endif
+
+#define V4L2_DEVCFG_PARSER_ERR(format, ARG...)\
+ fprintf(stderr, "Libv4l device config parser: "format "\n", ##ARG)
+
+#define V4L2_DEVCFG_PARSER_LOG(format, ARG...)\
+ fprintf(stdout, &qu
Re: [PATCH/RFC 1/1] Add a libv4l plugin for Exynos4 camera
On 10/08/2014 05:49 PM, Antonio Ospite wrote: On Wed, 08 Oct 2014 15:22:43 +0200 Jacek Anaszewski wrote: Hi Hans, On 10/08/2014 02:42 PM, Hans de Goede wrote: Hi, On 10/08/2014 10:46 AM, Jacek Anaszewski wrote: The plugin provides support for the media device on Exynos4 SoC. Added is also a media device configuration file parser. The media configuration file is used for conveying information about media device links that need to be established as well as V4L2 user control ioctls redirection to a particular sub-device. The plugin performs single plane <-> multi plane API conversion, video pipeline linking and takes care of automatic data format negotiation for the whole pipeline, after intercepting VIDIOC_S_FMT or VIDIOC_TRY_FMT ioctls. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Mauro Carvalho Chehab Cc: Hans Verkuil --- configure.ac |1 + lib/Makefile.am|5 +- lib/libv4l-exynos4-camera/Makefile.am |7 + .../libv4l-devconfig-parser.h | 145 ++ lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c | 2486 5 files changed, 2642 insertions(+), 2 deletions(-) create mode 100644 lib/libv4l-exynos4-camera/Makefile.am create mode 100644 lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h create mode 100644 lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c Ugh, that is a big plugin. Can you please split out the parser stuff into a separate file ? Yes, I tried to split it, but spent so much time fighting with autotools, that I decided to submit it in this form and ask more experienced v4l-utils build system maintainers for the advice. I mentioned this in the cover letter. What autotools issue in particular? The following change followed by "automake && ./configure" should be enough to add a new file libv4l-devconfig-parser.c: The same modifications produced libv4l-exynos4-camera.so without parser symbols, when I applied them previously, but when I tried them again everything is ok. Probably I wasn't doing proper cleanup. Thanks for the hints. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/1] Add a libv4l plugin for Exynos4 camera
Hi, On 10/09/2014 10:20 AM, Hans de Goede wrote: Hi, On 10/08/2014 03:22 PM, Jacek Anaszewski wrote: Hi Hans, On 10/08/2014 02:42 PM, Hans de Goede wrote: +} + +/* refresh device topology data after linking */ +release_entities(mdev); + +ret = get_device_topology(mdev); + +/* close media device fd as it won't be longer required */ +close(mdev->media_fd); + +if (ret < 0) +goto err_get_dev_topology; + +/* discover a pipeline for the capture device */ +ret = discover_pipeline_by_fd(mdev, fd); +if (ret < 0) +goto err_discover_pipeline; There does not seem to be any code here to ensure that this plugin does not bind to non exonys4 fimc devices. Please fix that. There is. Please look above at the "if (!capture_entity(media_entity_name))" condition above. I already checked that, that just checks for the string "capture", which is way too generic, please add a more narrow guard. While making cleanup I mistakenly removed checking for the driver name after QUERYCAP in the beginning of plugin_init. Will fix it in the next version. Regards, Jacek -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
