Re: [PATCH 08/43] imx-drm: ipu-v3: Add units required for video capture
On Sat, Jun 07, 2014 at 02:56:10PM -0700, Steve Longerbeam wrote:
Adds the following new IPU units:
- Camera Sensor Interface (csi)
- Sensor Multi FIFO Controller (smfc)
- Image Converter (ic)
- Image Rotator (irt)
Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com
---
drivers/staging/imx-drm/ipu-v3/Makefile |3 +-
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 67 ++-
drivers/staging/imx-drm/ipu-v3/ipu-csi.c| 821 ++
drivers/staging/imx-drm/ipu-v3/ipu-ic.c | 835
+++
drivers/staging/imx-drm/ipu-v3/ipu-irt.c| 103
drivers/staging/imx-drm/ipu-v3/ipu-prv.h| 24 +
drivers/staging/imx-drm/ipu-v3/ipu-smfc.c | 348 +++
include/linux/platform_data/imx-ipu-v3.h| 151 +
8 files changed, 2350 insertions(+), 2 deletions(-)
create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-csi.c
create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-ic.c
create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-irt.c
create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-smfc.c
diff --git a/drivers/staging/imx-drm/ipu-v3/Makefile
b/drivers/staging/imx-drm/ipu-v3/Makefile
index 28ed72e..79c0c88 100644
--- a/drivers/staging/imx-drm/ipu-v3/Makefile
+++ b/drivers/staging/imx-drm/ipu-v3/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += imx-ipu-v3.o
-imx-ipu-v3-objs := ipu-common.o ipu-dc.o ipu-di.o ipu-dp.o ipu-dmfc.o
+imx-ipu-v3-objs := ipu-common.o ipu-csi.o ipu-dc.o ipu-di.o \
+ ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-irt.o ipu-smfc.o
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index 1c606b5..3d7e28d 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -834,6 +834,10 @@ struct ipu_devtype {
unsigned long cpmem_ofs;
unsigned long srm_ofs;
unsigned long tpm_ofs;
+ unsigned long csi0_ofs;
+ unsigned long csi1_ofs;
+ unsigned long smfc_ofs;
+ unsigned long ic_ofs;
unsigned long disp0_ofs;
unsigned long disp1_ofs;
unsigned long dc_tmpl_ofs;
@@ -873,8 +877,12 @@ static struct ipu_devtype ipu_type_imx6q = {
.cpmem_ofs = 0x0030,
.srm_ofs = 0x0034,
.tpm_ofs = 0x0036,
+ .csi0_ofs = 0x0023,
+ .csi1_ofs = 0x00238000,
.disp0_ofs = 0x0024,
.disp1_ofs = 0x00248000,
+ .smfc_ofs = 0x0025,
+ .ic_ofs = 0x0022,
.dc_tmpl_ofs = 0x0038,
.vdi_ofs = 0x00268000,
.type = IPUV3H,
@@ -915,8 +923,44 @@ static int ipu_submodules_init(struct ipu_soc *ipu,
struct device *dev = pdev-dev;
const struct ipu_devtype *devtype = ipu-devtype;
+ ret = ipu_csi_init(ipu, dev, 0, ipu_base + devtype-csi0_ofs,
+IPU_CONF_CSI0_EN, ipu_clk);
+ if (ret) {
+ unit = csi0;
+ goto err_csi_0;
+ }
Please be nice to other SoCs. You set csi0_ofs for i.MX6, but not for
i.MX5. For i.MX5 you silently initialize the CSI with bogus register
offsets. Either test for _ofs == 0 before initializing it or add the
correct values for i.MX51/53 (preferred).
+int ipu_csi_set_src(struct ipu_csi *csi, u32 vc, bool select_mipi_csi2)
+{
+ struct ipu_soc *ipu = csi-ipu;
+ int ipu_id = ipu_get_num(ipu);
+ u32 val, bit;
+
+ /*
+ * Set the muxes that choose between mipi-csi2 and parallel inputs
+ * to the CSI's.
+ */
+ if (csi-ipu-ipu_type == IPUV3HDL) {
+ /*
+ * On D/L, the mux is in GPR13. The TRM is unclear,
+ * but it appears the mux allows selecting the MIPI
+ * CSI-2 virtual channel number to route to the CSIs.
+ */
+ bit = GPR13_IPUV3HDL_CSI_MUX_CTL_SHIFT + csi-id * 3;
+ val = select_mipi_csi2 ? vc bit : 4 bit;
+ regmap_update_bits(ipu-gp_reg, IOMUXC_GPR13,
+0x7 bit, val);
+ } else if (csi-ipu-ipu_type == IPUV3H) {
+ /*
+ * For Q/D, the mux only exists on IPU0-CSI0 and IPU1-CSI1,
+ * and the routed virtual channel numbers are fixed at 0 and
+ * 3 respectively.
+ */
+ if ((ipu_id == 0 csi-id == 0) ||
+ (ipu_id == 1 csi-id == 1)) {
+ bit = GPR1_IPU_CSI_MUX_CTL_SHIFT + csi-ipu-id;
+ val = select_mipi_csi2 ? 0 : 1 bit;
+ regmap_update_bits(ipu-gp_reg, IOMUXC_GPR1,
+0x1 bit, val);
+ }
+ } else {
+ dev_err(csi-ipu-dev,
+ ERROR: %s: unsupported CPU version!\n,
+ __func__);
+ return -EINVAL;
+ }
+
+ /*
+ * there is another mux in the IPU config register that
+ * must be set as
Re: [PATCH v3 2/3] smiapp: Add driver-specific test pattern menu item definitions
Hi Prabhakar, Thanks for the review! :-) Prabhakar Lad wrote: Hi Sakari, On Thu, May 29, 2014 at 3:40 PM, Sakari Ailus sakari.ai...@linux.intel.com wrote: Add numeric definitions for menu items used in the smiapp driver's test pattern menu. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com --- include/uapi/linux/smiapp.h | 29 + Don't you need to add an entry in Kbuild file for this ? Good poing. I'll send v3.1 for this one as well. -- Sakari Ailus sakari.ai...@linux.intel.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
[PATCH v3.1 2/4] smiapp: Add driver-specific test pattern menu item definitions
Add numeric definitions for menu items used in the smiapp driver's test pattern menu. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- since v3: - Add Kbuild entry for the header include/uapi/linux/Kbuild | 1 + include/uapi/linux/smiapp.h | 29 + 2 files changed, 30 insertions(+) create mode 100644 include/uapi/linux/smiapp.h diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild index 6929571..a3ee163 100644 --- a/include/uapi/linux/Kbuild +++ b/include/uapi/linux/Kbuild @@ -352,6 +352,7 @@ header-y += serio.h header-y += shm.h header-y += signal.h header-y += signalfd.h +header-y += smiapp.h header-y += snmp.h header-y += sock_diag.h header-y += socket.h diff --git a/include/uapi/linux/smiapp.h b/include/uapi/linux/smiapp.h new file mode 100644 index 000..53938f4 --- /dev/null +++ b/include/uapi/linux/smiapp.h @@ -0,0 +1,29 @@ +/* + * include/uapi/linux/smiapp.h + * + * Generic driver for SMIA/SMIA++ compliant camera modules + * + * Copyright (C) 2014 Intel Corporation + * Contact: Sakari Ailus sakari.ai...@iki.fi + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + */ + +#ifndef __UAPI_LINUX_SMIAPP_H_ +#define __UAPI_LINUX_SMIAPP_H_ + +#define V4L2_SMIAPP_TEST_PATTERN_MODE_DISABLED 0 +#define V4L2_SMIAPP_TEST_PATTERN_MODE_SOLID_COLOUR 1 +#define V4L2_SMIAPP_TEST_PATTERN_MODE_COLOUR_BARS 2 +#define V4L2_SMIAPP_TEST_PATTERN_MODE_COLOUR_BARS_GREY 3 +#define V4L2_SMIAPP_TEST_PATTERN_MODE_PN9 4 + +#endif /* __UAPI_LINUX_SMIAPP_H_ */ -- 1.8.3.2 -- 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: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically
Hey Jason, Do we know if that RF problem exists in 3.14.5? Using the IT913X driver? I have a Leadtek Winfast Dual Dongle (0413:6a05 - dual usb - ITE9137 BX + IE9133) which is being extremely painful (random signal locks, tzap reports ok signal strength for one tuner but poor for the other, random signal dropouts (ie working fine, then progressively getting more and more blips in visual/audio from stream)). I dont think its signal strength related because 3x Leadtek Winfast Gold dongles (AF9013) all work (until they stop tuning and cold reboot is required) I suspect something about the firmware is at fault, I have tried to talk to Antti - but he must be busy. I have tried three different dvb-usb-it9135-02.fw firmwares, and they don't seem to make a huge difference (newest doesn't create /dev/dvb bits)... Does a BX (v2) 9137 require yet another firmware image? If I use the AF9035 kernel driver it doesn't tune at all. But does detect the tuners... Sorry to threadjack - but seeing your @ite.com.tw I thought I would ask while I can :) Regards David On 11 June 2014 15:31, jason.d...@ite.com.tw wrote: Dear Sebastian, There is a RF performance issue in the af9033 driver of kernel 3.15. It is no problem in the it913x driver of kernel 3.14. There were some initial sequences not correct after the it913x driver was integrated into af9033 driver. BRs, Jason -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Sebastian Kemper Sent: Tuesday, June 10, 2014 8:51 PM To: linux-media@vger.kernel.org Subject: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically Hello list, I have an Avermedia A835B(1835) USB DVB-T stick (07ca:1835) which works only (very) sporadically. It's pure luck as far as I can see. I can't reproduce how to get it working. There are no special steps that I can take to guarantee that it'll work once I plug it in. I'd rate my chances of having the device actually working between 5 and 10 percent. In the log everything looks fine, apart from the messages at the bottom about the device not being able to get a lock on a channel. Reception here is really good, so there's no problem with signal strength. When loading the device in Windows 7 64 bit it always finds a lock. Has anybody any idea? Thanks for any suggestions! Jun 10 14:18:07 meiner kernel: usb 1-2: new high-speed USB device number 2 using xhci_hcd Jun 10 14:18:07 meiner kernel: WARNING: You are using an experimental version of the media stack. Jun 10 14:18:07 meiner kernel: As the driver is backported to an older kernel, it doesn't offer Jun 10 14:18:07 meiner kernel: enough quality for its usage in production. Jun 10 14:18:07 meiner kernel: Use it with care. Jun 10 14:18:07 meiner kernel: Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): Jun 10 14:18:07 meiner kernel: bfd0306462fdbc5e0a8c6999aef9dde0f9745399 [media] v4l: Document timestamp buffer flag behaviour Jun 10 14:18:07 meiner kernel: 309f4d62eda0e864c2d4eef536cc82e41931c3c5 [media] v4l: Copy timestamp source flags to destination on m2m devices Jun 10 14:18:07 meiner kernel: 599b08929efe9b90e44b504454218a120bb062a0 [media] exynos-gsc, m2m-deinterlace, mx2_emmaprp: Copy v4l2_buffer data from src to dst Jun 10 14:18:07 meiner kernel: experimental: a60b303c3e347297a25f0a203f0ff11a8efc818c experimental/ngene: Support DuoFlex C/C2/T/T2 (V3) Jun 10 14:18:07 meiner kernel: v4l-dvb-saa716x: 052c468e33be00a3d4d9b93da3581ffa861bb288 saa716x: IO memory of upper PHI1 regions is mapped in saa716x_ff driver. Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_af9035: prechip_version=83 chip_version=02 chip_type=9135 Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_v2: found a 'Avermedia A835B(1835)' in cold state Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9135-02.fw' Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_af9035: firmware version=3.42.3.3 Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_v2: found a 'Avermedia A835B(1835)' in warm state Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer Jun 10 14:18:07 meiner kernel: DVB: registering new adapter (Avermedia A835B(1835)) Jun 10 14:18:07 meiner kernel: i2c i2c-0: af9033: firmware version: LINK=0.0.0.0 OFDM=3.29.3.3 Jun 10 14:18:07 meiner kernel: usb 1-2: DVB: registering adapter 0 frontend 0 (Afatech AF9033 (DVB-T))... Jun 10 14:18:07 meiner kernel: i2c i2c-0: tuner_it913x: ITE Tech IT913X successfully attached Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_v2: 'Avermedia A835B(1835)' successfully initialized and connected Jun 10 14:18:07 meiner kernel: usbcore: registered new interface driver dvb_usb_af9035 Jun 10 14:18:28 meiner vdr: [1653] VDR version 2.0.4 started Jun 10 14:18:28 meiner vdr:
Re: [PATCH 00/43] i.MX6 Video capture
On 06/11/2014 02:54 AM, Steve Longerbeam wrote:
On 06/10/2014 08:11 AM, Hans Verkuil wrote:
On 06/09/2014 06:42 PM, Steve Longerbeam wrote:
On 06/08/2014 01:36 AM, Hans Verkuil wrote:
Hi Steve!
On 06/07/2014 11:56 PM, Steve Longerbeam wrote:
Hi all,
This patch set adds video capture support for the Freescale i.MX6 SOC.
It is a from-scratch standardized driver that works with community
v4l2 utilities, such as v4l2-ctl, v4l2-cap, and the v4l2src gstreamer
plugin. It uses the latest v4l2 interfaces (subdev, videobuf2).
Please see Documentation/video4linux/mx6_camera.txt for it's full list
of features!
The first 38 patches:
- prepare the ipu-v3 driver for video capture support. The current driver
contains only video display functionality to support the imx DRM
drivers.
At some point ipu-v3 should be moved out from under staging/imx-drm
since
it will no longer only support DRM.
- Adds the device tree nodes and OF graph bindings for video capture
support
on sabrelite, sabresd, and sabreauto reference platforms.
The new i.MX6 capture host interface driver is at patch 39.
To support the sensors found on the sabrelite, sabresd, and sabreauto,
three patches add sensor subdev's for parallel OV5642, MIPI CSI-2 OV5640,
and the ADV7180 decoder chip, beginning at patch 40.
There is an existing adv7180 subdev driver under drivers/media/i2c, but
it needs some extra functionality to work on the sabreauto. It will need
OF graph bindings support and gpio for a power-on pin on the sabreauto.
It would also need to send a new subdev notification to take advantage
of decoder status change handling provided by the host driver. This
feature makes it possible to correctly handle hot (while streaming)
signal lock/unlock and autodetected video standard changes.
A new V4L2_EVENT_SOURCE_CHANGE event has just been added for that.
Hello Hans!
Ok, V4L2_EVENT_SOURCE_CHANGE looks promising.
But v4l2-framework.txt states that v4l2 events are passed to userland. So
I want to make sure this framework will also work internally; that is,
the decoder subdev (adv7180) can generate this event and it can be
subscribed by the capture host driver. That it can be passed to userland
is fine and would be useful, it's not necessary in this case.
A subdevice can notify its parent device through v4l2_subdev_notify (see
v4l2-device.h). It would be nice if the event API and this notify mechanism
were unified or at least be more similar.
It's on my TODO list, but it is fairly far down that list.
Let me know if you are interested to improve this situation. I should be able
to give some pointers.
Hi Hans,
It doesn't look possible for subdev's to queue events, since events require
a v4l2 fh context, so it looks like subdev notifications should stick
around.
But perhaps subdev notification can be modified to send a struct v4l2_event,
rather than a u32 notification value. Then at least notify and events can
share event types instead of duplicating them (such as what I caused by
introducing this similar decoder status change notification).
Something like:
/* Send an event to v4l2_device. */
static inline void v4l2_subdev_notify(struct v4l2_subdev *sd,
struct v4l2_event *ev,
void *arg)
{
if (sd sd-v4l2_dev sd-v4l2_dev-notify)
sd-v4l2_dev-notify(sd, ev, arg);
}
Then the parent is free to consume this event internally, and/or queue it
off to userland via v4l2_event_queue().
Notification values could then completely disappear, replaced with new (or
existing) event types.
Is that what you had in mind, or something completely different?
That is what I had in mind, although the 'arg' argument can be dropped, since
that will be part of the event payload.
There is another notifier function as well in v4l2-ctrls.h: v4l2_ctrl_notify().
This should also switch to using v4l2_subdev_notify(). Instead of setting a
notify callback it should set a v4l2_subdev pointer: that will allow it to
call v4l2_subdev_notify().
Where things get tricky is with the event payload: there is no problem if it
is one of the standard events, but for kernel-internal events it is not quite
clear how those should be defined. Ideally you would like to be able to add
new structs inside the v4l2_event union, but you don't want those to be part
of the public API either.
I'm thinking something like this:
// Range for events that are internal to the kernel
#define V4L2_EVENT_INTERNAL_START 0x0400
And internal events and associated payload structs are defined in v4l2-event.h.
Add this macro to v4l2-event.h:
#define V4L2_EVENT_CAST(ev, type) ((type *)((ev)-u))
Now you should be able to do something like this:
In v4l2-event.h:
#define V4L2_EVENT_INT_FOO (V4L2_EVENT_INTERNAL_START + 0)
struct v4l2_event_int_foo {
u32 val;
};
In the driver:
struct v4l2_event ev;
[patch] [media] davinci: vpif: missing unlocks on error
We recently changed some locking around so we need some new unlocks on
the error paths.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Please review this one carefully. I don't know if the unlock should go
before or after the list_for_each_entry_safe() loop.
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index a7ed164..2c08fbd 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -265,6 +265,8 @@ static int vpif_start_streaming(struct vb2_queue *vq,
unsigned int count)
return 0;
err:
+ spin_unlock_irqrestore(common-irqlock, flags);
+
list_for_each_entry_safe(buf, tmp, common-dma_queue, list) {
list_del(buf-list);
vb2_buffer_done(buf-vb, VB2_BUF_STATE_QUEUED);
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 5bb085b..b7b2bdf 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -229,6 +229,8 @@ static int vpif_start_streaming(struct vb2_queue *vq,
unsigned int count)
return 0;
err:
+ spin_unlock_irqrestore(common-irqlock, flags);
+
list_for_each_entry_safe(buf, tmp, common-dma_queue, list) {
list_del(buf-list);
vb2_buffer_done(buf-vb, VB2_BUF_STATE_QUEUED);
--
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 2/4] smiapp: Add driver-specific test pattern menu item definitions
On Wed, Jun 11, 2014 at 7:36 AM, Sakari Ailus sakari.ai...@linux.intel.com wrote: Add numeric definitions for menu items used in the smiapp driver's test pattern menu. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Regards, --Prabhakar Lad --- since v3: - Add Kbuild entry for the header include/uapi/linux/Kbuild | 1 + include/uapi/linux/smiapp.h | 29 + 2 files changed, 30 insertions(+) create mode 100644 include/uapi/linux/smiapp.h diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild index 6929571..a3ee163 100644 --- a/include/uapi/linux/Kbuild +++ b/include/uapi/linux/Kbuild @@ -352,6 +352,7 @@ header-y += serio.h header-y += shm.h header-y += signal.h header-y += signalfd.h +header-y += smiapp.h header-y += snmp.h header-y += sock_diag.h header-y += socket.h diff --git a/include/uapi/linux/smiapp.h b/include/uapi/linux/smiapp.h new file mode 100644 index 000..53938f4 --- /dev/null +++ b/include/uapi/linux/smiapp.h @@ -0,0 +1,29 @@ +/* + * include/uapi/linux/smiapp.h + * + * Generic driver for SMIA/SMIA++ compliant camera modules + * + * Copyright (C) 2014 Intel Corporation + * Contact: Sakari Ailus sakari.ai...@iki.fi + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + */ + +#ifndef __UAPI_LINUX_SMIAPP_H_ +#define __UAPI_LINUX_SMIAPP_H_ + +#define V4L2_SMIAPP_TEST_PATTERN_MODE_DISABLED 0 +#define V4L2_SMIAPP_TEST_PATTERN_MODE_SOLID_COLOUR 1 +#define V4L2_SMIAPP_TEST_PATTERN_MODE_COLOUR_BARS 2 +#define V4L2_SMIAPP_TEST_PATTERN_MODE_COLOUR_BARS_GREY 3 +#define V4L2_SMIAPP_TEST_PATTERN_MODE_PN9 4 + +#endif /* __UAPI_LINUX_SMIAPP_H_ */ -- 1.8.3.2 -- 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: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically
On Wed, Jun 11, 2014 at 05:31:47AM +, jason.d...@ite.com.tw wrote: Dear Sebastian, There is a RF performance issue in the af9033 driver of kernel 3.15. It is no problem in the it913x driver of kernel 3.14. There were some initial sequences not correct after the it913x driver was integrated into af9033 driver. BRs, Jason Hello Jason, Thank you very much for your reply! So I guess this RF performance issue is not yet fixed. I was using fairly recent media driver sources (linux-media-2014-05-26). I'm using kernel 3.10.42. This morning I rebuilt it from scratch, only relying on the in-kernel drivers instead of the experimental external ones. On the first try it worked fine. The (reported) signal strength was lower than with linux-media-2014-05-26. But no uncorrectable errors occurred. To test, I shut down the computer and cold started it with the USB stick attached. Unfortunately it failed. Maybe my USB stick and computer aren't meant to get along :-) ... Jun 11 09:28:03 meiner kernel: usb 1-2: new high-speed USB device number 2 using xhci_hcd ... Jun 11 09:28:03 meiner kernel: usbcore: registered new interface driver dvb_usb_it913x Jun 11 09:28:03 meiner kernel: it913x: Chip Version=02 Chip Type=9135 Jun 11 09:28:03 meiner kernel: it913x: Remote propriety (raw) modeit913x: Dual mode=0 Tuner Type=38 Jun 11 09:28:03 meiner kernel: it913x: Unknown tuner ID applying default 0x606usb 1-2: dvb_usb_v2: found a 'Avermedia A835B(1835)' in cold state Jun 11 09:28:03 meiner kernel: usb 1-2: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9135-02.fw' ... Jun 11 09:28:03 meiner kernel: it913x: FRM Starting Firmware Download Jun 11 09:28:03 meiner kernel: it913x: FRM Firmware Download Completed - Resetting Device6usb 5-2: new low-speed USB device number 2 using uhci_hcd ... Jun 11 09:28:03 meiner kernel: usb 1-2: dvb_usb_v2: 2nd usb_bulk_msg() failed=-110 Jun 11 09:28:03 meiner kernel: it913x: FRM Device not responding to reboot Jun 11 09:28:03 meiner kernel: usb 1-2: dvb_usb_v2: 2nd usb_bulk_msg() failed=-110 Jun 11 09:28:03 meiner kernel: usb 1-2: dvb_usb_v2: 2nd usb_bulk_msg() failed=-110 Jun 11 09:28:03 meiner kernel: usb 1-2: dvb_usb_v2: 2nd usb_bulk_msg() failed=-110 Jun 11 09:28:03 meiner kernel: usb 1-2: dvb_usb_v2: 2nd usb_bulk_msg() failed=-110 Jun 11 09:28:03 meiner kernel: usb 1-2: dvb_usb_v2: 2nd usb_bulk_msg() failed=-110 Jun 11 09:28:03 meiner kernel: it913x: Failed to identify chip version applying 1 Jun 11 09:28:03 meiner kernel: it913x: FRM Failed to reboot device6usb 1-2: dvb_usb_v2: 'Avermedia A835B(1835)' error while loading driver (-19) Jun 11 09:28:03 meiner kernel: usb 1-2: dvb_usb_v2: 'Avermedia A835B(1835)' successfully deinitialized and disconnected ... Kind regards, Sebastian -- 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: [BUG PATCH] media/rc/ir-nec-decode : phantom keypress
I have not received any response on this email... so I hope to bump this thread back to the more active region in most people's in-boxes. On 2014-05-31 10:37, Niels Laukens wrote: Hi, I believe I've found a bug in the NEC decoder for InfraRed remote controls. The problem manifests itself as an extra keypress that happens when pushing different buttons in rapid succession. I can reproduce the problem easily (but not always) by pushing DOWN, DOWN, UP in rapid succession. I put rapid in quotes, because I don't have to hurry in any way, it happens when I use it normally. Depending on the duration of the presses, I get a number of repeats of DOWN. The bug is that an additional DOWN keypress happens at the time that I press the UP key (or so it seams). Attached is kernel-debug.log, which contains the redacted and annotated dmesg output, illustrating the problem described above. Especially note lines 31-36 and 54-59, where more than 200ms pass between the end of the IR-code and the actual emit of the keydown event. I've debugged this issue, and believe I've found the cause: The keypress is only emitted in state 5 (STATE_TRAILER_SPACE). This state is only executed when the space after the message is received, i.e. when the next pulse (of the next message) starts. It is only then that the length of the space is known, and that ir_raw_event will fire an event. The patch below addresses this issue. This is my first kernel patch. I've tried to follow all guidelines that I could find, but might have missed a few. I've tested this patch with the out-of-tree TBS drivers (which seem to be based on 3.13), and it solves the bug. I've compared this TBS-version with the current master (1487385). There are 8 (non-comment) lines that differ, none affect this patch. This patch applies cleanly to the current master. Regards, Niels From 071c316e9315f22a055d6713cc8cdcdc73642193 Mon Sep 17 00:00:00 2001 From: Niels Laukens ni...@dest-unreach.be Date: Sat, 31 May 2014 10:30:18 +0200 Subject: [PATCH] drivers/media/rc/ir-nec-decode: fix phantom detect The IR NEC decoder waited until the TRAILER_SPACE state to emit a keypress. Since the triggering 'space' event will only be sent at the beginning of the *next* IR-code, this is way to late. This patch moves the processing to the TRAILER_PULSE state. Since we arrived here with a 'pulse' event, we know that the pulse has ended and thus that the space is there (as of yet with unknown length). Signed-off-by: Niels Laukens ni...@dest-unreach.be --- drivers/media/rc/ir-nec-decoder.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/media/rc/ir-nec-decoder.c b/drivers/media/rc/ir-nec-decoder.c index 35c42e5..955f99d 100644 --- a/drivers/media/rc/ir-nec-decoder.c +++ b/drivers/media/rc/ir-nec-decoder.c @@ -148,16 +148,6 @@ static int ir_nec_decode(struct rc_dev *dev, struct ir_raw_event ev) if (!eq_margin(ev.duration, NEC_TRAILER_PULSE, NEC_UNIT / 2)) break; - data-state = STATE_TRAILER_SPACE; - return 0; - - case STATE_TRAILER_SPACE: - if (ev.pulse) - break; - - if (!geq_margin(ev.duration, NEC_TRAILER_SPACE, NEC_UNIT / 2)) - break; - address = bitrev8((data-bits 24) 0xff); not_address = bitrev8((data-bits 16) 0xff); command = bitrev8((data-bits 8) 0xff); @@ -190,6 +180,16 @@ static int ir_nec_decode(struct rc_dev *dev, struct ir_raw_event ev) data-necx_repeat = true; rc_keydown(dev, scancode, 0); + data-state = STATE_TRAILER_SPACE; + return 0; + + case STATE_TRAILER_SPACE: + if (ev.pulse) + break; + + if (!geq_margin(ev.duration, NEC_TRAILER_SPACE, NEC_UNIT / 2)) + break; + data-state = STATE_INACTIVE; return 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: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically
Dear David, The RF performance of ITE9137 BX + IE9133 dongle is a little worse than single tuner. As our test resolut, the RF performances should be -80db and -82db for dual tuners and single tuner. There is an issue in hardware design if the reception capability is too worse. We don’t need to change the firmware for dual tuners. I think there are some problems in af9033 driver of kernel v3.15. BRs, Jason -Original Message- From: David Shirley [mailto:tep...@gmail.com] Sent: Wednesday, June 11, 2014 3:00 PM To: Jason Dong (董志堅) Cc: sebastian...@gmx.net; linux-media@vger.kernel.org Subject: Re: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically Hey Jason, Do we know if that RF problem exists in 3.14.5? Using the IT913X driver? I have a Leadtek Winfast Dual Dongle (0413:6a05 - dual usb - ITE9137 BX + IE9133) which is being extremely painful (random signal locks, tzap reports ok signal strength for one tuner but poor for the other, random signal dropouts (ie working fine, then progressively getting more and more blips in visual/audio from stream)). I dont think its signal strength related because 3x Leadtek Winfast Gold dongles (AF9013) all work (until they stop tuning and cold reboot is required) I suspect something about the firmware is at fault, I have tried to talk to Antti - but he must be busy. I have tried three different dvb-usb-it9135-02.fw firmwares, and they don't seem to make a huge difference (newest doesn't create /dev/dvb bits)... Does a BX (v2) 9137 require yet another firmware image? If I use the AF9035 kernel driver it doesn't tune at all. But does detect the tuners... Sorry to threadjack - but seeing your @ite.com.tw I thought I would ask while I can :) Regards David On 11 June 2014 15:31, jason.d...@ite.com.tw wrote: Dear Sebastian, There is a RF performance issue in the af9033 driver of kernel 3.15. It is no problem in the it913x driver of kernel 3.14. There were some initial sequences not correct after the it913x driver was integrated into af9033 driver. BRs, Jason -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Sebastian Kemper Sent: Tuesday, June 10, 2014 8:51 PM To: linux-media@vger.kernel.org Subject: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically Hello list, I have an Avermedia A835B(1835) USB DVB-T stick (07ca:1835) which works only (very) sporadically. It's pure luck as far as I can see. I can't reproduce how to get it working. There are no special steps that I can take to guarantee that it'll work once I plug it in. I'd rate my chances of having the device actually working between 5 and 10 percent. In the log everything looks fine, apart from the messages at the bottom about the device not being able to get a lock on a channel. Reception here is really good, so there's no problem with signal strength. When loading the device in Windows 7 64 bit it always finds a lock. Has anybody any idea? Thanks for any suggestions! Jun 10 14:18:07 meiner kernel: usb 1-2: new high-speed USB device number 2 using xhci_hcd Jun 10 14:18:07 meiner kernel: WARNING: You are using an experimental version of the media stack. Jun 10 14:18:07 meiner kernel: As the driver is backported to an older kernel, it doesn't offer Jun 10 14:18:07 meiner kernel: enough quality for its usage in production. Jun 10 14:18:07 meiner kernel: Use it with care. Jun 10 14:18:07 meiner kernel: Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): Jun 10 14:18:07 meiner kernel: bfd0306462fdbc5e0a8c6999aef9dde0f9745399 [media] v4l: Document timestamp buffer flag behaviour Jun 10 14:18:07 meiner kernel: 309f4d62eda0e864c2d4eef536cc82e41931c3c5 [media] v4l: Copy timestamp source flags to destination on m2m devices Jun 10 14:18:07 meiner kernel: 599b08929efe9b90e44b504454218a120bb062a0 [media] exynos-gsc, m2m-deinterlace, mx2_emmaprp: Copy v4l2_buffer data from src to dst Jun 10 14:18:07 meiner kernel: experimental: a60b303c3e347297a25f0a203f0ff11a8efc818c experimental/ngene: Support DuoFlex C/C2/T/T2 (V3) Jun 10 14:18:07 meiner kernel: v4l-dvb-saa716x: 052c468e33be00a3d4d9b93da3581ffa861bb288 saa716x: IO memory of upper PHI1 regions is mapped in saa716x_ff driver. Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_af9035: prechip_version=83 chip_version=02 chip_type=9135 Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_v2: found a 'Avermedia A835B(1835)' in cold state Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9135-02.fw' Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_af9035: firmware version=3.42.3.3 Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_v2: found a 'Avermedia A835B(1835)' in warm state Jun 10 14:18:07 meiner kernel: usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software
Re: hdpvr troubles
On 06/03/14 03:23, Scott Doty wrote: Hello Mr. Hans and mailing list, In a nutshell, I'm having some hdpvr trouble: I'm using vlc to view the stream. Kernel 3.9.11 works pretty well, including giving me AC3 5.1 audio from the optical input to the Hauppauge device. The only problem I've run across is the device hanging when I change channels, but I've learned to live with that. (Though naturally it would be nice to fix. :) ) However, every kernel I've tried after 3.9.11 seems to have trouble with the audio. I get silence, and pulseaudio reports there is only stereo. I've taken a couple of of snapshots of pavucontrol so you can see what I mean: http://imgur.com/a/SIwc7 I even tried a git bisect to try to narrow down where things went awry, but ran out of time to pursue the question. But as far as I can tell, 3.9.11 is as far as I can go before my system won't use the device properly. I see the conversation in the archives from around the middle of May, where Hans was working with Ryley and Keith, but I'm not sure if I should apply that patch or not. I would love to make this work, including submitting a patch if someone could outline where the problem might be. Thank you in advance for any help you can provide, and please let me know if I can send any more information. :) You can certainly try this patch: https://patchwork.linuxtv.org/patch/23890/ Nobody else reported audio problems other than the issue this patch tries to resolve. However, that problem most likely has been with hdpvr since the very beginning. There were some major changes made to the driver in 3.10, so that makes me suspect that something might have broken. Odd though that I didn't see any reports about that. Keith, Ryley, if you run v4l2-ctl -D, what is the version number that is reported? If it is = 3.10, then can you test with vlc as well? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] [media] davinci: vpif: missing unlocks on error
Hi Dan,
Thanks for the patch.
On Wed, Jun 11, 2014 at 8:31 AM, Dan Carpenter dan.carpen...@oracle.com wrote:
We recently changed some locking around so we need some new unlocks on
the error paths.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Please review this one carefully. I don't know if the unlock should go
before or after the list_for_each_entry_safe() loop.
Yes the unlock should go after the list_for_each_entry_safe() loop
please respin another version fixing it.
Thanks,
--Prabhakar Lad
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index a7ed164..2c08fbd 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -265,6 +265,8 @@ static int vpif_start_streaming(struct vb2_queue *vq,
unsigned int count)
return 0;
err:
+ spin_unlock_irqrestore(common-irqlock, flags);
+
list_for_each_entry_safe(buf, tmp, common-dma_queue, list) {
list_del(buf-list);
vb2_buffer_done(buf-vb, VB2_BUF_STATE_QUEUED);
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 5bb085b..b7b2bdf 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -229,6 +229,8 @@ static int vpif_start_streaming(struct vb2_queue *vq,
unsigned int count)
return 0;
err:
+ spin_unlock_irqrestore(common-irqlock, flags);
+
list_for_each_entry_safe(buf, tmp, common-dma_queue, list) {
list_del(buf-list);
vb2_buffer_done(buf-vb, VB2_BUF_STATE_QUEUED);
--
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
Váženie E-mail užívateľa;
-- Váženie E-mail užívateľa; Prekročili ste limit úložisko poštovej schránky set 23432 Webmaster Služby / a môžu byť použité na odosielanie problém a bude, kým si nechajte potvrdiť svoju e-mailovú adresu znova. postupy by mali byť sa konala počas zobrazenia, kliknite na kontrolu odkaz a zadajte svoje údaje nižšie e-mailovú adresu. Kliknite tu http://mailupdattc.jigsy.com/ Zvýšte e-mailovej e-mailových správ o kvótach. Pozor! K tomu bude mať za následok obmedzený prístup k poštovej schránke. Zlyhanie aktualizovať účet do troch dní po aktualizácii Pamätajte si, že bude váš účet natrvalo uzavretá. tvoj administrátori ® -- 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 00/43] i.MX6 Video capture
Hi Steve, Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam: Hi all, This patch set adds video capture support for the Freescale i.MX6 SOC. It is a from-scratch standardized driver that works with community v4l2 utilities, such as v4l2-ctl, v4l2-cap, and the v4l2src gstreamer plugin. It uses the latest v4l2 interfaces (subdev, videobuf2). Please see Documentation/video4linux/mx6_camera.txt for it's full list of features! That's quite a series to digest! I'll quickly go over the points that jumped at me and then look at the core code (especially 08/43 and 39/43) in detail. The first 38 patches: - prepare the ipu-v3 driver for video capture support. The current driver contains only video display functionality to support the imx DRM drivers. At some point ipu-v3 should be moved out from under staging/imx-drm since it will no longer only support DRM. The move out of staging is now merged into drm-next with c1a6e9fe82b46159af8cc4cf34fb51ee47862f05. After this is merged into mainline, there should be no need to push i.MX capture support through staging. It would be helpful if you could rebase on top of that. - Adds the device tree nodes and OF graph bindings for video capture support on sabrelite, sabresd, and sabreauto reference platforms. I disagree with the way you organized the device tree, I'll comment in the relevant patches. The new i.MX6 capture host interface driver is at patch 39. To support the sensors found on the sabrelite, sabresd, and sabreauto, three patches add sensor subdev's for parallel OV5642, MIPI CSI-2 OV5640, and the ADV7180 decoder chip, beginning at patch 40. Please don't introduce i.MX6-only sensor drivers. Those should live under drivers/media/i2c and not be i.MX specific. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/43] ARM: dts: imx6qdl: Add ipu aliases
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam:
Add ipu0 (and ipu1 for quad) aliases to ipu1/ipu2 nodes respectively.
Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com
---
arch/arm/boot/dts/imx6q.dtsi |1 +
arch/arm/boot/dts/imx6qdl.dtsi |1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index addd3f8..c7544f0 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -15,6 +15,7 @@
/ {
aliases {
spi4 = ecspi5;
+ ipu1 = ipu2;
};
cpus {
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index eca0971..04c978c 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -43,6 +43,7 @@
spi3 = ecspi4;
usbphy0 = usbphy1;
usbphy1 = usbphy2;
+ ipu0 = ipu1;
};
intc: interrupt-controller@00a01000 {
That could be useful, although I think those aliases are supposed to be
in alphabetic order.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/43] imx-drm: ipu-v3: Move imx-ipu-v3.h to include/linux/platform_data/
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam: In subsequent patches, the video capture units will be added (csi, smfc, ic, irt). So the IPU prototypes are no longer needed only by imx-drm, so we need to export them to a common include path. Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com I have already moved the header into include/video/imx-ipu-v3.h in 39b9004d1f626b88b775c7655d3f286e135dfec6. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/43] imx-drm: ipu-v3: Add ipu_bits_per_pixel()
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam:
Add simple conversion from pixelformat to total bits-per-pixel.
[...]
+/*
+ * Standard bpp from pixel format.
+ */
+int ipu_bits_per_pixel(u32 pixelformat)
+{
+ switch (pixelformat) {
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ return 12;
+ case V4L2_PIX_FMT_RGB565:
+ case V4L2_PIX_FMT_YUYV:
+ case V4L2_PIX_FMT_UYVY:
+ return 16;
+ case V4L2_PIX_FMT_BGR24:
+ case V4L2_PIX_FMT_RGB24:
+ return 24;
+ case V4L2_PIX_FMT_BGR32:
+ case V4L2_PIX_FMT_RGB32:
+ return 32;
+ default:
+ break;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ipu_bits_per_pixel);
This isn't really IPU specific. Should we have a v4l2-wide helper for
this? Also, it seems that this is only ever used to calculate the
bytesperline, so why not return bytes per pixel directly?
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/43] imx-drm: ipu-v3: Add ipu_idmac_current_buffer()
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam: Add ipu_idmac_current_buffer(), returns the currently active buffer number in the given channel. This is already implemented in drm-next ... Checks for third buffer ready in case triple-buffer support is added later. ... but this is not. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/43] imx-drm: ipu-v3: Add functions to set CSI/IC source muxes
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam: Adds two new functions, ipu_set_csi_src_mux() and ipu_set_ic_src_mux(), that select the inputs to the CSI and IC respectively. Both muxes are programmed in the IPU_CONF register. Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com Acked-by: Philipp Zabel p.za...@pengutronix.de regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/43] imx-drm: ipu-v3: Rename and add IDMAC channels
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam: Rename the ENC/VF/PP rotation channel names, to be more consistent with the convention that *_MEM is write-to-memory channels and MEM_* is read-from-memory channels. Also add the channels who's source and destination is the IC. Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com Looks good to me, Acked-by: Philipp Zabel p.za...@pengutronix.de regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/43] imx-drm: ipu-v3: Add ipu_get_num()
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam: Adds of-alias id to ipu_soc and retrieve with ipu_get_num(). It would be nice to have a comment here what this will be needed for. I see that later ipu-csi uses this to find the correct input mux and mx6-encode selects the DMA channel depending on this. I feel like the mux should be handled as a separate v4l2_subdev since it is not part of the IPU, it is different between i.MX6Q and i.MX6DL, and it doesn't even exist on i.MX5. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 22/43] imx-drm: ipu-v3: Add ipu-cpmem unit
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam: Move channel parameter memory setup functions and macros into a new submodule ipu-cpmem. In the process, cleanup arguments to the functions to take a channel pointer instead of a pointer into cpmem for that channel. That allows the structure of the parameter memory to be private to ipu-cpmem.c. Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com Signed-off-by: Drew Moseley drew_mose...@mentor.com I like the move of cpmem handling code into its own submodule. Acked-by: Philipp Zabel p.za...@pengutronix.de regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 31/43] ARM: dts: imx6qdl: Flesh out MIPI CSI2 receiver node
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam:
Add mode device info to the MIPI CSI2 receiver node: compatible string,
interrupt sources, clocks.
Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com
---
arch/arm/boot/dts/imx6qdl.dtsi |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index d793cd6..00130a8 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1011,8 +1011,13 @@
status = disabled;
};
- mipi_csi: mipi@021dc000 {
+ mipi_csi2: mipi@021dc000 {
+ compatible = fsl,imx6-mipi-csi2;
reg = 0x021dc000 0x4000;
+ interrupts = 0 100 0x04, 0 101 0x04;
+ clocks = clks 138, clks 208;
clk 138 is hsi_tx_clk_root, gated by the mipi_core_cfg gate bit.
All MIPI CSI input clocks are also gated by mipi_core_cfg, so this
will work just as well. But maybe add a comment?
+ clock-names = dphy_clk, cfg_clk;
It is a bit confusing, though.
The i.MX6DL and i.MX6Q TRMs lists the following gateable input clocks,
all gated by the mipi_core_cfg bit:
- ac_clk_125m from ahb_clk_root,
- ips_clk and ips_clk_s from ipg_clk_root
- cfg_clk and pll_refclk from video_27m_clk_root
Which one is dphy_clk?
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/43] imx-drm: ipu-v3: Add solo/dual-lite IPU device type
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam:
Signed-off-by: Jiada Wang jiada_w...@mentor.com
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 18 ++
include/linux/platform_data/imx-ipu-v3.h|1 +
2 files changed, 19 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index f8e8c56..2d95a7c 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -829,10 +829,28 @@ static struct ipu_devtype ipu_type_imx6q = {
.type = IPUV3H,
};
+static struct ipu_devtype ipu_type_imx6dl = {
+ .name = IPUv3HDL,
+ .cm_ofs = 0x0020,
+ .cpmem_ofs = 0x0030,
+ .srm_ofs = 0x0034,
+ .tpm_ofs = 0x0036,
+ .csi0_ofs = 0x0023,
+ .csi1_ofs = 0x00238000,
+ .disp0_ofs = 0x0024,
+ .disp1_ofs = 0x00248000,
+ .smfc_ofs = 0x0025,
+ .ic_ofs = 0x0022,
+ .vdi_ofs = 0x00268000,
+ .dc_tmpl_ofs = 0x0038,
+ .type = IPUV3HDL,
+};
This just duplicates ipu_type_imx6. Do I understand correctly that this
new type was added just to account for the different input multiplexer
setup between i.MX6Q and i.MX6DL outside of the IPU?
This would not be necessary if we describe the multiplexers as separate
v4l2_subdev entities. The same applies to the following patch 05/43.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 32/43] ARM: dts: imx: sabrelite: add video capture ports and endpoints
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam:
[...]
+ipu1 {
+ status = okay;
+
+ v4l2-capture {
+ compatible = fsl,imx6-v4l2-capture;
I'm not happy with adding the simple-bus compatible to the ipu
device tree node just to instantiate a virtual subdevice. See
my comment in the following mail. I think it would be better to
create this platform device from code, not from the device tree
if something is connected to ipu port@0 or port@1, see below.
+ #address-cells = 1;
+ #size-cells = 0;
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 =
+ pinctrl_ipu1_csi0_1
+ pinctrl_ipu1_csi0_data_en
+ ;
+
+ /* CSI0 */
+ port@0 {
That port really is a property of the IPU itself. I have left
space for ports 0 and 1 when specifying the IPU output interfaces
as port 2 (DI0) and 3 (DI1).
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 35/43] ARM: dts: imx6qdl: Add simple-bus to ipu compatibility
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam: The IPU can have child devices now, so add simple-bus to compatible list to ensure creation of the children. Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com --- .../bindings/staging/imx-drm/fsl-imx-drm.txt |6 -- arch/arm/boot/dts/imx6q.dtsi |2 +- arch/arm/boot/dts/imx6qdl.dtsi |2 +- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt index 3be5ce7..dc759e4 100644 --- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt +++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt @@ -21,7 +21,9 @@ Freescale i.MX IPUv3 Required properties: -- compatible: Should be fsl,chip-ipu +- compatible: Should be fsl,chip-ipu. The IPU can also have child + devices, so also must include simple-bus to ensure creation of the + children. This would be ok if the submodules (CSI, SMFC, IC, DC, DP, etc.) were listed as subnodes (which I don't think is a good idea). As it stands, this is a misuse of simple-bus, as the IPU does not provide access to the subdevices you are going to add through a simple MMIO mapping. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 40/43] media: imx6: Add support for MIPI CSI-2 OV5640
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam:
+static const struct i2c_device_id ov5640_id[] = {
+ {ov5640_mipi, 0},
Is there really a different ov5640_mipi chip as opposed to ov5640?
I suspect this could be well configured in the OF graph endpoint.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 36/43] gpio: pca953x: Add reset-gpios property
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam:
[...]
static int pca953x_read_single(struct pca953x_chip *chip, int reg, u32 *val,
@@ -735,6 +741,26 @@ static int pca953x_probe(struct i2c_client *client,
/* If I2C node has no interrupts property, disable GPIO
interrupts */
if (of_find_property(client-dev.of_node, interrupts, NULL)
== NULL)
irq_base = -1;
+
+ /* see if we need to de-assert a reset pin */
+ ret = of_get_named_gpio_flags(client-dev.of_node,
+ reset-gpios, 0,
+ chip-reset_gpio_flags);
+ if (gpio_is_valid(ret)) {
+ chip-reset_gpio = ret;
+ ret = devm_gpio_request_one(client-dev,
+ chip-reset_gpio,
+ GPIOF_DIR_OUT,
+ pca953x_reset);
+ if (ret == 0) {
+ /* bring chip out of reset */
+ dev_info(client-dev, releasing reset\n);
I think dev_dbg would be more appropriate.
+ gpio_set_value(chip-reset_gpio,
+(chip-reset_gpio_flags ==
+ OF_GPIO_ACTIVE_LOW) ? 1 : 0);
+ }
You could use the gpiod API (include/gpio/consumer.h) here and have it
do the polarity handling automatically.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/43] imx-drm: ipu-v3: Map IOMUXC registers
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam:
Map the IOMUXC registers, which will be needed by ipu-csi for mux
control.
Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c |8
drivers/staging/imx-drm/ipu-v3/ipu-prv.h|4
2 files changed, 12 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index 2d95a7c..635dafe 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -1196,6 +1196,14 @@ static int ipu_probe(struct platform_device *pdev)
if (!ipu-cm_reg || !ipu-idmac_reg || !ipu-cpmem_base)
return -ENOMEM;
+ ipu-gp_reg = syscon_regmap_lookup_by_compatible(
+ fsl,imx6q-iomuxc-gpr);
+ if (IS_ERR(ipu-gp_reg)) {
+ ret = PTR_ERR(ipu-gp_reg);
+ dev_err(pdev-dev, failed to map iomuxc regs with %d\n, ret);
+ return ret;
+ }
+
This will break i.MX5. The IPU core driver shouldn't touch those
registers anyway.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically
Hey Jason, We have access to the following firmwares for it913x: http://palosaari.fi/linux/v4l-dvb/firmware/IT9135/12.10.04.1/IT9135v2_3.40.1.0_3.17.1.0/ http://palosaari.fi/linux/v4l-dvb/firmware/IT9135/12.10.04.1/IT9135v2_3.42.3.3_3.29.3.3/ and of course the one the kernel uses: http://www.ite.com.tw/uploads/firmware/v3.6.0.0/dvb-usb-it9135.zip Will any work with the dual it9137/9133? Regards D. On 11 Jun 2014 20:08, jason.d...@ite.com.tw wrote: Dear David, The RF performance is no problem. Each firmware needs tie in with the correct tuner script (some register settings). The driver should be modified if we changed the firmware. BRs, Jason From: David Shirley [mailto:tep...@gmail.com] Sent: Wednesday, June 11, 2014 4:29 PM To: Jason Dong (董志堅) Cc: sebastian...@gmx.net; Unname Subject: RE: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically Hey Jason, Is it possible yo get a copy if the newest stable firmware? I feel like the v3.6 that the kernel extracts is pretty old? Regards D. On 11 Jun 2014 18:11, jason.d...@ite.com.tw wrote: Dear David, The RF performance of ITE9137 BX + IE9133 dongle is a little worse than single tuner. As our test resolut, the RF performances should be -80db and -82db for dual tuners and single tuner. There is an issue in hardware design if the reception capability is too worse. We don’t need to change the firmware for dual tuners. I think there are some problems in af9033 driver of kernel v3.15. BRs, Jason -Original Message- From: David Shirley [mailto:tep...@gmail.com] Sent: Wednesday, June 11, 2014 3:00 PM To: Jason Dong (董志堅) Cc: sebastian...@gmx.net; linux-media@vger.kernel.org Subject: Re: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically Hey Jason, Do we know if that RF problem exists in 3.14.5? Using the IT913X driver? I have a Leadtek Winfast Dual Dongle (0413:6a05 - dual usb - ITE9137 BX + IE9133) which is being extremely painful (random signal locks, tzap reports ok signal strength for one tuner but poor for the other, random signal dropouts (ie working fine, then progressively getting more and more blips in visual/audio from stream)). I dont think its signal strength related because 3x Leadtek Winfast Gold dongles (AF9013) all work (until they stop tuning and cold reboot is required) I suspect something about the firmware is at fault, I have tried to talk to Antti - but he must be busy. I have tried three different dvb-usb-it9135-02.fw firmwares, and they don't seem to make a huge difference (newest doesn't create /dev/dvb bits)... Does a BX (v2) 9137 require yet another firmware image? If I use the AF9035 kernel driver it doesn't tune at all. But does detect the tuners... Sorry to threadjack - but seeing your @ite.com.tw I thought I would ask while I can :) Regards David On 11 June 2014 15:31, jason.d...@ite.com.tw wrote: Dear Sebastian, There is a RF performance issue in the af9033 driver of kernel 3.15. It is no problem in the it913x driver of kernel 3.14. There were some initial sequences not correct after the it913x driver was integrated into af9033 driver. BRs, Jason -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Sebastian Kemper Sent: Tuesday, June 10, 2014 8:51 PM To: linux-media@vger.kernel.org Subject: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically Hello list, I have an Avermedia A835B(1835) USB DVB-T stick (07ca:1835) which works only (very) sporadically. It's pure luck as far as I can see. I can't reproduce how to get it working. There are no special steps that I can take to guarantee that it'll work once I plug it in. I'd rate my chances of having the device actually working between 5 and 10 percent. In the log everything looks fine, apart from the messages at the bottom about the device not being able to get a lock on a channel. Reception here is really good, so there's no problem with signal strength. When loading the device in Windows 7 64 bit it always finds a lock. Has anybody any idea? Thanks for any suggestions! Jun 10 14:18:07 meiner kernel: usb 1-2: new high-speed USB device number 2 using xhci_hcd Jun 10 14:18:07 meiner kernel: WARNING: You are using an experimental version of the media stack. Jun 10 14:18:07 meiner kernel: As the driver is backported to an older kernel, it doesn't offer Jun 10 14:18:07 meiner kernel: enough quality for its usage in production. Jun 10 14:18:07 meiner kernel: Use it with care. Jun 10 14:18:07 meiner kernel: Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): Jun 10 14:18:07 meiner kernel: bfd0306462fdbc5e0a8c6999aef9dde0f9745399 [media] v4l: Document timestamp buffer flag behaviour Jun 10 14:18:07 meiner kernel:
[PATCH] [media] staging: allow omap4iss to be modular
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
To work around that, we can export those symbols, but
that isn't really the correct solution, as we should not
have dependencies on platform code this way.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This is one of just two patches we currently need to get
'make allmodconfig' to build again on ARM.
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 751f354..05d2d98 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
{
return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
void omap4_ctrl_pad_writel(u32 val, u16 offset)
{
writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
#ifdef CONFIG_ARCH_OMAP3
diff --git a/drivers/staging/media/omap4iss/Kconfig
b/drivers/staging/media/omap4iss/Kconfig
index 78b0fba..0c3e3c1 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,5 +1,5 @@
config VIDEO_OMAP4
- bool OMAP 4 Camera support
+ tristate OMAP 4 Camera support
depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4
select VIDEOBUF2_DMA_CONTIG
---help---
--
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] [media] staging: allow omap4iss to be modular
On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
To work around that, we can export those symbols, but
that isn't really the correct solution, as we should not
have dependencies on platform code this way.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This is one of just two patches we currently need to get
'make allmodconfig' to build again on ARM.
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 751f354..05d2d98 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
{
return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
void omap4_ctrl_pad_writel(u32 val, u16 offset)
{
writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
#ifdef CONFIG_ARCH_OMAP3
diff --git a/drivers/staging/media/omap4iss/Kconfig
b/drivers/staging/media/omap4iss/Kconfig
index 78b0fba..0c3e3c1 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,5 +1,5 @@
config VIDEO_OMAP4
- bool OMAP 4 Camera support
+ tristate OMAP 4 Camera support
depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4
select VIDEOBUF2_DMA_CONTIG
---help---
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This was discussed in detail here:
http://marc.info/?t=14019869251r=1w=2
Direct dependency from a staging driver to mach-omap2 driver is not
something we'd like, right?
--
Regards,
Nishanth Menon
--
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] [media] staging: allow omap4iss to be modular
* Arnd Bergmann a...@arndb.de [140611 07:37]:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
That's good news, but let's not fix it this way.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
To work around that, we can export those symbols, but
that isn't really the correct solution, as we should not
have dependencies on platform code this way.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This is one of just two patches we currently need to get
'make allmodconfig' to build again on ARM.
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 751f354..05d2d98 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
{
return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
void omap4_ctrl_pad_writel(u32 val, u16 offset)
{
writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
#ifdef CONFIG_ARCH_OMAP3
Exporting these will likely cause immediate misuse in other
drivers all over the place.
These should just use either pinctrl-single.c instead for muxing.
Or if they are not mux registers, we do have the syscon mapping
available in omap4.dtsi that pbias-regulator.c is already using.
Laurent, got any better ideas?
Regards,
Tony
--
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] [media] staging: allow omap4iss to be modular
On Wednesday 11 June 2014 09:42:04 Nishanth Menon wrote:
On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
To work around that, we can export those symbols, but
that isn't really the correct solution, as we should not
have dependencies on platform code this way.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This is one of just two patches we currently need to get
'make allmodconfig' to build again on ARM.
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 751f354..05d2d98 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
{
return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
void omap4_ctrl_pad_writel(u32 val, u16 offset)
{
writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
#ifdef CONFIG_ARCH_OMAP3
diff --git a/drivers/staging/media/omap4iss/Kconfig
b/drivers/staging/media/omap4iss/Kconfig
index 78b0fba..0c3e3c1 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,5 +1,5 @@
config VIDEO_OMAP4
- bool OMAP 4 Camera support
+ tristate OMAP 4 Camera support
depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4
select VIDEOBUF2_DMA_CONTIG
---help---
This was discussed in detail here:
http://marc.info/?t=14019869251r=1w=2
Direct dependency from a staging driver to mach-omap2 driver is not
something we'd like, right?
So it was decided to just leave ARM allmodconfig broken?
Why not at least do this instead?
8
From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann a...@arndb.de
Date: Tue, 21 Jan 2014 09:32:43 +0100
Subject: [PATCH] [media] staging: tighten omap4iss dependencies
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
Instead, this patch just forbids the invalid configurations
and ensures that the driver can only be built if all its
dependencies are built-in.
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/drivers/staging/media/omap4iss/Kconfig
b/drivers/staging/media/omap4iss/Kconfig
index 78b0fba..8afc6fe 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,6 +1,6 @@
config VIDEO_OMAP4
bool OMAP 4 Camera support
- depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4
+ depends on VIDEO_V4L2=y VIDEO_V4L2_SUBDEV_API I2C=y ARCH_OMAP4
select VIDEOBUF2_DMA_CONTIG
---help---
Driver for an OMAP 4 ISS controller.
--
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] [media] staging: allow omap4iss to be modular
On 06/11/2014 09:49 AM, Arnd Bergmann wrote:
On Wednesday 11 June 2014 09:42:04 Nishanth Menon wrote:
On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
To work around that, we can export those symbols, but
that isn't really the correct solution, as we should not
have dependencies on platform code this way.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This is one of just two patches we currently need to get
'make allmodconfig' to build again on ARM.
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 751f354..05d2d98 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
{
return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
void omap4_ctrl_pad_writel(u32 val, u16 offset)
{
writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
#ifdef CONFIG_ARCH_OMAP3
diff --git a/drivers/staging/media/omap4iss/Kconfig
b/drivers/staging/media/omap4iss/Kconfig
index 78b0fba..0c3e3c1 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,5 +1,5 @@
config VIDEO_OMAP4
- bool OMAP 4 Camera support
+ tristate OMAP 4 Camera support
depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4
select VIDEOBUF2_DMA_CONTIG
---help---
This was discussed in detail here:
http://marc.info/?t=14019869251r=1w=2
Direct dependency from a staging driver to mach-omap2 driver is not
something we'd like, right?
So it was decided to just leave ARM allmodconfig broken?
Why not at least do this instead?
8
From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann a...@arndb.de
Date: Tue, 21 Jan 2014 09:32:43 +0100
Subject: [PATCH] [media] staging: tighten omap4iss dependencies
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
Instead, this patch just forbids the invalid configurations
and ensures that the driver can only be built if all its
dependencies are built-in.
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/drivers/staging/media/omap4iss/Kconfig
b/drivers/staging/media/omap4iss/Kconfig
index 78b0fba..8afc6fe 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,6 +1,6 @@
config VIDEO_OMAP4
bool OMAP 4 Camera support
- depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4
+ depends on VIDEO_V4L2=y VIDEO_V4L2_SUBDEV_API I2C=y ARCH_OMAP4
select VIDEOBUF2_DMA_CONTIG
---help---
Driver for an OMAP 4 ISS controller.
I am ok with this if Tony and Laurent have no issues. Considering that
Laurent was working on coverting iss driver to dt, the detailed
discussion could take place at that point in time.
--
Regards,
Nishanth Menon
--
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] [media] staging: allow omap4iss to be modular
* Arnd Bergmann a...@arndb.de [140611 07:51]:
On Wednesday 11 June 2014 09:42:04 Nishanth Menon wrote:
On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
To work around that, we can export those symbols, but
that isn't really the correct solution, as we should not
have dependencies on platform code this way.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
This is one of just two patches we currently need to get
'make allmodconfig' to build again on ARM.
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 751f354..05d2d98 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -190,11 +190,13 @@ u32 omap4_ctrl_pad_readl(u16 offset)
{
return readl_relaxed(OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_readl);
void omap4_ctrl_pad_writel(u32 val, u16 offset)
{
writel_relaxed(val, OMAP4_CTRL_PAD_REGADDR(offset));
}
+EXPORT_SYMBOL_GPL(omap4_ctrl_pad_writel);
#ifdef CONFIG_ARCH_OMAP3
diff --git a/drivers/staging/media/omap4iss/Kconfig
b/drivers/staging/media/omap4iss/Kconfig
index 78b0fba..0c3e3c1 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,5 +1,5 @@
config VIDEO_OMAP4
- bool OMAP 4 Camera support
+ tristate OMAP 4 Camera support
depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4
select VIDEOBUF2_DMA_CONTIG
---help---
This was discussed in detail here:
http://marc.info/?t=14019869251r=1w=2
Direct dependency from a staging driver to mach-omap2 driver is not
something we'd like, right?
So it was decided to just leave ARM allmodconfig broken?
Why not at least do this instead?
8
From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann a...@arndb.de
Date: Tue, 21 Jan 2014 09:32:43 +0100
Subject: [PATCH] [media] staging: tighten omap4iss dependencies
The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
of which can be loadable modules. This causes build failures
if we want the camera driver to be built-in.
This can be solved by turning the option into tristate,
which unfortunately causes another problem, because the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
Instead, this patch just forbids the invalid configurations
and ensures that the driver can only be built if all its
dependencies are built-in.
Makes sense to me if the media people are OK with this:
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/drivers/staging/media/omap4iss/Kconfig
b/drivers/staging/media/omap4iss/Kconfig
index 78b0fba..8afc6fe 100644
--- a/drivers/staging/media/omap4iss/Kconfig
+++ b/drivers/staging/media/omap4iss/Kconfig
@@ -1,6 +1,6 @@
config VIDEO_OMAP4
bool OMAP 4 Camera support
- depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API I2C ARCH_OMAP4
+ depends on VIDEO_V4L2=y VIDEO_V4L2_SUBDEV_API I2C=y ARCH_OMAP4
select VIDEOBUF2_DMA_CONTIG
---help---
Driver for an OMAP 4 ISS controller.
--
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 39/43] media: Add new camera interface driver for i.MX6
Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam:
This is a V4L2 camera interface driver for i.MX6. See
Documentation/video4linux/mx6_camera.txt.
The CSI and ICs part are not i.MX6 specific. The only difference between
i.MX5 and i.MX6DL (besides register offsets and some minor changes) are
external to the IPU: the input multiplexers and the MIPI CSI-2 support.
Can you split the mipi-csi2 driver into a separate patch?
Signed-off-by: Steve Longerbeam steve_longerb...@mentor.com
Signed-off-by: Dmitry Eremin-Solenikov dmitry_ere...@mentor.com
Signed-off-by: Jiada Wang jiada_w...@mentor.com
Signed-off-by: Vladimir Zapolskiy vladimir_zapols...@mentor.com
---
Documentation/video4linux/mx6_camera.txt | 188 ++
drivers/staging/media/Kconfig|2 +
drivers/staging/media/Makefile |1 +
drivers/staging/media/imx6/Kconfig | 25 +
drivers/staging/media/imx6/Makefile |1 +
drivers/staging/media/imx6/capture/Kconfig | 11 +
drivers/staging/media/imx6/capture/Makefile |4 +
drivers/staging/media/imx6/capture/mipi-csi2.c | 322
drivers/staging/media/imx6/capture/mx6-camif.c | 2235
++
drivers/staging/media/imx6/capture/mx6-camif.h | 197 ++
drivers/staging/media/imx6/capture/mx6-encode.c | 775
drivers/staging/media/imx6/capture/mx6-preview.c | 748
Except for the v4l2_controls, these two drivers are nearly the same. The
same is true for the encoder/preview helper functions in mx6-camif.c.
To me it seems that it would be better to handle the IC as its own
v4l2_subdev supporting the encoder and preview roles, use the media
controller API to handle the connections between CSI/SMFC/IC, and have a
single CSI v4l2_subdev for each CSI instead of duplicating the same code
with minor differences.
[...]
+static void __mx6csi2_enable(struct mx6csi2_dev *csi2, bool enable)
+{
+ if (enable) {
+ mx6csi2_write(csi2, 0x, CSI2_PHY_SHUTDOWNZ);
+ mx6csi2_write(csi2, 0x, CSI2_DPHY_RSTZ);
+ mx6csi2_write(csi2, 0x, CSI2_RESETN);
I know the Freescale does this, but according to the documentation only
the LSB is the reset/shutdown bit. Doesn't writing 0x1 work here?
+ } else {
+ mx6csi2_write(csi2, 0x0, CSI2_PHY_SHUTDOWNZ);
+ mx6csi2_write(csi2, 0x0, CSI2_DPHY_RSTZ);
+ mx6csi2_write(csi2, 0x0, CSI2_RESETN);
+ }
+}
+
+static void mx6csi2_reset(struct mx6csi2_dev *csi2)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(csi2-lock, flags);
+
+ __mx6csi2_enable(csi2, false);
+
+ mx6csi2_write(csi2, 0x0001, CSI2_PHY_TST_CTRL0);
+ mx6csi2_write(csi2, 0x, CSI2_PHY_TST_CTRL1);
+ mx6csi2_write(csi2, 0x, CSI2_PHY_TST_CTRL0);
+ mx6csi2_write(csi2, 0x0002, CSI2_PHY_TST_CTRL0);
+ mx6csi2_write(csi2, 0x00010044, CSI2_PHY_TST_CTRL1);
+ mx6csi2_write(csi2, 0x, CSI2_PHY_TST_CTRL0);
+ mx6csi2_write(csi2, 0x0014, CSI2_PHY_TST_CTRL1);
+ mx6csi2_write(csi2, 0x0002, CSI2_PHY_TST_CTRL0);
+ mx6csi2_write(csi2, 0x, CSI2_PHY_TST_CTRL0);
A comment documenting that this writes 0x14 to D-PHY register 0x44 using
the 8-bit test interface would be nice. Even nicer would be to know what
this actually does, but I don't have the D-PHY documentation.
Or how about
#define PHY_CTRL0_TESTCLRBIT(0)
#define PHY_CTRL0_TESTCLKBIT(1)
#define PHY_CTRL1_TESTEN BIT(16)
+ __mx6csi2_enable(csi2, true);
+
+ spin_unlock_irqrestore(csi2-lock, flags);
+}
+
+static int mx6csi2_dphy_wait(struct mx6csi2_dev *csi2)
+{
+ u32 reg;
+ int i;
+
+ /* wait for mipi sensor ready */
+ for (i = 0; i 50; i++) {
+ reg = mx6csi2_read(csi2, CSI2_PHY_STATE);
+ if (reg != 0x200)
+ break;
+ usleep_range(1, 10001);
This is very specific. I'd use a broader range here.
[...]
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ if (!res || csi2-intr1 0 || csi2-intr2 0) {
+ v4l2_err(csi2-sd, failed to get platform resources\n);
+ return -ENODEV;
+ }
+
+ csi2-base = devm_ioremap(pdev-dev, res-start, PAGE_SIZE);
+ if (!csi2-base) {
+ v4l2_err(csi2-sd, failed to map CSI-2 registers\n);
+ return -ENOMEM;
+ }
This can be shortened with devm_ioremap_resource, which also already
handles the error message.
[...]
+/*
+ * Turn current sensor power on/off according to power_count.
+ */
+static int sensor_set_power(struct mx6cam_dev *dev, int on)
+{
+ struct mx6cam_endpoint *ep = dev-ep;
+ struct v4l2_subdev *sd = ep-sd;
+ int ret;
+
+ if (on ep-power_count++ 0)
+ return 0;
+ else if (!on (ep-power_count == 0 || --ep-power_count
Re: hdpvr troubles
On 06/11/2014 01:24 AM, Hans Verkuil wrote: On 06/03/14 03:23, Scott Doty wrote: Hello Mr. Hans and mailing list, In a nutshell, I'm having some hdpvr trouble: I'm using vlc to view the stream. Kernel 3.9.11 works pretty well, including giving me AC3 5.1 audio from the optical input to the Hauppauge device. The only problem I've run across is the device hanging when I change channels, but I've learned to live with that. (Though naturally it would be nice to fix. :) ) However, every kernel I've tried after 3.9.11 seems to have trouble with the audio. I get silence, and pulseaudio reports there is only stereo. I've taken a couple of of snapshots of pavucontrol so you can see what I mean: http://imgur.com/a/SIwc7 I even tried a git bisect to try to narrow down where things went awry, but ran out of time to pursue the question. But as far as I can tell, 3.9.11 is as far as I can go before my system won't use the device properly. I see the conversation in the archives from around the middle of May, where Hans was working with Ryley and Keith, but I'm not sure if I should apply that patch or not. I would love to make this work, including submitting a patch if someone could outline where the problem might be. Thank you in advance for any help you can provide, and please let me know if I can send any more information. :) You can certainly try this patch: https://patchwork.linuxtv.org/patch/23890/ Nobody else reported audio problems other than the issue this patch tries to resolve. However, that problem most likely has been with hdpvr since the very beginning. There were some major changes made to the driver in 3.10, so that makes me suspect that something might have broken. Odd though that I didn't see any reports about that. Keith, Ryley, if you run v4l2-ctl -D, what is the version number that is reported? If it is = 3.10, then can you test with vlc as well? Just tried the patch with 3.14.5, and it didn't solve the problem. I'm not sure what's different about my system than other folks', unless they aren't using the optical input? Indeed, it acts just like the driver isn't properly honoring default_audio_input=2. (For S/PDIF). Thinking that might be a clue, I hooked up stereo through the RCA jacks. With default_audio_input=2, I did hear some crackling sounds -- but nothing intelligible, and I'm having a hard time reproducing that. With default_audio_input=0, I get clear stereo sound from the RCA jacks. -Scott -- 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: hdpvr troubles
On 06/11/2014 09:43 PM, Scott Doty wrote: On 06/11/2014 01:24 AM, Hans Verkuil wrote: On 06/03/14 03:23, Scott Doty wrote: Hello Mr. Hans and mailing list, In a nutshell, I'm having some hdpvr trouble: I'm using vlc to view the stream. Kernel 3.9.11 works pretty well, including giving me AC3 5.1 audio from the optical input to the Hauppauge device. The only problem I've run across is the device hanging when I change channels, but I've learned to live with that. (Though naturally it would be nice to fix. :) ) However, every kernel I've tried after 3.9.11 seems to have trouble with the audio. I get silence, and pulseaudio reports there is only stereo. I've taken a couple of of snapshots of pavucontrol so you can see what I mean: http://imgur.com/a/SIwc7 I even tried a git bisect to try to narrow down where things went awry, but ran out of time to pursue the question. But as far as I can tell, 3.9.11 is as far as I can go before my system won't use the device properly. I see the conversation in the archives from around the middle of May, where Hans was working with Ryley and Keith, but I'm not sure if I should apply that patch or not. I would love to make this work, including submitting a patch if someone could outline where the problem might be. Thank you in advance for any help you can provide, and please let me know if I can send any more information. :) You can certainly try this patch: https://patchwork.linuxtv.org/patch/23890/ Nobody else reported audio problems other than the issue this patch tries to resolve. However, that problem most likely has been with hdpvr since the very beginning. There were some major changes made to the driver in 3.10, so that makes me suspect that something might have broken. Odd though that I didn't see any reports about that. Keith, Ryley, if you run v4l2-ctl -D, what is the version number that is reported? If it is = 3.10, then can you test with vlc as well? Just tried the patch with 3.14.5, and it didn't solve the problem. I'm not sure what's different about my system than other folks', unless they aren't using the optical input? Indeed, it acts just like the driver isn't properly honoring default_audio_input=2. (For S/PDIF). Thinking that might be a clue, I hooked up stereo through the RCA jacks. With default_audio_input=2, I did hear some crackling sounds -- but nothing intelligible, and I'm having a hard time reproducing that. With default_audio_input=0, I get clear stereo sound from the RCA jacks. Ah, you never mentioned that you used the default_audio_input module option. I looked at that and that did indeed break in 3.10. You probably need to do 'v4l2-ctl -c audio_encoding=4'. In 3.9 selecting default_audio_input=2 would also switch to AC3 audio encoding, but in 3.10 that is reset a bit later to AAC. But by selecting it manually it should work again. Let me know if I am correct and if so, then I'll make a patch for this to fix this behavior. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hdpvr troubles
On 06/11/2014 01:33 PM, Hans Verkuil wrote: On 06/11/2014 09:43 PM, Scott Doty wrote: On 06/11/2014 01:24 AM, Hans Verkuil wrote: On 06/03/14 03:23, Scott Doty wrote: Hello Mr. Hans and mailing list, In a nutshell, I'm having some hdpvr trouble: I'm using vlc to view the stream. Kernel 3.9.11 works pretty well, including giving me AC3 5.1 audio from the optical input to the Hauppauge device. The only problem I've run across is the device hanging when I change channels, but I've learned to live with that. (Though naturally it would be nice to fix. :) ) However, every kernel I've tried after 3.9.11 seems to have trouble with the audio. I get silence, and pulseaudio reports there is only stereo. I've taken a couple of of snapshots of pavucontrol so you can see what I mean: http://imgur.com/a/SIwc7 I even tried a git bisect to try to narrow down where things went awry, but ran out of time to pursue the question. But as far as I can tell, 3.9.11 is as far as I can go before my system won't use the device properly. I see the conversation in the archives from around the middle of May, where Hans was working with Ryley and Keith, but I'm not sure if I should apply that patch or not. I would love to make this work, including submitting a patch if someone could outline where the problem might be. Thank you in advance for any help you can provide, and please let me know if I can send any more information. :) You can certainly try this patch: https://patchwork.linuxtv.org/patch/23890/ Nobody else reported audio problems other than the issue this patch tries to resolve. However, that problem most likely has been with hdpvr since the very beginning. There were some major changes made to the driver in 3.10, so that makes me suspect that something might have broken. Odd though that I didn't see any reports about that. Keith, Ryley, if you run v4l2-ctl -D, what is the version number that is reported? If it is = 3.10, then can you test with vlc as well? Just tried the patch with 3.14.5, and it didn't solve the problem. I'm not sure what's different about my system than other folks', unless they aren't using the optical input? Indeed, it acts just like the driver isn't properly honoring default_audio_input=2. (For S/PDIF). Thinking that might be a clue, I hooked up stereo through the RCA jacks. With default_audio_input=2, I did hear some crackling sounds -- but nothing intelligible, and I'm having a hard time reproducing that. With default_audio_input=0, I get clear stereo sound from the RCA jacks. Ah, you never mentioned that you used the default_audio_input module option. I looked at that and that did indeed break in 3.10. You probably need to do 'v4l2-ctl -c audio_encoding=4'. In 3.9 selecting default_audio_input=2 would also switch to AC3 audio encoding, but in 3.10 that is reset a bit later to AAC. But by selecting it manually it should work again. Let me know if I am correct and if so, then I'll make a patch for this to fix this behavior. Hello, Unfortunately, using the v4l2-ctl command doesn't seem to make any difference. I do know it's taking effect because when I set it to 3, the video pauses a bit then resumes, which I assume is your recent patch resetting the stream; and when I reset it to 4, I get the pause/resume again, but still no audio. Setting it to 4 before running vlc doesn't seem to help, either, alas. Maybe we need to set the pvr to do passthrough of its AC3 when running on newer kernels? -Scott -- 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]cxd2820r: TS clock inversion in config
Reviewed-by: Antti Palosaari cr...@iki.fi
Acked-by: Antti Palosaari cr...@iki.fi
On 06/03/2014 08:19 PM, CrazyCat wrote:
TS clock inversion in config.
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
---
drivers/media/dvb-frontends/cxd2820r.h| 6 ++
drivers/media/dvb-frontends/cxd2820r_c.c | 1 +
drivers/media/dvb-frontends/cxd2820r_t.c | 1 +
drivers/media/dvb-frontends/cxd2820r_t2.c | 1 +
4 files changed, 9 insertions(+)
diff --git a/drivers/media/dvb-frontends/cxd2820r.h
b/drivers/media/dvb-frontends/cxd2820r.h
index 82b3d93..6095dbc 100644
--- a/drivers/media/dvb-frontends/cxd2820r.h
+++ b/drivers/media/dvb-frontends/cxd2820r.h
@@ -52,6 +52,12 @@ struct cxd2820r_config {
*/
u8 ts_mode;
+ /* TS clock inverted.
+* Default: 0
+* Values: 0, 1
+*/
+ bool ts_clock_inv;
+
/* IF AGC polarity.
* Default: 0
* Values: 0, 1
diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c
b/drivers/media/dvb-frontends/cxd2820r_c.c
index 5c6ab49..0f4657e 100644
--- a/drivers/media/dvb-frontends/cxd2820r_c.c
+++ b/drivers/media/dvb-frontends/cxd2820r_c.c
@@ -45,6 +45,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
{ 0x1008b, 0x07, 0xff },
{ 0x1001f, priv-cfg.if_agc_polarity 7, 0x80 },
{ 0x10070, priv-cfg.ts_mode, 0xff },
+ { 0x10071, !priv-cfg.ts_clock_inv 4, 0x10 },
};
dev_dbg(priv-i2c-dev, %s: frequency=%d symbol_rate=%d\n, __func__,
diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c
b/drivers/media/dvb-frontends/cxd2820r_t.c
index fa184ca..9b5a45b 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t.c
@@ -46,6 +46,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)
{ 0x00088, 0x01, 0xff },
{ 0x00070, priv-cfg.ts_mode, 0xff },
+ { 0x00071, !priv-cfg.ts_clock_inv 4, 0x10 },
{ 0x000cb, priv-cfg.if_agc_polarity 6, 0x40 },
{ 0x000a5, 0x00, 0x01 },
{ 0x00082, 0x20, 0x60 },
diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c
b/drivers/media/dvb-frontends/cxd2820r_t2.c
index 2ba130e..9c0c4f4 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t2.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
@@ -47,6 +47,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)
{ 0x02083, 0x0a, 0xff },
{ 0x020cb, priv-cfg.if_agc_polarity 6, 0x40 },
{ 0x02070, priv-cfg.ts_mode, 0xff },
+ { 0x02071, !priv-cfg.ts_clock_inv 6, 0x40 },
{ 0x020b5, priv-cfg.spec_inv 4, 0x10 },
{ 0x02567, 0x07, 0x0f },
{ 0x02569, 0x03, 0x03 },
--
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
em28xx submit of urb 0 failed (error=-27)
Do you have any idea about that bug? kernel: submit of urb 0 failed (error=-27) https://bugzilla.kernel.org/show_bug.cgi?id=72891 I have seen it recently very often when I try start streaming DVB. When it happens, device is unusable. I have feeling that it could be coming from recent 28xx big changes where it was modularised. IIRC I reported that at the time and Mauro added error number printing to log entry. Anyhow, it is very annoying and occurs very often. And people have started pinging me as I have added very many DVB devices to em28xx. regards Antti -- 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: em28xx submit of urb 0 failed (error=-27)
I just ran blind scan using w_scan and it interrupted scanning, with following error (ioctl DMX_SET_FILTER failed: 27 File too large). 602000: (time: 00:58.973) (0.308sec): SCL (0x1F) (0.308sec) signal (0.308sec) lock signal ok: QAM_AUTO f = 602000 kHz I999B8C999D999T999G999Y999 (0:0:0) initial PAT lookup.. start_filter:1644: ERROR: ioctl DMX_SET_FILTER failed: 27 File too large regards Antti On 06/12/2014 03:23 AM, Antti Palosaari wrote: Do you have any idea about that bug? kernel: submit of urb 0 failed (error=-27) https://bugzilla.kernel.org/show_bug.cgi?id=72891 I have seen it recently very often when I try start streaming DVB. When it happens, device is unusable. I have feeling that it could be coming from recent 28xx big changes where it was modularised. IIRC I reported that at the time and Mauro added error number printing to log entry. Anyhow, it is very annoying and occurs very often. And people have started pinging me as I have added very many DVB devices to em28xx. regards Antti -- 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 00/43] i.MX6 Video capture
On 06/11/2014 04:21 AM, Philipp Zabel wrote: Hi Steve, Am Samstag, den 07.06.2014, 14:56 -0700 schrieb Steve Longerbeam: Hi all, This patch set adds video capture support for the Freescale i.MX6 SOC. It is a from-scratch standardized driver that works with community v4l2 utilities, such as v4l2-ctl, v4l2-cap, and the v4l2src gstreamer plugin. It uses the latest v4l2 interfaces (subdev, videobuf2). Please see Documentation/video4linux/mx6_camera.txt for it's full list of features! That's quite a series to digest! I'll quickly go over the points that jumped at me and then look at the core code (especially 08/43 and 39/43) in detail. The first 38 patches: - prepare the ipu-v3 driver for video capture support. The current driver contains only video display functionality to support the imx DRM drivers. At some point ipu-v3 should be moved out from under staging/imx-drm since it will no longer only support DRM. The move out of staging is now merged into drm-next with c1a6e9fe82b46159af8cc4cf34fb51ee47862f05. After this is merged into mainline, there should be no need to push i.MX capture support through staging. It would be helpful if you could rebase on top of that. Hi Philipp and Sascha, First of all, thanks for the detailed review. I think it's obvious that this patch set should be split into two: first, the changes to IPU core driver submitted to drm-next, and the capture driver to media-tree. Or, do you prefer I submit the IPU core patches to your own pengutronix git tree, and we can correspond on one of your internal mailing lists? I can then leave it to you to push those changes to drm-next. I agree with most of your feedback, and most is specific to the IPU core changes. We can discuss those in detail elsewhere, but just in summary here, some of your comments seem to conflict: 1. Regarding the input muxes to the CSI and IC, Philipp you acked those functions but would like to see these muxes as v4l2 subdevs and configured in the DT, but Sascha, you had a comment that this should be a job for mediactrl. 2. Philipp, you would like to see CSI, IC, and SMFC units moved out of IPU core and become v4l2 subdevs. I agree with that, but drm-next has ipu-smfc as part of IPU core, and SMFC is most definitely v4l2 capture specific. Steve -- 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: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically
Dear David, From our test, Linux kernel 3.14 + v3.6.0.0 firmware have good RF performance on single and dual tuners. BRs, Jason -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of David Shirley Sent: Wednesday, June 11, 2014 9:23 PM To: Jason Dong (董志堅) Cc: sebastian...@gmx.net; Unname Subject: RE: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically Hey Jason, We have access to the following firmwares for it913x: http://palosaari.fi/linux/v4l-dvb/firmware/IT9135/12.10.04.1/IT9135v2_3.40.1.0_3.17.1.0/ http://palosaari.fi/linux/v4l-dvb/firmware/IT9135/12.10.04.1/IT9135v2_3.42.3.3_3.29.3.3/ and of course the one the kernel uses: http://www.ite.com.tw/uploads/firmware/v3.6.0.0/dvb-usb-it9135.zip Will any work with the dual it9137/9133? Regards D. On 11 Jun 2014 20:08, jason.d...@ite.com.tw wrote: Dear David, The RF performance is no problem. Each firmware needs tie in with the correct tuner script (some register settings). The driver should be modified if we changed the firmware. BRs, Jason From: David Shirley [mailto:tep...@gmail.com] Sent: Wednesday, June 11, 2014 4:29 PM To: Jason Dong (董志堅) Cc: sebastian...@gmx.net; Unname Subject: RE: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically Hey Jason, Is it possible yo get a copy if the newest stable firmware? I feel like the v3.6 that the kernel extracts is pretty old? Regards D. On 11 Jun 2014 18:11, jason.d...@ite.com.tw wrote: Dear David, The RF performance of ITE9137 BX + IE9133 dongle is a little worse than single tuner. As our test resolut, the RF performances should be -80db and -82db for dual tuners and single tuner. There is an issue in hardware design if the reception capability is too worse. We don’t need to change the firmware for dual tuners. I think there are some problems in af9033 driver of kernel v3.15. BRs, Jason -Original Message- From: David Shirley [mailto:tep...@gmail.com] Sent: Wednesday, June 11, 2014 3:00 PM To: Jason Dong (董志堅) Cc: sebastian...@gmx.net; linux-media@vger.kernel.org Subject: Re: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically Hey Jason, Do we know if that RF problem exists in 3.14.5? Using the IT913X driver? I have a Leadtek Winfast Dual Dongle (0413:6a05 - dual usb - ITE9137 BX + IE9133) which is being extremely painful (random signal locks, tzap reports ok signal strength for one tuner but poor for the other, random signal dropouts (ie working fine, then progressively getting more and more blips in visual/audio from stream)). I dont think its signal strength related because 3x Leadtek Winfast Gold dongles (AF9013) all work (until they stop tuning and cold reboot is required) I suspect something about the firmware is at fault, I have tried to talk to Antti - but he must be busy. I have tried three different dvb-usb-it9135-02.fw firmwares, and they don't seem to make a huge difference (newest doesn't create /dev/dvb bits)... Does a BX (v2) 9137 require yet another firmware image? If I use the AF9035 kernel driver it doesn't tune at all. But does detect the tuners... Sorry to threadjack - but seeing your @ite.com.tw I thought I would ask while I can :) Regards David On 11 June 2014 15:31, jason.d...@ite.com.tw wrote: Dear Sebastian, There is a RF performance issue in the af9033 driver of kernel 3.15. It is no problem in the it913x driver of kernel 3.14. There were some initial sequences not correct after the it913x driver was integrated into af9033 driver. BRs, Jason -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Sebastian Kemper Sent: Tuesday, June 10, 2014 8:51 PM To: linux-media@vger.kernel.org Subject: AF9033 / IT913X: Avermedia A835B(1835) only works sporadically Hello list, I have an Avermedia A835B(1835) USB DVB-T stick (07ca:1835) which works only (very) sporadically. It's pure luck as far as I can see. I can't reproduce how to get it working. There are no special steps that I can take to guarantee that it'll work once I plug it in. I'd rate my chances of having the device actually working between 5 and 10 percent. In the log everything looks fine, apart from the messages at the bottom about the device not being able to get a lock on a channel. Reception here is really good, so there's no problem with signal strength. When loading the device in Windows 7 64 bit it always finds a lock. Has anybody any idea? Thanks for any suggestions! Jun 10 14:18:07 meiner kernel: usb 1-2: new high-speed USB device number 2 using xhci_hcd Jun 10 14:18:07 meiner kernel: WARNING: You are using an experimental version of the media stack. Jun 10 14:18:07 meiner kernel: As the driver is backported to an older kernel, it
cron job: media_tree daily build: OK
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: Thu Jun 12 04:00:29 CEST 2014 git branch: test git hash: 5ea878796f0a1d9649fe43a6a09df53d3915c0ef gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-5.slh.5-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
