Re: [PATCH v8 5/8] exynos4-is: Add support for v4l2-flash subdevs
Hi Jacek, On Wed, May 20, 2015 at 04:10:12PM +0200, Jacek Anaszewski wrote: > This patch adds support for external v4l2-flash devices. > The support includes parsing "samsung,flash-led" DT property > and asynchronous subdevice registration. > > Signed-off-by: Jacek Anaszewski > Acked-by: Kyungmin Park > Cc: Sylwester Nawrocki > --- > drivers/media/platform/exynos4-is/media-dev.c | 39 > +++-- > drivers/media/platform/exynos4-is/media-dev.h | 13 - > 2 files changed, 49 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..80cecd8 100644 > --- a/drivers/media/platform/exynos4-is/media-dev.c > +++ b/drivers/media/platform/exynos4-is/media-dev.c > @@ -451,6 +451,28 @@ rpm_put: > return ret; > } > > +static void fimc_md_register_flash_entities(struct fimc_md *fmd) > +{ > + int i; > + > + fmd->num_flashes = 0; > + > + for (i = 0; i < fmd->num_sensors; i++) { > + const struct device_node *np = > + fmd->sensor[i].asd.match.of.node; > + const int nf = fmd->num_flashes; > + > + np = of_parse_phandle(np, "samsung,flash-led", 0); > + if (!np) > + continue; > + > + fmd->flash[nf].asd.match_type = V4L2_ASYNC_MATCH_OF; > + fmd->flash[nf].asd.match.of.node = np; > + fmd->async_subdevs[fmd->num_sensors + nf] = &fmd->flash[nf].asd; > + fmd->num_flashes++; > + } > +} > + > static int __of_get_csis_id(struct device_node *np) > { > u32 reg = 0; > @@ -1275,6 +1297,15 @@ static int subdev_notifier_bound(struct > v4l2_async_notifier *notifier, > struct fimc_sensor_info *si = NULL; > int i; > > + /* Register flash subdev if detected any */ > + for (i = 0; i < ARRAY_SIZE(fmd->flash); i++) { > + if (fmd->flash[i].asd.match.of.node == subdev->of_node) { Does the index of a particular sub-device index matter? Could you just use the next available one? There would be no need to for the check anything here, please see how the omap3isp driver does it --- it's in isp_subdev_notifier_bound() drivers/media/platform/omap3isp/isp.c . > + 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) -- 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: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback
On 20 May 2015 at 23:45, David Härdeman wrote: > On Wed, May 20, 2015 at 10:26:54PM +0300, Antti Seppälä wrote: >>On 20 May 2015 at 21:29, David Härdeman wrote: >>> On Wed, May 20, 2015 at 07:46:21PM +0300, Antti Seppälä wrote: On 19 May 2015 at 23:38, David Härdeman wrote: > On Tue, Mar 31, 2015 at 08:48:06PM +0300, Antti Seppälä wrote: >>From: James Hogan >> >>Add a callback to raw ir handlers for encoding and modulating a scancode >>to a set of raw events. This could be used for transmit, or for >>converting a wakeup scancode filter to a form that is more suitable for >>raw hardware wake up filters. >> >>Signed-off-by: James Hogan >>Signed-off-by: Antti Seppälä >>Cc: David Härdeman >>--- >> >>Notes: >>Changes in v3: >> - Ported to apply against latest media-tree >> >>Changes in v2: >> - Alter encode API to return -ENOBUFS when there isn't enough buffer >> space. When this occurs all buffer contents must have been written >> with the partial encoding of the scancode. This is to allow drivers >> such as nuvoton-cir to provide a shorter buffer and still get a >> useful partial encoding for the wakeup pattern. >> >> drivers/media/rc/rc-core-priv.h | 2 ++ >> drivers/media/rc/rc-ir-raw.c| 37 >> + >> include/media/rc-core.h | 3 +++ >> 3 files changed, 42 insertions(+) >> >>diff --git a/drivers/media/rc/rc-core-priv.h >>b/drivers/media/rc/rc-core-priv.h >>index b68d4f76..122c25f 100644 >>--- a/drivers/media/rc/rc-core-priv.h >>+++ b/drivers/media/rc/rc-core-priv.h >>@@ -25,6 +25,8 @@ struct ir_raw_handler { >> >> u64 protocols; /* which are handled by this handler */ >> int (*decode)(struct rc_dev *dev, struct ir_raw_event event); >>+ int (*encode)(u64 protocols, const struct rc_scancode_filter >>*scancode, >>+struct ir_raw_event *events, unsigned int max); >> >> /* These two should only be used by the lirc decoder */ >> int (*raw_register)(struct rc_dev *dev); >>diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c >>index b732ac6..dd47fe5 100644 >>--- a/drivers/media/rc/rc-ir-raw.c >>+++ b/drivers/media/rc/rc-ir-raw.c >>@@ -246,6 +246,43 @@ static int change_protocol(struct rc_dev *dev, u64 >>*rc_type) >> return 0; >> } >> >>+/** >>+ * ir_raw_encode_scancode() - Encode a scancode as raw events >>+ * >>+ * @protocols:permitted protocols >>+ * @scancode: scancode filter describing a single scancode >>+ * @events: array of raw events to write into >>+ * @max: max number of raw events >>+ * >>+ * Attempts to encode the scancode as raw events. >>+ * >>+ * Returns: The number of events written. >>+ *-ENOBUFS if there isn't enough space in the array to fit >>the >>+ *encoding. In this case all @max events will have been >>written. >>+ *-EINVAL if the scancode is ambiguous or invalid, or if no >>+ *compatible encoder was found. >>+ */ >>+int ir_raw_encode_scancode(u64 protocols, > > Why a bitmask of protocols and not a single protocol enum? What's the > use case for encoding a given scancode according to one out of a number > of protocols (and not even knowing which one)?? > I think bitmask was used simply for consistency reasons. Most of the rc-core handles protocols in a bitmask (u64 protocols or some variant of it). >>> >>> Yes, all the parts where multiple protocols make sense use a bitmap of >>> protocols. If there's any part which uses a bitmap where only one >>> protocol makes sense that'd be a bug... >>> Especially in the decoders the dev->enabled_protocols is used to mean "decode any of these protocols but I don't care which one" and the encoders were written to follow that logic. >>> >>> The fact that you might want to be able to receive and decode more than >>> one protocol has no bearing on encoding when you're supposed to know >>> what it is you want to encode >>> >>> >From ir driver point of view it was also kind of nice to use the u64 enabled_wakeup_protocols from struct rc_dev which already exists and is manipulated with the same sysfs code as the enabled_protocols bitmask. >>> >>> But it makes no sense? "here's a scancode...I have no idea what it means >>> since only knowing the protocol allows you to make any sense of the >>> scancode...but please encode it to something...anything" >>> >> >>Well it made sense from code simplicity point of view :) >> >>But yes current use cases will most likely be valid when encoding only >>to a single specific protocol at a time. However h
[linuxtv-media:master 985/1029] drivers/media/common/b2c2/flexcop-fe-tuner.c:31:12: warning: 'flexcop_fe_request_firmware' defined but not used
tree: git://linuxtv.org/media_tree.git master head: 2a80f296422a01178d0a993479369e94f5830127 commit: 5afc9a25be8d4e627cf07aa8a7500eafe3664b94 [985/1029] [media] Add support for TechniSat Skystar S2 config: i386-randconfig-c1-05180904 (attached as .config) reproduce: git checkout 5afc9a25be8d4e627cf07aa8a7500eafe3664b94 # save the attached .config to linux build tree make ARCH=i386 All warnings: >> drivers/media/common/b2c2/flexcop-fe-tuner.c:31:12: warning: >> 'flexcop_fe_request_firmware' defined but not used [-Wunused-function] static int flexcop_fe_request_firmware(struct dvb_frontend *fe, ^ vim +/flexcop_fe_request_firmware +31 drivers/media/common/b2c2/flexcop-fe-tuner.c 15 #include "cx24120.h" 16 #include "mt352.h" 17 #include "bcm3510.h" 18 #include "nxt200x.h" 19 #include "dvb-pll.h" 20 #include "lgdt330x.h" 21 #include "tuner-simple.h" 22 #include "stv0297.h" 23 24 25 /* Can we use the specified front-end? Remember that if we are compiled 26 * into the kernel we can't call code that's in modules. */ 27 #define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ 28 (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) 29 30 #if FE_SUPPORTED(BCM3510) || FE_SUPPORTED(CX24120) > 31 static int flexcop_fe_request_firmware(struct dvb_frontend *fe, 32 const struct firmware **fw, char *name) 33 { 34 struct flexcop_device *fc = fe->dvb->priv; 35 36 return request_firmware(fw, name, fc->dev); 37 } 38 #endif 39 --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/i386 4.1.0-rc3 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=3 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set CONFIG_KERNEL_LZO=y # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_RCU_FANOUT_EXACT=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_KTHREAD_PRIO=0 CONFIG_RCU_NOCB_CPU=y # CONFIG_RCU_NOCB_CPU_NONE is not set
Re: [PATCH 4/5] leds: aat1290: Pass dev and dev->of_node to v4l2_flash_init()
Hi Sakari, On 05/20/2015 04:31 PM, Sakari Ailus wrote: Hi Jacek, On Wed, May 20, 2015 at 03:47:25PM +0200, Jacek Anaszewski wrote: ... --- a/drivers/leds/leds-aat1290.c +++ b/drivers/leds/leds-aat1290.c @@ -524,9 +524,8 @@ static int aat1290_led_probe(struct platform_device *pdev) led_cdev->dev->of_node = sub_node; /* Create V4L2 Flash subdev. */ -led->v4l2_flash = v4l2_flash_init(fled_cdev, - &v4l2_flash_ops, - &v4l2_sd_cfg); +led->v4l2_flash = v4l2_flash_init(dev, NULL, fled_cdev, + &v4l2_flash_ops, &v4l2_sd_cfg); Here the first argument should be led_cdev->dev, not dev, which is &pdev->dev, whereas led_cdev->dev is returned by device_create_with_groups (it takes dev as a parent) called from led_classdev_register. The reason for this is the fact that pdev->dev has its of_node field initialized, which makes v4l2_async trying to match subdev by parent node of a LED device, not by sub-LED related DT node. If v4l2_subdev->of_node is set, then it won't be replaced with one from struct device. I.e. you need to provide of_node pointer only if it's different from dev->of_node. It will always be different since dev->of_node pointer is related to the main DT node of LED device, whereas each LED connected to it must be expressed in the form of sub-node, as Documentation/devicetree/bindings/leds/common.txt DT states. You can still refer to the device's root device_node using a phandle. Why should I need to refer to the device's root node? What I meant here was that DT documentation enforces that even if there is a single LED connected to the device it has to be expressed as a sub-node anyway. Each LED will have to be matched by the phandle to the sub-node representing it. This implies that v4l2_subdev->of_node (related to sub-LED DT node) will be always different from dev->of_node (related to LED controller DT node). Say, if you have a LED flash controller with an indicator. It's intended to be used together with the flash LED, and the existing as3645a driver exposes it through the same sub-device. I think that'd make sense with LED class driver as well (i.e. you'd have two LED class devices but a single sub-device). Small changes to the wrapper would be needed. How the sub-device name should look like then? We would have to concatenate somehow both LED class device names? -- 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 02/20] media: adv7180: add of match table
From: Ben Dooks Add a proper of match id for use when the device is being bound via device tree, to avoid having to use the i2c old-style binding of the device. Signed-off-by: Ben Dooks Signed-off-by: William.Towle Reviewed-by: Rob Taylor --- drivers/media/i2c/adv7180.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c index a493c0b..09a96df 100644 --- a/drivers/media/i2c/adv7180.c +++ b/drivers/media/i2c/adv7180.c @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -1324,11 +1325,21 @@ static SIMPLE_DEV_PM_OPS(adv7180_pm_ops, adv7180_suspend, adv7180_resume); #define ADV7180_PM_OPS NULL #endif +#ifdef CONFIG_OF +static const struct of_device_id adv7180_of_id[] = { + { .compatible = "adi,adv7180", }, + { }, +}; + +MODULE_DEVICE_TABLE(of, adv7180_of_id); +#endif + static struct i2c_driver adv7180_driver = { .driver = { .owner = THIS_MODULE, .name = KBUILD_MODNAME, .pm = ADV7180_PM_OPS, + .of_match_table = of_match_ptr(adv7180_of_id), }, .probe = adv7180_probe, .remove = adv7180_remove, -- 1.7.10.4 -- 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 10/20] media: soc_camera: soc_scale_crop: Use correct pad when calling subdev try_fmt
From: Rob Taylor Fix calls to subdev try_fmt to use correct pad. Fixes failures with subdevs that care about having the right pad number set. Signed-off-by: William Towle Reviewed-by: Rob Taylor --- drivers/media/platform/soc_camera/soc_scale_crop.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/media/platform/soc_camera/soc_scale_crop.c b/drivers/media/platform/soc_camera/soc_scale_crop.c index bda29bc..d8d32ea 100644 --- a/drivers/media/platform/soc_camera/soc_scale_crop.c +++ b/drivers/media/platform/soc_camera/soc_scale_crop.c @@ -224,6 +224,10 @@ static int client_set_fmt(struct soc_camera_device *icd, struct v4l2_cropcap cap; bool host_1to1; int ret; + struct media_pad *remote_pad; + + remote_pad = media_entity_remote_pad(&icd->vdev->entity.pads[0]); + format->pad = remote_pad->index; ret = v4l2_device_call_until_err(sd->v4l2_dev, soc_camera_grp_id(icd), pad, @@ -261,10 +265,17 @@ static int client_set_fmt(struct soc_camera_device *icd, /* width <= max_width && height <= max_height - guaranteed by try_fmt */ while ((width > tmp_w || height > tmp_h) && tmp_w < max_width && tmp_h < max_height) { + struct media_pad *remote_pad; + tmp_w = min(2 * tmp_w, max_width); tmp_h = min(2 * tmp_h, max_height); mf->width = tmp_w; mf->height = tmp_h; + + remote_pad = media_entity_remote_pad( + &icd->vdev->entity.pads[0]); + format->pad = remote_pad->index; + ret = v4l2_device_call_until_err(sd->v4l2_dev, soc_camera_grp_id(icd), pad, set_fmt, NULL, format); -- 1.7.10.4 -- 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 14/20] media: rcar_vin: Reject videobufs that are too small for current format
In videobuf_setup reject buffers that are too small for the configured format. Fixes v4l2-complience issue. Signed-off-by: Rob Taylor Reviewed-by: William Towle --- drivers/media/platform/soc_camera/rcar_vin.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 571ab20..222002a 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -541,6 +541,9 @@ static int rcar_vin_videobuf_setup(struct vb2_queue *vq, unsigned int bytes_per_line; int ret; + if (fmt->fmt.pix.sizeimage < icd->sizeimage) + return -EINVAL; + xlate = soc_camera_xlate_by_fourcc(icd, fmt->fmt.pix.pixelformat); if (!xlate) -- 1.7.10.4 -- 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 18/20] media: adv7604: Always query_dv_timings in adv76xx_fill_format
Make sure we're always reporting the current format of the input. Fixes start of day bugs. Signed-off-by: Rob Taylor Signed-off-by: William Towle --- drivers/media/i2c/adv7604.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index d77ee1f..526fa4e 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -1787,8 +1787,12 @@ static int adv76xx_enum_mbus_code(struct v4l2_subdev *sd, static void adv76xx_fill_format(struct adv76xx_state *state, struct v4l2_mbus_framefmt *format) { + struct v4l2_subdev *sd = &state->sd; + memset(format, 0, sizeof(*format)); + v4l2_subdev_call(sd, video, query_dv_timings, &state->timings); + format->width = state->timings.bt.width; format->height = state->timings.bt.height; -- 1.7.10.4 -- 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 06/20] ARM: shmobile: lager dts: specify default-input for ADV7612
Set 'default-input' property for ADV7612. Enables image/video capture without the need to have userspace specifying routing. Signed-off-by: Ian Molton Tested-by: William Towle --- arch/arm/boot/dts/r8a7790-lager.dts |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts index 90c4531..6946e9a 100644 --- a/arch/arm/boot/dts/r8a7790-lager.dts +++ b/arch/arm/boot/dts/r8a7790-lager.dts @@ -544,6 +544,7 @@ port { hdmi_in_ep: endpoint { remote-endpoint = <&vin0ep0>; + default-input = <0>; }; }; }; -- 1.7.10.4 -- 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 07/20] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support
From: Koji Matsuoka Signed-off-by: Koji Matsuoka Signed-off-by: Simon Horman Signed-off-by: Yoshihiro Kaneko Modified to use MEDIA_BUS_FMT_* constants Signed-off-by: William Towle Reviewed-by: Rob Taylor --- drivers/media/platform/soc_camera/rcar_vin.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index db7700b..0f67646 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -98,6 +98,7 @@ #define VNMC_INF_YUV10_BT656 (2 << 16) #define VNMC_INF_YUV10_BT601 (3 << 16) #define VNMC_INF_YUV16 (5 << 16) +#define VNMC_INF_RGB888(6 << 16) #define VNMC_VUP (1 << 10) #define VNMC_IM_ODD(0 << 3) #define VNMC_IM_ODD_EVEN (1 << 3) @@ -620,6 +621,10 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv) /* input interface */ switch (icd->current_fmt->code) { + case MEDIA_BUS_FMT_RGB888_1X24: + /* BT.601/BT.709 24-bit RGB-888 */ + vnmc |= VNMC_INF_RGB888; + break; case MEDIA_BUS_FMT_YUYV8_1X16: /* BT.601/BT.1358 16bit YCbCr422 */ vnmc |= VNMC_INF_YUV16; @@ -679,6 +684,15 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv) if (output_is_yuv) vnmc |= VNMC_BPS; + /* +* The above assumes YUV input, toggle BPS for RGB input. +* RGB inputs can be detected by checking that the most-significant +* two bits of INF are set. This corresponds to the bits +* set in VNMC_INF_RGB888. +*/ + if ((vnmc & VNMC_INF_RGB888) == VNMC_INF_RGB888) + vnmc ^= VNMC_BPS; + /* progressive or interlaced mode */ interrupts = progressive ? VNIE_FIE : VNIE_EFE; @@ -1423,6 +1437,7 @@ static int rcar_vin_get_formats(struct soc_camera_device *icd, unsigned int idx, case MEDIA_BUS_FMT_YUYV8_1X16: case MEDIA_BUS_FMT_YUYV8_2X8: case MEDIA_BUS_FMT_YUYV10_2X10: + case MEDIA_BUS_FMT_RGB888_1X24: if (cam->extra_fmt) break; -- 1.7.10.4 -- 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 17/20] media: adv7604: Support V4L_FIELD_INTERLACED
When hardware reports interlaced input, correctly set field to V4L_FIELD_INTERLACED ini adv76xx_fill_format. Signed-off-by: Rob Taylor Reviewed-by: William Towle --- drivers/media/i2c/adv7604.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index 4bde3e1..d77ee1f 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -1791,7 +1791,12 @@ static void adv76xx_fill_format(struct adv76xx_state *state, format->width = state->timings.bt.width; format->height = state->timings.bt.height; - format->field = V4L2_FIELD_NONE; + + if (state->timings.bt.interlaced) + format->field= V4L2_FIELD_INTERLACED; + else + format->field= V4L2_FIELD_NONE; + format->colorspace = V4L2_COLORSPACE_SRGB; if (state->timings.bt.flags & V4L2_DV_FL_IS_CE_VIDEO) -- 1.7.10.4 -- 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 11/20] media: soc_camera: Fill std field in enum_input
From: Hans Verkuil Fill in the std field from the video_device tvnorms field in enum_input. Signed-off-by: Hans Verkuil Signed-off-by: Rob Taylor --- drivers/media/platform/soc_camera/soc_camera.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index 126d645..5afbf65 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -309,11 +309,14 @@ static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv, static int soc_camera_enum_input(struct file *file, void *priv, struct v4l2_input *inp) { + struct soc_camera_device *icd = file->private_data; + if (inp->index != 0) return -EINVAL; /* default is camera */ inp->type = V4L2_INPUT_TYPE_CAMERA; + inp->std = icd->vdev->tvnorms; strcpy(inp->name, "Camera"); return 0; -- 1.7.10.4 -- 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 20/20] media: soc_camera: Add debugging for get_formats
From: Rob Taylor Some helpful debugging for get_formats use, useful for debugging v4l2-compliance issues. Signed-off-by: Rob Taylor Reviewed-by: William Towle --- drivers/media/platform/soc_camera/soc_camera.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index 583c5e6..503e9b6 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -522,7 +522,7 @@ static int soc_camera_init_user_formats(struct soc_camera_device *icd) /* Second pass - actually fill data formats */ fmts = 0; - for (i = 0; i < raw_fmts; i++) + for (i = 0; i < raw_fmts; i++) { if (!ici->ops->get_formats) { code.index = i; v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, &code); @@ -537,6 +537,8 @@ static int soc_camera_init_user_formats(struct soc_camera_device *icd) goto egfmt; fmts += ret; } + dev_dbg(icd->pdev, " Format: %x %c%c%c%c", icd->user_formats[fmts-1].code, pixfmtstr(icd->user_formats[fmts-1].host_fmt->fourcc)); + } icd->num_user_formats = fmts; icd->current_fmt = &icd->user_formats[0]; @@ -732,6 +734,8 @@ static int soc_camera_open(struct file *file) * apart from someone else calling open() simultaneously, but * .host_lock is protecting us against it. */ + + dev_dbg(icd->pdev, "%s:%d calling set_fmt with size %d x %d",__func__, __LINE__, f.fmt.pix.width, f.fmt.pix.height); ret = soc_camera_set_fmt(icd, &f); if (ret < 0) goto esfmt; @@ -2234,6 +2238,7 @@ static int soc_camera_pdrv_probe(struct platform_device *pdev) icd->user_width = DEFAULT_WIDTH; icd->user_height= DEFAULT_HEIGHT; + dev_dbg(icd->pdev, "%s:%d setting default user size to %d x %d",__func__, __LINE__, icd->user_width, icd->user_height); return soc_camera_device_register(icd); } -- 1.7.10.4 -- 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 01/20] ARM: shmobile: lager dts: Add entries for VIN HDMI input support
Adds DT entries for vin0_pins, adv7612 and vin0 Signed-off-by: William Towle Signed-off-by: Rob Taylor --- arch/arm/boot/dts/r8a7790-lager.dts | 41 ++- 1 file changed, 40 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts index aaa4f25..90c4531 100644 --- a/arch/arm/boot/dts/r8a7790-lager.dts +++ b/arch/arm/boot/dts/r8a7790-lager.dts @@ -370,7 +370,12 @@ renesas,function = "usb2"; }; - vin1_pins: vin { + vin0_pins: vin0 { + renesas,groups = "vin0_data24", "vin0_sync", "vin0_field", "vin0_clkenb", "vin0_clk"; + renesas,function = "vin0"; + }; + + vin1_pins: vin1 { renesas,groups = "vin1_data8", "vin1_clk"; renesas,function = "vin1"; }; @@ -531,6 +536,18 @@ reg = <0x12>; }; + hdmi-in@4c { + compatible = "adi,adv7612"; + reg = <0x4c>; + remote = <&vin0>; + + port { + hdmi_in_ep: endpoint { + remote-endpoint = <&vin0ep0>; + }; + }; + }; + composite-in@20 { compatible = "adi,adv7180"; reg = <0x20>; @@ -646,6 +663,28 @@ status = "okay"; }; +/* HDMI video input */ +&vin0 { + pinctrl-0 = <&vin0_pins>; + pinctrl-names = "default"; + + status = "ok"; + + port { + #address-cells = <1>; + #size-cells = <0>; + + vin0ep0: endpoint { + remote-endpoint = <&hdmi_in_ep>; + bus-width = <24>; + hsync-active = <0>; + vsync-active = <0>; + pclk-sample = <1>; + data-active = <1>; + }; + }; +}; + /* composite video input */ &vin1 { pinctrl-0 = <&vin1_pins>; -- 1.7.10.4 -- 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 04/20] media: adv7604: document support for ADV7612 dual HDMI input decoder
From: Ian Molton This documentation accompanies the patch adding support for the ADV7612 dual HDMI decoder / repeater chip. Signed-off-by: Ian Molton Reviewed-by: William Towle --- .../devicetree/bindings/media/i2c/adv7604.txt| 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index c27cede..7eafdbc 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -1,15 +1,17 @@ -* Analog Devices ADV7604/11 video decoder with HDMI receiver +* Analog Devices ADV7604/11/12 video decoder with HDMI receiver -The ADV7604 and ADV7611 are multiformat video decoders with an integrated HDMI -receiver. The ADV7604 has four multiplexed HDMI inputs and one analog input, -and the ADV7611 has one HDMI input and no analog input. +The ADV7604 and ADV7611/12 are multiformat video decoders with an integrated +HDMI receiver. The ADV7604 has four multiplexed HDMI inputs and one analog +input, and the ADV7611 has one HDMI input and no analog input. The 7612 is +similar to the 7611 but has 2 HDMI inputs. -These device tree bindings support the ADV7611 only at the moment. +These device tree bindings support the ADV7611/12 only at the moment. Required Properties: - compatible: Must contain one of the following - "adi,adv7611" for the ADV7611 +- "adi,adv7612" for the ADV7612 - reg: I2C slave address @@ -22,10 +24,10 @@ port, in accordance with the video interface bindings defined in Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes are numbered as follows. - Port ADV7611 + Port ADV7611ADV7612 - HDMI 0 - Digital output 1 + HDMI 0 0, 1 + Digital output 12 The digital output port node must contain at least one endpoint. -- 1.7.10.4 -- 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 09/20] media: rcar_vin: Use correct pad number in try_fmt
From: Rob Taylor Fix rcar_vin_try_fmt to use the correct pad number when calling the subdev set_fmt. Previously pad number 0 was always used, resulting in EINVAL if the subdev cares about the pad number (e.g. ADV7612). Signed-off-by: William Towle Taylor Reviewed-by: Rob Taylor --- drivers/media/platform/soc_camera/rcar_vin.c | 29 +- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index b4e9b43..571ab20 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -1707,12 +1707,13 @@ static int rcar_vin_try_fmt(struct soc_camera_device *icd, const struct soc_camera_format_xlate *xlate; struct v4l2_pix_format *pix = &f->fmt.pix; struct v4l2_subdev *sd = soc_camera_to_subdev(icd); - struct v4l2_subdev_pad_config pad_cfg; + struct v4l2_subdev_pad_config pad_cfg[sd->entity.num_pads]; struct v4l2_subdev_format format = { .which = V4L2_SUBDEV_FORMAT_TRY, }; struct v4l2_mbus_framefmt *mf = &format.format; __u32 pixfmt = pix->pixelformat; + struct media_pad *remote_pad; int width, height; int ret; @@ -1744,17 +1745,24 @@ static int rcar_vin_try_fmt(struct soc_camera_device *icd, mf->code = xlate->code; mf->colorspace = pix->colorspace; - ret = v4l2_device_call_until_err(sd->v4l2_dev, soc_camera_grp_id(icd), -pad, set_fmt, &pad_cfg, &format); + remote_pad = media_entity_remote_pad( + &icd->vdev->entity.pads[0]); + format.pad = remote_pad->index; + + ret = v4l2_device_call_until_err(sd->v4l2_dev, + soc_camera_grp_id(icd), pad, + set_fmt, pad_cfg, + &format); if (ret < 0) return ret; - /* Adjust only if VIN cannot scale */ - if (pix->width > mf->width * 2) - pix->width = mf->width * 2; - if (pix->height > mf->height * 3) - pix->height = mf->height * 3; - + /* In case the driver has adjusted 'fmt' to match the +* resolution of the live stream, 'pix' needs to pass this +* change out so that the buffer userland creates for the +* captured image/video has these dimensions +*/ + pix->width = mf->width; + pix->height = mf->height; pix->field = mf->field; pix->colorspace = mf->colorspace; @@ -1769,9 +1777,10 @@ static int rcar_vin_try_fmt(struct soc_camera_device *icd, */ mf->width = VIN_MAX_WIDTH; mf->height = VIN_MAX_HEIGHT; + format.pad = remote_pad->index; ret = v4l2_device_call_until_err(sd->v4l2_dev, soc_camera_grp_id(icd), -pad, set_fmt, &pad_cfg, +pad, set_fmt, pad_cfg, &format); if (ret < 0) { dev_err(icd->parent, -- 1.7.10.4 -- 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 15/20] media: rcar_vin: Don't advertise support for USERPTR
rcar_vin requires physically contiguous buffer, so shouldn't advertise support for USERPTR. Signed-off-by: Rob Taylor Reviewed-by: William Towle --- drivers/media/platform/soc_camera/rcar_vin.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 222002a..b530503 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -1824,7 +1824,7 @@ static int rcar_vin_init_videobuf2(struct vb2_queue *vq, struct soc_camera_host *ici = to_soc_camera_host(icd->parent); vq->type = V4L2_BUF_TYPE_VIDEO_CAPTURE; - vq->io_modes = VB2_MMAP | VB2_USERPTR; + vq->io_modes = VB2_MMAP; vq->drv_priv = icd; vq->ops = &rcar_vin_vb2_ops; vq->mem_ops = &vb2_dma_contig_memops; -- 1.7.10.4 -- 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 05/20] media: adv7604: ability to read default input port from DT
From: Ian Molton Adds support to the adv7604 driver for specifying the default input port in the Device tree. If no value is provided, the driver will be unable to select an input without help from userspace. Tested-by: William Towle Signed-off-by: Ian Molton --- Documentation/devicetree/bindings/media/i2c/adv7604.txt |3 +++ drivers/media/i2c/adv7604.c |8 +++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index 7eafdbc..8337f75 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -47,6 +47,7 @@ Optional Endpoint Properties: If none of hsync-active, vsync-active and pclk-sample is specified the endpoint will use embedded BT.656 synchronization. + - default-input: Select which input is selected after reset. Example: @@ -60,6 +61,8 @@ Example: #address-cells = <1>; #size-cells = <0>; + default-input = <0>; + port@0 { reg = <0>; }; diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index a2abb04..4bde3e1 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -2739,6 +2739,7 @@ static int adv76xx_parse_dt(struct adv76xx_state *state) struct device_node *endpoint; struct device_node *np; unsigned int flags; + u32 v; np = state->i2c_clients[ADV76XX_PAGE_IO]->dev.of_node; @@ -2748,6 +2749,12 @@ static int adv76xx_parse_dt(struct adv76xx_state *state) return -EINVAL; v4l2_of_parse_endpoint(endpoint, &bus_cfg); + + if (!of_property_read_u32(endpoint, "default-input", &v)) + state->pdata.default_input = v; + else + state->pdata.default_input = -1; + of_node_put(endpoint); flags = bus_cfg.bus.parallel.flags; @@ -2786,7 +2793,6 @@ static int adv76xx_parse_dt(struct adv76xx_state *state) /* Hardcode the remaining platform data fields. */ state->pdata.disable_pwrdnb = 0; state->pdata.disable_cable_det_rst = 0; - state->pdata.default_input = -1; state->pdata.blank_data = 1; state->pdata.alt_data_sat = 1; state->pdata.op_format_mode_sel = ADV7604_OP_FORMAT_MODE0; -- 1.7.10.4 -- 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
HDMI and Composite capture on Lager, for kernel 4.1
This is our latest test branch for video support on Lager, ported to kernel 4.1 as per commit 9cae84b32dd52768cf2fd2fcb214c3f570676c4b ("[media] DocBook/media: fix syntax error") on the media-tree master branch last week. Single frame and video capture is working with appropriate test cases for gstreamer, some (minor) quirks notwithstanding. Functionally, this is in more or less the state we need it to be; for the rest of the world we hope we have enhanced the ability to do any necessary debugging on it. The intention is to upstream this version as soon as possible, subject to feedback. NB: for single frame capture, images of appropriate resolutions are created from both composite and HDMI inputs. For best quality video capture we have found that gst-launch-1.0 needs a pipeline specifying width, height, format ("=YUY2" in particular has an appropriate turnaround time for smooth results), and framerate. Enclosed are: [PATCH 01/20] ARM: shmobile: lager dts: Add entries for VIN HDMI [PATCH 02/20] media: adv7180: add of match table [PATCH 03/20] media: adv7604: chip info and formats for ADV7612 [PATCH 04/20] media: adv7604: document support for ADV7612 dual HDMI [PATCH 05/20] media: adv7604: ability to read default input port [PATCH 06/20] ARM: shmobile: lager dts: specify default-input for [PATCH 07/20] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 [PATCH 08/20] media: soc_camera pad-aware driver initialisation [PATCH 09/20] media: rcar_vin: Use correct pad number in try_fmt [PATCH 10/20] media: soc_camera: soc_scale_crop: Use correct pad [PATCH 11/20] media: soc_camera: Fill std field in enum_input [PATCH 12/20] media: soc_camera: Fix error reporting in expbuf [PATCH 13/20] media: soc_camera: v4l2-compliance fixes for querycap [PATCH 14/20] media: rcar_vin: Reject videobufs that are too small [PATCH 15/20] media: rcar_vin: Don't advertise support for USERPTR [PATCH 16/20] media: adv7180: Fix set_pad_format() passing wrong [PATCH 17/20] media: adv7604: Support V4L_FIELD_INTERLACED [PATCH 18/20] media: adv7604: Always query_dv_timings in [PATCH 19/20] media: rcar_vin: Clean up format debugging statements [PATCH 20/20] media: soc_camera: Add debugging for get_formats "Phew!" Cheers, Wills. -- 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 13/20] media: soc_camera: v4l2-compliance fixes for querycap
Fill in bus_info field and zero reserved field. Signed-off-by: Rob Taylor Reviewed-by: William Towle --- drivers/media/platform/soc_camera/soc_camera.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index fd7497e..583c5e6 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -954,6 +954,8 @@ static int soc_camera_querycap(struct file *file, void *priv, WARN_ON(priv != file->private_data); strlcpy(cap->driver, ici->drv_name, sizeof(cap->driver)); + strlcpy(cap->bus_info, "platform:soc_camera", sizeof(cap->bus_info)); + memset(cap->reserved, 0, sizeof(cap->reserved)); return ici->ops->querycap(ici, cap); } -- 1.7.10.4 -- 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 16/20] media: adv7180: Fix set_pad_format() passing wrong format
Return a usable format (and resolution) from adv7180_set_pad_format() in the TRY_FORMAT case Signed-off-by: Rob Taylor Tested-by: William Towle --- drivers/media/i2c/adv7180.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c index 09a96df..ba0b92d5 100644 --- a/drivers/media/i2c/adv7180.c +++ b/drivers/media/i2c/adv7180.c @@ -686,12 +686,14 @@ static int adv7180_set_pad_format(struct v4l2_subdev *sd, adv7180_set_field_mode(state); adv7180_set_power(state, true); } + adv7180_mbus_fmt(sd, framefmt); } else { framefmt = v4l2_subdev_get_try_format(sd, cfg, 0); *framefmt = format->format; + adv7180_mbus_fmt(sd, framefmt); + format->format = *framefmt; } - - return adv7180_mbus_fmt(sd, framefmt); + return 0; } static int adv7180_g_mbus_config(struct v4l2_subdev *sd, -- 1.7.10.4 -- 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 03/20] media: adv7604: chip info and formats for ADV7612
Add support for the ADV7612 chip as implemented on Renesas' Lager board to adv7604.c, including lists for formats/colourspace/timing selection and an IRQ handler. Signed-off-by: William Towle --- drivers/media/i2c/adv7604.c | 83 +-- 1 file changed, 81 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index be3f866..a2abb04 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -80,6 +80,7 @@ MODULE_LICENSE("GPL"); enum adv76xx_type { ADV7604, ADV7611, + ADV7612, }; struct adv76xx_reg_seq { @@ -753,6 +754,23 @@ static const struct adv76xx_format_info adv7611_formats[] = { ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_12BIT }, }; +static const struct adv76xx_format_info adv7612_formats[] = { + { MEDIA_BUS_FMT_RGB888_1X24, ADV76XX_OP_CH_SEL_RGB, true, false, + ADV76XX_OP_MODE_SEL_SDR_444 | ADV76XX_OP_FORMAT_SEL_8BIT }, + { MEDIA_BUS_FMT_YUYV8_2X8, ADV76XX_OP_CH_SEL_RGB, false, false, + ADV76XX_OP_MODE_SEL_SDR_422 | ADV76XX_OP_FORMAT_SEL_8BIT }, + { MEDIA_BUS_FMT_YVYU8_2X8, ADV76XX_OP_CH_SEL_RGB, false, true, + ADV76XX_OP_MODE_SEL_SDR_422 | ADV76XX_OP_FORMAT_SEL_8BIT }, + { MEDIA_BUS_FMT_UYVY8_1X16, ADV76XX_OP_CH_SEL_RBG, false, false, + ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT }, + { MEDIA_BUS_FMT_VYUY8_1X16, ADV76XX_OP_CH_SEL_RBG, false, true, + ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT }, + { MEDIA_BUS_FMT_YUYV8_1X16, ADV76XX_OP_CH_SEL_RGB, false, false, + ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT }, + { MEDIA_BUS_FMT_YVYU8_1X16, ADV76XX_OP_CH_SEL_RGB, false, true, + ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT }, +}; + static const struct adv76xx_format_info * adv76xx_format_info(struct adv76xx_state *state, u32 code) { @@ -2465,6 +2483,11 @@ static void adv7611_setup_irqs(struct v4l2_subdev *sd) io_write(sd, 0x41, 0xd0); /* STDI irq for any change, disable INT2 */ } +static void adv7612_setup_irqs(struct v4l2_subdev *sd) +{ + io_write(sd, 0x41, 0xd0); /* disable INT2 */ +} + static void adv76xx_unregister_clients(struct adv76xx_state *state) { unsigned int i; @@ -2552,6 +2575,19 @@ static const struct adv76xx_reg_seq adv7611_recommended_settings_hdmi[] = { { ADV76XX_REG_SEQ_TERM, 0 }, }; +static const struct adv76xx_reg_seq adv7612_recommended_settings_hdmi[] = { + { ADV76XX_REG(ADV76XX_PAGE_CP, 0x6c), 0x00 }, + { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x9b), 0x03 }, + { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x6f), 0x08 }, + { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x85), 0x1f }, + { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x87), 0x70 }, + { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x57), 0xda }, + { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x58), 0x01 }, + { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x03), 0x98 }, + { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x4c), 0x44 }, + { ADV76XX_REG_SEQ_TERM, 0 }, +}; + static const struct adv76xx_chip_info adv76xx_chip_info[] = { [ADV7604] = { .type = ADV7604, @@ -2640,17 +2676,59 @@ static const struct adv76xx_chip_info adv76xx_chip_info[] = { .field1_vsync_mask = 0x3fff, .field1_vbackporch_mask = 0x3fff, }, + [ADV7612] = { + .type = ADV7612, + .has_afe = false, + .max_port = ADV7604_PAD_HDMI_PORT_B, + .num_dv_ports = 2, + .edid_enable_reg = 0x74, + .edid_status_reg = 0x76, + .lcf_reg = 0xa3, + .tdms_lock_mask = 0x43, + .cable_det_mask = 0x01, + .fmt_change_digital_mask = 0x03, + .formats = adv7612_formats, + .nformats = ARRAY_SIZE(adv7612_formats), + .set_termination = adv7611_set_termination, + .setup_irqs = adv7612_setup_irqs, + .read_hdmi_pixelclock = adv7611_read_hdmi_pixelclock, + .read_cable_det = adv7611_read_cable_det, + .recommended_settings = { + [1] = adv7612_recommended_settings_hdmi, + }, + .num_recommended_settings = { + [1] = ARRAY_SIZE(adv7612_recommended_settings_hdmi), + }, + .page_mask = BIT(ADV76XX_PAGE_IO) | BIT(ADV76XX_PAGE_CEC) | + BIT(ADV76XX_PAGE_INFOFRAME) | BIT(ADV76XX_PAGE_AFE) | + BIT(ADV76XX_PAGE_REP) | BIT(ADV76XX_PAGE_EDID) | + BIT(ADV76XX_PAGE_HDMI) | BIT(ADV76XX_PAGE_CP), + .linewidth_mask = 0x1fff, + .field0_height_mask = 0x1fff, + .field1_height_mask = 0x1fff, + .hfrontporch_mask = 0x1fff, + .hsync_mask = 0x1fff, + .hbackpo
[PATCH 12/20] media: soc_camera: Fix error reporting in expbuf
From: Hans Verkuil Remove unnecessary check and fix the error code for vb1 drivers. Signed-off-by: Hans Verkuil Signed-off-by: Rob Taylor --- drivers/media/platform/soc_camera/soc_camera.c |8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index 5afbf65..fd7497e 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -470,14 +470,10 @@ static int soc_camera_expbuf(struct file *file, void *priv, struct soc_camera_device *icd = file->private_data; struct soc_camera_host *ici = to_soc_camera_host(icd->parent); - if (icd->streamer != file) - return -EBUSY; - /* videobuf2 only */ if (ici->ops->init_videobuf) - return -EINVAL; - else - return vb2_expbuf(&icd->vb2_vidq, p); + return -ENOTTY; + return vb2_expbuf(&icd->vb2_vidq, p); } /* Always entered with .host_lock held */ -- 1.7.10.4 -- 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 08/20] media: soc_camera pad-aware driver initialisation
Add detection of source pad number for drivers aware of the media controller API, so that soc_camera/rcar_vin can create device nodes to support a driver such as adv7604.c (for HDMI on Lager) underneath. Signed-off-by: William Towle Reviewed-by: Rob Taylor --- drivers/media/platform/soc_camera/rcar_vin.c |4 drivers/media/platform/soc_camera/soc_camera.c | 27 +++- include/media/soc_camera.h |1 + 3 files changed, 31 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 0f67646..b4e9b43 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -1364,8 +1364,12 @@ static int rcar_vin_get_formats(struct soc_camera_device *icd, unsigned int idx, struct v4l2_mbus_framefmt *mf = &fmt.format; struct v4l2_rect rect; struct device *dev = icd->parent; + struct media_pad *remote_pad; int shift; + remote_pad = media_entity_remote_pad( + &icd->vdev->entity.pads[0]); + fmt.pad = remote_pad->index; ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, &fmt); if (ret < 0) return ret; diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index d708df4..126d645 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -1293,6 +1293,7 @@ static int soc_camera_probe_finish(struct soc_camera_device *icd) .which = V4L2_SUBDEV_FORMAT_ACTIVE, }; struct v4l2_mbus_framefmt *mf = &fmt.format; + int src_pad_idx = -1; int ret; sd->grp_id = soc_camera_grp_id(icd); @@ -1311,7 +1312,25 @@ static int soc_camera_probe_finish(struct soc_camera_device *icd) } /* At this point client .probe() should have run already */ - ret = soc_camera_init_user_formats(icd); + ret = media_entity_init(&icd->vdev->entity, 1, &icd->pad, 0); + if (!ret) { + for (src_pad_idx = 0; src_pad_idx < sd->entity.num_pads; + src_pad_idx++) + if (sd->entity.pads[src_pad_idx].flags + == MEDIA_PAD_FL_SOURCE) + break; + + if (src_pad_idx < sd->entity.num_pads) { + if (!media_entity_create_link( + &icd->vdev->entity, 0, + &sd->entity, src_pad_idx, + MEDIA_LNK_FL_IMMUTABLE | + MEDIA_LNK_FL_ENABLED)) { + ret = soc_camera_init_user_formats(icd); + } + } + } + if (ret < 0) goto eusrfmt; @@ -1322,6 +1341,7 @@ static int soc_camera_probe_finish(struct soc_camera_device *icd) goto evidstart; /* Try to improve our guess of a reasonable window format */ + fmt.pad = src_pad_idx; if (!v4l2_subdev_call(sd, pad, get_fmt, NULL, &fmt)) { icd->user_width = mf->width; icd->user_height= mf->height; @@ -1335,6 +1355,7 @@ static int soc_camera_probe_finish(struct soc_camera_device *icd) evidstart: soc_camera_free_user_formats(icd); eusrfmt: + media_entity_cleanup(&icd->vdev->entity); soc_camera_remove_device(icd); return ret; @@ -1856,6 +1877,10 @@ static int soc_camera_remove(struct soc_camera_device *icd) if (icd->num_user_formats) soc_camera_free_user_formats(icd); + if (icd->vdev->entity.num_pads) { + media_entity_cleanup(&icd->vdev->entity); + } + if (icd->clk) { /* For the synchronous case */ v4l2_clk_unregister(icd->clk); diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h index 2f6261f..f0c5238 100644 --- a/include/media/soc_camera.h +++ b/include/media/soc_camera.h @@ -42,6 +42,7 @@ struct soc_camera_device { unsigned char devnum; /* Device number per host */ struct soc_camera_sense *sense; /* See comment in struct definition */ struct video_device *vdev; + struct media_pad pad; struct v4l2_ctrl_handler ctrl_handler; const struct soc_camera_format_xlate *current_fmt; struct soc_camera_format_xlate *user_formats; -- 1.7.10.4 -- 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 19/20] media: rcar_vin: Clean up format debugging statements
Pretty print fourcc and code in format debugging statements. Signed-off-by: Rob Taylor Reviewed-by: William Towle --- drivers/media/platform/soc_camera/rcar_vin.c | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index b530503..0bebca5 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -39,6 +39,9 @@ #include "soc_scale_crop.h" +#define pixfmtstr(x) (x) & 0xff, ((x) >> 8) & 0xff, ((x) >> 16) & 0xff, \ + ((x) >> 24) & 0xff + #define DRV_NAME "rcar_vin" /* Register offsets for R-Car VIN */ @@ -1352,10 +1355,12 @@ static int rcar_vin_get_formats(struct soc_camera_device *icd, unsigned int idx, fmt = soc_mbus_get_fmtdesc(code.code); if (!fmt) { - dev_warn(dev, "unsupported format code #%u: %d\n", idx, code.code); + dev_warn(dev, "unsupported format code #%u: %x\n", idx, code.code); return 0; } + dev_dbg(dev, "Supported format: %x (%c%c%c%c)", code.code, pixfmtstr(fmt->fourcc)); + ret = rcar_vin_try_bus_param(icd, fmt->bits_per_sample); if (ret < 0) return 0; @@ -1456,7 +1461,7 @@ static int rcar_vin_get_formats(struct soc_camera_device *icd, unsigned int idx, for (k = 0; xlate && k < n; k++, xlate++) { xlate->host_fmt = &rcar_vin_formats[k]; xlate->code = code.code; - dev_dbg(dev, "Providing format %s using code %d\n", + dev_dbg(dev, "Providing format %s using code %x\n", rcar_vin_formats[k].name, code.code); } break; @@ -1596,8 +1601,8 @@ static int rcar_vin_set_fmt(struct soc_camera_device *icd, enum v4l2_field field; v4l2_std_id std; - dev_dbg(dev, "S_FMT(pix=0x%x, %ux%u)\n", - pixfmt, pix->width, pix->height); + dev_dbg(dev, "S_FMT(pix=%c%c%c%c, %ux%u)\n", + pixfmtstr(pixfmt), pix->width, pix->height); switch (pix->field) { default: @@ -1623,7 +1628,7 @@ static int rcar_vin_set_fmt(struct soc_camera_device *icd, xlate = soc_camera_xlate_by_fourcc(icd, pixfmt); if (!xlate) { - dev_warn(dev, "Format %x not found\n", pixfmt); + dev_warn(dev, "Format %c%c%c%c not found\n", pixfmtstr(pixfmt)); return -EINVAL; } /* Calculate client output geometry */ @@ -1720,11 +1725,14 @@ static int rcar_vin_try_fmt(struct soc_camera_device *icd, int width, height; int ret; + dev_dbg(icd->parent, "TRY_FMT(%c%c%c%c, %ux%u)\n", + pixfmtstr(pix->pixelformat), pix->width, pix->height); + xlate = soc_camera_xlate_by_fourcc(icd, pixfmt); if (!xlate) { xlate = icd->current_fmt; - dev_dbg(icd->parent, "Format %x not found, keeping %x\n", - pixfmt, xlate->host_fmt->fourcc); + dev_dbg(icd->parent, "Format %c%c%c%c not found, keeping %x\n", + pixfmtstr(pixfmt), xlate->host_fmt->fourcc); pixfmt = xlate->host_fmt->fourcc; pix->pixelformat = pixfmt; pix->colorspace = icd->colorspace; -- 1.7.10.4 -- 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 v8 8/8] DT: samsung-fimc: Add examples for samsung,flash-led property
Hi Sakari, On 05/21/2015 12:00 AM, Sakari Ailus wrote: Hi Jacek, On Wed, May 20, 2015 at 04:10:15PM +0200, Jacek Anaszewski wrote: This patch adds examples for samsung,flash-led property to the samsung-fimc.txt. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Sylwester Nawrocki Cc: devicet...@vger.kernel.org --- .../devicetree/bindings/media/samsung-fimc.txt |4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt index 922d6f8..57edffa 100644 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt @@ -126,6 +126,8 @@ Example: clocks = <&camera 1>; clock-names = "mclk"; + samsung,flash-led = <&front_cam_flash>; + port { s5k6aa_ep: endpoint { remote-endpoint = <&fimc0_ep>; @@ -147,6 +149,8 @@ Example: clocks = <&camera 0>; clock-names = "mclk"; + samsung,flash-led = <&rear_cam_flash>; + port { s5c73m3_1: endpoint { data-lanes = <1 2 3 4>; Oops. I missed this property would have ended to the sensor's DT node. I don't think we should have properties here that are parsed by another driver --- let's discuss this tomorrow. exynos4-is driver already parses sensor nodes (at least their 'port' sub-nodes). There are two main options that I can think of --- either put the property under the bridge (ISP) driver's device node as a temporary solution that works on a few ISP drivers, or think how sensor modules should be modelled, in which case we'd have some idea how lens device would be taken into account. Cc Sebastian. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback
On 2015-05-21 09:53, Antti Seppälä wrote: On 20 May 2015 at 23:45, David Härdeman wrote: On Wed, May 20, 2015 at 10:26:54PM +0300, Antti Seppälä wrote: On 20 May 2015 at 21:29, David Härdeman wrote: On Wed, May 20, 2015 at 07:46:21PM +0300, Antti Seppälä wrote: On 19 May 2015 at 23:38, David Härdeman wrote: On Tue, Mar 31, 2015 at 08:48:06PM +0300, Antti Seppälä wrote: From: James Hogan Add a callback to raw ir handlers for encoding and modulating a scancode to a set of raw events. This could be used for transmit, or for converting a wakeup scancode filter to a form that is more suitable for raw hardware wake up filters. Signed-off-by: James Hogan Signed-off-by: Antti Seppälä Cc: David Härdeman --- Notes: Changes in v3: - Ported to apply against latest media-tree Changes in v2: - Alter encode API to return -ENOBUFS when there isn't enough buffer space. When this occurs all buffer contents must have been written with the partial encoding of the scancode. This is to allow drivers such as nuvoton-cir to provide a shorter buffer and still get a useful partial encoding for the wakeup pattern. drivers/media/rc/rc-core-priv.h | 2 ++ drivers/media/rc/rc-ir-raw.c| 37 + include/media/rc-core.h | 3 +++ 3 files changed, 42 insertions(+) diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h index b68d4f76..122c25f 100644 --- a/drivers/media/rc/rc-core-priv.h +++ b/drivers/media/rc/rc-core-priv.h @@ -25,6 +25,8 @@ struct ir_raw_handler { u64 protocols; /* which are handled by this handler */ int (*decode)(struct rc_dev *dev, struct ir_raw_event event); + int (*encode)(u64 protocols, const struct rc_scancode_filter *scancode, +struct ir_raw_event *events, unsigned int max); /* These two should only be used by the lirc decoder */ int (*raw_register)(struct rc_dev *dev); diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c index b732ac6..dd47fe5 100644 --- a/drivers/media/rc/rc-ir-raw.c +++ b/drivers/media/rc/rc-ir-raw.c @@ -246,6 +246,43 @@ static int change_protocol(struct rc_dev *dev, u64 *rc_type) return 0; } +/** + * ir_raw_encode_scancode() - Encode a scancode as raw events + * + * @protocols:permitted protocols + * @scancode: scancode filter describing a single scancode + * @events: array of raw events to write into + * @max: max number of raw events + * + * Attempts to encode the scancode as raw events. + * + * Returns: The number of events written. + *-ENOBUFS if there isn't enough space in the array to fit the + *encoding. In this case all @max events will have been written. + *-EINVAL if the scancode is ambiguous or invalid, or if no + *compatible encoder was found. + */ +int ir_raw_encode_scancode(u64 protocols, Why a bitmask of protocols and not a single protocol enum? What's the use case for encoding a given scancode according to one out of a number of protocols (and not even knowing which one)?? I think bitmask was used simply for consistency reasons. Most of the rc-core handles protocols in a bitmask (u64 protocols or some variant of it). Yes, all the parts where multiple protocols make sense use a bitmap of protocols. If there's any part which uses a bitmap where only one protocol makes sense that'd be a bug... Especially in the decoders the dev->enabled_protocols is used to mean "decode any of these protocols but I don't care which one" and the encoders were written to follow that logic. The fact that you might want to be able to receive and decode more than one protocol has no bearing on encoding when you're supposed to know what it is you want to encode >From ir driver point of view it was also kind of nice to use the u64 enabled_wakeup_protocols from struct rc_dev which already exists and is manipulated with the same sysfs code as the enabled_protocols bitmask. But it makes no sense? "here's a scancode...I have no idea what it means since only knowing the protocol allows you to make any sense of the scancode...but please encode it to something...anything" Well it made sense from code simplicity point of view :) But yes current use cases will most likely be valid when encoding only to a single specific protocol at a time. However having a flexible api allows for future expansion though if a new use case is needed to be supported. And like I said earlier using bitmask is also consistent with what rc-core already has. * drivers/media/rc/img-ir/img-ir-hw.c only seems to support one protocol at a time * drivers/media/rc/rc-loopback.c doesn't care * drivers/media/rc/winbond-cir.c seems hardware-wise very similar to nuvoton-cir.c, was not converted to use the in-kernel encoders...has a private implementation * drivers/media/rc/n
[PATCH] b2c2: Mismatch in config ifdefs for SkystarS2
Compilation warning issued by kbuild test robot: >> drivers/media/common/b2c2/flexcop-fe-tuner.c:31:12: warning: >> 'flexcop_fe_request_firmware' defined but not used [-Wunused-function] static int flexcop_fe_request_firmware(struct dvb_frontend *fe, This patch fixes a mismatch in Kconfig define checks. One had a check for just CX24120, the other is checking for both CX24120 and ISL6421. Signed-off-by: Jemma Denson --- drivers/media/common/b2c2/flexcop-fe-tuner.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/common/b2c2/flexcop-fe-tuner.c b/drivers/media/common/b2c2/flexcop-fe-tuner.c index 2426062..a8d562f 100644 --- a/drivers/media/common/b2c2/flexcop-fe-tuner.c +++ b/drivers/media/common/b2c2/flexcop-fe-tuner.c @@ -27,7 +27,7 @@ #define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \ (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE))) -#if FE_SUPPORTED(BCM3510) || FE_SUPPORTED(CX24120) +#if FE_SUPPORTED(BCM3510) || (FE_SUPPORTED(CX24120) && FE_SUPPORTED(ISL6421)) static int flexcop_fe_request_firmware(struct dvb_frontend *fe, const struct firmware **fw, char *name) { -- 2.1.0 -- 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 v8 5/8] exynos4-is: Add support for v4l2-flash subdevs
On 05/21/2015 09:46 AM, Sakari Ailus wrote: Hi Jacek, On Wed, May 20, 2015 at 04:10:12PM +0200, Jacek Anaszewski wrote: This patch adds support for external v4l2-flash devices. The support includes parsing "samsung,flash-led" DT property and asynchronous subdevice registration. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Sylwester Nawrocki --- drivers/media/platform/exynos4-is/media-dev.c | 39 +++-- drivers/media/platform/exynos4-is/media-dev.h | 13 - 2 files changed, 49 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..80cecd8 100644 --- a/drivers/media/platform/exynos4-is/media-dev.c +++ b/drivers/media/platform/exynos4-is/media-dev.c @@ -451,6 +451,28 @@ rpm_put: return ret; } +static void fimc_md_register_flash_entities(struct fimc_md *fmd) +{ + int i; + + fmd->num_flashes = 0; + + for (i = 0; i < fmd->num_sensors; i++) { + const struct device_node *np = + fmd->sensor[i].asd.match.of.node; + const int nf = fmd->num_flashes; + + np = of_parse_phandle(np, "samsung,flash-led", 0); + if (!np) + continue; + + fmd->flash[nf].asd.match_type = V4L2_ASYNC_MATCH_OF; + fmd->flash[nf].asd.match.of.node = np; + fmd->async_subdevs[fmd->num_sensors + nf] = &fmd->flash[nf].asd; + fmd->num_flashes++; + } +} + static int __of_get_csis_id(struct device_node *np) { u32 reg = 0; @@ -1275,6 +1297,15 @@ static int subdev_notifier_bound(struct v4l2_async_notifier *notifier, struct fimc_sensor_info *si = NULL; int i; + /* Register flash subdev if detected any */ + for (i = 0; i < ARRAY_SIZE(fmd->flash); i++) { + if (fmd->flash[i].asd.match.of.node == subdev->of_node) { Does the index of a particular sub-device index matter? Could you just use the next available one? Having the positions of sensor sub-devices kept in synch with the positions of associated flash sub-devices in the 'flash' array allows to avoid the addition o a condition for checking if the element of the flash array is available. There would be no need to for the check anything here, please see how the omap3isp driver does it --- it's in isp_subdev_notifier_bound() drivers/media/platform/omap3isp/isp.c . This 'for' loop allows to detect that the sub-device being bound is of flash type and basing on that we can exit the function at this point. Otherwise some guards would have to be added in the remaining part of the function. + 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) -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] leds: aat1290: Pass dev and dev->of_node to v4l2_flash_init()
Hi Jacek, On Thu, May 21, 2015 at 10:54:07AM +0200, Jacek Anaszewski wrote: > Hi Sakari, > > On 05/20/2015 04:31 PM, Sakari Ailus wrote: > >Hi Jacek, > > > >On Wed, May 20, 2015 at 03:47:25PM +0200, Jacek Anaszewski wrote: > >... > >>--- a/drivers/leds/leds-aat1290.c > >>+++ b/drivers/leds/leds-aat1290.c > >>@@ -524,9 +524,8 @@ static int aat1290_led_probe(struct > >>platform_device *pdev) > >> led_cdev->dev->of_node = sub_node; > >> > >> /* Create V4L2 Flash subdev. */ > >>-led->v4l2_flash = v4l2_flash_init(fled_cdev, > >>- &v4l2_flash_ops, > >>- &v4l2_sd_cfg); > >>+led->v4l2_flash = v4l2_flash_init(dev, NULL, fled_cdev, > >>+ &v4l2_flash_ops, &v4l2_sd_cfg); > > > >Here the first argument should be led_cdev->dev, not dev, which is > >&pdev->dev, whereas led_cdev->dev is returned by > >device_create_with_groups (it takes dev as a parent) called from > >led_classdev_register. > > The reason for this is the fact that pdev->dev has its of_node > field initialized, which makes v4l2_async trying to match > subdev by parent node of a LED device, not by sub-LED related > DT node. > >>> > >>>If v4l2_subdev->of_node is set, then it won't be replaced with one from > >>>struct device. I.e. you need to provide of_node pointer only if it's > >>>different from dev->of_node. > >>> > >> > >>It will always be different since dev->of_node pointer is related > >>to the main DT node of LED device, whereas each LED connected to it > >>must be expressed in the form of sub-node, as > >>Documentation/devicetree/bindings/leds/common.txt DT states. > > > >You can still refer to the device's root device_node using a phandle. > > Why should I need to refer to the device's root node? > > What I meant here was that DT documentation enforces that even if > there is a single LED connected to the device it has to be expressed > as a sub-node anyway. Each LED will have to be matched by the phandle > to the sub-node representing it. This implies that v4l2_subdev->of_node > (related to sub-LED DT node) will be always different from dev->of_node > (related to LED controller DT node). >From driver point of view this makes no difference; it's just easier to parse if you don't refer to the LEDs separately. I think this is a bit special case; nowadays many LED flash controllers drive two LEDs. > > >Say, if you have a LED flash controller with an indicator. It's intended to > >be used together with the flash LED, and the existing as3645a driver exposes > >it through the same sub-device. I think that'd make sense with LED class > >driver as well (i.e. you'd have two LED class devices but a single > >sub-device). Small changes to the wrapper would be needed. > > > > How the sub-device name should look like then? We would have to > concatenate somehow both LED class device names? It'd be different, i.e. there would be no flash or indicator in the name. -- 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
[PATCH linuxtv-media] cx24120: cx24120_calculate_ber_window() can be static
Signed-off-by: Fengguang Wu --- cx24120.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/cx24120.c b/drivers/media/dvb-frontends/cx24120.c index 2d46780..edff79a 100644 --- a/drivers/media/dvb-frontends/cx24120.c +++ b/drivers/media/dvb-frontends/cx24120.c @@ -803,7 +803,7 @@ static int cx24120_get_fec(struct dvb_frontend *fe) } /* Calculate ber window time */ -void cx24120_calculate_ber_window(struct cx24120_state *state, u32 rate) +static void cx24120_calculate_ber_window(struct cx24120_state *state, u32 rate) { struct dvb_frontend *fe = &state->frontend; struct dtv_frontend_properties *c = &fe->dtv_property_cache; -- 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
[linuxtv-media:master 1013/1029] drivers/media/dvb-frontends/cx24120.c:806:6: sparse: symbol 'cx24120_calculate_ber_window' was not declared. Should it be static?
tree: git://linuxtv.org/media_tree.git master head: 2a80f296422a01178d0a993479369e94f5830127 commit: ddcb252e41c15b360c0e9a172fbd29d3f0ed18cd [1013/1029] [media] cx24120: Add in dvbv5 stats for bit error rate reproduce: # apt-get install sparse git checkout ddcb252e41c15b360c0e9a172fbd29d3f0ed18cd make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/media/dvb-frontends/cx24120.c:806:6: sparse: symbol >> 'cx24120_calculate_ber_window' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- 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 17/20] media: adv7604: Support V4L_FIELD_INTERLACED
On 21/05/15 07:10, Hans Verkuil wrote: > On 05/20/2015 06:39 PM, William Towle wrote: >> When hardware reports interlaced input, correctly set field to >> V4L_FIELD_INTERLACED ini adv76xx_fill_format. >> >> Signed-off-by: Rob Taylor >> Reviewed-by: William Towle >> --- >> drivers/media/i2c/adv7604.c |7 ++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c >> index 4bde3e1..d77ee1f 100644 >> --- a/drivers/media/i2c/adv7604.c >> +++ b/drivers/media/i2c/adv7604.c >> @@ -1791,7 +1791,12 @@ static void adv76xx_fill_format(struct adv76xx_state >> *state, >> >> format->width = state->timings.bt.width; >> format->height = state->timings.bt.height; >> -format->field = V4L2_FIELD_NONE; >> + >> +if (state->timings.bt.interlaced) >> +format->field= V4L2_FIELD_INTERLACED; > > No, this should be FIELD_ALTERNATE. FIELD_INTERLACED means that the two fields > are interlaced into a single frame buffer, with FIELD_ALTERNATE each buffer > contains one field. And when capturing v4l2_buffer should return which field > (TOP/BOTTOM) the buffer contains. It also complicates cropping/composing: the > crop rectangle is in frame coordinates, composing uses field coordinates. > The vivid driver handles this correctly and can be used as a reference. > > OK, that makes sense. I think for now we'll just drop this patch from the series until we can test this properly - its a bit undercooked.. > Also, no space before the '='. Please add. > > You might be interested in this patch series as well: > > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/90578 Ah yes, this does look useful. > I'm thinking of doing some interlaced tests myself, possibly this weekend, > using the adv7604. That would be great, happy to test anything on our side. Thanks Rob > Regards, > > Hans > >> +else >> +format->field= V4L2_FIELD_NONE; >> + >> format->colorspace = V4L2_COLORSPACE_SRGB; >> >> if (state->timings.bt.flags & V4L2_DV_FL_IS_CE_VIDEO) >> > -- 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 v8 5/8] exynos4-is: Add support for v4l2-flash subdevs
Hi Jacek, On Thu, May 21, 2015 at 11:39:35AM +0200, Jacek Anaszewski wrote: > > > On 05/21/2015 09:46 AM, Sakari Ailus wrote: > >Hi Jacek, > > > >On Wed, May 20, 2015 at 04:10:12PM +0200, Jacek Anaszewski wrote: > >>This patch adds support for external v4l2-flash devices. > >>The support includes parsing "samsung,flash-led" DT property > >>and asynchronous subdevice registration. > >> > >>Signed-off-by: Jacek Anaszewski > >>Acked-by: Kyungmin Park > >>Cc: Sylwester Nawrocki > >>--- > >> drivers/media/platform/exynos4-is/media-dev.c | 39 > >> +++-- > >> drivers/media/platform/exynos4-is/media-dev.h | 13 - > >> 2 files changed, 49 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..80cecd8 100644 > >>--- a/drivers/media/platform/exynos4-is/media-dev.c > >>+++ b/drivers/media/platform/exynos4-is/media-dev.c > >>@@ -451,6 +451,28 @@ rpm_put: > >>return ret; > >> } > >> > >>+static void fimc_md_register_flash_entities(struct fimc_md *fmd) > >>+{ > >>+ int i; > >>+ > >>+ fmd->num_flashes = 0; > >>+ > >>+ for (i = 0; i < fmd->num_sensors; i++) { > >>+ const struct device_node *np = > >>+ fmd->sensor[i].asd.match.of.node; > >>+ const int nf = fmd->num_flashes; > >>+ > >>+ np = of_parse_phandle(np, "samsung,flash-led", 0); > >>+ if (!np) > >>+ continue; > >>+ > >>+ fmd->flash[nf].asd.match_type = V4L2_ASYNC_MATCH_OF; > >>+ fmd->flash[nf].asd.match.of.node = np; > >>+ fmd->async_subdevs[fmd->num_sensors + nf] = &fmd->flash[nf].asd; > >>+ fmd->num_flashes++; > >>+ } > >>+} > >>+ > >> static int __of_get_csis_id(struct device_node *np) > >> { > >>u32 reg = 0; > >>@@ -1275,6 +1297,15 @@ static int subdev_notifier_bound(struct > >>v4l2_async_notifier *notifier, > >>struct fimc_sensor_info *si = NULL; > >>int i; > >> > >>+ /* Register flash subdev if detected any */ > >>+ for (i = 0; i < ARRAY_SIZE(fmd->flash); i++) { > >>+ if (fmd->flash[i].asd.match.of.node == subdev->of_node) { > > > >Does the index of a particular sub-device index matter? Could you just use > >the next available one? > > Having the positions of sensor sub-devices kept in synch with > the positions of associated flash sub-devices in the 'flash' array > allows to avoid the addition o a condition for checking if the element > of the flash array is available. > > >There would be no need to for the check anything here, please see how the > >omap3isp driver does it --- it's in isp_subdev_notifier_bound() > >drivers/media/platform/omap3isp/isp.c . > > This 'for' loop allows to detect that the sub-device being bound > is of flash type and basing on that we can exit the function > at this point. Otherwise some guards would have to be added in > the remaining part of the function. You have that information in fimc_md_register_flash_entities() but you're not storing that. A common struct for all async sub-device would help. I think you could associate sensors to flashes the same way. -- 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: [PATCH v8 8/8] DT: samsung-fimc: Add examples for samsung,flash-led property
Hi Jacek, On Thu, May 21, 2015 at 11:10:49AM +0200, Jacek Anaszewski wrote: > Hi Sakari, > > On 05/21/2015 12:00 AM, Sakari Ailus wrote: > >Hi Jacek, > > > >On Wed, May 20, 2015 at 04:10:15PM +0200, Jacek Anaszewski wrote: > >>This patch adds examples for samsung,flash-led property to the > >>samsung-fimc.txt. > >> > >>Signed-off-by: Jacek Anaszewski > >>Acked-by: Kyungmin Park > >>Cc: Sylwester Nawrocki > >>Cc: devicet...@vger.kernel.org > >>--- > >> .../devicetree/bindings/media/samsung-fimc.txt |4 > >> 1 file changed, 4 insertions(+) > >> > >>diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt > >>b/Documentation/devicetree/bindings/media/samsung-fimc.txt > >>index 922d6f8..57edffa 100644 > >>--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt > >>+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt > >>@@ -126,6 +126,8 @@ Example: > >>clocks = <&camera 1>; > >>clock-names = "mclk"; > >> > >>+ samsung,flash-led = <&front_cam_flash>; > >>+ > >>port { > >>s5k6aa_ep: endpoint { > >>remote-endpoint = <&fimc0_ep>; > >>@@ -147,6 +149,8 @@ Example: > >>clocks = <&camera 0>; > >>clock-names = "mclk"; > >> > >>+ samsung,flash-led = <&rear_cam_flash>; > >>+ > >>port { > >>s5c73m3_1: endpoint { > >>data-lanes = <1 2 3 4>; > > > >Oops. I missed this property would have ended to the sensor's DT node. I > >don't think we should have properties here that are parsed by another > >driver --- let's discuss this tomorrow. > > exynos4-is driver already parses sensor nodes (at least their 'port' > sub-nodes). If you read the code and the comment, it looks like something that should be done better but hasn't been done yet. :-) That's something we should avoid. Also, flash devices are by far more common than external ISPs I presume. -- 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: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback
On 21 May 2015 at 12:14, David Härdeman wrote: > On 2015-05-21 09:53, Antti Seppälä wrote: >> >> On 20 May 2015 at 23:45, David Härdeman wrote: >>> >>> On Wed, May 20, 2015 at 10:26:54PM +0300, Antti Seppälä wrote: On 20 May 2015 at 21:29, David Härdeman wrote: > > On Wed, May 20, 2015 at 07:46:21PM +0300, Antti Seppälä wrote: >> >> On 19 May 2015 at 23:38, David Härdeman wrote: >>> >>> On Tue, Mar 31, 2015 at 08:48:06PM +0300, Antti Seppälä wrote: From: James Hogan Add a callback to raw ir handlers for encoding and modulating a scancode to a set of raw events. This could be used for transmit, or for converting a wakeup scancode filter to a form that is more suitable for raw hardware wake up filters. Signed-off-by: James Hogan Signed-off-by: Antti Seppälä Cc: David Härdeman --- Notes: Changes in v3: - Ported to apply against latest media-tree Changes in v2: - Alter encode API to return -ENOBUFS when there isn't enough buffer space. When this occurs all buffer contents must have been written with the partial encoding of the scancode. This is to allow drivers such as nuvoton-cir to provide a shorter buffer and still get a useful partial encoding for the wakeup pattern. drivers/media/rc/rc-core-priv.h | 2 ++ drivers/media/rc/rc-ir-raw.c| 37 + include/media/rc-core.h | 3 +++ 3 files changed, 42 insertions(+) diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h index b68d4f76..122c25f 100644 --- a/drivers/media/rc/rc-core-priv.h +++ b/drivers/media/rc/rc-core-priv.h @@ -25,6 +25,8 @@ struct ir_raw_handler { u64 protocols; /* which are handled by this handler */ int (*decode)(struct rc_dev *dev, struct ir_raw_event event); + int (*encode)(u64 protocols, const struct rc_scancode_filter *scancode, +struct ir_raw_event *events, unsigned int max); /* These two should only be used by the lirc decoder */ int (*raw_register)(struct rc_dev *dev); diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c index b732ac6..dd47fe5 100644 --- a/drivers/media/rc/rc-ir-raw.c +++ b/drivers/media/rc/rc-ir-raw.c @@ -246,6 +246,43 @@ static int change_protocol(struct rc_dev *dev, u64 *rc_type) return 0; } +/** + * ir_raw_encode_scancode() - Encode a scancode as raw events + * + * @protocols:permitted protocols + * @scancode: scancode filter describing a single scancode + * @events: array of raw events to write into + * @max: max number of raw events + * + * Attempts to encode the scancode as raw events. + * + * Returns: The number of events written. + *-ENOBUFS if there isn't enough space in the array to fit the + *encoding. In this case all @max events will have been written. + *-EINVAL if the scancode is ambiguous or invalid, or if no + *compatible encoder was found. + */ +int ir_raw_encode_scancode(u64 protocols, >>> >>> >>> Why a bitmask of protocols and not a single protocol enum? What's the >>> use case for encoding a given scancode according to one out of a >>> number >>> of protocols (and not even knowing which one)?? >>> >> >> I think bitmask was used simply for consistency reasons. Most of the >> rc-core handles protocols in a bitmask (u64 protocols or some variant >> of it). > > > Yes, all the parts where multiple protocols make sense use a bitmap of > protocols. If there's any part which uses a bitmap where only one > protocol makes sense that'd be a bug... > >> Especially in the decoders the dev->enabled_protocols is used >> to mean "decode any of these protocols but I don't care which one" and >> the encoders were written to follow that logic. > > > The fact that you might want to be able to receive and decode more than > one protocol has no bearing on encoding when you're supposed to know > what it is you want to encode > > >From ir driver point of view it was also kind of nice to use the u64 >> >> enabled_wakeup_protocols from struct rc_dev which already exists and >
[linuxtv-media:master 1023/1029] drivers/media/pci/cobalt/cobalt-driver.c:299:32: sparse: Using plain integer as NULL pointer
tree: git://linuxtv.org/media_tree.git master head: 2a80f296422a01178d0a993479369e94f5830127 commit: 85756a069c55e0315ac5990806899cfb607b987f [1023/1029] [media] cobalt: add new driver reproduce: # apt-get install sparse git checkout 85756a069c55e0315ac5990806899cfb607b987f make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/media/pci/cobalt/cobalt-driver.c:299:32: sparse: Using plain integer >> as NULL pointer >> drivers/media/pci/cobalt/cobalt-driver.c:303:32: sparse: Using plain integer >> as NULL pointer -- >> drivers/media/pci/cobalt/cobalt-flash.c:39:36: sparse: incorrect type in >> initializer (different address spaces) drivers/media/pci/cobalt/cobalt-flash.c:39:36:expected struct cobalt *cobalt drivers/media/pci/cobalt/cobalt-flash.c:39:36:got void [noderef] *virt >> drivers/media/pci/cobalt/cobalt-flash.c:54:36: sparse: incorrect type in >> initializer (different address spaces) drivers/media/pci/cobalt/cobalt-flash.c:54:36:expected struct cobalt *cobalt drivers/media/pci/cobalt/cobalt-flash.c:54:36:got void [noderef] *virt >> drivers/media/pci/cobalt/cobalt-flash.c:63:36: sparse: incorrect type in >> initializer (different address spaces) drivers/media/pci/cobalt/cobalt-flash.c:63:36:expected struct cobalt *cobalt drivers/media/pci/cobalt/cobalt-flash.c:63:36:got void [noderef] *virt >> drivers/media/pci/cobalt/cobalt-flash.c:82:36: sparse: incorrect type in >> initializer (different address spaces) drivers/media/pci/cobalt/cobalt-flash.c:82:36:expected struct cobalt *cobalt drivers/media/pci/cobalt/cobalt-flash.c:82:36:got void [noderef] *virt >> drivers/media/pci/cobalt/cobalt-flash.c:107:19: sparse: incorrect type in >> assignment (different address spaces) drivers/media/pci/cobalt/cobalt-flash.c:107:19:expected void [noderef] *virt drivers/media/pci/cobalt/cobalt-flash.c:107:19:got struct cobalt *cobalt -- >> drivers/media/pci/cobalt/cobalt-i2c.c:130:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:147:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:151:26: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:156:34: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:206:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:210:26: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:215:34: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:225:27: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:335:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:336:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:337:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:348:34: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:352:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:353:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:356:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:357:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-i2c.c:359:17: sparse: dereference of noderef >> expression -- >> drivers/media/pci/cobalt/cobalt-irq.c:62:33: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:64:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:65:23: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:72:21: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:73:25: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:74:25: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:82:33: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:83:33: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:91:25: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:94:23: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:103:25: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:107:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:109:17: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:116:13: sparse: dereference of noderef >> expression >> drivers/media/pci/cobalt/cobalt-irq.c:119
Re: [PATCH 4/5] leds: aat1290: Pass dev and dev->of_node to v4l2_flash_init()
Hi Sakari On 05/21/2015 12:06 PM, Sakari Ailus wrote: [...] On Wed, May 20, 2015 at 03:47:25PM +0200, Jacek Anaszewski wrote: ... --- a/drivers/leds/leds-aat1290.c +++ b/drivers/leds/leds-aat1290.c @@ -524,9 +524,8 @@ static int aat1290_led_probe(struct platform_device *pdev) led_cdev->dev->of_node = sub_node; /* Create V4L2 Flash subdev. */ -led->v4l2_flash = v4l2_flash_init(fled_cdev, - &v4l2_flash_ops, - &v4l2_sd_cfg); +led->v4l2_flash = v4l2_flash_init(dev, NULL, fled_cdev, + &v4l2_flash_ops, &v4l2_sd_cfg); Here the first argument should be led_cdev->dev, not dev, which is &pdev->dev, whereas led_cdev->dev is returned by device_create_with_groups (it takes dev as a parent) called from led_classdev_register. The reason for this is the fact that pdev->dev has its of_node field initialized, which makes v4l2_async trying to match subdev by parent node of a LED device, not by sub-LED related DT node. If v4l2_subdev->of_node is set, then it won't be replaced with one from struct device. I.e. you need to provide of_node pointer only if it's different from dev->of_node. It will always be different since dev->of_node pointer is related to the main DT node of LED device, whereas each LED connected to it must be expressed in the form of sub-node, as Documentation/devicetree/bindings/leds/common.txt DT states. You can still refer to the device's root device_node using a phandle. Why should I need to refer to the device's root node? What I meant here was that DT documentation enforces that even if there is a single LED connected to the device it has to be expressed as a sub-node anyway. Each LED will have to be matched by the phandle to the sub-node representing it. This implies that v4l2_subdev->of_node (related to sub-LED DT node) will be always different from dev->of_node (related to LED controller DT node). From driver point of view this makes no difference; it's just easier to parse if you don't refer to the LEDs separately. I think this is a bit special case; nowadays many LED flash controllers drive two LEDs. As I understand, your stance is as follows: - second argument to v4l2_flash_init needn't always be initialized because some LEDs could be referred to by the phandle to the parent node (e.g. flash LED and indicator under common sub-device) If this is true, than how we would handle the situation where there is a flash LED controller with two separate flash LEDs and one of them is associated with indicator LED? Say, if you have a LED flash controller with an indicator. It's intended to be used together with the flash LED, and the existing as3645a driver exposes it through the same sub-device. I think that'd make sense with LED class driver as well (i.e. you'd have two LED class devices but a single sub-device). Small changes to the wrapper would be needed. How the sub-device name should look like then? We would have to concatenate somehow both LED class device names? It'd be different, i.e. there would be no flash or indicator in the name. Currently there is no such a requirement too. As we discussed it few months ago v4l2-flash sub-device name should be composed: - for I2C devices " -" - for GPIO driven devices: -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback
On 2015-05-21 13:51, Antti Seppälä wrote: On 21 May 2015 at 12:14, David Härdeman wrote: I'm talking about ir_raw_encode_scancode() which is entirely broken in its current state. It will, given more than one enabled protocol, encode a scancode to pulse/space events according to the rules of a randomly chosen protocol. That random selection will be influenced by things like *module load order* (independent of the separate fact that passing multiple protocols to it is completely bogus in the first place). To be clear: the same scancode may be encoded differently depending on if you've load the nec decoder before or after the rc5 decoder! That kind of behavior can't go into a release kernel (Mauro...). So... if the ir_raw_handler_list is sorted to eliminate the randomness caused by module load ordering you will be happy (or happier)? No, cause it's a horrible hack. And the caller of ir_raw_handler_list() still has no idea of knowing (given more than one protocol) which protocol a given scancode will be encoded according to. That is something that could be useful even for the ir-decoding functionality and might be worth a separate patch. Useful how? -- 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] return BUF_STATE_ERROR if streaming stopped during acquisition
Signed-off-by: Martin Kaltenbrunner Signed-off-by: Florian Echtler --- drivers/input/touchscreen/sur40.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/input/touchscreen/sur40.c b/drivers/input/touchscreen/sur40.c index 8add986..8be7b9b 100644 --- a/drivers/input/touchscreen/sur40.c +++ b/drivers/input/touchscreen/sur40.c @@ -438,6 +438,10 @@ static void sur40_process_video(struct sur40_state *sur40) dev_dbg(sur40->dev, "image acquired\n"); + /* return error if streaming was stopped in the meantime */ + if (sur40->sequence == -1) + goto err_poll; + /* mark as finished */ v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp); new_buf->vb.v4l2_buf.sequence = sur40->sequence++; @@ -723,6 +727,7 @@ static int sur40_start_streaming(struct vb2_queue *vq, unsigned int count) static void sur40_stop_streaming(struct vb2_queue *vq) { struct sur40_state *sur40 = vb2_get_drv_priv(vq); + sur40->sequence = -1; /* Release all active buffers */ return_all_buffers(sur40, VB2_BUF_STATE_ERROR); -- 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] add frame size/frame rate query functions
Signed-off-by: Martin Kaltenbrunner Signed-off-by: Florian Echtler --- drivers/input/touchscreen/sur40.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drivers/input/touchscreen/sur40.c b/drivers/input/touchscreen/sur40.c index e707b8d..d860d05 100644 --- a/drivers/input/touchscreen/sur40.c +++ b/drivers/input/touchscreen/sur40.c @@ -778,6 +778,33 @@ static int sur40_vidioc_enum_fmt(struct file *file, void *priv, return 0; } +static int sur40_vidioc_enum_framesizes(struct file *file, void *priv, + struct v4l2_frmsizeenum *f) +{ + if ((f->index != 0) || (f->pixel_format != V4L2_PIX_FMT_GREY)) + return -EINVAL; + + f->type = V4L2_FRMSIZE_TYPE_DISCRETE; + f->discrete.width = sur40_video_format.width; + f->discrete.height = sur40_video_format.height; + return 0; +} + +static int sur40_vidioc_enum_frameintervals(struct file *file, void *priv, + struct v4l2_frmivalenum *f) +{ + if ((f->index > 1) || (f->pixel_format != V4L2_PIX_FMT_GREY) + || (f->width != sur40_video_format.width) + || (f->height != sur40_video_format.height)) + return -EINVAL; + + f->type = V4L2_FRMIVAL_TYPE_DISCRETE; + f->discrete.denominator = 60/(f->index+1); + f->discrete.numerator = 1; + return 0; +} + + static const struct usb_device_id sur40_table[] = { { USB_DEVICE(ID_MICROSOFT, ID_SUR40) }, /* Samsung SUR40 */ { } /* terminating null entry */ @@ -829,6 +856,9 @@ static const struct v4l2_ioctl_ops sur40_video_ioctl_ops = { .vidioc_s_fmt_vid_cap = sur40_vidioc_fmt, .vidioc_g_fmt_vid_cap = sur40_vidioc_fmt, + .vidioc_enum_framesizes = sur40_vidioc_enum_framesizes, + .vidioc_enum_frameintervals = sur40_vidioc_enum_frameintervals, + .vidioc_enum_input = sur40_vidioc_enum_input, .vidioc_g_input = sur40_vidioc_g_input, .vidioc_s_input = sur40_vidioc_s_input, -- 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] reduce poll interval to allow full 60 FPS framerate
Signed-off-by: Martin Kaltenbrunner Signed-off-by: Florian Echtler --- drivers/input/touchscreen/sur40.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/sur40.c b/drivers/input/touchscreen/sur40.c index a24eba5..e707b8d 100644 --- a/drivers/input/touchscreen/sur40.c +++ b/drivers/input/touchscreen/sur40.c @@ -125,7 +125,7 @@ struct sur40_image_header { #define VIDEO_PACKET_SIZE 16384 /* polling interval (ms) */ -#define POLL_INTERVAL 10 +#define POLL_INTERVAL 4 /* maximum number of contacts FIXME: this is a guess? */ #define MAX_CONTACTS 64 -- 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] add extra debug output, remove noisy warning
Signed-off-by: Martin Kaltenbrunner Signed-off-by: Florian Echtler --- drivers/input/touchscreen/sur40.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/sur40.c b/drivers/input/touchscreen/sur40.c index d860d05..8add986 100644 --- a/drivers/input/touchscreen/sur40.c +++ b/drivers/input/touchscreen/sur40.c @@ -342,7 +342,7 @@ static void sur40_poll(struct input_polled_dev *polldev) * instead of at the end. */ if (packet_id != header->packet_id) - dev_warn(sur40->dev, "packet ID mismatch\n"); + dev_dbg(sur40->dev, "packet ID mismatch\n"); packet_blobs = result / sizeof(struct sur40_blob); dev_dbg(sur40->dev, "received %d blobs\n", packet_blobs); @@ -389,6 +389,8 @@ static void sur40_process_video(struct sur40_state *sur40) list_del(&new_buf->list); spin_unlock(&sur40->qlock); + dev_dbg(sur40->dev, "buffer acquired\n"); + /* retrieve data via bulk read */ result = usb_bulk_msg(sur40->usbdev, usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT), @@ -416,6 +418,8 @@ static void sur40_process_video(struct sur40_state *sur40) goto err_poll; } + dev_dbg(sur40->dev, "header acquired\n"); + sgt = vb2_dma_sg_plane_desc(&new_buf->vb, 0); result = usb_sg_init(&sgr, sur40->usbdev, @@ -432,11 +436,14 @@ static void sur40_process_video(struct sur40_state *sur40) goto err_poll; } + dev_dbg(sur40->dev, "image acquired\n"); + /* mark as finished */ v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp); new_buf->vb.v4l2_buf.sequence = sur40->sequence++; new_buf->vb.v4l2_buf.field = V4L2_FIELD_NONE; vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_DONE); + dev_dbg(sur40->dev, "buffer marked done\n"); return; err_poll: -- 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] [sur40] minor fixes & performance improvements
This patch series adds several small fixes, features & performance improvements. Many thanks to Martin Kaltenbrunner for testing the original driver & submitting the patches. Martin Kaltenbrunner (4): reduce poll interval to allow full 60 FPS framerate add frame size/frame rate query functions add extra debug output, remove noisy warning return BUF_STATE_ERROR if streaming stopped during acquisition drivers/input/touchscreen/sur40.c | 46 +-- 1 file changed, 44 insertions(+), 2 deletions(-) -- 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
Re: [PATCH 13/20] media: soc_camera: v4l2-compliance fixes for querycap
On 21/05/15 06:58, Hans Verkuil wrote: > On 05/20/2015 06:39 PM, William Towle wrote: >> Fill in bus_info field and zero reserved field. >> >> Signed-off-by: Rob Taylor >> Reviewed-by: William Towle >> --- >> drivers/media/platform/soc_camera/soc_camera.c |2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/media/platform/soc_camera/soc_camera.c >> b/drivers/media/platform/soc_camera/soc_camera.c >> index fd7497e..583c5e6 100644 >> --- a/drivers/media/platform/soc_camera/soc_camera.c >> +++ b/drivers/media/platform/soc_camera/soc_camera.c >> @@ -954,6 +954,8 @@ static int soc_camera_querycap(struct file *file, void >> *priv, >> WARN_ON(priv != file->private_data); >> >> strlcpy(cap->driver, ici->drv_name, sizeof(cap->driver)); >> +strlcpy(cap->bus_info, "platform:soc_camera", sizeof(cap->bus_info)); >> +memset(cap->reserved, 0, sizeof(cap->reserved)); > > Why the memset? That shouldn't be needed. v4l2-complience complained it wasn't zero (v4l2-compliance.cpp:308 in v4l-utils v1.6.2 [1]) Thanks, Rob [1] http://git.linuxtv.org/cgit.cgi/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-compliance.cpp?id=v4l-utils-1.6.2#n308 > Regards, > > Hans > >> return ici->ops->querycap(ici, cap); >> } >> >> > -- 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 15/20] media: rcar_vin: Don't advertise support for USERPTR
On 21/05/15 07:03, Hans Verkuil wrote: > On 05/20/2015 06:39 PM, William Towle wrote: >> rcar_vin requires physically contiguous buffer, so shouldn't advertise >> support for USERPTR. >> >> Signed-off-by: Rob Taylor >> Reviewed-by: William Towle >> --- >> drivers/media/platform/soc_camera/rcar_vin.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c >> b/drivers/media/platform/soc_camera/rcar_vin.c >> index 222002a..b530503 100644 >> --- a/drivers/media/platform/soc_camera/rcar_vin.c >> +++ b/drivers/media/platform/soc_camera/rcar_vin.c >> @@ -1824,7 +1824,7 @@ static int rcar_vin_init_videobuf2(struct vb2_queue >> *vq, >> struct soc_camera_host *ici = to_soc_camera_host(icd->parent); >> >> vq->type = V4L2_BUF_TYPE_VIDEO_CAPTURE; >> -vq->io_modes = VB2_MMAP | VB2_USERPTR; >> +vq->io_modes = VB2_MMAP; > > NACK. > > USERPTR can be used, but the user pointer must point to physically contig > memory (and this is checked). There are cases where the system will carve out > phys. contig. memory and userspace has pointers to that. I'm pretty sure some > of > this is used by systems where soc-camera is run. > > Unfortunately, userspace has currently no way of knowing such userptr > restrictions. > That's a failing of the API. It's ugly as hell, but it is in use today and > can't > be dropped. Ah, that is ugly - I assumed because there wasn't an interface to query restrictions it would be necessary to drop support. We can drop this patch for now. It seems rcar_vin doesn't pass compliance with USERPTR, but we'll have to look into fixing that at a later date. Thanks, Rob > Regards, > > Hans > >> vq->drv_priv = icd; >> vq->ops = &rcar_vin_vb2_ops; >> vq->mem_ops = &vb2_dma_contig_memops; >> > -- 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: imx53 IPU support on 4.0.4
Le mercredi 20 mai 2015 à 21:55 +0100, Russell King - ARM Linux a écrit : > The way kernel development works is that patches are sent to mailing > lists for review. Kernel developers review the patches and provide > comments back. The comments are discussed and actioned, and a new > set of patches posted for further review. This cycle repeats. This patchset is already in the queue, so nothing to be done here. @Fabio, you simply have to be patient. Nicolas -- 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: imx53 IPU support on 4.0.4
Nicolas, On Thu, May 21, 2015 at 9:51 AM, Nicolas Dufresne wrote: > Le mercredi 20 mai 2015 à 21:55 +0100, Russell King - ARM Linux a écrit > : >> The way kernel development works is that patches are sent to mailing >> lists for review. Kernel developers review the patches and provide >> comments back. The comments are discussed and actioned, and a new >> set of patches posted for further review. This cycle repeats. > > This patchset is already in the queue, so nothing to be done here. > @Fabio, you simply have to be patient. I am not sure why you are saying this as I was just explaining the same to Enrico. -- 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 4/5] leds: aat1290: Pass dev and dev->of_node to v4l2_flash_init()
On Thu, May 21, 2015 at 02:13:12PM +0200, Jacek Anaszewski wrote: > Hi Sakari > > On 05/21/2015 12:06 PM, Sakari Ailus wrote: > [...] > >>>On Wed, May 20, 2015 at 03:47:25PM +0200, Jacek Anaszewski wrote: > >>>... > --- a/drivers/leds/leds-aat1290.c > +++ b/drivers/leds/leds-aat1290.c > @@ -524,9 +524,8 @@ static int aat1290_led_probe(struct > platform_device *pdev) > led_cdev->dev->of_node = sub_node; > > /* Create V4L2 Flash subdev. */ > -led->v4l2_flash = v4l2_flash_init(fled_cdev, > - &v4l2_flash_ops, > - &v4l2_sd_cfg); > +led->v4l2_flash = v4l2_flash_init(dev, NULL, fled_cdev, > + &v4l2_flash_ops, &v4l2_sd_cfg); > >>> > >>>Here the first argument should be led_cdev->dev, not dev, which is > >>>&pdev->dev, whereas led_cdev->dev is returned by > >>>device_create_with_groups (it takes dev as a parent) called from > >>>led_classdev_register. > >> > >>The reason for this is the fact that pdev->dev has its of_node > >>field initialized, which makes v4l2_async trying to match > >>subdev by parent node of a LED device, not by sub-LED related > >>DT node. > > > >If v4l2_subdev->of_node is set, then it won't be replaced with one from > >struct device. I.e. you need to provide of_node pointer only if it's > >different from dev->of_node. > > > > It will always be different since dev->of_node pointer is related > to the main DT node of LED device, whereas each LED connected to it > must be expressed in the form of sub-node, as > Documentation/devicetree/bindings/leds/common.txt DT states. > >>> > >>>You can still refer to the device's root device_node using a phandle. > >> > >>Why should I need to refer to the device's root node? > >> > >>What I meant here was that DT documentation enforces that even if > >>there is a single LED connected to the device it has to be expressed > >>as a sub-node anyway. Each LED will have to be matched by the phandle > >>to the sub-node representing it. This implies that v4l2_subdev->of_node > >>(related to sub-LED DT node) will be always different from dev->of_node > >>(related to LED controller DT node). > > > >>From driver point of view this makes no difference; it's just easier to > >parse if you don't refer to the LEDs separately. I think this is a bit > >special case; nowadays many LED flash controllers drive two LEDs. > > As I understand, your stance is as follows: > - second argument to v4l2_flash_init needn't always be initialized > because some LEDs could be referred to by the phandle to the parent > node (e.g. flash LED and indicator under common sub-device) > > If this is true, than how we would handle the situation where > there is a flash LED controller with two separate flash LEDs > and one of them is associated with indicator LED? I referred to cases where there's exactly one flash LED and one indicator LED. The as3645a driver already does expose them through the same sub-device, as does the adp1653 driver. I wouldn't attempt to change this, and I think it makes sense for other drivers that have one of each LEDs. > >>>Say, if you have a LED flash controller with an indicator. It's intended to > >>>be used together with the flash LED, and the existing as3645a driver > >>>exposes > >>>it through the same sub-device. I think that'd make sense with LED class > >>>driver as well (i.e. you'd have two LED class devices but a single > >>>sub-device). Small changes to the wrapper would be needed. > >>> > >> > >>How the sub-device name should look like then? We would have to > >>concatenate somehow both LED class device names? > > > >It'd be different, i.e. there would be no flash or indicator in the name. > > > > Currently there is no such a requirement too. As we discussed it few > months ago v4l2-flash sub-device name should be composed: > - for I2C devices " -" > - for GPIO driven devices: The indicator and the flash may not have the same name, so it wouldn't be a bad idea to include that to the name of the LED device. I2C devices the names are always different anyway due to the bus address. It's up to the driver to set the name correctly. -- 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: [PATCH v8 8/8] DT: samsung-fimc: Add examples for samsung,flash-led property
On 21/05/15 13:32, Sakari Ailus wrote: @@ -147,6 +149,8 @@ Example: > >> clocks = <&camera 0>; > >> clock-names = "mclk"; > >> > >>+ samsung,flash-led = <&rear_cam_flash>; > >>+ > >> port { > >> s5c73m3_1: endpoint { > >> data-lanes = <1 2 3 4>; >>> > > >>> > >Oops. I missed this property would have ended to the sensor's DT node. I >>> > >don't think we should have properties here that are parsed by another >>> > >driver --- let's discuss this tomorrow. >> > >> > exynos4-is driver already parses sensor nodes (at least their 'port' >> > sub-nodes). > > If you read the code and the comment, it looks like something that should be > done better but hasn't been done yet. :-) That's something we should avoid. > Also, flash devices are by far more common than external ISPs I presume. Yes, especially let's not require any samsung specific properties in other vendors' sensor bindings. One way of modelling [flash led]/[image sensor] association I imagine would be to put, e.g. 'flash-leds' property in the SoC camera host interface/ISP DT node. This property would then contain pairs of phandles, first to the led node and the second to the sensor node, e.g. i2c_controller { ... flash_xx@NN { ... led_a { ... } }; image_sensor_x@NN { ... }; }; flash-leds = <&flash_xx &image_sensor_x>, <...>; For the purpose of this patch set presumably just samsung specific property name could be used (i.e. samsung,flash-leds). -- Thanks, Sylwester -- 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 v8 8/8] DT: samsung-fimc: Add examples for samsung,flash-led property
Hi Sylwester, On Thu, May 21, 2015 at 03:28:40PM +0200, Sylwester Nawrocki wrote: > On 21/05/15 13:32, Sakari Ailus wrote: > @@ -147,6 +149,8 @@ Example: > > >> clocks = <&camera 0>; > > >> clock-names = "mclk"; > > >> > > >>+samsung,flash-led = <&rear_cam_flash>; > > >>+ > > >> port { > > >> s5c73m3_1: endpoint { > > >> data-lanes = <1 2 3 4>; > >>> > > > >>> > >Oops. I missed this property would have ended to the sensor's DT node. > >>> > >I > >>> > >don't think we should have properties here that are parsed by another > >>> > >driver --- let's discuss this tomorrow. > >> > > >> > exynos4-is driver already parses sensor nodes (at least their 'port' > >> > sub-nodes). > > > > If you read the code and the comment, it looks like something that should be > > done better but hasn't been done yet. :-) That's something we should avoid. > > Also, flash devices are by far more common than external ISPs I presume. > > Yes, especially let's not require any samsung specific properties in > other vendors' sensor bindings. > > One way of modelling [flash led]/[image sensor] association I imagine > would be to put, e.g. 'flash-leds' property in the SoC camera host > interface/ISP DT node. This property would then contain pairs of phandles, > first to the led node and the second to the sensor node, e.g. > > i2c_controller { > ... > flash_xx@NN { > ... > led_a { > ... > } > }; > > image_sensor_x@NN { > ... > }; > }; > > flash-leds = <&flash_xx &image_sensor_x>, <...>; Maybe a stupid question, but how do you access this in a driver? I have to admit I'm no DT expert. > > For the purpose of this patch set presumably just samsung specific > property name could be used (i.e. samsung,flash-leds). I agree. I'll add similar support for the omap3isp driver in the near future though. Let's see how the camera modules will get modelled, if they will, and if this property still fits to the picture by that time, then we make it more generic. What do you think? -- 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: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback
On 21 May 2015 at 15:30, David Härdeman wrote: > On 2015-05-21 13:51, Antti Seppälä wrote: >> >> On 21 May 2015 at 12:14, David Härdeman wrote: >>> >>> I'm talking about ir_raw_encode_scancode() which is entirely broken in >>> its >>> current state. It will, given more than one enabled protocol, encode a >>> scancode to pulse/space events according to the rules of a randomly >>> chosen >>> protocol. That random selection will be influenced by things like *module >>> load order* (independent of the separate fact that passing multiple >>> protocols to it is completely bogus in the first place). >>> >>> To be clear: the same scancode may be encoded differently depending on if >>> you've load the nec decoder before or after the rc5 decoder! That kind of >>> behavior can't go into a release kernel (Mauro...). >>> >> >> So... if the ir_raw_handler_list is sorted to eliminate the randomness >> caused by module load ordering you will be happy (or happier)? > > > No, cause it's a horrible hack. And the caller of ir_raw_handler_list() > still has no idea of knowing (given more than one protocol) which protocol a > given scancode will be encoded according to. > Okay, so how about "demuxing" the first protocol before handing them to encoder callback? Simply something like below: - if (handler->protocols & protocols && handler->encode) { + if (handler->protocols & ffs(protocols) && handler->encode) { Now the behavior is well-defined even when multiple protocols are selected. >> That is something that could be useful even for the ir-decoding >> functionality and might be worth a separate patch. > > > Useful how? Keeping dynamically filled lists sorted is a good practice if one wishes to achieve determinism in behavior (like running decoders always in certain order too). -- Antti -- 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 v8 8/8] DT: samsung-fimc: Add examples for samsung,flash-led property
Hi Sakari, On 21/05/15 16:20, Sakari Ailus wrote: > On Thu, May 21, 2015 at 03:28:40PM +0200, Sylwester Nawrocki wrote: >> > On 21/05/15 13:32, Sakari Ailus wrote: >> > @@ -147,6 +149,8 @@ Example: > > > >> clocks = <&camera 0>; > > > >> clock-names = "mclk"; > > > >> > > > >>+ samsung,flash-led = <&rear_cam_flash>; > > > >>+ > > > >> port { > > > >> s5c73m3_1: endpoint { > > > >> data-lanes = <1 2 3 4>; >>> > >>> > > >>> > >>> > >Oops. I missed this property would have ended to the sensor's >>> > >>> > >DT node. I >>> > >>> > >don't think we should have properties here that are parsed by >>> > >>> > >another >>> > >>> > >driver --- let's discuss this tomorrow. > > >> > > > >> > exynos4-is driver already parses sensor nodes (at least their > > >> > 'port' > > >> > sub-nodes). >>> > > >>> > > If you read the code and the comment, it looks like something that >>> > > should be >>> > > done better but hasn't been done yet. :-) That's something we should >>> > > avoid. >>> > > Also, flash devices are by far more common than external ISPs I presume. >> > >> > Yes, especially let's not require any samsung specific properties in >> > other vendors' sensor bindings. >> > >> > One way of modelling [flash led]/[image sensor] association I imagine >> > would be to put, e.g. 'flash-leds' property in the SoC camera host >> > interface/ISP DT node. This property would then contain pairs of phandles, >> > first to the led node and the second to the sensor node, e.g. >> > >> > i2c_controller { >> >... >> >flash_xx@NN { >> >... >> >led_a { >> >... >> >} >> >}; >> > >> >image_sensor_x@NN { >> >... >> >}; >> > }; >> > >> > flash-leds = <&flash_xx &image_sensor_x>, <...>; > > Maybe a stupid question, but how do you access this in a driver? I have to > admit I'm no DT expert. You could get of_node pointers with of_parse_phandle() call and then lookup related flash and sensor devices based on that. >> > For the purpose of this patch set presumably just samsung specific >> > property name could be used (i.e. samsung,flash-leds). > > I agree. I'll add similar support for the omap3isp driver in the near future > though. Let's see how the camera modules will get modelled, if they will, > and if this property still fits to the picture by that time, then we make it > more generic. > > What do you think? I think we could do that, perhaps we could get some more opinions and use generic name already in this series? I'm not sure what are exact plans for this series, I guess it is targeted for 4.2? -- Regards, Sylwester -- 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] saa7134: add AverMedia AverTV/505 card support
Add AverMedia AverTV/505 card to saa7134 driver. It is a card bearing SAA7130HL chip and FQ1216ME/IH-3 tuner. Working: Composite, TV and IR remote control. Untested: S-Video. Signed-off-by: Dmitry Eremin-Solenikov --- Documentation/video4linux/CARDLIST.saa7134 | 1 + drivers/media/pci/saa7134/saa7134-cards.c | 42 +- drivers/media/pci/saa7134/saa7134-input.c | 2 ++ drivers/media/pci/saa7134/saa7134.h| 1 + 4 files changed, 45 insertions(+), 1 deletion(-) diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index a93d864..f4b395b 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -192,3 +192,4 @@ 191 -> Hawell HW-9004V1 192 -> AverMedia AverTV Satellite Hybrid+FM A706 [1461:2055] 193 -> WIS Voyager or compatible[1905:7007] +194 -> AverMedia AverTV/505 [1461:a10a] diff --git a/drivers/media/pci/saa7134/saa7134-cards.c b/drivers/media/pci/saa7134/saa7134-cards.c index 3ca0780..adc3563 100644 --- a/drivers/media/pci/saa7134/saa7134-cards.c +++ b/drivers/media/pci/saa7134/saa7134-cards.c @@ -5850,6 +5850,39 @@ struct saa7134_board saa7134_boards[] = { .amux = LINE1, } }, }, + [SAA7134_BOARD_AVERMEDIA_505] = { + /* much like the "studio" version but without radio + * and another tuner (dbarysh...@gmail.com) */ + .name = "AverMedia AverTV/505", + .audio_clock= 0x00187de7, + .tuner_type = TUNER_PHILIPS_FQ1216ME, + .radio_type = UNSET, + .tuner_addr = ADDR_UNSET, + .radio_addr = ADDR_UNSET, + .tda9887_conf = TDA9887_PRESENT, + .inputs = {{ + .name = name_tv, + .vmux = 1, + .amux = LINE2, + .tv = 1, + },{ + .name = name_comp1, + .vmux = 0, + .amux = LINE2, + },{ + .name = name_comp2, + .vmux = 3, + .amux = LINE2, + },{ + .name = name_svideo, + .vmux = 8, + .amux = LINE2, + }}, + .mute = { + .name = name_mute, + .amux = LINE1, + }, + }, }; @@ -7108,6 +7141,12 @@ struct pci_device_id saa7134_pci_tbl[] = { .subvendor= 0x1905, /* WIS */ .subdevice= 0x7007, .driver_data = SAA7134_BOARD_WIS_VOYAGER, + },{ + .vendor = PCI_VENDOR_ID_PHILIPS, + .device = PCI_DEVICE_ID_PHILIPS_SAA7130, + .subvendor= 0x1461, /* Avermedia Technologies Inc */ + .subdevice= 0xa10a, + .driver_data = SAA7134_BOARD_AVERMEDIA_505, }, { /* --- boards without eeprom + subsystem ID --- */ .vendor = PCI_VENDOR_ID_PHILIPS, @@ -7448,8 +7487,9 @@ int saa7134_board_init1(struct saa7134_dev *dev) case SAA7134_BOARD_KWORLD_VSTREAM_XPERT: case SAA7134_BOARD_KWORLD_XPERT: case SAA7134_BOARD_AVERMEDIA_STUDIO_305: - case SAA7134_BOARD_AVERMEDIA_STUDIO_505: case SAA7134_BOARD_AVERMEDIA_305: + case SAA7134_BOARD_AVERMEDIA_STUDIO_505: + case SAA7134_BOARD_AVERMEDIA_505: case SAA7134_BOARD_AVERMEDIA_STUDIO_307: case SAA7134_BOARD_AVERMEDIA_307: case SAA7134_BOARD_AVERMEDIA_STUDIO_507: diff --git a/drivers/media/pci/saa7134/saa7134-input.c b/drivers/media/pci/saa7134/saa7134-input.c index dc3d651..9f7e861 100644 --- a/drivers/media/pci/saa7134/saa7134-input.c +++ b/drivers/media/pci/saa7134/saa7134-input.c @@ -481,6 +481,7 @@ static int __saa7134_ir_start(void *priv) case SAA7134_BOARD_KWORLD_VSTREAM_XPERT: case SAA7134_BOARD_AVERMEDIA_305: case SAA7134_BOARD_AVERMEDIA_307: + case SAA7134_BOARD_AVERMEDIA_505: case SAA7134_BOARD_AVERMEDIA_STUDIO_305: case SAA7134_BOARD_AVERMEDIA_STUDIO_505: case SAA7134_BOARD_AVERMEDIA_STUDIO_307: @@ -629,6 +630,7 @@ int saa7134_input_init1(struct saa7134_dev *dev) case SAA7134_BOARD_KWORLD_VSTREAM_XPERT: case SAA7134_BOARD_AVERMEDIA_305: case SAA7134_BOARD_AVERMEDIA_307: + case SAA7134_BOARD_AVERMEDIA_505: case SAA7134_BOARD_AVERMEDIA_STUDIO_305: case SAA7134_BOARD_AVERMEDIA_STUDIO_505: case SAA7134_BOARD_AVERMEDIA_STUDIO_307: diff --git a/drivers/media/pci/saa7134/saa7134.h b/drivers/media/pci/saa7134/saa7134.h index 8bf0553..583e9f1 100644 --- a/drivers/media/pci/saa7134/saa7134.h +++ b/drivers/media/pci/saa7134/saa7134.h @@ -3
[PATCHv2 2/5] m88ds3103: implement DVBv5 CNR statistics
Implement DVBv5 CNR statistics. Wrap legacy DVBv3 SNR to DVBv5 CNR. Signed-off-by: Antti Palosaari --- drivers/media/dvb-frontends/m88ds3103.c | 154 +--- 1 file changed, 82 insertions(+), 72 deletions(-) diff --git a/drivers/media/dvb-frontends/m88ds3103.c b/drivers/media/dvb-frontends/m88ds3103.c index 03dceb5..381a8ad 100644 --- a/drivers/media/dvb-frontends/m88ds3103.c +++ b/drivers/media/dvb-frontends/m88ds3103.c @@ -190,8 +190,9 @@ static int m88ds3103_read_status(struct dvb_frontend *fe, fe_status_t *status) { struct m88ds3103_priv *priv = fe->demodulator_priv; struct dtv_frontend_properties *c = &fe->dtv_property_cache; - int ret; + int ret, i, itmp; u8 u8tmp; + u8 buf[3]; *status = 0; @@ -233,6 +234,77 @@ static int m88ds3103_read_status(struct dvb_frontend *fe, fe_status_t *status) dev_dbg(&priv->i2c->dev, "%s: lock=%02x status=%02x\n", __func__, u8tmp, *status); + /* CNR */ + if (priv->fe_status & FE_HAS_VITERBI) { + unsigned int cnr, noise, signal, noise_tot, signal_tot; + + cnr = 0; + /* more iterations for more accurate estimation */ + #define M88DS3103_SNR_ITERATIONS 3 + + switch (c->delivery_system) { + case SYS_DVBS: + itmp = 0; + + for (i = 0; i < M88DS3103_SNR_ITERATIONS; i++) { + ret = m88ds3103_rd_reg(priv, 0xff, &buf[0]); + if (ret) + goto err; + + itmp += buf[0]; + } + + /* use of single register limits max value to 15 dB */ + /* SNR(X) dB = 10 * ln(X) / ln(10) dB */ + itmp = DIV_ROUND_CLOSEST(itmp, 8 * M88DS3103_SNR_ITERATIONS); + if (itmp) + cnr = div_u64((u64) 1 * intlog2(itmp), intlog2(10)); + break; + case SYS_DVBS2: + noise_tot = 0; + signal_tot = 0; + + for (i = 0; i < M88DS3103_SNR_ITERATIONS; i++) { + ret = m88ds3103_rd_regs(priv, 0x8c, buf, 3); + if (ret) + goto err; + + noise = buf[1] << 6;/* [13:6] */ + noise |= buf[0] & 0x3f; /* [5:0] */ + noise >>= 2; + signal = buf[2] * buf[2]; + signal >>= 1; + + noise_tot += noise; + signal_tot += signal; + } + + noise = noise_tot / M88DS3103_SNR_ITERATIONS; + signal = signal_tot / M88DS3103_SNR_ITERATIONS; + + /* SNR(X) dB = 10 * log10(X) dB */ + if (signal > noise) { + itmp = signal / noise; + cnr = div_u64((u64) 1 * intlog10(itmp), (1 << 24)); + } + break; + default: + dev_dbg(&priv->i2c->dev, + "%s: invalid delivery_system\n", __func__); + ret = -EINVAL; + goto err; + } + + if (cnr) { + c->cnr.stat[0].scale = FE_SCALE_DECIBEL; + c->cnr.stat[0].svalue = cnr; + } else { + c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE; + } + } else { + c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE; + } + return 0; err: dev_dbg(&priv->i2c->dev, "%s: failed=%d\n", __func__, ret); @@ -577,6 +649,7 @@ err: static int m88ds3103_init(struct dvb_frontend *fe) { struct m88ds3103_priv *priv = fe->demodulator_priv; + struct dtv_frontend_properties *c = &fe->dtv_property_cache; int ret, len, remaining; const struct firmware *fw = NULL; u8 *fw_file; @@ -684,7 +757,9 @@ static int m88ds3103_init(struct dvb_frontend *fe) skip_fw_download: /* warm state */ priv->warm = true; - + /* init stats here in order signal app which stats are supported */ + c->cnr.len = 1; + c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE; return 0; error_fw_release: @@ -702,6 +777,7 @@ static int m88ds3103_sleep(struct dvb_frontend *fe) dev_dbg(&priv->i2c->dev, "%s:\n", __func__); + priv->fe_status = 0; priv->delivery_system = SYS_UNDEFINED; /* TS Hi-Z */ @@ -908,80 +984,14 @@ err: static int m88ds3103_read_snr(struct dvb_frontend *fe, u16 *snr) { -
[PATCHv2 1/5] m88ds3103: do not return error from get_frontend() when not ready
Do not return error from get_frontend() when status is queried, but device is not ready. dvbv5-zap has habit to call that IOCTL before device is tuned and it also refuses to use DVBv5 statistic after that... Signed-off-by: Antti Palosaari --- drivers/media/dvb-frontends/m88ds3103.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/m88ds3103.c b/drivers/media/dvb-frontends/m88ds3103.c index d3d928e..03dceb5 100644 --- a/drivers/media/dvb-frontends/m88ds3103.c +++ b/drivers/media/dvb-frontends/m88ds3103.c @@ -742,7 +742,7 @@ static int m88ds3103_get_frontend(struct dvb_frontend *fe) dev_dbg(&priv->i2c->dev, "%s:\n", __func__); if (!priv->warm || !(priv->fe_status & FE_HAS_LOCK)) { - ret = -EAGAIN; + ret = 0; goto err; } -- http://palosaari.fi/ -- 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
[PATCHv2 4/5] m88ds3103: use jiffies when polling DiSEqC TX ready
Use jiffies to set timeout for DiSEqC TX ready polling. Using jiffies is more elegant solution than looping N times with sleep. Signed-off-by: Antti Palosaari --- drivers/media/dvb-frontends/m88ds3103.c | 53 + 1 file changed, 34 insertions(+), 19 deletions(-) diff --git a/drivers/media/dvb-frontends/m88ds3103.c b/drivers/media/dvb-frontends/m88ds3103.c index 33d8c19..e45641f 100644 --- a/drivers/media/dvb-frontends/m88ds3103.c +++ b/drivers/media/dvb-frontends/m88ds3103.c @@ -1195,7 +1195,8 @@ static int m88ds3103_diseqc_send_master_cmd(struct dvb_frontend *fe, struct dvb_diseqc_master_cmd *diseqc_cmd) { struct m88ds3103_priv *priv = fe->demodulator_priv; - int ret, i; + int ret; + unsigned long timeout; u8 u8tmp; dev_dbg(&priv->i2c->dev, "%s: msg=%*ph\n", __func__, @@ -1226,21 +1227,24 @@ static int m88ds3103_diseqc_send_master_cmd(struct dvb_frontend *fe, if (ret) goto err; - /* DiSEqC message typical period is 54 ms */ - usleep_range(4, 6); - /* wait DiSEqC TX ready */ - for (i = 20, u8tmp = 1; i && u8tmp; i--) { - usleep_range(5000, 1); + #define SEND_MASTER_CMD_TIMEOUT 120 + timeout = jiffies + msecs_to_jiffies(SEND_MASTER_CMD_TIMEOUT); + + /* DiSEqC message typical period is 54 ms */ + usleep_range(5, 54000); + for (u8tmp = 1; !time_after(jiffies, timeout) && u8tmp;) { ret = m88ds3103_rd_reg_mask(priv, 0xa1, &u8tmp, 0x40); if (ret) goto err; } - dev_dbg(&priv->i2c->dev, "%s: loop=%d\n", __func__, i); - - if (i == 0) { + if (u8tmp == 0) { + dev_dbg(&priv->i2c->dev, "%s: diseqc tx took %u ms\n", __func__, + jiffies_to_msecs(jiffies) - + (jiffies_to_msecs(timeout) - SEND_MASTER_CMD_TIMEOUT)); + } else { dev_dbg(&priv->i2c->dev, "%s: diseqc tx timeout\n", __func__); ret = m88ds3103_wr_reg_mask(priv, 0xa1, 0x40, 0xc0); @@ -1252,7 +1256,7 @@ static int m88ds3103_diseqc_send_master_cmd(struct dvb_frontend *fe, if (ret) goto err; - if (i == 0) { + if (u8tmp == 1) { ret = -ETIMEDOUT; goto err; } @@ -1267,7 +1271,8 @@ static int m88ds3103_diseqc_send_burst(struct dvb_frontend *fe, fe_sec_mini_cmd_t fe_sec_mini_cmd) { struct m88ds3103_priv *priv = fe->demodulator_priv; - int ret, i; + int ret; + unsigned long timeout; u8 u8tmp, burst; dev_dbg(&priv->i2c->dev, "%s: fe_sec_mini_cmd=%d\n", __func__, @@ -1301,26 +1306,36 @@ static int m88ds3103_diseqc_send_burst(struct dvb_frontend *fe, if (ret) goto err; - /* DiSEqC ToneBurst period is 12.5 ms */ - usleep_range(11000, 2); - /* wait DiSEqC TX ready */ - for (i = 5, u8tmp = 1; i && u8tmp; i--) { - usleep_range(800, 2000); + #define SEND_BURST_TIMEOUT 40 + timeout = jiffies + msecs_to_jiffies(SEND_BURST_TIMEOUT); + + /* DiSEqC ToneBurst period is 12.5 ms */ + usleep_range(8500, 12500); + for (u8tmp = 1; !time_after(jiffies, timeout) && u8tmp;) { ret = m88ds3103_rd_reg_mask(priv, 0xa1, &u8tmp, 0x40); if (ret) goto err; } - dev_dbg(&priv->i2c->dev, "%s: loop=%d\n", __func__, i); + if (u8tmp == 0) { + dev_dbg(&priv->i2c->dev, "%s: diseqc tx took %u ms\n", __func__, + jiffies_to_msecs(jiffies) - + (jiffies_to_msecs(timeout) - SEND_BURST_TIMEOUT)); + } else { + dev_dbg(&priv->i2c->dev, "%s: diseqc tx timeout\n", __func__); + + ret = m88ds3103_wr_reg_mask(priv, 0xa1, 0x40, 0xc0); + if (ret) + goto err; + } ret = m88ds3103_wr_reg_mask(priv, 0xa2, 0x80, 0xc0); if (ret) goto err; - if (i == 0) { - dev_dbg(&priv->i2c->dev, "%s: diseqc tx timeout\n", __func__); + if (u8tmp == 1) { ret = -ETIMEDOUT; goto err; } -- http://palosaari.fi/ -- 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
[PATCHv2 0/5] m88ds3103 improvements (DVBv5 stats and more)
v2 Meld some commits together. Antti Palosaari (5): m88ds3103: do not return error from get_frontend() when not ready m88ds3103: implement DVBv5 CNR statistics m88ds3103: implement DVBv5 BER m88ds3103: use jiffies when polling DiSEqC TX ready m88ds3103: add I2C client binding drivers/media/dvb-frontends/m88ds3103.c | 642 --- drivers/media/dvb-frontends/m88ds3103.h | 63 ++- drivers/media/dvb-frontends/m88ds3103_priv.h | 6 +- 3 files changed, 456 insertions(+), 255 deletions(-) -- http://palosaari.fi/ -- 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
[PATCHv2 5/5] m88ds3103: add I2C client binding
Implement I2C client device binding. Wrap media attach to driver I2C probe. Add wrapper from m88ds3103_attach() to m88ds3103_probe() via driver core in order to provide proper I2C client for legacy media attach binding. Signed-off-by: Antti Palosaari --- drivers/media/dvb-frontends/m88ds3103.c | 268 +++ drivers/media/dvb-frontends/m88ds3103.h | 63 ++- drivers/media/dvb-frontends/m88ds3103_priv.h | 2 + 3 files changed, 245 insertions(+), 88 deletions(-) diff --git a/drivers/media/dvb-frontends/m88ds3103.c b/drivers/media/dvb-frontends/m88ds3103.c index e45641f..01b9ded 100644 --- a/drivers/media/dvb-frontends/m88ds3103.c +++ b/drivers/media/dvb-frontends/m88ds3103.c @@ -1357,9 +1357,9 @@ static int m88ds3103_get_tune_settings(struct dvb_frontend *fe, static void m88ds3103_release(struct dvb_frontend *fe) { struct m88ds3103_priv *priv = fe->demodulator_priv; + struct i2c_client *client = priv->client; - i2c_del_mux_adapter(priv->i2c_adapter); - kfree(priv); + i2c_unregister_device(client); } static int m88ds3103_select(struct i2c_adapter *adap, void *mux_priv, u32 chan) @@ -1401,43 +1401,158 @@ static int m88ds3103_deselect(struct i2c_adapter *adap, void *mux_priv, return 0; } +/* + * XXX: That is wrapper to m88ds3103_probe() via driver core in order to provide + * proper I2C client for legacy media attach binding. + * New users must use I2C client binding directly! + */ struct dvb_frontend *m88ds3103_attach(const struct m88ds3103_config *cfg, struct i2c_adapter *i2c, struct i2c_adapter **tuner_i2c_adapter) { + struct i2c_client *client; + struct i2c_board_info board_info; + struct m88ds3103_platform_data pdata; + + pdata.clk = cfg->clock; + pdata.i2c_wr_max = cfg->i2c_wr_max; + pdata.ts_mode = cfg->ts_mode; + pdata.ts_clk = cfg->ts_clk; + pdata.ts_clk_pol = cfg->ts_clk_pol; + pdata.spec_inv = cfg->spec_inv; + pdata.agc = cfg->agc; + pdata.agc_inv = cfg->agc_inv; + pdata.clk_out = cfg->clock_out; + pdata.envelope_mode = cfg->envelope_mode; + pdata.lnb_hv_pol = cfg->lnb_hv_pol; + pdata.lnb_en_pol = cfg->lnb_en_pol; + pdata.attach_in_use = true; + + memset(&board_info, 0, sizeof(board_info)); + strlcpy(board_info.type, "m88ds3103", I2C_NAME_SIZE); + board_info.addr = cfg->i2c_addr; + board_info.platform_data = &pdata; + client = i2c_new_device(i2c, &board_info); + if (!client || !client->dev.driver) + return NULL; + + *tuner_i2c_adapter = pdata.get_i2c_adapter(client); + return pdata.get_dvb_frontend(client); +} +EXPORT_SYMBOL(m88ds3103_attach); + +static struct dvb_frontend_ops m88ds3103_ops = { + .delsys = { SYS_DVBS, SYS_DVBS2 }, + .info = { + .name = "Montage M88DS3103", + .frequency_min = 95, + .frequency_max = 215, + .frequency_tolerance = 5000, + .symbol_rate_min = 100, + .symbol_rate_max = 4500, + .caps = FE_CAN_INVERSION_AUTO | + FE_CAN_FEC_1_2 | + FE_CAN_FEC_2_3 | + FE_CAN_FEC_3_4 | + FE_CAN_FEC_4_5 | + FE_CAN_FEC_5_6 | + FE_CAN_FEC_6_7 | + FE_CAN_FEC_7_8 | + FE_CAN_FEC_8_9 | + FE_CAN_FEC_AUTO | + FE_CAN_QPSK | + FE_CAN_RECOVER | + FE_CAN_2G_MODULATION + }, + + .release = m88ds3103_release, + + .get_tune_settings = m88ds3103_get_tune_settings, + + .init = m88ds3103_init, + .sleep = m88ds3103_sleep, + + .set_frontend = m88ds3103_set_frontend, + .get_frontend = m88ds3103_get_frontend, + + .read_status = m88ds3103_read_status, + .read_snr = m88ds3103_read_snr, + .read_ber = m88ds3103_read_ber, + + .diseqc_send_master_cmd = m88ds3103_diseqc_send_master_cmd, + .diseqc_send_burst = m88ds3103_diseqc_send_burst, + + .set_tone = m88ds3103_set_tone, + .set_voltage = m88ds3103_set_voltage, +}; + +static struct dvb_frontend *m88ds3103_get_dvb_frontend(struct i2c_client *client) +{ + struct m88ds3103_priv *dev = i2c_get_clientdata(client); + + dev_dbg(&client->dev, "\n"); + + return &dev->fe; +} + +static struct i2c_adapter *m88ds3103_get_i2c_adapter(struct i2c_client *client) +{ + struct m88ds3103_priv *dev = i2c_get_clientdata(client); + + dev_dbg(&client->dev, "\n"); + + return dev->i2c_adapter; +} + +static int m88ds3103_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct m88ds3103_priv *dev; + struct m88ds3103_platform_data *pdata = client->dev.platform_data; int
[PATCHv2 3/5] m88ds3103: implement DVBv5 BER
Implement DVBv5 BER statistics. Wrap legacy DVBv3 BER to DVBv5 BER. Signed-off-by: Antti Palosaari --- drivers/media/dvb-frontends/m88ds3103.c | 165 +++ drivers/media/dvb-frontends/m88ds3103_priv.h | 4 +- 2 files changed, 94 insertions(+), 75 deletions(-) diff --git a/drivers/media/dvb-frontends/m88ds3103.c b/drivers/media/dvb-frontends/m88ds3103.c index 381a8ad..33d8c19 100644 --- a/drivers/media/dvb-frontends/m88ds3103.c +++ b/drivers/media/dvb-frontends/m88ds3103.c @@ -305,6 +305,92 @@ static int m88ds3103_read_status(struct dvb_frontend *fe, fe_status_t *status) c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE; } + /* BER */ + if (priv->fe_status & FE_HAS_LOCK) { + unsigned int utmp, post_bit_error, post_bit_count; + + switch (c->delivery_system) { + case SYS_DVBS: + ret = m88ds3103_wr_reg(priv, 0xf9, 0x04); + if (ret) + goto err; + + ret = m88ds3103_rd_reg(priv, 0xf8, &u8tmp); + if (ret) + goto err; + + /* measurement ready? */ + if (!(u8tmp & 0x10)) { + ret = m88ds3103_rd_regs(priv, 0xf6, buf, 2); + if (ret) + goto err; + + post_bit_error = buf[1] << 8 | buf[0] << 0; + post_bit_count = 0x80; + priv->post_bit_error += post_bit_error; + priv->post_bit_count += post_bit_count; + priv->dvbv3_ber = post_bit_error; + + /* restart measurement */ + u8tmp |= 0x10; + ret = m88ds3103_wr_reg(priv, 0xf8, u8tmp); + if (ret) + goto err; + } + break; + case SYS_DVBS2: + ret = m88ds3103_rd_regs(priv, 0xd5, buf, 3); + if (ret) + goto err; + + utmp = buf[2] << 16 | buf[1] << 8 | buf[0] << 0; + + /* enough data? */ + if (utmp > 4000) { + ret = m88ds3103_rd_regs(priv, 0xf7, buf, 2); + if (ret) + goto err; + + post_bit_error = buf[1] << 8 | buf[0] << 0; + post_bit_count = 32 * utmp; /* TODO: FEC */ + priv->post_bit_error += post_bit_error; + priv->post_bit_count += post_bit_count; + priv->dvbv3_ber = post_bit_error; + + /* restart measurement */ + ret = m88ds3103_wr_reg(priv, 0xd1, 0x01); + if (ret) + goto err; + + ret = m88ds3103_wr_reg(priv, 0xf9, 0x01); + if (ret) + goto err; + + ret = m88ds3103_wr_reg(priv, 0xf9, 0x00); + if (ret) + goto err; + + ret = m88ds3103_wr_reg(priv, 0xd1, 0x00); + if (ret) + goto err; + } + break; + default: + dev_dbg(&priv->i2c->dev, + "%s: invalid delivery_system\n", __func__); + ret = -EINVAL; + goto err; + } + + c->post_bit_error.stat[0].scale = FE_SCALE_COUNTER; + c->post_bit_error.stat[0].uvalue = priv->post_bit_error; + c->post_bit_count.stat[0].scale = FE_SCALE_COUNTER; + c->post_bit_count.stat[0].uvalue = priv->post_bit_count; + } else { + c->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE; + c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE; + } + return 0; err: dev_dbg(&priv->i2c->dev, "%s: failed=%d\n", __func__, ret); @@ -760,6 +846,10 @@ skip_fw_download: /* init stats here in order signal app which stats are supported */ c->cnr.len = 1; c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE; + c->post_bit_error.len = 1; + c->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE; + c->post_bit_count.len = 1; + c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE; return 0; error_fw_
[GIT PULL 4.2] m88ds3103 enhancements
The following changes since commit 2a80f296422a01178d0a993479369e94f5830127: [media] dvb-core: fix 32-bit overflow during bandwidth calculation (2015-05-20 14:01:46 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git m88ds3103_pull for you to fetch changes up to bfdb54de213477ec9f5d45d43c91bdaa54382cda: m88ds3103: add I2C client binding (2015-05-21 22:17:10 +0300) Antti Palosaari (5): m88ds3103: do not return error from get_frontend() when not ready m88ds3103: implement DVBv5 CNR statistics m88ds3103: implement DVBv5 BER m88ds3103: use jiffies when polling DiSEqC TX ready m88ds3103: add I2C client binding drivers/media/dvb-frontends/m88ds3103.c | 642 +- drivers/media/dvb-frontends/m88ds3103.h | 63 ++-- drivers/media/dvb-frontends/m88ds3103_priv.h | 6 +- 3 files changed, 456 insertions(+), 255 deletions(-) -- http://palosaari.fi/ -- 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/7] rc: rc-ir-raw: Add scancode encoder callback
On Thu, May 21, 2015 at 05:22:08PM +0300, Antti Seppälä wrote: >On 21 May 2015 at 15:30, David Härdeman wrote: >> On 2015-05-21 13:51, Antti Seppälä wrote: >>> >>> On 21 May 2015 at 12:14, David Härdeman wrote: I'm talking about ir_raw_encode_scancode() which is entirely broken in its current state. It will, given more than one enabled protocol, encode a scancode to pulse/space events according to the rules of a randomly chosen protocol. That random selection will be influenced by things like *module load order* (independent of the separate fact that passing multiple protocols to it is completely bogus in the first place). To be clear: the same scancode may be encoded differently depending on if you've load the nec decoder before or after the rc5 decoder! That kind of behavior can't go into a release kernel (Mauro...). >>> >>> So... if the ir_raw_handler_list is sorted to eliminate the randomness >>> caused by module load ordering you will be happy (or happier)? >> >> >> No, cause it's a horrible hack. And the caller of ir_raw_handler_list() >> still has no idea of knowing (given more than one protocol) which protocol a >> given scancode will be encoded according to. >> > >Okay, so how about "demuxing" the first protocol before handing them >to encoder callback? Simply something like below: > >- if (handler->protocols & protocols && handler->encode) { >+ if (handler->protocols & ffs(protocols) && handler->encode) { > >Now the behavior is well-defined even when multiple protocols are selected. Your patchset introduced ir_raw_encode_scancode() as well as the only two callers of that function: drivers/media/rc/nuvoton-cir.c drivers/media/rc/rc-loopback.c I realize that the sysfs wakeup_protocols file (which bakes several protocols into one label) makes defining *the* protocol difficult, but if you're going to add hacks like this, keep them to the sole driver using the API rather than the core API itself. That is, change nvt_ir_raw_change_wakeup_protocol() so that it picks a single protocol, no matter how many are passed to it (the img-ir driver already sets a precedent here so it wouldn't be an API change to change to a set of protocols which might be different than what the user suggested). (Also...yes, that'll make supporting several versions of e.g. RC6 impossible with the current sysfs code). Then change both ir_raw_encode_scancode() to take a single protocol enum and change the *encode function pointer in struct ir_raw_handler to also take a single protocol enum. That way encoders won't have to guess (using scanmasks...!?) what protocol they should encode to. And Mauro...I strongly suggest you revert all of this encoding stuff until this has been fixed...it's broken. >> >> Useful how? > >Keeping dynamically filled lists sorted is a good practice if one >wishes to achieve determinism in behavior (like running decoders >always in certain order too). That's a new "good practice" to me... -- David Härdeman -- 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] af9035: add USB ID 07ca:0337 AVerMedia HD Volar (A867)
It is AF9035 + MxL5007T. Driver reports: prechip_version=00 chip_version=03 chip_type=3802 Not sure if that USB ID is reserved only for HP brand or if it is common, but the stick I have is branded as HP part no. 580715-001 rmn A867. Signed-off-by: Antti Palosaari --- drivers/media/usb/dvb-usb-v2/af9035.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c b/drivers/media/usb/dvb-usb-v2/af9035.c index be077f2..6e02a15 100644 --- a/drivers/media/usb/dvb-usb-v2/af9035.c +++ b/drivers/media/usb/dvb-usb-v2/af9035.c @@ -2035,6 +2035,8 @@ static const struct usb_device_id af9035_id_table[] = { &af9035_props, "Asus U3100Mini Plus", NULL) }, { DVB_USB_DEVICE(USB_VID_TERRATEC, 0x00aa, &af9035_props, "TerraTec Cinergy T Stick (rev. 2)", NULL) }, + { DVB_USB_DEVICE(USB_VID_AVERMEDIA, 0x0337, + &af9035_props, "AVerMedia HD Volar (A867)", NULL) }, /* IT9135 devices */ { DVB_USB_DEVICE(USB_VID_ITETECH, USB_PID_ITETECH_IT9135, -- http://palosaari.fi/ -- 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] af9035: add USB ID 07ca:0337 AVerMedia HD Volar (A867)
The following changes since commit 2a80f296422a01178d0a993479369e94f5830127: [media] dvb-core: fix 32-bit overflow during bandwidth calculation (2015-05-20 14:01:46 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git af9035_pull for you to fetch changes up to a12c204cc89dbcbc23489bd755608c7d5fd5ebd0: af9035: add USB ID 07ca:0337 AVerMedia HD Volar (A867) (2015-05-21 22:54:40 +0300) Antti Palosaari (1): af9035: add USB ID 07ca:0337 AVerMedia HD Volar (A867) drivers/media/usb/dvb-usb-v2/af9035.c | 2 ++ 1 file changed, 2 insertions(+) -- http://palosaari.fi/ -- 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: dvb_usb_af9015: command failed=1 _ kernel >= 4.1.x
On 18.05.2015 21:15, poma wrote: > On 17.05.2015 01:07, Antti Palosaari wrote: ... >> try that >> http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/commit/?h=af9015_mxl5007t_1 >> >> Antti >> > > Thanks. > For now, I have noticed, unlike before the EIT program data are updated in > full and promptly. > > I'll be back in a week. > > No need to continue to test this patch because this is repeated: BOOT from S5/Soft Off: [1.007886] usb 1-2: Product: DVB-T 2 [1.032430] Afatech DVB-T 2: Fixing fullspeed to highspeed interval: 10 -> 7 [1.035255] input: Afatech DVB-T 2 as /devices/pci:00/:00:02.1/usb1/1-2/1-2:1.1/0003:15A4:9016.0001/input/input5 [1.089852] hid-generic 0003:15A4:9016.0001: input,hidraw0: USB HID v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:02.1-2/input1 [ 13.353105] usb 1-2: dvb_usb_v2: found a 'Afatech AF9015 reference design' in warm state [ 13.557671] usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 13.558315] DVB: registering new adapter (Afatech AF9015 reference design) [ 13.726582] usb 1-2: DVB: registering adapter 0 frontend 0 (Afatech AF9013)... [ 13.814649] mxl5007t 13-00c0: creating new instance [ 13.817588] mxl5007t_get_chip_id: MxL5007T.v4 detected @ 13-00c0 [ 13.820460] mxl5007t_get_chip_id: MxL5007T.v4 detected @ 13-00c0 [ 13.824594] usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 13.825234] DVB: registering new adapter (Afatech AF9015 reference design) [ 14.040582] usb 1-2: DVB: registering adapter 1 frontend 0 (Afatech AF9013)... [ 14.040921] mxl5007t 13-00c0: attaching existing instance [ 14.043201] usb 1-2: dvb_usb_af9015: command failed=1 [ 14.043429] mxl5007t_read_reg: 505: failed! [ 14.043656] mxl5007t_get_chip_id: error -121 on line 824 [ 14.043880] mxl5007t_get_chip_id: unable to identify device @ 13-00c0 [ 14.044698] usb 1-2: dvb_usb_af9015: command failed=1 [ 14.044911] mxl5007t_soft_reset: 527: failed! [ 14.046841] mxl5007t_attach: error -121 on line 914 [ 14.051434] usbcore: registered new interface driver dvb_usb_af9015 $ ls /dev/dvb/ ls: cannot access /dev/dvb/: No such file or directory # modprobe -rv dvb_usb_af9015 mxl5007t rmmod dvb_usb_af9015 rmmod dvb_usb_v2 rmmod rc_core rmmod dvb_core rmmod mxl5007t # modprobe -v dvb_usb_af9015 insmod /lib/modules/4.0.4-502.fc21.x86_64/kernel/drivers/media/rc/rc-core.ko.xz insmod /lib/modules/4.0.4-502.fc21.x86_64/kernel/drivers/media/dvb-core/dvb-core.ko.xz insmod /lib/modules/4.0.4-502.fc21.x86_64/kernel/drivers/media/usb/dvb-usb-v2/dvb_usb_v2.ko.xz insmod /lib/modules/4.0.4-502.fc21.x86_64/kernel/drivers/media/usb/dvb-usb-v2/dvb-usb-af9015.ko.xz [ 2101.659729] usbcore: deregistering interface driver dvb_usb_af9015 [ 2117.056136] usb 1-2: dvb_usb_v2: found a 'Afatech AF9015 reference design' in warm state [ 2117.265520] usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 2117.265607] DVB: registering new adapter (Afatech AF9015 reference design) [ 2117.268348] i2c i2c-13: af9013: firmware version 5.1.0.0 [ 2117.274958] usb 1-2: DVB: registering adapter 0 frontend 0 (Afatech AF9013)... [ 2117.280031] mxl5007t 13-00c0: creating new instance [ 2117.281700] mxl5007t_get_chip_id: MxL5007T.v4 detected @ 13-00c0 [ 2117.284211] mxl5007t_get_chip_id: MxL5007T.v4 detected @ 13-00c0 [ 2117.287208] usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 2117.287245] DVB: registering new adapter (Afatech AF9015 reference design) [ 2117.493132] i2c i2c-13: af9013: found a 'Afatech AF9013' in warm state [ 2117.496887] i2c i2c-13: af9013: firmware version 5.1.0.0 [ 2117.504373] usb 1-2: DVB: registering adapter 1 frontend 0 (Afatech AF9013)... [ 2117.504664] mxl5007t 13-00c0: attaching existing instance [ 2117.506848] usb 1-2: dvb_usb_af9015: command failed=1 [ 2117.506858] mxl5007t_read_reg: 505: failed! [ 2117.506864] mxl5007t_get_chip_id: error -121 on line 824 [ 2117.506868] mxl5007t_get_chip_id: unable to identify device @ 13-00c0 [ 2117.507344] usb 1-2: dvb_usb_af9015: command failed=1 [ 2117.507350] mxl5007t_soft_reset: 527: failed! [ 2117.509007] mxl5007t_attach: error -121 on line 914 [ 2117.511150] usbcore: registered new interface driver dvb_usb_af9015 $ ls /dev/dvb/ ls: cannot access /dev/dvb/: No such file or directory REBOOT: [1.049265] usb 1-2: Product: DVB-T 2 [1.067810] Afatech DVB-T 2: Fixing fullspeed to highspeed interval: 10 -> 7 [1.068145] input: Afatech DVB-T 2 as /devices/pci:00/:00:02.1/usb1/1-2/1-2:1.1/0003:15A4:9016.0001/input/input5 [1.118889] hid-generic 0003:15A4:9016.0001: input,hidraw0: USB HID v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:02.1-2/input1 [ 12.023590] usb 1-2: dvb_usb_v2: found a 'Afatech AF9015 reference design' in warm state [ 12.225419] usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport
[PATCH 1/8] tda10071: implement I2C client bindings
Implement I2C client bindings. Signed-off-by: Antti Palosaari --- drivers/media/dvb-frontends/tda10071.c | 95 + drivers/media/dvb-frontends/tda10071.h | 29 + drivers/media/dvb-frontends/tda10071_priv.h | 1 + 3 files changed, 125 insertions(+) diff --git a/drivers/media/dvb-frontends/tda10071.c b/drivers/media/dvb-frontends/tda10071.c index 4a19b85..3132854 100644 --- a/drivers/media/dvb-frontends/tda10071.c +++ b/drivers/media/dvb-frontends/tda10071.c @@ -1313,6 +1313,101 @@ static struct dvb_frontend_ops tda10071_ops = { .set_voltage = tda10071_set_voltage, }; +static struct dvb_frontend *tda10071_get_dvb_frontend(struct i2c_client *client) +{ + struct tda10071_priv *dev = i2c_get_clientdata(client); + + dev_dbg(&client->dev, "\n"); + + return &dev->fe; +} + +static int tda10071_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct tda10071_priv *dev; + struct tda10071_platform_data *pdata = client->dev.platform_data; + int ret; + u8 u8tmp; + + dev = kzalloc(sizeof(*dev), GFP_KERNEL); + if (!dev) { + ret = -ENOMEM; + goto err; + } + + dev->client = client; + dev->i2c = client->adapter; + dev->cfg.demod_i2c_addr = client->addr; + dev->cfg.i2c_wr_max = pdata->i2c_wr_max; + dev->cfg.ts_mode = pdata->ts_mode; + dev->cfg.spec_inv = pdata->spec_inv; + dev->cfg.xtal = pdata->clk; + dev->cfg.pll_multiplier = pdata->pll_multiplier; + dev->cfg.tuner_i2c_addr = pdata->tuner_i2c_addr; + + /* chip ID */ + ret = tda10071_rd_reg(dev, 0xff, &u8tmp); + if (ret || u8tmp != 0x0f) + goto err_kfree; + + /* chip type */ + ret = tda10071_rd_reg(dev, 0xdd, &u8tmp); + if (ret || u8tmp != 0x00) + goto err_kfree; + + /* chip version */ + ret = tda10071_rd_reg(dev, 0xfe, &u8tmp); + if (ret || u8tmp != 0x01) + goto err_kfree; + + /* create dvb_frontend */ + memcpy(&dev->fe.ops, &tda10071_ops, sizeof(struct dvb_frontend_ops)); + dev->fe.ops.release = NULL; + dev->fe.demodulator_priv = dev; + i2c_set_clientdata(client, dev); + + /* setup callbacks */ + pdata->get_dvb_frontend = tda10071_get_dvb_frontend; + + dev_info(&client->dev, "NXP TDA10071 successfully identified\n"); + return 0; +err_kfree: + kfree(dev); +err: + dev_dbg(&client->dev, "failed=%d\n", ret); + return ret; +} + +static int tda10071_remove(struct i2c_client *client) +{ + struct tda10071_dev *dev = i2c_get_clientdata(client); + + dev_dbg(&client->dev, "\n"); + + kfree(dev); + return 0; +} + +static const struct i2c_device_id tda10071_id_table[] = { + {"tda10071_cx24118", 0}, + {} +}; +MODULE_DEVICE_TABLE(i2c, tda10071_id_table); + +static struct i2c_driver tda10071_driver = { + .driver = { + .owner = THIS_MODULE, + .name = "tda10071", + .suppress_bind_attrs = true, + }, + .probe = tda10071_probe, + .remove = tda10071_remove, + .id_table = tda10071_id_table, +}; + +module_i2c_driver(tda10071_driver); + MODULE_AUTHOR("Antti Palosaari "); MODULE_DESCRIPTION("NXP TDA10071 DVB-S/S2 demodulator driver"); MODULE_LICENSE("GPL"); diff --git a/drivers/media/dvb-frontends/tda10071.h b/drivers/media/dvb-frontends/tda10071.h index da89f42..0ffbfa5 100644 --- a/drivers/media/dvb-frontends/tda10071.h +++ b/drivers/media/dvb-frontends/tda10071.h @@ -24,6 +24,35 @@ #include #include +/* + * I2C address + * 0x55, + */ + +/** + * struct tda10071_platform_data - Platform data for the tda10071 driver + * @clk: Clock frequency. + * @i2c_wr_max: Max bytes I2C adapter can write at once. + * @ts_mode: TS mode. + * @spec_inv: Input spectrum inversion. + * @pll_multiplier: PLL multiplier. + * @tuner_i2c_addr: CX24118A tuner I2C address (0x14, 0x54, ...). + * @get_dvb_frontend: Get DVB frontend. + */ + +struct tda10071_platform_data { + u32 clk; + u16 i2c_wr_max; +#define TDA10071_TS_SERIAL0 +#define TDA10071_TS_PARALLEL 1 + u8 ts_mode; + bool spec_inv; + u8 pll_multiplier; + u8 tuner_i2c_addr; + + struct dvb_frontend* (*get_dvb_frontend)(struct i2c_client *); +}; + struct tda10071_config { /* Demodulator I2C address. * Default: none, must set diff --git a/drivers/media/dvb-frontends/tda10071_priv.h b/drivers/media/dvb-frontends/tda10071_priv.h index 03f839c..7ec69ac 100644 --- a/drivers/media/dvb-frontends/tda10071_priv.h +++ b/drivers/media/dvb-frontends/tda10071_priv.h @@ -28,6 +28,7 @@ struct tda10071_priv { struct i2c_adapter *i2c; struct dvb_frontend fe; + struct i2c_client *client; struct tda10071_config cfg; u8 meas_cou
[PATCH 3/8] em28xx: add support for DVB SEC I2C client
Add support for DVB SEC (satellite equipment controller) I2C client. Signed-off-by: Antti Palosaari --- drivers/media/usb/em28xx/em28xx-dvb.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c b/drivers/media/usb/em28xx/em28xx-dvb.c index 5b7c7c88..ef1bfa2 100644 --- a/drivers/media/usb/em28xx/em28xx-dvb.c +++ b/drivers/media/usb/em28xx/em28xx-dvb.c @@ -96,6 +96,7 @@ struct em28xx_dvb { int lna_gpio; struct i2c_client *i2c_client_demod; struct i2c_client *i2c_client_tuner; + struct i2c_client *i2c_client_sec; }; static inline void print_err_status(struct em28xx *dev, @@ -1729,7 +1730,6 @@ static int em28xx_dvb_fini(struct em28xx *dev) em28xx_info("Closing DVB extension\n"); dvb = dev->dvb; - client = dvb->i2c_client_tuner; em28xx_uninit_usb_xfer(dev, EM28XX_DIGITAL_MODE); @@ -1746,7 +1746,15 @@ static int em28xx_dvb_fini(struct em28xx *dev) } } + /* remove I2C SEC */ + client = dvb->i2c_client_sec; + if (client) { + module_put(client->dev.driver->owner); + i2c_unregister_device(client); + } + /* remove I2C tuner */ + client = dvb->i2c_client_tuner; if (client) { module_put(client->dev.driver->owner); i2c_unregister_device(client); -- http://palosaari.fi/ -- 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 5/8] cx23885: add support for DVB I2C SEC client
Add support for I2C SEC (satellite equipment controller) client. Signed-off-by: Antti Palosaari --- drivers/media/pci/cx23885/cx23885-dvb.c | 16 drivers/media/pci/cx23885/cx23885.h | 1 + 2 files changed, 17 insertions(+) diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c b/drivers/media/pci/cx23885/cx23885-dvb.c index 37fd013..ac062a5 100644 --- a/drivers/media/pci/cx23885/cx23885-dvb.c +++ b/drivers/media/pci/cx23885/cx23885-dvb.c @@ -1190,6 +1190,7 @@ static int dvb_register(struct cx23885_tsport *port) struct i2c_board_info info; struct i2c_adapter *adapter; struct i2c_client *client_demod = NULL, *client_tuner = NULL; + struct i2c_client *client_sec = NULL; const struct m88ds3103_config *p_m88ds3103_config = NULL; int (*p_set_voltage)(struct dvb_frontend *fe, fe_sec_voltage_t voltage) = NULL; int mfe_shared = 0; /* bus not shared by default */ @@ -2242,6 +2243,14 @@ static int dvb_register(struct cx23885_tsport *port) return 0; frontend_detach: + /* remove I2C client for SEC */ + client_sec = port->i2c_client_sec; + if (client_sec) { + module_put(client_sec->dev.driver->owner); + i2c_unregister_device(client_sec); + port->i2c_client_sec = NULL; + } + /* remove I2C client for tuner */ client_tuner = port->i2c_client_tuner; if (client_tuner) { @@ -2343,6 +2352,13 @@ int cx23885_dvb_unregister(struct cx23885_tsport *port) i2c_unregister_device(client); } + /* remove I2C client for SEC */ + client = port->i2c_client_sec; + if (client) { + module_put(client->dev.driver->owner); + i2c_unregister_device(client); + } + /* remove I2C client for tuner */ client = port->i2c_client_tuner; if (client) { diff --git a/drivers/media/pci/cx23885/cx23885.h b/drivers/media/pci/cx23885/cx23885.h index aeda8d3..81e2519 100644 --- a/drivers/media/pci/cx23885/cx23885.h +++ b/drivers/media/pci/cx23885/cx23885.h @@ -304,6 +304,7 @@ struct cx23885_tsport { struct i2c_client *i2c_client_demod; struct i2c_client *i2c_client_tuner; + struct i2c_client *i2c_client_sec; struct i2c_client *i2c_client_ci; int (*set_frontend)(struct dvb_frontend *fe); -- http://palosaari.fi/ -- 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 8/8] cx23885: Hauppauge WinTV-HVR5525 bind I2C SEC
Bind a8293 SEC using I2C binding. Signed-off-by: Antti Palosaari --- drivers/media/pci/cx23885/cx23885-dvb.c | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c b/drivers/media/pci/cx23885/cx23885-dvb.c index ef1ebcb..9f377ad 100644 --- a/drivers/media/pci/cx23885/cx23885-dvb.c +++ b/drivers/media/pci/cx23885/cx23885-dvb.c @@ -864,10 +864,6 @@ static const struct tda10071_platform_data hauppauge_tda10071_pdata = { .tuner_i2c_addr = 0x54, }; -static const struct a8293_config hauppauge_a8293_config = { - .i2c_addr = 0x0b, -}; - static const struct si2165_config hauppauge_hvr4400_si2165_config = { .i2c_addr = 0x64, .chip_mode = SI2165_MODE_PLL_XTAL, @@ -2167,6 +2163,7 @@ static int dvb_register(struct cx23885_tsport *port) case CX23885_BOARD_HAUPPAUGE_HVR5525: switch (port->nr) { struct m88rs6000t_config m88rs6000t_config; + struct a8293_platform_data a8293_pdata = {}; /* port b - satellite */ case 1: @@ -2178,10 +2175,20 @@ static int dvb_register(struct cx23885_tsport *port) break; /* attach SEC */ - if (!dvb_attach(a8293_attach, fe0->dvb.frontend, - &dev->i2c_bus[0].i2c_adap, - &hauppauge_a8293_config)) + a8293_pdata.dvb_frontend = fe0->dvb.frontend; + memset(&info, 0, sizeof(info)); + strlcpy(info.type, "a8293", I2C_NAME_SIZE); + info.addr = 0x0b; + info.platform_data = &a8293_pdata; + request_module("a8293"); + client_sec = i2c_new_device(&dev->i2c_bus[0].i2c_adap, &info); + if (!client_sec || !client_sec->dev.driver) goto frontend_detach; + if (!try_module_get(client_sec->dev.driver->owner)) { + i2c_unregister_device(client_sec); + goto frontend_detach; + } + port->i2c_client_sec = client_sec; /* attach tuner */ memset(&m88rs6000t_config, 0, sizeof(m88rs6000t_config)); -- http://palosaari.fi/ -- 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 6/8] cx23885: Hauppauge WinTV Starburst bind I2C demod and SEC
Bind tda10071 demod and a8293 SEC using I2C binding. Signed-off-by: Antti Palosaari --- drivers/media/pci/cx23885/cx23885-dvb.c | 52 - 1 file changed, 44 insertions(+), 8 deletions(-) diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c b/drivers/media/pci/cx23885/cx23885-dvb.c index ac062a5..4c41e11 100644 --- a/drivers/media/pci/cx23885/cx23885-dvb.c +++ b/drivers/media/pci/cx23885/cx23885-dvb.c @@ -866,6 +866,14 @@ static const struct tda10071_config hauppauge_tda10071_config = { .pll_multiplier = 20, }; +static const struct tda10071_platform_data hauppauge_tda10071_pdata = { + .clk = 40444000, /* 40.444 MHz */ + .i2c_wr_max = 64, + .ts_mode = TDA10071_TS_SERIAL, + .pll_multiplier = 20, + .tuner_i2c_addr = 0x54, +}; + static const struct a8293_config hauppauge_a8293_config = { .i2c_addr = 0x0b, }; @@ -1830,17 +1838,45 @@ static int dvb_register(struct cx23885_tsport *port) break; } break; - case CX23885_BOARD_HAUPPAUGE_STARBURST: + case CX23885_BOARD_HAUPPAUGE_STARBURST: { + struct tda10071_platform_data tda10071_pdata = hauppauge_tda10071_pdata; + struct a8293_platform_data a8293_pdata = {}; + i2c_bus = &dev->i2c_bus[0]; - fe0->dvb.frontend = dvb_attach(tda10071_attach, - &hauppauge_tda10071_config, - &i2c_bus->i2c_adap); - if (fe0->dvb.frontend != NULL) { - dvb_attach(a8293_attach, fe0->dvb.frontend, - &i2c_bus->i2c_adap, - &hauppauge_a8293_config); + + /* attach demod + tuner combo */ + memset(&info, 0, sizeof(info)); + strlcpy(info.type, "tda10071_cx24118", I2C_NAME_SIZE); + info.addr = 0x05; + info.platform_data = &tda10071_pdata; + request_module("tda10071"); + client_demod = i2c_new_device(&i2c_bus->i2c_adap, &info); + if (!client_demod || !client_demod->dev.driver) + goto frontend_detach; + if (!try_module_get(client_demod->dev.driver->owner)) { + i2c_unregister_device(client_demod); + goto frontend_detach; } + fe0->dvb.frontend = tda10071_pdata.get_dvb_frontend(client_demod); + port->i2c_client_demod = client_demod; + + /* attach SEC */ + a8293_pdata.dvb_frontend = fe0->dvb.frontend; + memset(&info, 0, sizeof(info)); + strlcpy(info.type, "a8293", I2C_NAME_SIZE); + info.addr = 0x0b; + info.platform_data = &a8293_pdata; + request_module("a8293"); + client_sec = i2c_new_device(&i2c_bus->i2c_adap, &info); + if (!client_sec || !client_sec->dev.driver) + goto frontend_detach; + if (!try_module_get(client_sec->dev.driver->owner)) { + i2c_unregister_device(client_sec); + goto frontend_detach; + } + port->i2c_client_sec = client_sec; break; + } case CX23885_BOARD_DVBSKY_T9580: case CX23885_BOARD_DVBSKY_S950: i2c_bus = &dev->i2c_bus[0]; -- http://palosaari.fi/ -- 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/8] a8293: implement I2C client bindings
Implement I2C client bindings. Signed-off-by: Antti Palosaari --- drivers/media/dvb-frontends/a8293.c | 87 +++-- drivers/media/dvb-frontends/a8293.h | 15 +++ 2 files changed, 99 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb-frontends/a8293.c b/drivers/media/dvb-frontends/a8293.c index 780da58..3f0cf9e 100644 --- a/drivers/media/dvb-frontends/a8293.c +++ b/drivers/media/dvb-frontends/a8293.c @@ -22,8 +22,9 @@ #include "a8293.h" struct a8293_priv { + u8 i2c_addr; struct i2c_adapter *i2c; - const struct a8293_config *cfg; + struct i2c_client *client; u8 reg[2]; }; @@ -32,7 +33,7 @@ static int a8293_i2c(struct a8293_priv *priv, u8 *val, int len, bool rd) int ret; struct i2c_msg msg[1] = { { - .addr = priv->cfg->i2c_addr, + .addr = priv->i2c_addr, .len = len, .buf = val, } @@ -128,7 +129,7 @@ struct dvb_frontend *a8293_attach(struct dvb_frontend *fe, /* setup the priv */ priv->i2c = i2c; - priv->cfg = cfg; + priv->i2c_addr = cfg->i2c_addr; fe->sec_priv = priv; /* check if the SEC is there */ @@ -164,6 +165,86 @@ err: } EXPORT_SYMBOL(a8293_attach); +static int a8293_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct a8293_priv *dev; + struct a8293_platform_data *pdata = client->dev.platform_data; + struct dvb_frontend *fe = pdata->dvb_frontend; + int ret; + u8 buf[2]; + + dev = kzalloc(sizeof(*dev), GFP_KERNEL); + if (!dev) { + ret = -ENOMEM; + goto err; + } + + dev->client = client; + dev->i2c = client->adapter; + dev->i2c_addr = client->addr; + + /* check if the SEC is there */ + ret = a8293_rd(dev, buf, 2); + if (ret) + goto err_kfree; + + /* ENB=0 */ + dev->reg[0] = 0x10; + ret = a8293_wr(dev, &dev->reg[0], 1); + if (ret) + goto err_kfree; + + /* TMODE=0, TGATE=1 */ + dev->reg[1] = 0x82; + ret = a8293_wr(dev, &dev->reg[1], 1); + if (ret) + goto err_kfree; + + /* override frontend ops */ + fe->ops.set_voltage = a8293_set_voltage; + + fe->sec_priv = dev; + i2c_set_clientdata(client, dev); + + dev_info(&client->dev, "Allegro A8293 SEC successfully attached\n"); + return 0; +err_kfree: + kfree(dev); +err: + dev_dbg(&client->dev, "failed=%d\n", ret); + return ret; +} + +static int a8293_remove(struct i2c_client *client) +{ + struct a8293_dev *dev = i2c_get_clientdata(client); + + dev_dbg(&client->dev, "\n"); + + kfree(dev); + return 0; +} + +static const struct i2c_device_id a8293_id_table[] = { + {"a8293", 0}, + {} +}; +MODULE_DEVICE_TABLE(i2c, a8293_id_table); + +static struct i2c_driver a8293_driver = { + .driver = { + .owner = THIS_MODULE, + .name = "a8293", + .suppress_bind_attrs = true, + }, + .probe = a8293_probe, + .remove = a8293_remove, + .id_table = a8293_id_table, +}; + +module_i2c_driver(a8293_driver); + MODULE_AUTHOR("Antti Palosaari "); MODULE_DESCRIPTION("Allegro A8293 SEC driver"); MODULE_LICENSE("GPL"); diff --git a/drivers/media/dvb-frontends/a8293.h b/drivers/media/dvb-frontends/a8293.h index 5f04119..aff3653 100644 --- a/drivers/media/dvb-frontends/a8293.h +++ b/drivers/media/dvb-frontends/a8293.h @@ -21,8 +21,23 @@ #ifndef A8293_H #define A8293_H +#include "dvb_frontend.h" #include +/* + * I2C address + * 0x08, 0x09, 0x0a, 0x0b + */ + +/** + * struct a8293_platform_data - Platform data for the a8293 driver + * @dvb_frontend: DVB frontend. + */ +struct a8293_platform_data { + struct dvb_frontend *dvb_frontend; +}; + + struct a8293_config { u8 i2c_addr; }; -- http://palosaari.fi/ -- 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 7/8] cx23885: Hauppauge WinTV-HVR4400/HVR5500 bind I2C demod and SEC
Bind tda10071 demod and a8293 SEC using I2C binding. Signed-off-by: Antti Palosaari --- drivers/media/pci/cx23885/cx23885-dvb.c | 54 + 1 file changed, 35 insertions(+), 19 deletions(-) diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c b/drivers/media/pci/cx23885/cx23885-dvb.c index 4c41e11..ef1ebcb 100644 --- a/drivers/media/pci/cx23885/cx23885-dvb.c +++ b/drivers/media/pci/cx23885/cx23885-dvb.c @@ -856,16 +856,6 @@ static struct mt2063_config terratec_mt2063_config[] = { }, }; -static const struct tda10071_config hauppauge_tda10071_config = { - .demod_i2c_addr = 0x05, - .tuner_i2c_addr = 0x54, - .i2c_wr_max = 64, - .ts_mode = TDA10071_TS_SERIAL, - .spec_inv = 0, - .xtal = 40444000, /* 40.444 MHz */ - .pll_multiplier = 20, -}; - static const struct tda10071_platform_data hauppauge_tda10071_pdata = { .clk = 40444000, /* 40.444 MHz */ .i2c_wr_max = 64, @@ -1806,21 +1796,46 @@ static int dvb_register(struct cx23885_tsport *port) fe0->dvb.frontend->ops.set_voltage = p8000_set_voltage; break; - case CX23885_BOARD_HAUPPAUGE_HVR4400: + case CX23885_BOARD_HAUPPAUGE_HVR4400: { + struct tda10071_platform_data tda10071_pdata = hauppauge_tda10071_pdata; + struct a8293_platform_data a8293_pdata = {}; + i2c_bus = &dev->i2c_bus[0]; i2c_bus2 = &dev->i2c_bus[1]; switch (port->nr) { /* port b */ case 1: - fe0->dvb.frontend = dvb_attach(tda10071_attach, - &hauppauge_tda10071_config, - &i2c_bus->i2c_adap); - if (fe0->dvb.frontend == NULL) - break; - if (!dvb_attach(a8293_attach, fe0->dvb.frontend, - &i2c_bus->i2c_adap, - &hauppauge_a8293_config)) + /* attach demod + tuner combo */ + memset(&info, 0, sizeof(info)); + strlcpy(info.type, "tda10071_cx24118", I2C_NAME_SIZE); + info.addr = 0x05; + info.platform_data = &tda10071_pdata; + request_module("tda10071"); + client_demod = i2c_new_device(&i2c_bus->i2c_adap, &info); + if (!client_demod || !client_demod->dev.driver) + goto frontend_detach; + if (!try_module_get(client_demod->dev.driver->owner)) { + i2c_unregister_device(client_demod); + goto frontend_detach; + } + fe0->dvb.frontend = tda10071_pdata.get_dvb_frontend(client_demod); + port->i2c_client_demod = client_demod; + + /* attach SEC */ + a8293_pdata.dvb_frontend = fe0->dvb.frontend; + memset(&info, 0, sizeof(info)); + strlcpy(info.type, "a8293", I2C_NAME_SIZE); + info.addr = 0x0b; + info.platform_data = &a8293_pdata; + request_module("a8293"); + client_sec = i2c_new_device(&i2c_bus->i2c_adap, &info); + if (!client_sec || !client_sec->dev.driver) goto frontend_detach; + if (!try_module_get(client_sec->dev.driver->owner)) { + i2c_unregister_device(client_sec); + goto frontend_detach; + } + port->i2c_client_sec = client_sec; break; /* port c */ case 2: @@ -1838,6 +1853,7 @@ static int dvb_register(struct cx23885_tsport *port) break; } break; + } case CX23885_BOARD_HAUPPAUGE_STARBURST: { struct tda10071_platform_data tda10071_pdata = hauppauge_tda10071_pdata; struct a8293_platform_data a8293_pdata = {}; -- http://palosaari.fi/ -- 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/8] em28xx: bind PCTV 460e using I2C client
Load PCTV 460e tda10071 demod and a8293 SEC using I2C client bindings. Remove old unused tda10071 config struct. We are using I2C platform data now. Signed-off-by: Antti Palosaari --- drivers/media/usb/em28xx/em28xx-dvb.c | 68 ++- 1 file changed, 51 insertions(+), 17 deletions(-) diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c b/drivers/media/usb/em28xx/em28xx-dvb.c index ef1bfa2..be0abca 100644 --- a/drivers/media/usb/em28xx/em28xx-dvb.c +++ b/drivers/media/usb/em28xx/em28xx-dvb.c @@ -808,16 +808,6 @@ static struct tda18271_config em28xx_cxd2820r_tda18271_config = { .gate = TDA18271_GATE_DIGITAL, }; -static const struct tda10071_config em28xx_tda10071_config = { - .demod_i2c_addr = 0x55, /* (0xaa >> 1) */ - .tuner_i2c_addr = 0x14, - .i2c_wr_max = 64, - .ts_mode = TDA10071_TS_SERIAL, - .spec_inv = 0, - .xtal = 40444000, /* 40.444 MHz */ - .pll_multiplier = 20, -}; - static const struct a8293_config em28xx_a8293_config = { .i2c_addr = 0x08, /* (0x10 >> 1) */ }; @@ -1332,16 +1322,60 @@ static int em28xx_dvb_init(struct em28xx *dev) &dev->i2c_adap[dev->def_i2c_bus], &c3tech_duo_tda18271_config); break; - case EM28174_BOARD_PCTV_460E: - /* attach demod */ - dvb->fe[0] = dvb_attach(tda10071_attach, - &em28xx_tda10071_config, &dev->i2c_adap[dev->def_i2c_bus]); + case EM28174_BOARD_PCTV_460E: { + struct i2c_client *client; + struct i2c_board_info board_info; + struct tda10071_platform_data tda10071_pdata = {}; + struct a8293_platform_data a8293_pdata = {}; + + /* attach demod + tuner combo */ + tda10071_pdata.clk = 40444000, /* 40.444 MHz */ + tda10071_pdata.i2c_wr_max = 64, + tda10071_pdata.ts_mode = TDA10071_TS_SERIAL, + tda10071_pdata.pll_multiplier = 20, + tda10071_pdata.tuner_i2c_addr = 0x14, + memset(&board_info, 0, sizeof(board_info)); + strlcpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE); + board_info.addr = 0x55; + board_info.platform_data = &tda10071_pdata; + request_module("tda10071"); + client = i2c_new_device(&dev->i2c_adap[dev->def_i2c_bus], &board_info); + if (client == NULL || client->dev.driver == NULL) { + result = -ENODEV; + goto out_free; + } + if (!try_module_get(client->dev.driver->owner)) { + i2c_unregister_device(client); + result = -ENODEV; + goto out_free; + } + dvb->fe[0] = tda10071_pdata.get_dvb_frontend(client); + dvb->i2c_client_demod = client; /* attach SEC */ - if (dvb->fe[0]) - dvb_attach(a8293_attach, dvb->fe[0], &dev->i2c_adap[dev->def_i2c_bus], - &em28xx_a8293_config); + a8293_pdata.dvb_frontend = dvb->fe[0]; + memset(&board_info, 0, sizeof(board_info)); + strlcpy(board_info.type, "a8293", I2C_NAME_SIZE); + board_info.addr = 0x08; + board_info.platform_data = &a8293_pdata; + request_module("a8293"); + client = i2c_new_device(&dev->i2c_adap[dev->def_i2c_bus], &board_info); + if (client == NULL || client->dev.driver == NULL) { + module_put(dvb->i2c_client_demod->dev.driver->owner); + i2c_unregister_device(dvb->i2c_client_demod); + result = -ENODEV; + goto out_free; + } + if (!try_module_get(client->dev.driver->owner)) { + i2c_unregister_device(client); + module_put(dvb->i2c_client_demod->dev.driver->owner); + i2c_unregister_device(dvb->i2c_client_demod); + result = -ENODEV; + goto out_free; + } + dvb->i2c_client_sec = client; break; + } case EM2874_BOARD_DELOCK_61959: case EM2874_BOARD_MAXMEDIA_UB425_TC: /* attach demodulator */ -- http://palosaari.fi/ -- 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 v8 8/8] DT: samsung-fimc: Add examples for samsung,flash-led property
Hi Sylwester, On Thu, May 21, 2015 at 06:58:59PM +0200, Sylwester Nawrocki wrote: > Hi Sakari, > > On 21/05/15 16:20, Sakari Ailus wrote: > > On Thu, May 21, 2015 at 03:28:40PM +0200, Sylwester Nawrocki wrote: > >> > On 21/05/15 13:32, Sakari Ailus wrote: > >> > @@ -147,6 +149,8 @@ Example: > > > > >> clocks = <&camera 0>; > > > > >> clock-names = "mclk"; > > > > >> > > > > >>+samsung,flash-led = > > > > >><&rear_cam_flash>; > > > > >>+ > > > > >> port { > > > > >> s5c73m3_1: endpoint { > > > > >> data-lanes = <1 > > > > >> 2 3 4>; > >>> > >>> > > > >>> > >>> > >Oops. I missed this property would have ended to the > >>> > >>> > >sensor's DT node. I > >>> > >>> > >don't think we should have properties here that are parsed > >>> > >>> > >by another > >>> > >>> > >driver --- let's discuss this tomorrow. > > > >> > > > > >> > exynos4-is driver already parses sensor nodes (at least their > > > >> > 'port' > > > >> > sub-nodes). > >>> > > > >>> > > If you read the code and the comment, it looks like something that > >>> > > should be > >>> > > done better but hasn't been done yet. :-) That's something we should > >>> > > avoid. > >>> > > Also, flash devices are by far more common than external ISPs I > >>> > > presume. > >> > > >> > Yes, especially let's not require any samsung specific properties in > >> > other vendors' sensor bindings. > >> > > >> > One way of modelling [flash led]/[image sensor] association I imagine > >> > would be to put, e.g. 'flash-leds' property in the SoC camera host > >> > interface/ISP DT node. This property would then contain pairs of > >> > phandles, > >> > first to the led node and the second to the sensor node, e.g. > >> > > >> > i2c_controller { > >> > ... > >> > flash_xx@NN { > >> > ... > >> > led_a { > >> > ... > >> > } > >> > }; > >> > > >> > image_sensor_x@NN { > >> > ... > >> > }; > >> > }; > >> > > >> > flash-leds = <&flash_xx &image_sensor_x>, <...>; > > > > Maybe a stupid question, but how do you access this in a driver? I have to > > admit I'm no DT expert. > > You could get of_node pointers with of_parse_phandle() call and then > lookup related flash and sensor devices based on that. Ack. Looks good to me. > >> > For the purpose of this patch set presumably just samsung specific > >> > property name could be used (i.e. samsung,flash-leds). > > > > I agree. I'll add similar support for the omap3isp driver in the near future > > though. Let's see how the camera modules will get modelled, if they will, > > and if this property still fits to the picture by that time, then we make it > > more generic. > > > > What do you think? > > I think we could do that, perhaps we could get some more opinions and > use generic name already in this series? I'm not sure what are exact > plans for this series, I guess it is targeted for 4.2? There have been very few opinions expressed besides yours, mine and Jacek's, unfortunately. I'm also not very certain on the future-proofness of this solution until we have better understanding of how modules would best be expressed in DT. v4.2 would be nice target for these, yes. -- 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:
Teraz mozesz uzyskac kredyt w wysokosci 2% za uniewaznic i dostac do 40 lat lub wiecej, aby splacic. Nie naleza do kredytów krótkoterminowych, które sprawiaja, ze zwróci sie w kilka tygodni lub miesiecy. Nasza oferta obejmuje; * Refinansowanie * Home Improvement * Kredyty samochodowe * Konsolidacja zadluzenia * Linia kredytowa * Druga hipoteczny * Biznes Pozyczki * Pozyczki Personal Zdobadz pieniadze potrzebne dzis z duza iloscia czasu, aby dokonac platnosci powrotem. Aby zastosowac, aby wyslac wszystkie pytania lub zaproszenia fwfshelpd...@gmail.com: + 1- 435-241-5945 Now you can get a loan at 2% per annul and get up to 40 years or more to pay it back. Don't fall for the short term loans that make you pay back in weeks or months. Our offer include; *Refinance *Home Improvement *Auto Loans *Debt Consolidation*Line of Credit *Second Mortgage *Business Loans*Personal Loans Get the money you need today with plenty of time to make the payments back. To apply, send all inquiries to fwfshelpd...@gmail.com or call : + 1- 435-241-5945 --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.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: ERRORS
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: Fri May 22 04:00:19 CEST 2015 git branch: test git hash: 2a80f296422a01178d0a993479369e94f5830127 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS 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-bf561: ERRORS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-i686: WARNINGS linux-4.1-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0-x86_64: WARNINGS linux-4.1-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: ERRORS ABI WARNING: change for blackfin-bf561 ABI WARNING: change for mips smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
[RFC PATCH v2 4/4] adv7842: Use interlaced info for cvt/gtf timing detection
The interlaced information from stdi is passed to detect_cvt/gtf(). Cc: Hans Verkuil Cc: Martin Bugge Cc: Mats Randgaard Cc: Laurent Pinchart Signed-off-by: Prashant Laddha --- drivers/media/i2c/adv7842.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c index b9264f7..8a7c9bd 100644 --- a/drivers/media/i2c/adv7842.c +++ b/drivers/media/i2c/adv7842.c @@ -1445,12 +1445,12 @@ static int stdi2dv_timings(struct v4l2_subdev *sd, if (v4l2_detect_cvt(stdi->lcf + 1, hfreq, stdi->lcvs, (stdi->hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) | (stdi->vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0), - false, timings)) + stdi->interlaced, timings)) return 0; if (v4l2_detect_gtf(stdi->lcf + 1, hfreq, stdi->lcvs, (stdi->hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) | (stdi->vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0), - false, state->aspect_ratio, timings)) + stdi->interlaced, state->aspect_ratio, timings)) return 0; v4l2_dbg(2, debug, sd, -- 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
[RFC PATCH v2 0/4] Support for interlaced in cvt/gtf timings
Please find version 2 of patches adding interlaced support in cvt/gtf timing. Changes compared to v1: Incorporated the comments from review of first RFC. It was about the error calculation of vertical back porch due to rounding. (Thanks to Hans for spoting this error). Prashant Laddha (4): v4l2-dv-timings: add interlace support in detect cvt/gtf vivid: Use interlaced info for cvt/gtf timing detection adv7604: Use interlaced info for cvt/gtf timing detection adv7842: Use interlaced info for cvt/gtf timing detection drivers/media/i2c/adv7604.c | 4 +-- drivers/media/i2c/adv7842.c | 4 +-- drivers/media/platform/vivid/vivid-vid-cap.c | 5 +-- drivers/media/v4l2-core/v4l2-dv-timings.c| 53 include/media/v4l2-dv-timings.h | 6 ++-- 5 files changed, 58 insertions(+), 14 deletions(-) -- 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
[RFC PATCH v2 3/4] adv7604: Use interlaced info for cvt/gtf timing detection
The interlaced information from stdi is passed to detect_cvt/gtf(). These functions now supports timing calculations for interlaced format. Cc: Hans Verkuil Cc: Martin Bugge Cc: Mats Randgaard Cc: Laurent Pinchart Signed-off-by: Prashant Laddha --- drivers/media/i2c/adv7604.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index f4ecb73..d290f7a 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -1323,12 +1323,12 @@ static int stdi2dv_timings(struct v4l2_subdev *sd, if (v4l2_detect_cvt(stdi->lcf + 1, hfreq, stdi->lcvs, (stdi->hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) | (stdi->vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0), - false, timings)) + stdi->interlaced, timings)) return 0; if (v4l2_detect_gtf(stdi->lcf + 1, hfreq, stdi->lcvs, (stdi->hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) | (stdi->vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0), - false, state->aspect_ratio, timings)) + stdi->interlaced, state->aspect_ratio, timings)) return 0; v4l2_dbg(2, debug, sd, -- 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
[RFC PATCH v2 2/4] vivid: Use interlaced info for cvt/gtf timing detection
The detect_cvt/gtf() now supports timing calculations for interlaced format. Cc: Hans Verkuil Signed-off-by: Prashant Laddha --- drivers/media/platform/vivid/vivid-vid-cap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c b/drivers/media/platform/vivid/vivid-vid-cap.c index a99362d..60298c7 100644 --- a/drivers/media/platform/vivid/vivid-vid-cap.c +++ b/drivers/media/platform/vivid/vivid-vid-cap.c @@ -1619,7 +1619,7 @@ static bool valid_cvt_gtf_timings(struct v4l2_dv_timings *timings) if (bt->standards == 0 || (bt->standards & V4L2_DV_BT_STD_CVT)) { if (v4l2_detect_cvt(total_v_lines, h_freq, bt->vsync, - bt->polarities, false, timings)) + bt->polarities, bt->interlaced, timings)) return true; } @@ -1630,7 +1630,7 @@ static bool valid_cvt_gtf_timings(struct v4l2_dv_timings *timings) &aspect_ratio.numerator, &aspect_ratio.denominator); if (v4l2_detect_gtf(total_v_lines, h_freq, bt->vsync, - bt->polarities, false, + bt->polarities, bt->interlaced, aspect_ratio, timings)) return true; } -- 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
[RFC PATCH v2 1/4] v4l2-dv-timings: add interlace support in detect cvt/gtf
Extended detect_cvt/gtf API to indicate the format type (interlaced or progressive). In case of interlaced, the vertical front and back porch and vsync values for both (odd,even) fields are considered to derive image height. Populated vsync, verical front, back porch values in bt timing structure for even and odd fields and updated the flags appropriately. Also modified the functions calling the detect_cvt/gtf(). As of now these functions are calling detect_cvt/gtf() with interlaced flag set to false. Cc: Hans Verkuil Cc: Martin Bugge Cc: Mats Randgaard Cc: Laurent Pinchart Signed-off-by: Prashant Laddha --- drivers/media/i2c/adv7604.c | 4 +-- drivers/media/i2c/adv7842.c | 4 +-- drivers/media/platform/vivid/vivid-vid-cap.c | 5 +-- drivers/media/v4l2-core/v4l2-dv-timings.c| 53 include/media/v4l2-dv-timings.h | 6 ++-- 5 files changed, 58 insertions(+), 14 deletions(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index aaa37b0..f4ecb73 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -1323,12 +1323,12 @@ static int stdi2dv_timings(struct v4l2_subdev *sd, if (v4l2_detect_cvt(stdi->lcf + 1, hfreq, stdi->lcvs, (stdi->hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) | (stdi->vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0), - timings)) + false, timings)) return 0; if (v4l2_detect_gtf(stdi->lcf + 1, hfreq, stdi->lcvs, (stdi->hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) | (stdi->vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0), - state->aspect_ratio, timings)) + false, state->aspect_ratio, timings)) return 0; v4l2_dbg(2, debug, sd, diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c index f5248ba..b9264f7 100644 --- a/drivers/media/i2c/adv7842.c +++ b/drivers/media/i2c/adv7842.c @@ -1445,12 +1445,12 @@ static int stdi2dv_timings(struct v4l2_subdev *sd, if (v4l2_detect_cvt(stdi->lcf + 1, hfreq, stdi->lcvs, (stdi->hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) | (stdi->vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0), - timings)) + false, timings)) return 0; if (v4l2_detect_gtf(stdi->lcf + 1, hfreq, stdi->lcvs, (stdi->hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) | (stdi->vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0), - state->aspect_ratio, timings)) + false, state->aspect_ratio, timings)) return 0; v4l2_dbg(2, debug, sd, diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c b/drivers/media/platform/vivid/vivid-vid-cap.c index fd7adc4..a99362d 100644 --- a/drivers/media/platform/vivid/vivid-vid-cap.c +++ b/drivers/media/platform/vivid/vivid-vid-cap.c @@ -1619,7 +1619,7 @@ static bool valid_cvt_gtf_timings(struct v4l2_dv_timings *timings) if (bt->standards == 0 || (bt->standards & V4L2_DV_BT_STD_CVT)) { if (v4l2_detect_cvt(total_v_lines, h_freq, bt->vsync, - bt->polarities, timings)) + bt->polarities, false, timings)) return true; } @@ -1630,7 +1630,8 @@ static bool valid_cvt_gtf_timings(struct v4l2_dv_timings *timings) &aspect_ratio.numerator, &aspect_ratio.denominator); if (v4l2_detect_gtf(total_v_lines, h_freq, bt->vsync, - bt->polarities, aspect_ratio, timings)) + bt->polarities, false, + aspect_ratio, timings)) return true; } return false; diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c b/drivers/media/v4l2-core/v4l2-dv-timings.c index 5792192..7e15749 100644 --- a/drivers/media/v4l2-core/v4l2-dv-timings.c +++ b/drivers/media/v4l2-core/v4l2-dv-timings.c @@ -339,6 +339,7 @@ EXPORT_SYMBOL_GPL(v4l2_print_dv_timings); * @vsync - the height of the vertical sync in lines. * @polarities - the horizontal and vertical polarities (same as struct * v4l2_bt_timings polarities). + * @interlaced - if this flag is true, it indicates interlaced format * @fmt - the resulting timings. * * This function will attempt to detect if the given values correspond to a @@ -350,7 +351,7 @@ EXPORT_SYMBOL_GPL(v4l2_print_dv_timings); * detection function. */ bool v4l2_detect_cvt(unsigned frame_height, unsigned hfreq, unsigned vsync, - u32 polarities, struct v4l2_dv_timings *fmt) + u32 polarities, bool interlac
Re: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback
On 21 May 2015 at 22:40, David Härdeman wrote: > On Thu, May 21, 2015 at 05:22:08PM +0300, Antti Seppälä wrote: >>On 21 May 2015 at 15:30, David Härdeman wrote: >>> On 2015-05-21 13:51, Antti Seppälä wrote: On 21 May 2015 at 12:14, David Härdeman wrote: > > I'm talking about ir_raw_encode_scancode() which is entirely broken in > its > current state. It will, given more than one enabled protocol, encode a > scancode to pulse/space events according to the rules of a randomly > chosen > protocol. That random selection will be influenced by things like *module > load order* (independent of the separate fact that passing multiple > protocols to it is completely bogus in the first place). > > To be clear: the same scancode may be encoded differently depending on if > you've load the nec decoder before or after the rc5 decoder! That kind of > behavior can't go into a release kernel (Mauro...). > So... if the ir_raw_handler_list is sorted to eliminate the randomness caused by module load ordering you will be happy (or happier)? >>> >>> >>> No, cause it's a horrible hack. And the caller of ir_raw_handler_list() >>> still has no idea of knowing (given more than one protocol) which protocol a >>> given scancode will be encoded according to. >>> >> >>Okay, so how about "demuxing" the first protocol before handing them >>to encoder callback? Simply something like below: >> >>- if (handler->protocols & protocols && handler->encode) { >>+ if (handler->protocols & ffs(protocols) && handler->encode) { >> >>Now the behavior is well-defined even when multiple protocols are selected. > > Your patchset introduced ir_raw_encode_scancode() as well as the only > two callers of that function: > > drivers/media/rc/nuvoton-cir.c > drivers/media/rc/rc-loopback.c > > I realize that the sysfs wakeup_protocols file (which bakes several > protocols into one label) makes defining *the* protocol difficult, but > if you're going to add hacks like this, keep them to the sole driver > using the API rather than the core API itself. > > That is, change nvt_ir_raw_change_wakeup_protocol() so that it picks a > single protocol, no matter how many are passed to it (the img-ir driver > already sets a precedent here so it wouldn't be an API change to change > to a set of protocols which might be different than what the user > suggested). (Also...yes, that'll make supporting several versions of > e.g. RC6 impossible with the current sysfs code). > I think that approach too is far from perfect as it leaves us with questions such as: How do we let the user know what variant of protocol the label "rc-6" really means? If in nvt we hardcode it to mean RC6-0-16 and a new driver cames along which chooses RC_TYPE_RC6_6A_24 how do we tell the user that the implementations differ? What if the scancode that was fed was really RC_TYPE_RC6_MCE? If only there were a sysfs api to set the exact variant life would be simpler... > Then change both ir_raw_encode_scancode() to take a single protocol enum > and change the *encode function pointer in struct ir_raw_handler to also > take a single protocol enum. > > That way encoders won't have to guess (using scanmasks...!?) what > protocol they should encode to. > > And Mauro...I strongly suggest you revert all of this encoding stuff > until this has been fixed...it's broken. > Let me shortly recap the points made so far about the encoding stuff: * If user enables multiple wakeup_protocols then the first matching one will be used to do the encoding. "First" being the module that was loaded first. * Currently the encoders use heuristics to determine the intended protocol variant from the scancode that was fed and from the length of the scanmask. This causes the programmer using the encoder to not know which exact variant will be used (until after the encoding is done when the information can be made available if needed). The way current sysfs api works using heuristics was a design choice since we don't have a better way to specify the protocol variant. Hope I didn't miss anything? So yeah.. The code isn't "broken" in a sense that it wouldn't work. It's more a question of what we want the api to look like. Mauro what do you think should be done? -- Antti -- 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