[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 j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org --- .../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 j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: devicet...@vger.kernel.org
---
.../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 j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
---
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 j.anaszew...@samsung.com
+ *
+ * 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 linux/delay.h
+#include linux/slab.h
+#include linux/platform_device.h
+#include linux/module.h
+#include linux/i2c.h
+#include linux/led-class-flash.h
+#include linux/leds.h
+#include linux/mutex.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/of.h
+#include media/v4l2-flash.h
+#include linux/workqueue.h
+
+#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);
+ }
+
+
[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 j.anaszew...@samsung.com
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Lee Jones lee.jo...@linaro.org
Cc: SangYoung Son hello@smasung.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
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 j.anaszew...@samsung.com
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Lee Jones lee.jo...@linaro.org
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: SangYoung Son hello@smasung.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
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 j.anaszew...@samsung.com
+ * Andrzej Hajda a.ha...@samsung.com
+ *
+ * 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 asm/div64.h
+#include linux/led-class-flash.h
+#include linux/mfd/max77693.h
+#include linux/mfd/max77693-private.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/slab.h
+#include linux/workqueue.h
+#include media/v4l2-flash.h
+
+#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
[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 j.anaszew...@samsung.com
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Lee Jones lee.jo...@linaro.org
Cc: SangYoung Son hello@smasung.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: devicet...@vger.kernel.org
---
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 j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org --- .../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 j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
---
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 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
[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 j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Hans Verkuil hans.verk...@cisco.com
---
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 media/v4l2-device.h
#include media/v4l2-subdev.h
-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, notifier-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 j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
---
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./para
after strobe during which another strobe will not be
possible. This is a read-only control./entry
/row
+ row
+ entry
spanname=idconstantV4L2_CID_FLASH_SYNC_STROBE/constant/entry
+ entryboolean/entry
+ /row
+ row
+ entry spanname=descrSynchronized strobe: whether the flash
+ should be strobed synchronously with the other ones controlled
+ by the same device/entry
+ /row
rowentry/entry/row
/tbody
/tgroup
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 j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
---
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 j.anaszew...@samsung.com
+ *
+ * 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 linux/led-class-flash.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/slab.h
+#include linux/types.h
+#include media/v4l2-flash.h
+
+#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);
+ }
+
[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 j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net --- 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 media/v4l2-flash.h). + +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 j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net --- 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 j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
---
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 j.anaszew...@samsung.com
+ *
+ * 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 linux/device.h
+#include linux/init.h
+#include linux/led-class-flash.h
+#include linux/leds.h
+#include linux/module.h
+#include linux/slab.h
+#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,
+
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
[PATCH 0/4] media: ov2640: add device tree support
This patch series add device tree support for ov2640. And also add the document for the devicetree properties. Josh Wu (4): media: ov2640: add async probe function media: ov2640: add primary dt support media: ov2640: add a master clock for sensor media: ov2640: dt: add the device tree binding document .../devicetree/bindings/media/i2c/ov2640.txt | 43 ++ drivers/media/i2c/soc_camera/ov2640.c | 151 ++--- 2 files changed, 178 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt -- 1.9.1 -- 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 0/4] media: ov2640: add device tree support
This patch series add device tree support for ov2640. And also add the document for the devicetree properties. Josh Wu (4): media: ov2640: add async probe function media: ov2640: add primary dt support media: ov2640: add a master clock for sensor media: ov2640: dt: add the device tree binding document .../devicetree/bindings/media/i2c/ov2640.txt | 43 ++ drivers/media/i2c/soc_camera/ov2640.c | 151 ++--- 2 files changed, 178 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt -- 1.9.1 -- 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/4] media: ov2640: add async probe function
To support async probe for ov2640, we need remove the code to get 'mclk'
in ov2640_probe() function. oterwise, if soc_camera host is not probed
in the moment, then we will fail to get 'mclk' and quit the ov2640_probe()
function.
So in this patch, we move such 'mclk' getting code to ov2640_s_power()
function. That make ov2640 survive, as we can pass a NULL (priv-clk) to
soc_camera_set_power() function.
And if soc_camera host is probed, the when ov2640_s_power() is called,
then we can get the 'mclk' and that make us enable/disable soc_camera
host's clock as well.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/i2c/soc_camera/ov2640.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 1fdce2f..9ee910d 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -739,6 +739,15 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov2640_priv *priv = to_ov2640(client);
+ struct v4l2_clk *clk;
+
+ if (!priv-clk) {
+ clk = v4l2_clk_get(client-dev, mclk);
+ if (IS_ERR(clk))
+ dev_warn(client-dev, Cannot get the mclk. maybe
soc-camera host is not probed yet.\n);
+ else
+ priv-clk = clk;
+ }
return soc_camera_set_power(client-dev, ssdd, priv-clk, on);
}
@@ -1078,21 +1087,21 @@ static int ov2640_probe(struct i2c_client *client,
if (priv-hdl.error)
return priv-hdl.error;
- priv-clk = v4l2_clk_get(client-dev, mclk);
- if (IS_ERR(priv-clk)) {
- ret = PTR_ERR(priv-clk);
- goto eclkget;
- }
-
ret = ov2640_video_probe(client);
if (ret) {
- v4l2_clk_put(priv-clk);
-eclkget:
- v4l2_ctrl_handler_free(priv-hdl);
+ goto evideoprobe;
} else {
dev_info(adapter-dev, OV2640 Probed\n);
}
+ ret = v4l2_async_register_subdev(priv-subdev);
+ if (ret 0)
+ goto evideoprobe;
+
+ return 0;
+
+evideoprobe:
+ v4l2_ctrl_handler_free(priv-hdl);
return ret;
}
@@ -1100,7 +1109,9 @@ static int ov2640_remove(struct i2c_client *client)
{
struct ov2640_priv *priv = to_ov2640(client);
- v4l2_clk_put(priv-clk);
+ v4l2_async_unregister_subdev(priv-subdev);
+ if (priv-clk)
+ v4l2_clk_put(priv-clk);
v4l2_device_unregister_subdev(priv-subdev);
v4l2_ctrl_handler_free(priv-hdl);
return 0;
--
1.9.1
--
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/4] media: ov2640: add a master clock for sensor
The master clock can be optional. It's a common clock framework clock.
It can make sensor output a pixel clock to the camera interface.
If you just use a external oscillator clock as the master clock, then,
just don't need set 'mck' in dt node.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/i2c/soc_camera/ov2640.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 6506126..06c2aa9 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -13,6 +13,7 @@
* published by the Free Software Foundation.
*/
+#include linux/clk.h
#include linux/init.h
#include linux/module.h
#include linux/i2c.h
@@ -31,6 +32,8 @@
#define VAL_SET(x, mask, rshift, lshift) \
x) rshift) mask) lshift)
+#define DEFAULT_MASTER_CLK_FREQ2500
+
/*
* DSP registers
* register offset for BANK_SEL == BANK_SEL_DSP
@@ -284,6 +287,7 @@ struct ov2640_priv {
struct v4l2_ctrl_handlerhdl;
u32 cfmt_code;
struct v4l2_clk *clk;
+ struct clk *master_clk;
const struct ov2640_win_size*win;
struct soc_camera_subdev_desc ssdd_dt;
@@ -746,6 +750,7 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov2640_priv *priv = to_ov2640(client);
struct v4l2_clk *clk;
+ int ret = 0;
if (!priv-clk) {
clk = v4l2_clk_get(client-dev, mclk);
@@ -755,6 +760,16 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
priv-clk = clk;
}
+ if (!IS_ERR(priv-master_clk)) {
+ if (on)
+ ret = clk_prepare_enable(priv-master_clk);
+ else
+ clk_disable_unprepare(priv-master_clk);
+
+ if (ret)
+ return ret;
+ }
+
return soc_camera_set_power(client-dev, ssdd, priv-clk, on);
}
@@ -1153,6 +1168,16 @@ static int ov2640_probe(struct i2c_client *client,
}
}
+ priv-master_clk = devm_clk_get(client-dev, mck);
+ if (!IS_ERR(priv-master_clk)) {
+ /* Set ISI_MCK's frequency, it should be faster than pixel
+* clock.
+*/
+ ret = clk_set_rate(priv-master_clk, DEFAULT_MASTER_CLK_FREQ);
+ if (ret 0)
+ return ret;
+ }
+
v4l2_i2c_subdev_init(priv-subdev, client, ov2640_subdev_ops);
v4l2_ctrl_handler_init(priv-hdl, 2);
v4l2_ctrl_new_std(priv-hdl, ov2640_ctrl_ops,
--
1.9.1
--
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 4/4] media: ov2640: dt: add the device tree binding document
Add the document for ov2640 dt.
Cc: devicet...@vger.kernel.org
Signed-off-by: Josh Wu josh...@atmel.com
---
.../devicetree/bindings/media/i2c/ov2640.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2640.txt
b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
new file mode 100644
index 000..adec147
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
@@ -0,0 +1,43 @@
+* Omnivision ov2640 CMOS sensor
+
+The Omnivision OV2640 sensor support multiple resolutions output, such as
+CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
+output format.
+
+Required Properties :
+- compatible : Must be omnivision,ov2640
+- reset-gpio : reset pin
+- power-down-gpio : power down pin
+
+Optional Properties:
+- clocks : reference master clock, if using external fixed clock, you
+no need to have such property.
+- clock-names : Must be mck, it means the master clock for ov2640.
+
+For further reading of port node refer Documentation/devicetree/bindings/media/
+video-interfaces.txt.
+
+Example:
+
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = omnivision,ov2640;
+ reg = 0x30;
+
+ ... ...
+
+ reset-gpio = pioE 24 GPIO_ACTIVE_HIGH;
+ power-down-gpio = pioE 29 GPIO_ACTIVE_HIGH;
+
+ /* use pck1 for the master clock of ov2640 */
+ clocks = pck1;
+ clock-names = mck;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = isi_0;
+ bus-width = 8;
+ };
+ };
+ };
+ };
--
1.9.1
--
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 2/4] media: ov2640: add primary dt support
Add device tree support for ov2640.
Cc: devicet...@vger.kernel.org
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/i2c/soc_camera/ov2640.c | 95 ---
1 file changed, 89 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 9ee910d..6506126 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -18,6 +18,8 @@
#include linux/i2c.h
#include linux/slab.h
#include linux/delay.h
+#include linux/gpio.h
+#include linux/of_gpio.h
#include linux/v4l2-mediabus.h
#include linux/videodev2.h
@@ -283,6 +285,10 @@ struct ov2640_priv {
u32 cfmt_code;
struct v4l2_clk *clk;
const struct ov2640_win_size*win;
+
+ struct soc_camera_subdev_desc ssdd_dt;
+ int reset_pin;
+ int pwr_down_pin;
};
/*
@@ -1047,6 +1053,70 @@ static struct v4l2_subdev_ops ov2640_subdev_ops = {
.video = ov2640_subdev_video_ops,
};
+/* OF probe functions */
+static int ov2640_hw_power(struct device *dev, int on)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ov2640_priv *priv = to_ov2640(client);
+
+ dev_dbg(client-dev, %s: %s the camera\n,
+ __func__, on ? ENABLE : DISABLE);
+
+ /* enable or disable the camera */
+ gpio_direction_output(priv-pwr_down_pin, !on);
+
+ return 0;
+}
+
+static int ov2640_hw_reset(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ov2640_priv *priv = to_ov2640(client);
+
+ /* If enabled, give a reset impulse */
+ gpio_direction_output(priv-reset_pin, 0);
+ msleep(20);
+ gpio_direction_output(priv-reset_pin, 1);
+ msleep(100);
+
+ return 0;
+}
+
+static int ov2640_probe_dt(struct i2c_client *client,
+ struct ov2640_priv *priv)
+{
+ struct device_node *np = client-dev.of_node;
+ int ret;
+
+ priv-reset_pin = of_get_named_gpio(np, reset-gpio, 0);
+ priv-pwr_down_pin = of_get_named_gpio(np, power-down-gpio, 0);
+ if (!gpio_is_valid(priv-reset_pin) ||
+ !gpio_is_valid(priv-pwr_down_pin))
+ return -EINVAL;
+
+ ret = devm_gpio_request(client-dev, priv-pwr_down_pin,
+ power-down-pin);
+ if (ret 0) {
+ dev_err(client-dev, request gpio pin %d failed\n,
+ priv-pwr_down_pin);
+ return ret;
+ }
+
+ ret = devm_gpio_request(client-dev, priv-reset_pin, reset_pin);
+ if (ret 0) {
+ dev_err(client-dev, request gpio pin %d failed\n,
+ priv-reset_pin);
+ return ret;
+ }
+
+ /* Initialize the soc_camera_subdev_desc */
+ priv-ssdd_dt.power = ov2640_hw_power;
+ priv-ssdd_dt.reset = ov2640_hw_reset;
+ client-dev.platform_data = priv-ssdd_dt;
+
+ return 0;
+}
+
/*
* i2c_driver functions
*/
@@ -1058,12 +1128,6 @@ static int ov2640_probe(struct i2c_client *client,
struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
int ret;
- if (!ssdd) {
- dev_err(adapter-dev,
- OV2640: Missing platform_data for driver\n);
- return -EINVAL;
- }
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
dev_err(adapter-dev,
OV2640: I2C-Adapter doesn't support SMBUS\n);
@@ -1077,6 +1141,18 @@ static int ov2640_probe(struct i2c_client *client,
return -ENOMEM;
}
+ if (!ssdd) {
+ if (client-dev.of_node) {
+ ret = ov2640_probe_dt(client, priv);
+ if (ret)
+ return ret;
+ } else {
+ dev_err(client-dev,
+ Missing platform_data for driver\n);
+ return -EINVAL;
+ }
+ }
+
v4l2_i2c_subdev_init(priv-subdev, client, ov2640_subdev_ops);
v4l2_ctrl_handler_init(priv-hdl, 2);
v4l2_ctrl_new_std(priv-hdl, ov2640_ctrl_ops,
@@ -1123,9 +1199,16 @@ static const struct i2c_device_id ov2640_id[] = {
};
MODULE_DEVICE_TABLE(i2c, ov2640_id);
+static const struct of_device_id ov2640_of_match[] = {
+ {.compatible = omnivision,ov2640, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ov2640_of_match);
+
static struct i2c_driver ov2640_i2c_driver = {
.driver = {
.name = ov2640,
+ .of_match_table = of_match_ptr(ov2640_of_match),
},
.probe= ov2640_probe,
.remove = ov2640_remove,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo
Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property
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 j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org --- .../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. 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. Mark. 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 devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.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
[PATCH] em28xx: checkpatch cleanup: whitespaces/new lines cleanups
This patch is basically produced while testing a tool that
Joe Perches sent upstream sometime ago:
https://lkml.org/lkml/2014/7/11/794
I used it with those arguments:
scripts/reformat_with_checkpatch.sh
drivers/media/usb/em28xx/em28xx*.[ch]
It actually produced 24 patches, with is too much, and showed
interesting things: gcc produced different codes on most of the
patches, even with just linespace changes. The total code data
remained the same on all cases I checked though.
Anyway, provided that we fold the resulting patches, this tool
seems useful.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/usb/em28xx/em28xx-audio.c
b/drivers/media/usb/em28xx/em28xx-audio.c
index 957c7ae30efe..44ae1e0661e6 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -56,7 +56,7 @@ MODULE_PARM_DESC(debug, activates debug info);
#define dprintk(fmt, arg...) do { \
if (debug) \
printk(KERN_INFO em28xx-audio %s: fmt, \
- __func__, ##arg); \
+ __func__, ##arg); \
} while (0)
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
@@ -232,7 +232,6 @@ static struct snd_pcm_hardware snd_em28xx_hw_capture = {
.channels_max = 2,
.buffer_bytes_max = 62720 * 8, /* just about the value in usbaudio.c */
-
/*
* The period is 12.288 bytes. Allow a 10% of variation along its
* value, in order to avoid overruns/underruns due to some clock
@@ -361,7 +360,7 @@ static int snd_em28xx_hw_capture_params(struct
snd_pcm_substream *substream,
dprintk(Setting capture parameters\n);
ret = snd_pcm_alloc_vmalloc_buffer(substream,
- params_buffer_bytes(hw_params));
+ params_buffer_bytes(hw_params));
if (ret 0)
return ret;
#if 0
@@ -478,7 +477,7 @@ static struct page *snd_pcm_get_vmalloc_page(struct
snd_pcm_substream *subs,
* AC97 volume control support
*/
static int em28xx_vol_info(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_info *info)
+ struct snd_ctl_elem_info *info)
{
struct em28xx *dev = snd_kcontrol_chip(kcontrol);
@@ -494,7 +493,7 @@ static int em28xx_vol_info(struct snd_kcontrol *kcontrol,
}
static int em28xx_vol_put(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *value)
+ struct snd_ctl_elem_value *value)
{
struct em28xx *dev = snd_kcontrol_chip(kcontrol);
struct snd_pcm_substream *substream = dev-adev.capture_pcm_substream;
@@ -534,7 +533,7 @@ err:
}
static int em28xx_vol_get(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *value)
+ struct snd_ctl_elem_value *value)
{
struct em28xx *dev = snd_kcontrol_chip(kcontrol);
struct snd_pcm_substream *substream = dev-adev.capture_pcm_substream;
@@ -655,7 +654,7 @@ static int em28xx_cvol_new(struct snd_card *card, struct
em28xx *dev,
struct snd_kcontrol *kctl;
struct snd_kcontrol_new tmp;
- memset (tmp, 0, sizeof(tmp));
+ memset(tmp, 0, sizeof(tmp));
tmp.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
tmp.private_value = id,
tmp.name = ctl_name,
@@ -672,7 +671,7 @@ static int em28xx_cvol_new(struct snd_card *card, struct
em28xx *dev,
dprintk(Added control %s for ac97 volume control 0x%04x\n,
ctl_name, id);
- memset (tmp, 0, sizeof(tmp));
+ memset(tmp, 0, sizeof(tmp));
tmp.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
tmp.private_value = id,
tmp.name = ctl_name,
@@ -731,7 +730,7 @@ static void em28xx_audio_free_urb(struct em28xx *dev)
/* high bandwidth multiplier, as encoded in highspeed endpoint descriptors */
static int em28xx_audio_ep_packet_size(struct usb_device *udev,
- struct usb_endpoint_descriptor *e)
+ struct usb_endpoint_descriptor *e)
{
int size = le16_to_cpu(e-wMaxPacketSize);
@@ -781,7 +780,7 @@ static int em28xx_audio_urb_init(struct em28xx *dev)
interval = 1 (ep-bInterval - 1);
em28xx_info(Endpoint 0x%02x %s on intf %d alt %d interval = %d, size
%d\n,
-EM28XX_EP_AUDIO, usb_speed_string(dev-udev-speed),
+ EM28XX_EP_AUDIO, usb_speed_string(dev-udev-speed),
dev-ifnum, alt,
interval,
ep_size);
diff --git a/drivers/media/usb/em28xx/em28xx-camera.c
b/drivers/media/usb/em28xx/em28xx-camera.c
index 38cf6c8491a4..7be661f73930 100644
---
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 j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org --- .../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
Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property
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 j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org --- .../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. 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? Using phandles is much better for the binding. I appreciate that this may require more code, but IMO it's worth that for the safety and uniformity given by the use of phandles for referring to nodes. 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. Thanks! Mark. -- 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 j.anaszew...@samsung.com
---
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 j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
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 j.anaszew...@samsung.com
+ *
+ * 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 config.h
+#include errno.h
+#include stdint.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+
+#include sys/syscall.h
+#include linux/types.h
+
+#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 3/9] clk: sunxi: Add prcm mod0 clock driver
Hi,
On 11/27/2014 08:05 PM, Maxime Ripard wrote:
Hi,
On Thu, Nov 27, 2014 at 11:10:51AM +0100, Hans de Goede wrote:
Hi,
On 11/27/2014 10:28 AM, Chen-Yu Tsai wrote:
Hi,
On Thu, Nov 27, 2014 at 4:41 PM, Hans de Goede hdego...@redhat.com wrote:
snip
I notice that you've not responded to my proposal to simple make the clock
node a child node of the clocks node in the dt, that should work nicely, and
avoid the need for any kernel level changes to support it, I'm beginning to
think that that is probably the best solution.
Would that not cause an overlap of the io regions, and cause one of them
to fail? AFAIK the OF subsystem doesn't like overlapping resources.
No the overlap check is done by the platform dev resource code, and
of_clk_declare
does not use that. So the overlap would be there, but not an issue (in theory
I did not test this).
An overlap is always an issue.
Thinking more about this, I believe that using the MFD framework for the prcm
seems
like a mistake to me. It gains us nothing, since we have no irq to de-multiplex
or
some such. We're not using MFD for the CMU, why use it for CMU2 (which the prcm
effectively is) ?
Because the PRCM is much more than that. It also handles the power
domains for example.
Ok, so thinking more about this, I'm still convinced that the MFD framework is
only
getting in the way here. But I can see having things represented in devicetree
properly, with the clocks, etc. as child nodes of the prcm being something which
we want.
So since all we are using the MFD for is to instantiate platform devices under
the prcm
nodes, and assign an io resource for the regs to them, why not simply make the
prcm node
itself a simple-bus.
This does everything the MFD prcm driver currently does, without actually
needing a specific
kernel driver, and as added bonus this will move the definition of the mfd
function reg offsets
out of the kernel and into the devicetree where they belong in the first place.
Please see the attached patches, I've tested this on sun6i, if we go this route
we should
make the same change on sun8i (I can make the change, but not test it).
Regards,
Hans
From 6756574293a1f291a8dcc29427b27f32f83acb2d Mon Sep 17 00:00:00 2001
From: Hans de Goede hdego...@redhat.com
Date: Fri, 28 Nov 2014 13:48:58 +0100
Subject: [PATCH v2 1/2] ARM: dts: sun6i: Change prcm node into a simple-bus
The prcm node's purpose is to group the various prcm sub-devices together,
it does not need any special handling beyond that, there is no need to
handle shared resources like a shared (multiplexed) interrupt or a shared
i2c bus.
As such there really is no need to have a separate compatible for it, using
simple-bus for it works fine. This also allows us to specify the register
offsets of the various child-devices directly into the dts, rather then having
to specify them in the OS implementation, putting the register offsets where
the belong.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 29e6438..4b8541f 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -846,11 +846,15 @@
};
prcm@01f01400 {
- compatible = allwinner,sun6i-a31-prcm;
+ compatible = simple-bus;
reg = 0x01f01400 0x200;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
ar100: ar100_clk {
compatible = allwinner,sun6i-a31-ar100-clk;
+reg = 0x01f01400 0x4;
#clock-cells = 0;
clocks = osc32k, osc24M, pll6, pll6;
clock-output-names = ar100;
@@ -867,6 +871,7 @@
apb0: apb0_clk {
compatible = allwinner,sun6i-a31-apb0-clk;
+reg = 0x01f0140c 0x4;
#clock-cells = 0;
clocks = ahb0;
clock-output-names = apb0;
@@ -874,6 +879,7 @@
apb0_gates: apb0_gates_clk {
compatible = allwinner,sun6i-a31-apb0-gates-clk;
+reg = 0x01f01428 0x4;
#clock-cells = 1;
clocks = apb0;
clock-output-names = apb0_pio, apb0_ir,
@@ -884,6 +890,7 @@
apb0_rst: apb0_rst {
compatible = allwinner,sun6i-a31-clock-reset;
+reg = 0x01f014b0 0x4;
#reset-cells = 1;
};
};
--
2.1.0
From a152b0405d446c748fef146915736e4a8fc548b1 Mon Sep 17 00:00:00 2001
From: Hans de Goede hdego...@redhat.com
Date: Fri, 28 Nov 2014 13:54:14 +0100
Subject: [PATCH v2 2/2] ARM: dts: sun6i: Add ir_clk node
Add an ir_clk sub-node to the prcm node.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 4b8541f..92a1c95 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -888,6 +888,14 @@
apb0_i2c;
};
+ ir_clk: ir_clk {
+reg = 0x01f01454 0x4;
+#clock-cells = 0;
+compatible =
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 j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org --- .../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 08/14] DT: Add documentation for exynos4-is 'flashes' property
On Fri, Nov 28, 2014 at 02:11:04PM +, Jacek Anaszewski wrote: 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 j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org --- .../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. On Linux, yes, but that's an implementation detail, not a property of the binding· Mark. -- 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 0/3] hdmi: add unpack and logging functions
This patch series adds new HDMI 2.0/CEA-861-F defines to hdmi.h and adds unpacking and logging functions to hdmi.c. It also uses those in the V4L2 adv7842 driver (and they will be used in other HDMI drivers once this functionality is merged). Patches 2 and 3 have been posted before by Martin Bugge. It stalled, but I am taking over from Martin to try and get this is. I want to use this in a bunch of v4l2 drivers, so I would really like to see this merged. Please let me know if there are things that need to be addressed in these patches before they can be merged. Regards, Hans -- 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] hdmi: add new HDMI 2.0 defines
From: Hans Verkuil hans.verk...@cisco.com
Add new Video InfoFrame colorspace information introduced in HDMI 2.0
and new Audio Coding Extension Types, also from HDMI 2.0.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/linux/hdmi.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 11c0182..38fd2a0 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -37,6 +37,8 @@ enum hdmi_colorspace {
HDMI_COLORSPACE_RGB,
HDMI_COLORSPACE_YUV422,
HDMI_COLORSPACE_YUV444,
+ HDMI_COLORSPACE_YUV420,
+ HDMI_COLORSPACE_IDO_DEFINED = 7,
};
enum hdmi_scan_mode {
@@ -77,6 +79,10 @@ enum hdmi_extended_colorimetry {
HDMI_EXTENDED_COLORIMETRY_S_YCC_601,
HDMI_EXTENDED_COLORIMETRY_ADOBE_YCC_601,
HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB,
+
+ /* The following EC values are only defined in CEA-861-F. */
+ HDMI_EXTENDED_COLORIMETRY_BT2020_CONST_LUM,
+ HDMI_EXTENDED_COLORIMETRY_BT2020,
};
enum hdmi_quantization_range {
@@ -201,9 +207,23 @@ enum hdmi_audio_sample_frequency {
enum hdmi_audio_coding_type_ext {
HDMI_AUDIO_CODING_TYPE_EXT_STREAM,
+
+ /*
+* The next three CXT values are defined in CEA-861-E only.
+* They do not exist in older versions, and in CEA-861-F they are
+* defined as 'Not in use'.
+*/
HDMI_AUDIO_CODING_TYPE_EXT_HE_AAC,
HDMI_AUDIO_CODING_TYPE_EXT_HE_AAC_V2,
HDMI_AUDIO_CODING_TYPE_EXT_MPEG_SURROUND,
+
+ /* The following CXT values are only defined in CEA-861-F. */
+ HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_HE_AAC,
+ HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_HE_AAC_V2,
+ HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_AAC_LC,
+ HDMI_AUDIO_CODING_TYPE_EXT_DRA,
+ HDMI_AUDIO_CODING_TYPE_EXT_MPEG_HE_AAC_SURROUND,
+ HDMI_AUDIO_CODING_TYPE_EXT_MPEG_AAC_LC_SURROUND = 10,
};
struct hdmi_audio_infoframe {
--
2.1.3
--
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 2/3] hdmi: added unpack and logging functions for InfoFrames
From: Martin Bugge marbu...@cisco.com
When receiving video it is very useful to be able to unpack the InfoFrames.
Logging is useful as well, both for transmitters and receivers.
Especially when implementing the VIDIOC_LOG_STATUS ioctl (supported by many
V4L2 drivers) for a receiver it is important to be able to easily log what
the InfoFrame contains. This greatly simplifies debugging.
Signed-off-by: Martin Bugge marbu...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/video/hdmi.c | 622 ++-
include/linux/hdmi.h | 3 +
2 files changed, 618 insertions(+), 7 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 9e758a8..9f0f554 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -27,10 +27,10 @@
#include linux/export.h
#include linux/hdmi.h
#include linux/string.h
+#include linux/device.h
-static void hdmi_infoframe_checksum(void *buffer, size_t size)
+static u8 hdmi_infoframe_calc_checksum(u8 *ptr, size_t size)
{
- u8 *ptr = buffer;
u8 csum = 0;
size_t i;
@@ -38,7 +38,14 @@ static void hdmi_infoframe_checksum(void *buffer, size_t
size)
for (i = 0; i size; i++)
csum += ptr[i];
- ptr[3] = 256 - csum;
+ return 256 - csum;
+}
+
+static void hdmi_infoframe_set_checksum(void *buffer, size_t size)
+{
+ u8 *ptr = buffer;
+ /* update checksum */
+ ptr[3] = hdmi_infoframe_calc_checksum(buffer, size);
}
/**
@@ -136,7 +143,7 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe
*frame, void *buffer,
ptr[11] = frame-right_bar 0xff;
ptr[12] = (frame-right_bar 8) 0xff;
- hdmi_infoframe_checksum(buffer, length);
+ hdmi_infoframe_set_checksum(buffer, length);
return length;
}
@@ -206,7 +213,7 @@ ssize_t hdmi_spd_infoframe_pack(struct hdmi_spd_infoframe
*frame, void *buffer,
ptr[24] = frame-sdi;
- hdmi_infoframe_checksum(buffer, length);
+ hdmi_infoframe_set_checksum(buffer, length);
return length;
}
@@ -281,7 +288,7 @@ ssize_t hdmi_audio_infoframe_pack(struct
hdmi_audio_infoframe *frame,
if (frame-downmix_inhibit)
ptr[4] |= BIT(7);
- hdmi_infoframe_checksum(buffer, length);
+ hdmi_infoframe_set_checksum(buffer, length);
return length;
}
@@ -373,7 +380,7 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
ptr[9] = (frame-s3d_ext_data 0xf) 4;
}
- hdmi_infoframe_checksum(buffer, length);
+ hdmi_infoframe_set_checksum(buffer, length);
return length;
}
@@ -434,3 +441,604 @@ hdmi_infoframe_pack(union hdmi_infoframe *frame, void
*buffer, size_t size)
return length;
}
EXPORT_SYMBOL(hdmi_infoframe_pack);
+
+static const char *hdmi_infoframe_type_txt(enum hdmi_infoframe_type type)
+{
+ switch (type) {
+ case HDMI_INFOFRAME_TYPE_VENDOR: return Vendor;
+ case HDMI_INFOFRAME_TYPE_AVI: return Auxiliary Video Information
(AVI);
+ case HDMI_INFOFRAME_TYPE_SPD: return Source Product Description (SPD);
+ case HDMI_INFOFRAME_TYPE_AUDIO: return Audio;
+ }
+ return Invalid/Unknown;
+}
+
+static void hdmi_infoframe_log_header(struct device *dev, void *f)
+{
+ struct hdmi_any_infoframe *frame = f;
+ dev_info(dev, HDMI infoframe: %s, version %d, length %d\n,
+ hdmi_infoframe_type_txt(frame-type), frame-version,
frame-length);
+}
+
+static const char *hdmi_colorspace_txt(enum hdmi_colorspace colorspace)
+{
+ switch (colorspace) {
+ case HDMI_COLORSPACE_RGB: return RGB;
+ case HDMI_COLORSPACE_YUV422: return YCbCr 4:2:2;
+ case HDMI_COLORSPACE_YUV444: return YCbCr 4:4:4;
+ case HDMI_COLORSPACE_YUV420: return YCbCr 4:2:0;
+ case HDMI_COLORSPACE_IDO_DEFINED: return IDO Defined;
+ }
+ return Future;
+}
+
+static const char *hdmi_scan_mode_txt(enum hdmi_scan_mode scan_mode)
+{
+ switch(scan_mode) {
+ case HDMI_SCAN_MODE_NONE: return No Data;
+ case HDMI_SCAN_MODE_OVERSCAN: return Composed for overscanned display;
+ case HDMI_SCAN_MODE_UNDERSCAN: return Composed for underscanned
display;
+ }
+ return Future;
+}
+
+static const char *hdmi_colorimetry_txt(enum hdmi_colorimetry colorimetry)
+{
+ switch(colorimetry) {
+ case HDMI_COLORIMETRY_NONE: return No Data;
+ case HDMI_COLORIMETRY_ITU_601: return ITU601;
+ case HDMI_COLORIMETRY_ITU_709: return ITU709;
+ case HDMI_COLORIMETRY_EXTENDED: return Extended;
+ }
+ return Invalid/Unknown;
+}
+
+static const char *hdmi_picture_aspect_txt(enum hdmi_picture_aspect
picture_aspect)
+{
+ switch (picture_aspect) {
+ case HDMI_PICTURE_ASPECT_NONE: return No Data;
+ case HDMI_PICTURE_ASPECT_4_3: return 4:3;
+ case HDMI_PICTURE_ASPECT_16_9: return 16:9;
+ }
+
[PATCH 3/3] adv7842: simplify InfoFrame logging
From: Martin Bugge marbu...@cisco.com
Use the new logging functions from the hdmi module.
Signed-off-by: Martin Bugge marbu...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/Kconfig | 1 +
drivers/media/i2c/adv7842.c | 174
2 files changed, 47 insertions(+), 128 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index f40b4cf..66fd1c1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -209,6 +209,7 @@ config VIDEO_ADV7604
config VIDEO_ADV7842
tristate Analog Devices ADV7842 decoder
depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API
MEDIA_CONTROLLER
+ select HDMI
---help---
Support for the Analog Devices ADV7842 video decoder.
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 75d26df..7dceed7 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -38,6 +38,7 @@
#include linux/videodev2.h
#include linux/workqueue.h
#include linux/v4l2-dv-timings.h
+#include linux/hdmi.h
#include media/v4l2-device.h
#include media/v4l2-ctrls.h
#include media/v4l2-dv-timings.h
@@ -2108,149 +2109,65 @@ static int adv7842_set_edid(struct v4l2_subdev *sd,
struct v4l2_edid *e)
return err;
}
-/*** avi info frame CEA-861-E **/
-/* TODO move to common library */
-
-struct avi_info_frame {
- uint8_t f17;
- uint8_t y10;
- uint8_t a0;
- uint8_t b10;
- uint8_t s10;
- uint8_t c10;
- uint8_t m10;
- uint8_t r3210;
- uint8_t itc;
- uint8_t ec210;
- uint8_t q10;
- uint8_t sc10;
- uint8_t f47;
- uint8_t vic;
- uint8_t yq10;
- uint8_t cn10;
- uint8_t pr3210;
- uint16_t etb;
- uint16_t sbb;
- uint16_t elb;
- uint16_t srb;
+struct adv7842_cfg_read_infoframe {
+ const char *desc;
+ u8 present_mask;
+ u8 head_addr;
+ u8 payload_addr;
};
-static const char *y10_txt[4] = {
- RGB,
- YCbCr 4:2:2,
- YCbCr 4:4:4,
- Future,
-};
-
-static const char *c10_txt[4] = {
- No Data,
- SMPTE 170M,
- ITU-R 709,
- Extended Colorimetry information valied,
-};
-
-static const char *itc_txt[2] = {
- No Data,
- IT content,
-};
-
-static const char *ec210_txt[8] = {
- xvYCC601,
- xvYCC709,
- sYCC601,
- AdobeYCC601,
- AdobeRGB,
- 5 reserved,
- 6 reserved,
- 7 reserved,
-};
-
-static const char *q10_txt[4] = {
- Default,
- Limited Range,
- Full Range,
- Reserved,
-};
-
-static void parse_avi_infoframe(struct v4l2_subdev *sd, uint8_t *buf,
- struct avi_info_frame *avi)
-{
- avi-f17 = (buf[1] 7) 0x1;
- avi-y10 = (buf[1] 5) 0x3;
- avi-a0 = (buf[1] 4) 0x1;
- avi-b10 = (buf[1] 2) 0x3;
- avi-s10 = buf[1] 0x3;
- avi-c10 = (buf[2] 6) 0x3;
- avi-m10 = (buf[2] 4) 0x3;
- avi-r3210 = buf[2] 0xf;
- avi-itc = (buf[3] 7) 0x1;
- avi-ec210 = (buf[3] 4) 0x7;
- avi-q10 = (buf[3] 2) 0x3;
- avi-sc10 = buf[3] 0x3;
- avi-f47 = (buf[4] 7) 0x1;
- avi-vic = buf[4] 0x7f;
- avi-yq10 = (buf[5] 6) 0x3;
- avi-cn10 = (buf[5] 4) 0x3;
- avi-pr3210 = buf[5] 0xf;
- avi-etb = buf[6] + 256*buf[7];
- avi-sbb = buf[8] + 256*buf[9];
- avi-elb = buf[10] + 256*buf[11];
- avi-srb = buf[12] + 256*buf[13];
-}
-
-static void print_avi_infoframe(struct v4l2_subdev *sd)
+static void log_infoframe(struct v4l2_subdev *sd, struct
adv7842_cfg_read_infoframe *cri)
{
int i;
- uint8_t buf[14];
- u8 avi_len;
- u8 avi_ver;
- struct avi_info_frame avi;
+ uint8_t buffer[32];
+ union hdmi_infoframe frame;
+ u8 len;
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct device *dev = client-dev;
- if (!(hdmi_read(sd, 0x05) 0x80)) {
- v4l2_info(sd, receive DVI-D signal (AVI infoframe not
supported)\n);
- return;
- }
- if (!(io_read(sd, 0x60) 0x01)) {
- v4l2_info(sd, AVI infoframe not received\n);
+ if (!(io_read(sd, 0x60) cri-present_mask)) {
+ v4l2_info(sd, %s infoframe not received\n, cri-desc);
return;
}
- if (io_read(sd, 0x88) 0x10) {
- v4l2_info(sd, AVI infoframe checksum error has occurred
earlier\n);
- io_write(sd, 0x8a, 0x10); /* clear AVI_INF_CKS_ERR_RAW */
- if (io_read(sd, 0x88) 0x10) {
- v4l2_info(sd, AVI infoframe checksum error still
present\n);
- io_write(sd, 0x8a, 0x10); /* clear AVI_INF_CKS_ERR_RAW
*/
- }
- }
+ for (i = 0; i 3; i++)
+ buffer[i] = infoframe_read(sd,
[PATCH] omap_vout: fix compile warnings
When compiling under COMPILE_TEST on a x86_64 the following warnings
appear:
drivers/media/platform/omap/omap_vout.c: In function
'omap_vout_uservirt_to_phys':
drivers/media/platform/omap/omap_vout.c:209:23: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
return virt_to_phys((void *) virtp);
^
drivers/media/platform/omap/omap_vout.c: In function 'omapvid_setup_overlay':
drivers/media/platform/omap/omap_vout.c:420:2: warning: format '%x' expects
argument of type 'unsigned int', but argument 5 has type 'dma_addr_t'
[-Wformat=]
v4l2_dbg(1, debug, vout-vid_dev-v4l2_dev,
^
drivers/media/platform/omap/omap_vout.c: In function 'omap_vout_buffer_prepare':
drivers/media/platform/omap/omap_vout.c:794:34: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
vout-queued_buf_addr[vb-i] = (u8 *)
^
In file included from arch/x86/include/asm/dma-mapping.h:44:0,
from include/linux/dma-mapping.h:82,
from drivers/media/platform/omap/omap_vout.c:40:
drivers/media/platform/omap/omap_vout.c:803:58: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
dma_addr = dma_map_single(vout-vid_dev-v4l2_dev.dev, (void *) addr,
^
include/asm-generic/dma-mapping-common.h:174:60: note: in definition of macro
'dma_map_single'
#define dma_map_single(d, a, s, r) dma_map_single_attrs(d, a, s, r, NULL)
^
These are fixed by this patch.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/omap/omap_vout.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/omap/omap_vout.c
b/drivers/media/platform/omap/omap_vout.c
index 64ab6fb..e6c8199 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -198,7 +198,7 @@ static int omap_vout_try_format(struct v4l2_pix_format *pix)
* omap_vout_uservirt_to_phys: This inline function is used to convert user
* space virtual address to physical address.
*/
-static u32 omap_vout_uservirt_to_phys(u32 virtp)
+static unsigned long omap_vout_uservirt_to_phys(unsigned long virtp)
{
unsigned long physp = 0;
struct vm_area_struct *vma;
@@ -418,7 +418,7 @@ static int omapvid_setup_overlay(struct omap_vout_device
*vout,
}
v4l2_dbg(1, debug, vout-vid_dev-v4l2_dev,
- %s enable=%d addr=%x width=%d\n height=%d color_mode=%d\n
+ %s enable=%d addr=%pad width=%d\n height=%d color_mode=%d\n
rotation=%d mirror=%d posx=%d posy=%d out_width = %d \n
out_height=%d rotation_type=%d screen_width=%d\n,
__func__, ovl-is_enabled(ovl), info.paddr, info.width,
info.height,
--
2.1.3
--
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: i.MX6 CODA960 encoder
Am Donnerstag, den 27.11.2014, 16:10 -0200 schrieb Fabio Estevam: On Thu, Nov 27, 2014 at 3:54 PM, Jean-Michel Hautbois jean-michel.hautb...@vodalys.com wrote: I don't have the same behaviour, but I may have missed a patch. I have taken linux-next and rebased my work on it. I have some issues, but nothing to be worried about, no link with coda. I get the following : $ v4l2-ctl -d0 --set-fmt-video-out=width=1280,height=720,pixelfor $ v4l2-ctl -d0 --stream-mmap --stream-out-mmap --stream-to x.raw [ 173.705701] coda 204.vpu: CODA PIC_RUN timeout I have this same error with linux-next when I try to decode a file. Philipp, Do you know if linux-next contains all required coda patches? Could this be caused by the fact that we are using an unsupported VPU firmware version? I missed that the commit a04a0b6fed4f (ARM: dts: imx6qdl: Enable CODA960 VPU) lost the switching of the interrupts between http://www.spinics.net/lists/arm-kernel/msg338645.html and http://www.spinics.net/lists/arm-kernel/msg376571.html . Of course the JPEG interrupt will never fire when encoding H.264, which causes the timeout. Patch in another mail. regards Philipp -- 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: em28xx: Terratec G1 USB stick doesn't start recording
Hi Is there anyone that could provide me with some kind of response here ? Not much use in posting questions to this mailinglist as suggested in http://www.linuxtv.org/wiki/index.php/Em28xx_devices if there is no response. Regards, Per Weisteen On 14. nov. 2014 15:52, Per Weisteen wrote: Hi My Terratec G1 USB Stick seems to be recognized ok but doesn't start recording when I push the recording button on the Terratec. (Recording light doesn't go red either). I'm aware that the device isn't listed in the Validated em28xx boards but I'm quite sure I've seen some info om people who've been successful with that device. Do I need firmware to make it work ? If yes, could someone point me to the right firmware ? Thanks in advance for any help. uname -a Linux PC32750 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux dmesg [28789.658015] usb 2-2: new high-speed USB device number 6 using xhci_hcd [28789.680840] usb 2-2: New USB device found, idVendor=0ccd, idProduct=10af [28789.680843] usb 2-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0 [28789.680844] usb 2-2: Product: Terratec G1 [28789.680846] usb 2-2: Manufacturer: TerraTec Electronic GmbH [28789.714496] em28xx: New device TerraTec Electronic GmbH Terratec G1 @ 480 Mbps (0ccd:10af, interface 0, class 0) [28789.714499] em28xx: Video interface 0 found: isoc [28789.714528] em28xx: chip ID is em2860 [28789.838639] em2860 #0: i2c eeprom 00: 1a eb 67 95 cd 0c af 10 50 00 11 03 6a 1a 84 34 [28789.838650] em2860 #0: i2c eeprom 10: 00 00 06 57 06 02 00 00 00 00 00 00 00 00 00 00 [28789.838657] em2860 #0: i2c eeprom 20: 02 00 01 00 f0 10 01 00 00 00 00 00 5b 00 00 00 [28789.838665] em2860 #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [28789.838672] em2860 #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838680] em2860 #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838687] em2860 #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 1a 03 54 00 65 00 [28789.838695] em2860 #0: i2c eeprom 70: 72 00 72 00 61 00 74 00 65 00 63 00 20 00 47 00 [28789.838702] em2860 #0: i2c eeprom 80: 31 00 00 00 34 03 54 00 65 00 72 00 72 00 61 00 [28789.838710] em2860 #0: i2c eeprom 90: 54 00 65 00 63 00 20 00 45 00 6c 00 65 00 63 00 [28789.838717] em2860 #0: i2c eeprom a0: 74 00 72 00 6f 00 6e 00 69 00 63 00 20 00 47 00 [28789.838725] em2860 #0: i2c eeprom b0: 6d 00 62 00 48 00 00 00 00 00 00 00 00 00 00 00 [28789.838732] em2860 #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838740] em2860 #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838747] em2860 #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838754] em2860 #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838764] em2860 #0: EEPROM ID = 1a eb 67 95, EEPROM hash = 0x9d3b7386 [28789.838766] em2860 #0: EEPROM info: [28789.838767] em2860 #0: AC97 audio (5 sample rates) [28789.838768] em2860 #0: 500mA max power [28789.838770] em2860 #0: Table at offset 0x06, strings=0x1a6a, 0x3484, 0x [28789.838773] em2860 #0: Identified as Terratec Grabby (card=67) [28790.230122] saa7115 8-0025: saa7113 found @ 0x4a (em2860 #0) [28790.997655] em2860 #0: Config register raw data: 0x50 [28791.021641] em2860 #0: AC97 vendor ID = 0x83847650 [28791.033530] em2860 #0: AC97 features = 0x6a90 [28791.033539] em2860 #0: Empia 202 AC97 audio processor detected [28791.505330] em2860 #0: v4l2 driver version 0.2.0 [28793.440703] em2860 #0: V4L2 video device registered as video1 [28793.440707] em2860 #0: V4L2 VBI device registered as vbi0 [28793.440709] em2860 #0: analog set to isoc mode. [28793.440729] em28xx audio device (0ccd:10af): interface 1, class 1 [28793.440737] em28xx audio device (0ccd:10af): interface 2, class 1 [28793.440753] usbcore: registered new interface driver em28xx [28793.462288] usbcore: registered new interface driver snd-usb-audio sudo lsusb -vd 0ccd:10af Bus 002 Device 006: ID 0ccd:10af TerraTec Electronic GmbH Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0ccd TerraTec Electronic GmbH idProduct 0x10af bcdDevice1.00 iManufacturer 2 TerraTec Electronic GmbH iProduct1 Terratec G1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 555 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA
Re: [PATCH/RFC v4 05/11] mediactl: Add media device graph helpers
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 j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
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 unistd.h
#include linux/media.h
+#include linux/kdev_t.h
#include linux/videodev2.h
#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.
+}
+
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?
+ /* 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;
+
+ entity_pads = malloc(sizeof(*entity_pads));
How about allocating room for entity-info.pads pads, and then making it
smaller as needed?
+ cnt_pads = 0;
You could use *num_pads instead of cnt_pads.
+ for (i = 0; i entity-info.pads; ++i) {
+ if (entity-pads[i].flags type) {
+ entity_pads = realloc(entity_pads, (i + 1) *
+
Re: [PATCH v3] media: usb: uvc: use vb2_ops_wait_prepare/finish helper
Hi Laurent, Thanks for the review. On Thu, Nov 27, 2014 at 9:32 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Prabhakar, [Snip] + queue-queue.lock = queue-mutex; I'm a bit concerned that this would introduce future breakages. Setting the queue.lock pointer enables locking in all vb2_fop_* and vb2_ops_wait_* functions. The uvcvideo driver isn't ready for that, but doesn't use the vb2_fop_* functions yet, so that's not an issue. However, in the future, videobuf2 might use the lock in more places, including functions used by the uvcvideo driver. This could then cause breakages. Even if in future if videobuf2 uses this lock it would be in helpers mostly, so any way it doesn’t harm :) It would be better to completely convert the uvcvideo driver to the vb2_fop_* functions if we want to use vb2_ops_*. I'm not sure how complex that would be though, and whether it would be possible while still keeping the fine-grained locking implemented by the uvcvideo driver. Do you think it should be attempted ? mmap poll should be fairly simple, looks like open release cannot be dropped as it does some usb_autopm_get/put_interface() calls which I am not aware of. Thanks, --Prabhakar Lad ret = vb2_queue_init(queue-queue); if (ret) return ret; -- Regards, Laurent Pinchart -- 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 07/11] media-ctl: libv4l2subdev: add VYUY8_2X8 mbus code
On Fri, Nov 21, 2014 at 05:14:36PM +0100, Jacek Anaszewski wrote:
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 j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
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 },
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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
ISDB caption support
What is the status of ISDB-Tb / ISDB-T International / ISDB Japanese closed captioning support? If anyone is working on this, please get in touch -- we're particularly interested in getting Brazilian SBTVD working. I see Mauro has been working on DVBv5 support, but does this include captioning? Cheers, David -- 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 v3 1/3] drm: add bus_formats and nbus_formats fields to drm_display_info
Hi Boris,
Thank you for the patch. I just have two small comments.
On Tuesday 18 November 2014 14:46:18 Boris Brezillon wrote:
Add bus_formats and nbus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.
This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/gpu/drm/drm_crtc.c | 30 ++
include/drm/drm_crtc.h | 7 +++
2 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..17e3acf 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -763,6 +763,36 @@ static void drm_mode_remove(struct drm_connector
*connector, drm_mode_destroy(connector-dev, mode);
}
+/*
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @fmts: array containing the supported bus formats
+ * @nfmts: the number of entries in the fmts array
+ *
+ * Store the suppported bus formats in display info structure.
Could you document that the formats are specified as MEDIA_BUS_FMT_* values ?
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info, const
u32 *fmts, + unsigned int num_fmts)
+{
+ u32 *formats = NULL;
+
+ if (!fmts num_fmts)
+ return -EINVAL;
+
+ if (fmts num_fmts) {
+ formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
+ if (!formats)
+ return -ENOMEM;
+ }
+
+ kfree(info-bus_formats);
+ info-bus_formats = formats;
+ info-num_bus_formats = num_fmts;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
/**
* drm_connector_get_cmdline_mode - reads the user's cmdline mode
* @connector: connector to quwery
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..2e0a3e8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -31,6 +31,7 @@
#include linux/idr.h
#include linux/fb.h
#include linux/hdmi.h
+#include linux/media-bus-format.h
#include uapi/drm/drm_mode.h
#include uapi/drm/drm_fourcc.h
#include drm/drm_modeset_lock.h
@@ -130,6 +131,9 @@ struct drm_display_info {
enum subpixel_order subpixel_order;
u32 color_formats;
+ const u32 *bus_formats;
+ int num_bus_formats;
As the number of formats is never negative, I would make it an unsigned int.
+
/* Mask of supported hdmi deep color modes */
u8 edid_hdmi_dc_modes;
@@ -982,6 +986,9 @@ extern int drm_mode_connector_set_path_property(struct
drm_connector *connector, extern int
drm_mode_connector_update_edid_property(struct drm_connector *connector,
struct edid *edid);
+extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
+ const u32 *fmts, unsigned int
nfmts);
+
static inline bool drm_property_type_is(struct drm_property *property,
uint32_t type)
{
--
Regards,
Laurent Pinchart
--
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
[GIT PULL] soc-camera: 1st set for 3.19
Hi Mauro, IIUC, this coming Sunday might be the last -rc, so, postponing pull requests to subsystem maintainers even further isn't a good idea, so, here goes an soc-camera request. I know it isn't complete, there are a few more patches waiting to be pushed upstream, but I won't have time this coming weekend and next two weeks I'm traveling, which won't simplify things either. Some more patches are being reworked, if they arrive soon and we do get another -rc, I might try to push them too, but I don't want to postpone these ones, while waiting. One of these patches has also been modified by me and hasn't been tested yet. But changes weren't too complex. If however I did break something, we'll have to fix it in an incremental patch. The following changes since commit d298a59791fad3a707c1dadbef0935ee2664a10e: Merge branch 'patchwork' into to_next (2014-11-21 17:01:46 -0200) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.19-1 for you to fetch changes up to d8f5c144e57d99d2a7325bf8877812bf560e22dd: rcar_vin: Fix interrupt enable in progressive (2014-11-23 12:08:19 +0100) Koji Matsuoka (4): rcar_vin: Add YUYV capture format support rcar_vin: Add scaling support rcar_vin: Enable VSYNC field toggle mode rcar_vin: Fix interrupt enable in progressive Yoshihiro Kaneko (1): rcar_vin: Add DT support for r8a7793 and r8a7794 SoCs .../devicetree/bindings/media/rcar_vin.txt | 2 + drivers/media/platform/soc_camera/rcar_vin.c | 466 - 2 files changed, 457 insertions(+), 11 deletions(-) Thanks Guennadi -- 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 v3 0/3] drm: describe display bus format
Hi Boris, On Thursday 27 November 2014 14:37:50 Boris Brezillon wrote: On Tue, 18 Nov 2014 14:46:17 +0100 Boris Brezillon wrote: Hello, This series makes use of the MEDIA_BUS_FMT definition to describe how the data are transmitted to the display. This will allow drivers to configure their output display bus according to the display capabilities. For example some display controllers support DPI (or raw RGB) connectors and need to specify which format will be transmitted on the DPI bus (RGB444, RGB565, RGB888, ...). This series also adds a field to the panel_desc struct so that one can specify which format is natevely supported by a panel. Thierry, Laurent, Dave, can you take a look at this patch series: this is the last missing dependency to get the atmel-hlcdc DRM driver mainlined, and I was expecting to get this driver in 3.19... I've reviewed the series, it looks globally fine to me. I just had two small comments on patch 1/3. -- Regards, Laurent Pinchart -- 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 v2.1 1/5] v4l: Clean up sub-device format documentation
The sub-device format documentation documented scaling configuration through formats. Instead the compose selection rectangle is elsewhere documented to be used for the purpose. Remove scaling related part of the documentation. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Hans Verkuil hans.verk...@cisco.com --- since v2: - Fix the last documentation paragraph to tell the driver propagates the size to source pad format, instead of the application having to set it. Documentation/DocBook/media/v4l/dev-subdev.xml | 109 ++-- 1 file changed, 63 insertions(+), 46 deletions(-) diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml b/Documentation/DocBook/media/v4l/dev-subdev.xml index d15aaf8..4f0ba58 100644 --- a/Documentation/DocBook/media/v4l/dev-subdev.xml +++ b/Documentation/DocBook/media/v4l/dev-subdev.xml @@ -195,53 +195,59 @@ titleSample Pipeline Configuration/title tgroup cols=3 colspec colname=what/ - colspec colname=sensor-0 / - colspec colname=frontend-0 / - colspec colname=frontend-1 / - colspec colname=scaler-0 / - colspec colname=scaler-1 / + colspec colname=sensor-0 format / + colspec colname=frontend-0 format / + colspec colname=frontend-1 format / + colspec colname=scaler-0 format / + colspec colname=scaler-0 compose / + colspec colname=scaler-1 format / thead row entry/entry - entrySensor/0/entry - entryFrontend/0/entry - entryFrontend/1/entry - entryScaler/0/entry - entryScaler/1/entry + entrySensor/0 format/entry + entryFrontend/0 format/entry + entryFrontend/1 format/entry + entryScaler/0 format/entry + entryScaler/0 compose selection rectangle/entry + entryScaler/1 format/entry /row /thead tbody valign=top row entryInitial state/entry - entry2048x1536/entry - entry-/entry - entry-/entry - entry-/entry - entry-/entry + entry2048x1536/SGRBG8_1X8/entry + entry(default)/entry + entry(default)/entry + entry(default)/entry + entry(default)/entry + entry(default)/entry /row row - entryConfigure frontend input/entry - entry2048x1536/entry - entryemphasis2048x1536/emphasis/entry - entryemphasis2046x1534/emphasis/entry - entry-/entry - entry-/entry + entryConfigure frontend sink format/entry + entry2048x1536/SGRBG8_1X8/entry + entryemphasis2048x1536/SGRBG8_1X8/emphasis/entry + entryemphasis2046x1534/SGRBG8_1X8/emphasis/entry + entry(default)/entry + entry(default)/entry + entry(default)/entry /row row - entryConfigure scaler input/entry - entry2048x1536/entry - entry2048x1536/entry - entry2046x1534/entry - entryemphasis2046x1534/emphasis/entry - entryemphasis2046x1534/emphasis/entry + entryConfigure scaler sink format/entry + entry2048x1536/SGRBG8_1X8/entry + entry2048x1536/SGRBG8_1X8/entry + entry2046x1534/SGRBG8_1X8/entry + entryemphasis2046x1534/SGRBG8_1X8/emphasis/entry + entryemphasis0,0/2046x1534/emphasis/entry + entryemphasis2046x1534/SGRBG8_1X8/emphasis/entry /row row - entryConfigure scaler output/entry - entry2048x1536/entry - entry2048x1536/entry - entry2046x1534/entry - entry2046x1534/entry - entryemphasis1280x960/emphasis/entry + entryConfigure scaler sink compose selection/entry + entry2048x1536/SGRBG8_1X8/entry + entry2048x1536/SGRBG8_1X8/entry + entry2046x1534/SGRBG8_1X8/entry + entry2046x1534/SGRBG8_1X8/entry + entryemphasis0,0/1280x960/emphasis/entry + entryemphasis1280x960/SGRBG8_1X8/emphasis/entry /row /tbody /tgroup @@ -249,19 +255,30 @@ para orderedlist - listitemparaInitial state. The sensor output is set to its native 3MP - resolution. Resolutions on the host frontend and scaler input and output - pads are undefined./para/listitem - listitemparaThe application configures the frontend input pad resolution to - 2048x1536. The driver propagates the format to the frontend output pad. - Note that the propagated output format can be different, as in this case, - than the input format, as the hardware might need to crop pixels (for - instance when
[GIT PULL FOR v3.19] Add V4L2_SEL_TGT_NATIVE_SIZE target
Hi Mauro, This pull request adds support for the V4L2_SEL_TGT_NATIVE_SIZE selection target to access the device's native size. Among is also a patch to clean up sub-device interface documentation and capability flags to tell whether setting the native size is possible. Please pull. The following changes since commit 504febc3f98c87a8bebd8f2f274f32c0724131e4: Revert [media] lmed04: add missing breaks (2014-11-25 22:16:25 -0200) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git native-size for you to fetch changes up to da7cf8011adc281a878dde254f5642745648decd: smiapp: Support V4L2_SEL_TGT_NATIVE_SIZE (2014-11-29 01:48:54 +0200) Sakari Ailus (5): v4l: Clean up sub-device format documentation v4l: Add V4L2_SEL_TGT_NATIVE_SIZE selection target v4l: Add input and output capability flags for native size setting smiapp: Set left and top to zero for crop bounds selection smiapp: Support V4L2_SEL_TGT_NATIVE_SIZE Documentation/DocBook/media/v4l/dev-subdev.xml | 109 +++- .../DocBook/media/v4l/selections-common.xml| 16 +++ .../DocBook/media/v4l/vidioc-enuminput.xml |8 ++ .../DocBook/media/v4l/vidioc-enumoutput.xml|8 ++ drivers/media/i2c/smiapp/smiapp-core.c |7 ++ include/uapi/linux/v4l2-common.h |2 + include/uapi/linux/videodev2.h |2 + 7 files changed, 106 insertions(+), 46 deletions(-) -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: ISDB caption support
Hi David, ISDB-T subtitles are done in a similar manner to DVB-T subtitles - there is a PID in the stream which contains the subtitle data, which needs to be decoded by the application (just as you would handle DVB-T subtitles or ATSC closed captions). It's entirely an application level function, having nothing to do with the driver layer. In short, this has nothing to do with DVBv5, as that is all about how the tuner is controlled, not what gets done with the resulting MPEG stream. You would need to talk to whoever is responsible for the application you are working with (whether that be VLC, mplayer, ccextractor, etc). Cheers, Devin On Fri, Nov 28, 2014 at 2:55 PM, David Liontooth lionte...@cogweb.net wrote: What is the status of ISDB-Tb / ISDB-T International / ISDB Japanese closed captioning support? If anyone is working on this, please get in touch -- we're particularly interested in getting Brazilian SBTVD working. I see Mauro has been working on DVBv5 support, but does this include captioning? Cheers, David -- 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 -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: ISDB caption support
Hi Devin, Great, thanks. I realize captions is an application-layer function, and intend to work with the CCExtractor team. Do any other applications already have ISDB caption support? For DVB and ATSC there's quite a bit of code written by several people for teletext and captions -- has anything at all been done for ISDB captions? It's used in nearly all of Central and South America, plus the Philippines and of course Japan -- you would have thought someone has started on the task? We're looking for a good solution for capturing television in Brazil, when the signal is encrypted -- are there set-top boxes or tv capture cards that handle the decryption so that the decoded signal is passed on with the ISDB-Tb caption stream intact? Our test system generates captions as an overlay and does not pass on the closed captions. Cheers, David On 11/28/14, 6:40 PM, Devin Heitmueller wrote: Hi David, ISDB-T subtitles are done in a similar manner to DVB-T subtitles - there is a PID in the stream which contains the subtitle data, which needs to be decoded by the application (just as you would handle DVB-T subtitles or ATSC closed captions). It's entirely an application level function, having nothing to do with the driver layer. In short, this has nothing to do with DVBv5, as that is all about how the tuner is controlled, not what gets done with the resulting MPEG stream. You would need to talk to whoever is responsible for the application you are working with (whether that be VLC, mplayer, ccextractor, etc). Cheers, Devin On Fri, Nov 28, 2014 at 2:55 PM, David Liontooth lionte...@cogweb.net wrote: What is the status of ISDB-Tb / ISDB-T International / ISDB Japanese closed captioning support? If anyone is working on this, please get in touch -- we're particularly interested in getting Brazilian SBTVD working. I see Mauro has been working on DVBv5 support, but does this include captioning? Cheers, David -- 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 -- 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: ISDB caption support
I realize captions is an application-layer function, and intend to work with the CCExtractor team. Do any other applications already have ISDB caption support? Based on a Google search, it looks like dvbviewer can decode them: http://www.dvbviewer.tv/forum/topic/41933-brazilian-terrestrial-isdb-tb-subtitles-closed-caption/ http://www.dvbviewer.com/en/index.php It's not open source, and it's not Linux, but at least it may give you something to compare against if you want to build the functionality yourself. For DVB and ATSC there's quite a bit of code written by several people for teletext and captions -- has anything at all been done for ISDB captions? Not to my knowledge. I've done a ton of work with CC decoding in VLC, but haven't poked around at the other formats. It's used in nearly all of Central and South America, plus the Philippines and of course Japan -- you would have thought someone has started on the task? From what I understand, most terrestrial TV in Japan is encrypted, so you're likely to not find many open source solutions which targeted at that market. Presumably there is less of that in Brazil (why else would Mauro be doing all that ISDB-T work if there was no way to watch the actual video?). We're looking for a good solution for capturing television in Brazil, when the signal is encrypted -- are there set-top boxes or tv capture cards that handle the decryption so that the decoded signal is passed on with the ISDB-Tb caption stream intact? This would be very unusual. Satellite captioning often has the same issues - the decoders only support overlaying the captions over the video and provide no means to access the underlying data. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Nov 29 04:00:15 CET 2014 git branch: test git hash: 504febc3f98c87a8bebd8f2f274f32c0724131e4 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-35-gc1c3f96 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.17-3.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-3.18-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-x86_64: OK linux-3.18-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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
