cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Mar 17 04:00:16 CET 2015 git branch: test git hash: 3d945be05ac1e806af075e9315bc1b3409adae2b gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.19.0-1.slh.1-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.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: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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
Re: Re: cx23885: DVBSky S952 dvb_register failed err = -22
Hello, what is the "chip_id" debug output from m88ts2022 module? I think you maybe hold the old S952 card. Its satellite tuner is M88TS2020, not M88TS2022. Best Regards, Max On 2015-03-15 19:07:07, Ole Ernst wrote: >Hi Antti, > >thanks for your quick response! Based on lsmod and modinfo I do have >m88ts2022. > >$ lsmod | grep m88 >m88ts2022 16898 0 >regmap_i2c 12783 1 m88ts2022 >m88ds3103 21452 0 >i2c_mux12534 1 m88ds3103 >dvb_core 102038 4 cx23885,altera_ci,m88ds3103,videobuf2_dvb >i2c_core 50240 13 >drm,i2c_i801,cx23885,cx25840,m88ts2022,i2c_mux,regmap_i2c,nvidia,v4l2_common,tveeprom,m88ds3103,tda18271,videodev > >$ modinfo m88ts2022 >filename: >/lib/modules/3.19.1-1-ARCH/kernel/drivers/media/tuners/m88ts2022.ko.gz >license:GPL >author: Antti Palosaari >description:Montage M88TS2022 silicon tuner driver >alias: i2c:m88ts2022 >depends:i2c-core,regmap-i2c >intree: Y >vermagic: 3.19.1-1-ARCH SMP preempt mod_unload modversions > >Thanks, >Ole > >Am 15.03.2015 um 11:49 schrieb Antti Palosaari: >> You don't have m88ts2022 driver installed. >> >> Antti >> >> On 03/15/2015 12:26 PM, Ole Ernst wrote: >>> Hi, >>> >>> I added some printk in cx23885-dvb.c and the problem is in >>> i2c_new_device: >>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/media/pci/cx23885/cx23885-dvb.c?id=refs/tags/v3.19.1#n1935 >>> >>> >>> The returned client_tuner is not NULL, but client_tuner->dev.driver is. >>> Hence it will goto frontend_detach, which will then return -EINVAL. Any >>> idea why client_tuner->dev.driver is NULL? >>> >>> Thanks, >>> Ole >>> >>> Am 14.03.2015 um 20:54 schrieb Ole Ernst: Hi, using linux-3.19.1-1 (Archlinux) I get the following output while booting without the media-build-tree provided by DVBSky: cx23885 driver version 0.0.4 loaded cx23885 :04:00.0: enabling device ( -> 0002) CORE cx23885[0]: subsystem: 4254:0952, board: DVBSky S952 [card=50,autodetected] cx25840 3-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0]) cx25840 3-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card i2c i2c-2: m88ds3103_attach: chip_id=70 i2c i2c-2: Added multiplexed i2c bus 4 cx23885_dvb_register() dvb_register failed err = -22 cx23885_dev_setup() Failed to register dvb adapters on VID_B cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card i2c i2c-1: m88ds3103_attach: chip_id=70 i2c i2c-1: Added multiplexed i2c bus 4 cx23885_dvb_register() dvb_register failed err = -22 cx23885_dev_setup() Failed to register dvb on VID_C cx23885_dev_checkrevision() Hardware revision = 0xa5 cx23885[0]/0: found at :04:00.0, rev: 4, irq: 17, latency: 0, mmio: 0xf720 Obviously there are no device in /dev/dvb. Using the media-build-tree works just fine though. The following firmware files are installed in /usr/lib/firmware: dvb-demod-m88ds3103.fw dvb-demod-m88rs6000.fw dvb-demod-si2168-a20-01.fw dvb-demod-si2168-a30-01.fw dvb-demod-si2168-b40-01.fw dvb-fe-ds300x.fw dvb-fe-ds3103.fw dvb-fe-rs6000.fw dvb-tuner-si2158-a20-01.fw Output of lspci -vvvnn: https://gist.githubusercontent.com/olebowle/6a4108363a9d1f7dd033/raw/lscpi I also set the module parameters debug, i2c_debug, irq_debug and irq_debug in cx23885. The output is pretty verbose and can be found here: https://gist.githubusercontent.com/olebowle/6a4108363a9d1f7dd033/raw/debug.log Thanks, Ole -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] omap3isp: Deprecate platform data support
Hi Sakari,
Thank you for the patch.
On Monday 16 March 2015 02:26:10 Sakari Ailus wrote:
> Print a warning when the driver is used with platform data. Existing
> platform data user should move to DT now.
s/user/users/
>
> Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 0d6012a..82940fe 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -2447,6 +2447,8 @@ static int isp_probe(struct platform_device *pdev)
> isp->syscon = syscon_regmap_lookup_by_pdevname("syscon.0");
> if (IS_ERR(isp->syscon))
> return PTR_ERR(isp->syscon);
> + dev_warn(&pdev->dev,
> + "Platform data support is deprecated! Please move to
> DT now!
\n");
> }
>
> isp->autoidle = autoidle;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/15] omap3isp: Add support for the Device Tree
Hi Sakari,
Thank you for the patch.
On Monday 16 March 2015 02:26:09 Sakari Ailus wrote:
> Add the ISP device to omap3 DT include file and add support to the driver to
> use it.
>
> Also obtain information on the external entities and the ISP configuration
> related to them through the Device Tree in addition to the platform data.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/platform/omap3isp/isp.c | 209 ++--
> drivers/media/platform/omap3isp/isp.h | 11 ++
> drivers/media/platform/omap3isp/ispcsiphy.c |7 +
> 3 files changed, 215 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 992e74c..0d6012a 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -64,6 +64,7 @@
>
> #include
> #include
> +#include
>
> #include "isp.h"
> #include "ispreg.h"
> @@ -1991,6 +1992,14 @@ static int isp_register_entities(struct isp_device
> *isp) if (ret < 0)
> goto done;
>
> + /*
> + * Device Tree --- the external of the sub-devices will be
What do you mean by "the external of the sub-devices" ?
> + * registered later. Same goes for the sub-device node
> + * registration.
> + */
> + if (isp->dev->of_node)
> + return 0;
> +
> /* Register external entities */
> for (isp_subdev = pdata ? pdata->subdevs : NULL;
>isp_subdev && isp_subdev->board_info; isp_subdev++) {
> @@ -2016,8 +2025,10 @@ static int isp_register_entities(struct isp_device
> *isp) ret = v4l2_device_register_subdev_nodes(&isp->v4l2_dev);
>
> done:
> - if (ret < 0)
> + if (ret < 0) {
> isp_unregister_entities(isp);
> + v4l2_async_notifier_unregister(&isp->notifier);
> + }
>
> return ret;
> }
> @@ -2232,6 +2243,7 @@ static int isp_remove(struct platform_device *pdev)
> {
> struct isp_device *isp = platform_get_drvdata(pdev);
>
> + v4l2_async_notifier_unregister(&isp->notifier);
> isp_unregister_entities(isp);
> isp_cleanup_modules(isp);
> isp_xclk_cleanup(isp);
> @@ -2243,6 +2255,151 @@ static int isp_remove(struct platform_device *pdev)
> return 0;
> }
>
> +enum isp_of_phy {
> + ISP_OF_PHY_PARALLEL = 0,
> + ISP_OF_PHY_CSIPHY1,
> + ISP_OF_PHY_CSIPHY2,
> +};
> +
> +static int isp_of_parse_node(struct device *dev, struct device_node *node,
> + struct isp_async_subdev *isd)
> +{
> + struct isp_bus_cfg *buscfg = &isd->bus;
> + struct v4l2_of_endpoint vep;
> + unsigned int i;
> +
> + v4l2_of_parse_endpoint(node, &vep);
> +
> + dev_dbg(dev, "interface %u\n", vep.base.port);
The message seems a bit terse to me, I would also print the endpoint node name
to give a bit of context.
dev_dbg(dev, "parsing endpoint %s, interface %u\n", node->full_name,
vep.base.port);
> +
> + switch (vep.base.port) {
> + case ISP_OF_PHY_PARALLEL:
> + buscfg->interface = ISP_INTERFACE_PARALLEL;
> + buscfg->bus.parallel.data_lane_shift =
> + vep.bus.parallel.data_shift;
> + buscfg->bus.parallel.clk_pol =
> + !!(vep.bus.parallel.flags
> +& V4L2_MBUS_PCLK_SAMPLE_FALLING);
> + buscfg->bus.parallel.hs_pol =
> + !!(vep.bus.parallel.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW);
> + buscfg->bus.parallel.vs_pol =
> + !!(vep.bus.parallel.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW);
> + buscfg->bus.parallel.fld_pol =
> + !!(vep.bus.parallel.flags & V4L2_MBUS_FIELD_EVEN_LOW);
> + buscfg->bus.parallel.data_pol =
> + !!(vep.bus.parallel.flags & V4L2_MBUS_DATA_ACTIVE_LOW);
> + break;
> +
> + case ISP_OF_PHY_CSIPHY1:
> + case ISP_OF_PHY_CSIPHY2:
> + /* FIXME: always assume CSI-2 for now. */
> + switch (vep.base.port) {
> + case ISP_OF_PHY_CSIPHY1:
I'd use an if - else here, but that's up to you.
> + buscfg->interface = ISP_INTERFACE_CSI2C_PHY1;
> + break;
> + case ISP_OF_PHY_CSIPHY2:
> + buscfg->interface = ISP_INTERFACE_CSI2A_PHY2;
> + break;
> + }
> + buscfg->bus.csi2.lanecfg.clk.pos = vep.bus.mipi_csi2.clock_lane;
> + buscfg->bus.csi2.lanecfg.clk.pol =
> + vep.bus.mipi_csi2.lane_polarity[0];
> + dev_dbg(dev, "clock lane polarity %u, pos %u\n",
> + buscfg->bus.csi2.lanecfg.clk.pol,
> + buscfg->bus.csi2.lanecfg.clk.pos);
> +
> + for (i = 0; i < ISP_CSIPHY2_NUM_DATA_LANES; i++) {
> + buscfg->bus.csi2.lanecfg.data[i].pos =
> + vep.bus.mipi_csi2.da
Re: [RFC/PATCH 0/5] Add live source objects to DRM
Hi Daniel, On Monday 16 March 2015 09:35:22 Daniel Vetter wrote: > On Sun, Mar 15, 2015 at 11:55:35PM +0200, Laurent Pinchart wrote: > > Hello, > > > > I have a feeling that RFC/PATCH will work better than just RFC, so here's > > a patch set that adds a new object named live source to DRM. > > > > The need comes from the Renesas R-Car SoCs in which a video processing > > engine (named VSP1) that operates from memory to memory has one output > > directly connected to a plane of the display engine (DU) without going > > through memory. > > > > The VSP1 is supported by a V4L2 driver. While it could be argued that it > > should instead be supported directly by the DRM rcar-du driver, this > > wouldn't be a good idea for at least two reasons. First, the R-Car SoCs > > contain several VSP1 instances, of which only a subset have a direct DU > > connection. The only other instances operate solely in memory to memory > > mode. Then, the VSP1 is a video processing engine and not a display > > engine. Its features are easily supported by the V4L2 API, but don't map > > to the DRM/KMS API. Significant changes to DRM/KMS would be required, > > beyond what is in my opinion an acceptable scope for a display API. > > > > Now that the need to interface two separate devices supported by two > > different drivers in two separate subsystems has been established, we > > need an API to do so. It should be noted that while that API doesn't > > exist in the mainline kernel, the need isn't limited to Renesas SoCs. > > > > This patch set proposes one possible solution for the problem in the form > > of a new DRM object named live source. Live sources are created by > > drivers to model hardware connections between a plane input and an > > external source, and are attached to planes through the KMS userspace > > API. > > > > Patch 1/5 adds live source objects to DRM, with an in-kernel API for > > drivers to register the sources, and a userspace API to enumerate and > > configure them. Configuring a live source sets the width, height and > > pixel format of the video stream. This should ideally be queried directly > > from the driver that supports the live source device, but I've decided > > not to implement such communication between V4L2 and DRM/KMS at the > > moment to keep the proposal simple. > > > > Patch 2/2 implements connection between live sources and planes. This > > takes different forms depending on whether drivers use the setplane or the > > atomic updates API: > > > > - For setplane, the fb field can now contain a live source ID in addition > > to a framebuffer ID. As DRM allocates object IDs from a single ID space, > > the type can be inferred from the ID. This makes specifying both a > > framebuffer and a live source impossible, which isn't an issue given > > that such a configuration would be invalid. > > > > The live source is looked up by the DRM core and passed as a pointer to > > the .update_plane() operation. Unlike framebuffers live sources are not > > refcounted as they're created statically at driver initialization time. > > > > - For atomic update, a new SRC_ID property has been added to planes. The > > live source is looked up from the source ID and stored into the plane > > state. > > What about directly treating live sources as (very) special framebuffers? > A bunch of reasons: > - All the abi fu above gets resolved naturally. > - You have lot of duplication between fb and live source wrt size, > possible/selected pixel format and other stuff. > - The backing storage of framebuffers is fully opaque anyway ... > > I think we still need separate live source objects though for things like > telling userspace what v4l thing it corresponds to, and for getting at the > pixel format. But connecting the live source with the plane could still be > done with a framebuffer and a special flag in the addfb2 ioctl to use > live sources as backing storage ids instead of gem/ttm handles. > > That would also give you a good point to enforce pixel format > compatibility: As soon as someone created a framebuffer for a live source > you disallow pixel format changes in the v4l pipeline to make sure things > will fit. That's an interesting idea, I'll give it a try. This will have to wait a little bit though, I'll be busy with other tasks this week, and I'll be attending ELC next week. Thank you for the quick review and the proposal, it's very appreciated. > > Patches 3/5 to 5/5 then implement support for live sources in the R-Car DU > > driver. > > > > Nothing here is set in stone. One point I'm not sure about is whether live > > sources support should be enabled for setplane or only for atomic updates. > > Other parts of the API can certainly be modified as well, and I'm open for > > totally different implementations as well. > > Imo this should be irrespective of atomic or not really. And by using > magic framebuffers as the link we'd get that for free. > > Cheers, Daniel > > >
[PATCH] drm: rcar-du: Implement write-back support
The R-Car DU supports writing back the display unit output to memory.
Add support for that feature using a V4L2 device.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Makefile| 3 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 47 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 7 +
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 8 +
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 4 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 8 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 5 +
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 4 +
drivers/gpu/drm/rcar-du/rcar_du_wback.c | 792
drivers/gpu/drm/rcar-du/rcar_du_wback.h | 102
10 files changed, 969 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_wback.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_wback.h
Hello,
This is (to my knowledge) the first attempt to use V4L2 as a capture API for
the write-back feature or a DRM/KMS device.
Overall the implementation isn't very intrusive and keeps the V4L2 API
implementation pretty much in a single source file. I'm quite happy with the
architecture, let's now see how the cross-subsystem review will affect that
mood :-)
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 05de1c4097af..65050435cbb9 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -5,7 +5,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
rcar_du_kms.o \
rcar_du_lvdscon.o \
rcar_du_plane.o \
-rcar_du_vgacon.o
+rcar_du_vgacon.o \
+rcar_du_wback.o
rcar-du-drm-$(CONFIG_DRM_RCAR_HDMI)+= rcar_du_hdmicon.o \
rcar_du_hdmienc.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 9e72133bb64b..479f14886ec1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -28,6 +28,7 @@
#include "rcar_du_kms.h"
#include "rcar_du_plane.h"
#include "rcar_du_regs.h"
+#include "rcar_du_wback.h"
static u32 rcar_du_crtc_read(struct rcar_du_crtc *rcrtc, u32 reg)
{
@@ -68,7 +69,7 @@ static void rcar_du_crtc_clr_set(struct rcar_du_crtc *rcrtc,
u32 reg,
rcar_du_write(rcdu, rcrtc->mmio_offset + reg, (value & ~clr) | set);
}
-static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
+int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
{
int ret;
@@ -93,7 +94,7 @@ error_clock:
return ret;
}
-static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
+void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
{
rcar_du_group_put(rcrtc->group);
@@ -173,6 +174,13 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
rcar_du_crtc_write(rcrtc, DESR, mode->htotal - mode->hsync_start);
rcar_du_crtc_write(rcrtc, DEWR, mode->hdisplay);
+
+ /* Program the raster interrupt offset (used by the writeback state
+* machine) to generate an interrupt as far as possible from the start
+* of vertical blanking.
+*/
+ rcar_du_crtc_write(rcrtc, RINTOFSR,
+ max(mode->crtc_vdisplay - mode->crtc_vtotal / 2, 1));
}
void rcar_du_crtc_route_output(struct drm_crtc *crtc,
@@ -511,9 +519,17 @@ static const struct drm_crtc_helper_funcs
crtc_helper_funcs = {
.atomic_flush = rcar_du_crtc_atomic_flush,
};
+static void rcar_du_crtc_destroy(struct drm_crtc *crtc)
+{
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+
+ rcar_du_wback_cleanup_crtc(rcrtc);
+ drm_crtc_cleanup(crtc);
+}
+
static const struct drm_crtc_funcs crtc_funcs = {
.reset = drm_atomic_helper_crtc_reset,
- .destroy = drm_crtc_cleanup,
+ .destroy = rcar_du_crtc_destroy,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
@@ -527,19 +543,20 @@ static const struct drm_crtc_funcs crtc_funcs = {
static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
{
struct rcar_du_crtc *rcrtc = arg;
- irqreturn_t ret = IRQ_NONE;
u32 status;
status = rcar_du_crtc_read(rcrtc, DSSR);
+
+ rcar_du_wback_irq(&rcrtc->wback, status);
+
rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
if (status & DSSR_FRM) {
drm_handle_vblank(rcrtc->crtc.dev, rcrtc->index);
rcar_du_crtc_finish_page_flip(rcrtc);
- ret = IRQ_HANDLED;
}
- return ret;
+ return status & (DSSR_FRM | DSSR_RINT) ? IRQ_HANDLED : IRQ_NONE;
}
/*
-
@@ -626,9 +643,27 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
unsigned int index)
return ret;
}
+ ret = rcar_du_wback_init
Re: [RFC 10/18] omap3isp: Move the syscon register out of the ISP register maps
On Mon, Mar 16, 2015 at 02:19:04AM +0200, Laurent Pinchart wrote: > Hi Sakari, > > On Saturday 07 March 2015 23:41:07 Sakari Ailus wrote: > > The syscon register isn't part of the ISP, use it through the syscom driver > > regmap instead. The syscom block is considered to be from 343x on ISP > > revision 2.0 whereas 15.0 is assumed to have 3630 syscon. > > > > Signed-off-by: Sakari Ailus > > --- > > arch/arm/boot/dts/omap3.dtsi|2 +- > > arch/arm/mach-omap2/devices.c | 10 -- > > drivers/media/platform/omap3isp/isp.c | 19 +++ > > drivers/media/platform/omap3isp/isp.h | 19 +-- > > drivers/media/platform/omap3isp/ispcsiphy.c | 20 +--- > > I've noticed another issue, you need a "select MFD_SYSCON" in Kconfig. Thanks, fixed! -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] rtl2832: PID filter support for slave demod
On 03/16/2015 11:57 PM, Antti Palosaari wrote: On 03/17/2015 12:12 AM, Benjamin Larsson wrote: Is this structure ok for the slave pid implementation? Or should there be only one filters parameter? Will the overlaying pid filter framework properly "flush" the set pid filters ? Note that this code currently is only compile tested. I am fine with it. byw. Have you tested if your QAM256 (DVB-C or DVB-T2) stream is valid even without a PID filtering? IIRC mine stream is correct and PID filtering is not required (but surely it could be implemented if you wish). regards Antti DVB-C seems fine and one of my DVB-T2 muxes is fine also. But one other DVB-T2 mux completely fails. It could be the reception but it might be that it needs pid filtering. I do get small disturbances on my DVB-C muxes. Will report back if pid filtering makes things better or not. MvH Benjamin Larsson -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] v4l: of: Read lane-polarity endpoint property
Hi Laurent,
On Mon, Mar 16, 2015 at 11:05:38AM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> Thank you for the patch.
>
> On Monday 16 March 2015 02:26:08 Sakari Ailus wrote:
> > Add lane_polarity field to struct v4l2_of_bus_mipi_csi2 and write the
> > contents of the lane polarity property to it. The field tells the polarity
> > of the physical lanes starting from the first one. Any unused lanes are
> > ignored, i.e. only the polarity of the used lanes is specified.
> >
> > Also rework reading the "data-lanes" property a little.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > drivers/media/v4l2-core/v4l2-of.c | 41 ++
> > include/media/v4l2-of.h |3 +++
> > 2 files changed, 35 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-of.c
> > b/drivers/media/v4l2-core/v4l2-of.c index b4ed9a9..e44cc15 100644
> > --- a/drivers/media/v4l2-core/v4l2-of.c
> > +++ b/drivers/media/v4l2-core/v4l2-of.c
> > @@ -19,11 +19,10 @@
> >
> > #include
> >
> > -static void v4l2_of_parse_csi_bus(const struct device_node *node,
> > - struct v4l2_of_endpoint *endpoint)
> > +static int v4l2_of_parse_csi_bus(const struct device_node *node,
> > +struct v4l2_of_endpoint *endpoint)
> > {
> > struct v4l2_of_bus_mipi_csi2 *bus = &endpoint->bus.mipi_csi2;
> > - u32 data_lanes[ARRAY_SIZE(bus->data_lanes)];
> > struct property *prop;
> > bool have_clk_lane = false;
> > unsigned int flags = 0;
> > @@ -32,16 +31,34 @@ static void v4l2_of_parse_csi_bus(const struct
> > device_node *node, prop = of_find_property(node, "data-lanes", NULL);
> > if (prop) {
> > const __be32 *lane = NULL;
> > - int i;
> > + unsigned int i;
> >
> > - for (i = 0; i < ARRAY_SIZE(data_lanes); i++) {
> > - lane = of_prop_next_u32(prop, lane, &data_lanes[i]);
> > + for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
> > + lane = of_prop_next_u32(prop, lane, &v);
> > if (!lane)
> > break;
> > + bus->data_lanes[i] = v;
> > }
> > bus->num_data_lanes = i;
> > - while (i--)
> > - bus->data_lanes[i] = data_lanes[i];
> > + }
> > +
> > + prop = of_find_property(node, "lane-polarity", NULL);
> > + if (prop) {
> > + const __be32 *polarity = NULL;
> > + unsigned int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(bus->lane_polarity); i++) {
> > + polarity = of_prop_next_u32(prop, polarity, &v);
> > + if (!polarity)
> > + break;
> > + bus->lane_polarity[i] = v;
> > + }
> > +
> > + if (i < 1 + bus->num_data_lanes /* clock + data */) {
> > + pr_warn("bad size of lane-polarity array in node %s,
> > was %u,
> should be
> > %u\n",
>
> How about
>
> pr_warn("%s: too few lane-polarity entries (need %u, got %u)\n",
> node->full_name, 1 + bus->num_data_lanes, i);
Fixed.
> > + node->full_name, i, 1 + bus->num_data_lanes);
> > + return -EINVAL;
> > + }
> > }
> >
> > if (!of_property_read_u32(node, "clock-lanes", &v)) {
> > @@ -56,6 +73,8 @@ static void v4l2_of_parse_csi_bus(const struct device_node
> > *node,
> >
> > bus->flags = flags;
> > endpoint->bus_type = V4L2_MBUS_CSI2;
> > +
> > + return 0;
> > }
> >
> > static void v4l2_of_parse_parallel_bus(const struct device_node *node,
> > @@ -127,11 +146,15 @@ static void v4l2_of_parse_parallel_bus(const struct
> > device_node *node, int v4l2_of_parse_endpoint(const struct device_node
> > *node,
> >struct v4l2_of_endpoint *endpoint)
> > {
> > + int rval;
> > +
> > of_graph_parse_endpoint(node, &endpoint->base);
> > endpoint->bus_type = 0;
> > memset(&endpoint->bus, 0, sizeof(endpoint->bus));
> >
> > - v4l2_of_parse_csi_bus(node, endpoint);
> > + rval = v4l2_of_parse_csi_bus(node, endpoint);
> > + if (rval)
> > + return rval;
> > /*
> > * Parse the parallel video bus properties only if none
> > * of the MIPI CSI-2 specific properties were found.
> > diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
> > index 70fa7b7..a70eb52 100644
> > --- a/include/media/v4l2-of.h
> > +++ b/include/media/v4l2-of.h
> > @@ -29,12 +29,15 @@ struct device_node;
> > * @data_lanes: an array of physical data lane indexes
> > * @clock_lane: physical lane index of the clock lane
> > * @num_data_lanes: number of data lanes
> > + * @lane_polarity: polarity of the lanes. The order is the same of
> > + *the physical lanes.
> > */
> > struct v4l2_of_bus_mipi_csi2 {
> > unsigned int flags;
> > unsigned char data_lanes[4];
> > unsigned
Re: [PATCH 10/10] mn88473: implement lock for all delivery systems
On 03/16/2015 11:44 PM, Antti Palosaari wrote: On 03/16/2015 11:47 PM, Antti Palosaari wrote: On 03/16/2015 12:57 AM, Benjamin Larsson wrote: Signed-off-by: Benjamin Larsson Applied. I found this does not work at least for DVB-C. After playing with modulator I find reg 0x85 on bank 1 is likely AGC. Its value is changed according to RF level even modulation itself is turned off. I will likely remove that patch... It is a bit hard to find out lock bits and it comes even harder without a modulator. Using typical tricks to plug and unplug antenna, while dumping register values out is error prone as you could not adjust signal strength nor change modulation parameters causing wrong decision easily. regards Antti Indeed the logic was inverted. Will respin the patch. MvH Benjamin Larsson -- 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: [RFC][PATCH] rtl2832: PID filter support for slave demod
On 03/17/2015 12:12 AM, Benjamin Larsson wrote: Is this structure ok for the slave pid implementation? Or should there be only one filters parameter? Will the overlaying pid filter framework properly "flush" the set pid filters ? Note that this code currently is only compile tested. I am fine with it. byw. Have you tested if your QAM256 (DVB-C or DVB-T2) stream is valid even without a PID filtering? IIRC mine stream is correct and PID filtering is not required (but surely it could be implemented if you wish). 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 10/10] mn88473: implement lock for all delivery systems
On 03/16/2015 11:47 PM, Antti Palosaari wrote:
On 03/16/2015 12:57 AM, Benjamin Larsson wrote:
Signed-off-by: Benjamin Larsson
Applied.
I found this does not work at least for DVB-C. After playing with
modulator I find reg 0x85 on bank 1 is likely AGC. Its value is changed
according to RF level even modulation itself is turned off.
I will likely remove that patch... It is a bit hard to find out lock
bits and it comes even harder without a modulator. Using typical tricks
to plug and unplug antenna, while dumping register values out is error
prone as you could not adjust signal strength nor change modulation
parameters causing wrong decision easily.
regards
Antti
Antti
---
drivers/staging/media/mn88473/mn88473.c | 50
+++--
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/mn88473/mn88473.c
b/drivers/staging/media/mn88473/mn88473.c
index a23e59e..ba39614 100644
--- a/drivers/staging/media/mn88473/mn88473.c
+++ b/drivers/staging/media/mn88473/mn88473.c
@@ -167,7 +167,10 @@ static int mn88473_read_status(struct
dvb_frontend *fe, fe_status_t *status)
{
struct i2c_client *client = fe->demodulator_priv;
struct mn88473_dev *dev = i2c_get_clientdata(client);
+struct dtv_frontend_properties *c = &fe->dtv_property_cache;
int ret;
+unsigned int utmp;
+int lock = 0;
*status = 0;
@@ -176,8 +179,51 @@ static int mn88473_read_status(struct
dvb_frontend *fe, fe_status_t *status)
goto err;
}
-*status = FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_VITERBI |
-FE_HAS_SYNC | FE_HAS_LOCK;
+switch (c->delivery_system) {
+case SYS_DVBT:
+ret = regmap_read(dev->regmap[0], 0x62, &utmp);
+if (ret)
+goto err;
+if (utmp & 0xA0) {
+if ((utmp & 0xF) >= 0x03)
+*status |= FE_HAS_SIGNAL;
+if ((utmp & 0xF) >= 0x09)
+lock = 1;
+}
+break;
+case SYS_DVBT2:
+ret = regmap_read(dev->regmap[2], 0x8B, &utmp);
+if (ret)
+goto err;
+if (utmp & 0x40) {
+if ((utmp & 0xF) >= 0x07)
+*status |= FE_HAS_SIGNAL;
+if ((utmp & 0xF) >= 0x0a)
+*status |= FE_HAS_CARRIER;
+if ((utmp & 0xF) >= 0x0d)
+*status |= FE_HAS_VITERBI | FE_HAS_SYNC | FE_HAS_LOCK;
+}
+break;
+case SYS_DVBC_ANNEX_A:
+ret = regmap_read(dev->regmap[1], 0x85, &utmp);
+if (ret)
+goto err;
+if (utmp & 0x40) {
+ret = regmap_read(dev->regmap[1], 0x89, &utmp);
+if (ret)
+goto err;
+if (utmp & 0x01)
+lock = 1;
+}
+break;
+default:
+ret = -EINVAL;
+goto err;
+}
+
+if (lock)
+*status = FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_VITERBI |
+FE_HAS_SYNC | FE_HAS_LOCK;
return 0;
err:
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH] rtl2832: PID filter support for slave demod
Is this structure ok for the slave pid implementation? Or should there
be only one filters parameter? Will the overlaying pid filter framework
properly "flush" the set pid filters ?
Note that this code currently is only compile tested.
MvH
Benjamin Larsson
>From 8efb26c18b4f9416bd516195c6a82853c924 Mon Sep 17 00:00:00 2001
From: Benjamin Larsson
Date: Mon, 16 Mar 2015 22:59:50 +0100
Subject: [PATCH] rtl2832: PID filter support for slave demod
Cc: Linux Media Mailing List
RTL2832p supports a slave configuration with a demodulator connected
to a ts input on the chip. This makes it possible to receive DVB-T2
muxes that are of larger size then what the rtl2832p usb-bridge is
capable of transfering.
Signed-off-by: Benjamin Larsson
---
drivers/media/dvb-frontends/rtl2832.c | 40 ++
drivers/media/dvb-frontends/rtl2832_priv.h | 2 ++
2 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.c b/drivers/media/dvb-frontends/rtl2832.c
index 5d2d8f4..3725211 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -488,6 +488,8 @@ static int rtl2832_set_frontend(struct dvb_frontend *fe)
if (ret)
goto err;
+ dev->slave_demod_active = 0;
+
/* If the frontend has get_if_frequency(), use it */
if (fe->ops.tuner_ops.get_if_frequency) {
u32 if_freq;
@@ -1114,6 +1116,8 @@ static int rtl2832_enable_slave_ts(struct i2c_client *client)
if (ret)
goto err;
+ dev->slave_demod_active = 1;
+
return 0;
err:
dev_dbg(&client->dev, "failed=%d\n", ret);
@@ -1135,7 +1139,10 @@ static int rtl2832_pid_filter_ctrl(struct dvb_frontend *fe, int onoff)
else
u8tmp = 0x00;
- ret = rtl2832_update_bits(client, 0x061, 0xc0, u8tmp);
+ if (dev->slave_demod_active)
+ ret = rtl2832_update_bits(client, 0x021, 0xc0, u8tmp);
+ else
+ ret = rtl2832_update_bits(client, 0x061, 0xc0, u8tmp);
if (ret)
goto err;
@@ -1152,6 +1159,7 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe, u8 index, u16 pid,
struct i2c_client *client = dev->client;
int ret;
u8 buf[4];
+ unsigned long* filters;
dev_dbg(&client->dev, "index=%d pid=%04x onoff=%d\n",
index, pid, onoff);
@@ -1160,24 +1168,36 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe, u8 index, u16 pid,
if (pid > 0x1fff || index > 32)
return 0;
- if (onoff)
- set_bit(index, &dev->filters);
+ if (dev->slave_demod_active)
+ filters = &dev->filters_slave;
else
- clear_bit(index, &dev->filters);
+ filters = &dev->filters;
+
+ if (onoff) {
+ set_bit(index, filters);
+ } else {
+ clear_bit(index, filters);
+ }
/* enable / disable PIDs */
- buf[0] = (dev->filters >> 0) & 0xff;
- buf[1] = (dev->filters >> 8) & 0xff;
- buf[2] = (dev->filters >> 16) & 0xff;
- buf[3] = (dev->filters >> 24) & 0xff;
- ret = rtl2832_bulk_write(client, 0x062, buf, 4);
+ buf[0] = (*filters >> 0) & 0xff;
+ buf[1] = (*filters >> 8) & 0xff;
+ buf[2] = (*filters >> 16) & 0xff;
+ buf[3] = (*filters >> 24) & 0xff;
+ if (dev->slave_demod_active)
+ ret = rtl2832_bulk_write(client, 0x022, buf, 4);
+ else
+ ret = rtl2832_bulk_write(client, 0x062, buf, 4);
if (ret)
goto err;
/* add PID */
buf[0] = (pid >> 8) & 0xff;
buf[1] = (pid >> 0) & 0xff;
- ret = rtl2832_bulk_write(client, 0x066 + 2 * index, buf, 2);
+ if (dev->slave_demod_active)
+ ret = rtl2832_bulk_write(client, 0x026 + 2 * index, buf, 2);
+ else
+ ret = rtl2832_bulk_write(client, 0x066 + 2 * index, buf, 2);
if (ret)
goto err;
diff --git a/drivers/media/dvb-frontends/rtl2832_priv.h b/drivers/media/dvb-frontends/rtl2832_priv.h
index c3a922c..b95a7b7 100644
--- a/drivers/media/dvb-frontends/rtl2832_priv.h
+++ b/drivers/media/dvb-frontends/rtl2832_priv.h
@@ -46,6 +46,8 @@ struct rtl2832_dev {
bool sleeping;
struct delayed_work i2c_gate_work;
unsigned long filters; /* PID filter */
+ unsigned long filters_slave; /* PID filter */
+ int slave_demod_active;
};
struct rtl2832_reg_entry {
--
2.1.0
Re: [PATCH 10/10] mn88473: implement lock for all delivery systems
On 03/16/2015 12:57 AM, Benjamin Larsson wrote:
Signed-off-by: Benjamin Larsson
Applied.
Antti
---
drivers/staging/media/mn88473/mn88473.c | 50 +++--
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/mn88473/mn88473.c
b/drivers/staging/media/mn88473/mn88473.c
index a23e59e..ba39614 100644
--- a/drivers/staging/media/mn88473/mn88473.c
+++ b/drivers/staging/media/mn88473/mn88473.c
@@ -167,7 +167,10 @@ static int mn88473_read_status(struct dvb_frontend *fe,
fe_status_t *status)
{
struct i2c_client *client = fe->demodulator_priv;
struct mn88473_dev *dev = i2c_get_clientdata(client);
+ struct dtv_frontend_properties *c = &fe->dtv_property_cache;
int ret;
+ unsigned int utmp;
+ int lock = 0;
*status = 0;
@@ -176,8 +179,51 @@ static int mn88473_read_status(struct dvb_frontend *fe,
fe_status_t *status)
goto err;
}
- *status = FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_VITERBI |
- FE_HAS_SYNC | FE_HAS_LOCK;
+ switch (c->delivery_system) {
+ case SYS_DVBT:
+ ret = regmap_read(dev->regmap[0], 0x62, &utmp);
+ if (ret)
+ goto err;
+ if (utmp & 0xA0) {
+ if ((utmp & 0xF) >= 0x03)
+ *status |= FE_HAS_SIGNAL;
+ if ((utmp & 0xF) >= 0x09)
+ lock = 1;
+ }
+ break;
+ case SYS_DVBT2:
+ ret = regmap_read(dev->regmap[2], 0x8B, &utmp);
+ if (ret)
+ goto err;
+ if (utmp & 0x40) {
+ if ((utmp & 0xF) >= 0x07)
+ *status |= FE_HAS_SIGNAL;
+ if ((utmp & 0xF) >= 0x0a)
+ *status |= FE_HAS_CARRIER;
+ if ((utmp & 0xF) >= 0x0d)
+ *status |= FE_HAS_VITERBI | FE_HAS_SYNC |
FE_HAS_LOCK;
+ }
+ break;
+ case SYS_DVBC_ANNEX_A:
+ ret = regmap_read(dev->regmap[1], 0x85, &utmp);
+ if (ret)
+ goto err;
+ if (utmp & 0x40) {
+ ret = regmap_read(dev->regmap[1], 0x89, &utmp);
+ if (ret)
+ goto err;
+ if (utmp & 0x01)
+ lock = 1;
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (lock)
+ *status = FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_VITERBI |
+ FE_HAS_SYNC | FE_HAS_LOCK;
return 0;
err:
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] mn88472: check if firmware is already running before loading it
On 03/16/2015 12:57 AM, Benjamin Larsson wrote:
Signed-off-by: Benjamin Larsson
Applied! Please try to add some commit message, even patch topic says it
all...
regards
Antti
---
drivers/staging/media/mn88472/mn88472.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/media/mn88472/mn88472.c
b/drivers/staging/media/mn88472/mn88472.c
index 4a00a4d..c041fbf 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -258,7 +258,7 @@ static int mn88472_init(struct dvb_frontend *fe)
int ret, len, remaining;
const struct firmware *fw = NULL;
u8 *fw_file = MN88472_FIRMWARE;
- unsigned int csum;
+ unsigned int tmp;
dev_dbg(&client->dev, "\n");
@@ -274,6 +274,17 @@ static int mn88472_init(struct dvb_frontend *fe)
if (ret)
goto err;
+ /* check if firmware is already running */
+ ret = regmap_read(dev->regmap[0], 0xf5, &tmp);
+ if (ret)
+ goto err;
+
+ if (!(tmp & 0x1)) {
+ dev_info(&client->dev, "firmware already running\n");
+ dev->warm = true;
+ return 0;
+ }
+
/* request the firmware, this will block and timeout */
ret = request_firmware(&fw, fw_file, &client->dev);
if (ret) {
@@ -305,18 +316,18 @@ static int mn88472_init(struct dvb_frontend *fe)
}
/* parity check of firmware */
- ret = regmap_read(dev->regmap[0], 0xf8, &csum);
+ ret = regmap_read(dev->regmap[0], 0xf8, &tmp);
if (ret) {
dev_err(&client->dev,
"parity reg read failed=%d\n", ret);
goto err;
}
- if (csum & 0x10) {
+ if (tmp & 0x10) {
dev_err(&client->dev,
- "firmware parity check failed=0x%x\n", csum);
+ "firmware parity check failed=0x%x\n", tmp);
goto err;
}
- dev_err(&client->dev, "firmware parity check succeeded=0x%x\n", csum);
+ dev_err(&client->dev, "firmware parity check succeeded=0x%x\n", tmp);
ret = regmap_write(dev->regmap[0], 0xf5, 0x00);
if (ret)
--
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 08/10] mn88473: check if firmware is already running before loading it
On 03/16/2015 12:57 AM, Benjamin Larsson wrote:
Signed-off-by: Benjamin Larsson
Applied!
Antti
---
drivers/staging/media/mn88473/mn88473.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/mn88473/mn88473.c
b/drivers/staging/media/mn88473/mn88473.c
index 607ce4d..a23e59e 100644
--- a/drivers/staging/media/mn88473/mn88473.c
+++ b/drivers/staging/media/mn88473/mn88473.c
@@ -196,8 +196,19 @@ static int mn88473_init(struct dvb_frontend *fe)
dev_dbg(&client->dev, "\n");
- if (dev->warm)
+ /* set cold state by default */
+ dev->warm = false;
+
+ /* check if firmware is already running */
+ ret = regmap_read(dev->regmap[0], 0xf5, &tmp);
+ if (ret)
+ goto err;
+
+ if (!(tmp & 0x1)) {
+ dev_info(&client->dev, "firmware already running\n");
+ dev->warm = true;
return 0;
+ }
/* request the firmware, this will block and timeout */
ret = request_firmware(&fw, fw_file, &client->dev);
--
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 08/10] mn88473: check if firmware is already running before loading it
On 03/16/2015 12:57 AM, Benjamin Larsson wrote:
Signed-off-by: Benjamin Larsson
Applied!
Antti
---
drivers/staging/media/mn88473/mn88473.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/mn88473/mn88473.c
b/drivers/staging/media/mn88473/mn88473.c
index 607ce4d..a23e59e 100644
--- a/drivers/staging/media/mn88473/mn88473.c
+++ b/drivers/staging/media/mn88473/mn88473.c
@@ -196,8 +196,19 @@ static int mn88473_init(struct dvb_frontend *fe)
dev_dbg(&client->dev, "\n");
- if (dev->warm)
+ /* set cold state by default */
+ dev->warm = false;
+
+ /* check if firmware is already running */
+ ret = regmap_read(dev->regmap[0], 0xf5, &tmp);
+ if (ret)
+ goto err;
+
+ if (!(tmp & 0x1)) {
+ dev_info(&client->dev, "firmware already running\n");
+ dev->warm = true;
return 0;
+ }
/* request the firmware, this will block and timeout */
ret = request_firmware(&fw, fw_file, &client->dev);
--
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
/dev/dvb not being creating when driver are loaded
Hi. I just installed a clean Debian Testing box and am having a problem. When I load dvb drivers, /dev/dvb is not being created. I don't know if this is a dvb issue, udev, or what. I have other boxes also running Debian Testing, all using current packages & the same versions of everything as this new install, and /dev/dvb is created just fine when I load drivers of them. The only difference between those boxes and the new one that I can tell is the new one uses systemd while the others use sysvinit. I installed sysvinit and then uninstalled systemd, did an upgrade-grub, and then reboot but /dev/dvb still isn't being created so I don't think the problem is with systemd. Also, none of the working boxes have any special udev files/rules that I've found so it's probably safe to eliminate the need for specific/special udev rules as well. Anyone have any clue about this? Thanks -- 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/10] mn88473: implement firmware parity check
On 03/16/2015 12:57 AM, Benjamin Larsson wrote:
Signed-off-by: Benjamin Larsson
Applied with same comments that mn88472 patch.
regards
Antti
---
drivers/staging/media/mn88473/mn88473.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/staging/media/mn88473/mn88473.c
b/drivers/staging/media/mn88473/mn88473.c
index 84bd4fa..607ce4d 100644
--- a/drivers/staging/media/mn88473/mn88473.c
+++ b/drivers/staging/media/mn88473/mn88473.c
@@ -192,6 +192,7 @@ static int mn88473_init(struct dvb_frontend *fe)
int ret, len, remaining;
const struct firmware *fw = NULL;
u8 *fw_file = MN88473_FIRMWARE;
+ unsigned int tmp;
dev_dbg(&client->dev, "\n");
@@ -227,6 +228,20 @@ static int mn88473_init(struct dvb_frontend *fe)
}
}
+ /* parity check of firmware */
+ ret = regmap_read(dev->regmap[0], 0xf8, &tmp);
+ if (ret) {
+ dev_err(&client->dev,
+ "parity reg read failed=%d\n", ret);
+ goto err;
+ }
+ if (tmp & 0x10) {
+ dev_err(&client->dev,
+ "firmware parity check failed=0x%x\n", tmp);
+ goto err;
+ }
+ dev_err(&client->dev, "firmware parity check succeeded=0x%x\n", tmp);
+
ret = regmap_write(dev->regmap[0], 0xf5, 0x00);
if (ret)
goto err;
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] mn88472: implement firmware parity check
On 03/16/2015 12:57 AM, Benjamin Larsson wrote:
Signed-off-by: Benjamin Larsson
Reviewed-by: Antti Palosaari
Signed-off-by: Antti Palosaari
Applied!
Please don't use dev_err() logging for nothing but errors. That last
logging should be dev_dbg(), but as this is staging driver and features
really rule over minor issues I will simply apply that and fix minor
issues later.
regards
Antti
---
drivers/staging/media/mn88472/mn88472.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/staging/media/mn88472/mn88472.c
b/drivers/staging/media/mn88472/mn88472.c
index 5070c37..4a00a4d 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -258,6 +258,7 @@ static int mn88472_init(struct dvb_frontend *fe)
int ret, len, remaining;
const struct firmware *fw = NULL;
u8 *fw_file = MN88472_FIRMWARE;
+ unsigned int csum;
dev_dbg(&client->dev, "\n");
@@ -303,6 +304,20 @@ static int mn88472_init(struct dvb_frontend *fe)
}
}
+ /* parity check of firmware */
+ ret = regmap_read(dev->regmap[0], 0xf8, &csum);
+ if (ret) {
+ dev_err(&client->dev,
+ "parity reg read failed=%d\n", ret);
+ goto err;
+ }
+ if (csum & 0x10) {
+ dev_err(&client->dev,
+ "firmware parity check failed=0x%x\n", csum);
+ goto err;
+ }
+ dev_err(&client->dev, "firmware parity check succeeded=0x%x\n", csum);
+
ret = regmap_write(dev->regmap[0], 0xf5, 0x00);
if (ret)
goto err;
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] mn88472: implement lock for all delivery systems
On 03/16/2015 12:57 AM, Benjamin Larsson wrote:
The increase of the lock timeout is needed for dvb-t2.
Signed-off-by: Benjamin Larsson
Applied!
regards
Antti
---
drivers/staging/media/mn88472/mn88472.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/mn88472/mn88472.c
b/drivers/staging/media/mn88472/mn88472.c
index 6eebe56..5070c37 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -19,7 +19,7 @@
static int mn88472_get_tune_settings(struct dvb_frontend *fe,
struct dvb_frontend_tune_settings *s)
{
- s->min_delay_ms = 400;
+ s->min_delay_ms = 800;
return 0;
}
@@ -201,6 +201,7 @@ static int mn88472_read_status(struct dvb_frontend *fe,
fe_status_t *status)
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
int ret;
unsigned int utmp;
+ int lock = 0;
*status = 0;
@@ -211,21 +212,36 @@ static int mn88472_read_status(struct dvb_frontend *fe,
fe_status_t *status)
switch (c->delivery_system) {
case SYS_DVBT:
+ ret = regmap_read(dev->regmap[0], 0x7F, &utmp);
+ if (ret)
+ goto err;
+ if ((utmp & 0xF) >= 0x09)
+ lock = 1;
+ break;
case SYS_DVBT2:
- /* FIXME: implement me */
- utmp = 0x08; /* DVB-C lock value */
+ ret = regmap_read(dev->regmap[2], 0x92, &utmp);
+ if (ret)
+ goto err;
+ if ((utmp & 0xF) >= 0x07)
+ *status |= FE_HAS_SIGNAL;
+ if ((utmp & 0xF) >= 0x0a)
+ *status |= FE_HAS_CARRIER;
+ if ((utmp & 0xF) >= 0x0d)
+ *status |= FE_HAS_VITERBI | FE_HAS_SYNC | FE_HAS_LOCK;
break;
case SYS_DVBC_ANNEX_A:
ret = regmap_read(dev->regmap[1], 0x84, &utmp);
if (ret)
goto err;
+ if ((utmp & 0xF) >= 0x08)
+ lock = 1;
break;
default:
ret = -EINVAL;
goto err;
}
- if (utmp == 0x08)
+ if (lock)
*status = FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_VITERBI |
FE_HAS_SYNC | FE_HAS_LOCK;
--
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 03/10] rtl28xxu: lower the rc poll time to mitigate i2c transfer errors
On 03/16/2015 12:57 AM, Benjamin Larsson wrote: The Astrometa device has issues with i2c transfers. Lowering the poll time somehow makes these errors disappear. Signed-off-by: Benjamin Larsson Applied! Antti --- drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c index 77dcfdf..ea75b3a 100644 --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c @@ -1611,7 +1611,7 @@ static int rtl2832u_get_rc_config(struct dvb_usb_device *d, rc->allowed_protos = RC_BIT_ALL; rc->driver_type = RC_DRIVER_IR_RAW; rc->query = rtl2832u_rc_query; - rc->interval = 400; + rc->interval = 200; return 0; } -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] r820t: change read_gain() code to match register layout
On 03/16/2015 12:57 AM, Benjamin Larsson wrote: Signed-off-by: Benjamin Larsson Looks correct, I will apply it. That routine is used to estimate signal strength only. regards Antti --- drivers/media/tuners/r820t.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c index 639c220..eaaf1dc 100644 --- a/drivers/media/tuners/r820t.c +++ b/drivers/media/tuners/r820t.c @@ -1199,7 +1199,7 @@ static int r820t_read_gain(struct r820t_priv *priv) if (rc < 0) return rc; - return ((data[3] & 0x0f) << 1) + ((data[3] & 0xf0) >> 4); + return ((data[3] & 0x08) << 1) + ((data[3] & 0xf0) >> 4); } #if 0 -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] rtl28xxu: swap frontend order for slave demods
On 03/16/2015 10:04 PM, Antti Palosaari wrote: On 03/16/2015 10:44 PM, Benjamin Larsson wrote: On 03/15/2015 11:57 PM, Benjamin Larsson wrote: Some devices have 2 demodulators, when this is the case make the slave demod be listed first. Enumerating the slave first will help legacy applications to use the hardware. Ignore this patch for now. Stuff gets broken if applied. I will not apply it even you fix it. I don't like idea adding such hack to kernel in order to workaround buggy applications. There is many older devices having similar situation, having 2 demods - one for DVB-T and one for DVB-C. So there has been surely enough time for app developers to add support for multiple frontends... laziness. Quite same happened for DVB-T2 support. I added initially hack for CXD2820R driver in order to support DVB-T2 even applications are not supporting it. That was implemented using trick driver did DVB-T2 tune when DVB-T tune fails. After many years I did another DVB-T2 driver Si2168 and didn't add such hack anymore. And what was result; almost all applications were still lacking proper DVB-T2 support, after many many years... So I will never ever add any hacks to driver to workaround application support as application developers are so lazy to add support or new things if there is some workaround available. regards Antti While I agree with your reasoning, the point with this patch is just to register one demod before another. If that is a hack or not I don't know. I have used it locally for test purposes and it is not needed for actual use so consider the patch withdrawn. MvH Benjamin Larsson -- 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/10] r820t: add DVBC profile in sysfreq_sel
On 03/16/2015 12:57 AM, Benjamin Larsson wrote: This will make the Astrometa DVB-T/T2/C usb stick be able to pick up muxes around 290-314 MHz. Signed-off-by: Benjamin Larsson Looks correct. I added initially DVB-C support for that driver, but I forget to add this. After looking the driver I realized there was 2 places to add standard specific configurations - and I added only one place. I will apply that to my tree. regards Antti --- drivers/media/tuners/r820t.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c index 8e040cf..639c220 100644 --- a/drivers/media/tuners/r820t.c +++ b/drivers/media/tuners/r820t.c @@ -775,6 +775,19 @@ static int r820t_sysfreq_sel(struct r820t_priv *priv, u32 freq, div_buf_cur = 0x30; /* 11, 150u */ filter_cur = 0x40; /* 10, low */ break; + case SYS_DVBC_ANNEX_A: + mixer_top = 0x24; /* mixer top:13 , top-1, low-discharge */ + lna_top = 0xe5; + lna_vth_l = 0x62; + mixer_vth_l = 0x75; + air_cable1_in = 0x60; + cable2_in = 0x00; + pre_dect = 0x40; + lna_discharge = 14; + cp_cur = 0x38; /* 111, auto */ + div_buf_cur = 0x30; /* 11, 150u */ + filter_cur = 0x40; /* 10, low */ + break; default: /* DVB-T 8M */ mixer_top = 0x24; /* mixer top:13 , top-1, low-discharge */ lna_top = 0xe5; /* detect bw 3, lna top:4, predet top:2 */ -- 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 04/10] rtl28xxu: swap frontend order for slave demods
On 03/16/2015 10:44 PM, Benjamin Larsson wrote: On 03/15/2015 11:57 PM, Benjamin Larsson wrote: Some devices have 2 demodulators, when this is the case make the slave demod be listed first. Enumerating the slave first will help legacy applications to use the hardware. Ignore this patch for now. Stuff gets broken if applied. I will not apply it even you fix it. I don't like idea adding such hack to kernel in order to workaround buggy applications. There is many older devices having similar situation, having 2 demods - one for DVB-T and one for DVB-C. So there has been surely enough time for app developers to add support for multiple frontends... laziness. Quite same happened for DVB-T2 support. I added initially hack for CXD2820R driver in order to support DVB-T2 even applications are not supporting it. That was implemented using trick driver did DVB-T2 tune when DVB-T tune fails. After many years I did another DVB-T2 driver Si2168 and didn't add such hack anymore. And what was result; almost all applications were still lacking proper DVB-T2 support, after many many years... So I will never ever add any hacks to driver to workaround application support as application developers are so lazy to add support or new things if there is some workaround available. 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: rt-mutex usage in i2c
On 03/15/2015 08:07 AM, Mike Rapoport wrote:
> On Sat, Mar 14, 2015 at 1:32 PM, Wolfram Sang wrote:
>> On Sat, Mar 14, 2015 at 12:27:03PM +0100, Wolfram Sang wrote:
>>> Hi Sebastian,
>>>
- i2c_transfer() has this piece:
2091 if (in_atomic() || irqs_disabled()) {
2092 ret = i2c_trylock_adapter(adap);
is this irqs_disabled() is what bothers me and should not be there.
pxa does a spin_lock_irq() which would enable interrupts on return /
too early.
mxs has a wait_for_completion() which needs irqs enabled _and_ makes
in_atomic() problematic, too. I have't checked other drivers but the
commit, that introduced it, does not explain why it is required.
>
> That was some time ago, but as far as I remember, PIO in i2c_pxa was
> required to enable communication with PMIC in interrupt context.
Let me add one thing I forgot: the locking is using raw locks which are
not irq safe. It usually works. But. If the wait_lock is hold during
the unlock's slow path (that means there is no owner but the owner
field is not yet NULL) and the interrupt handler gets here with a
try_lock attempt then and it will spin forever on the wait_lock.
I will try to lookup the threads later…
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: [PATCH 04/10] rtl28xxu: swap frontend order for slave demods
On 03/15/2015 11:57 PM, Benjamin Larsson wrote: Some devices have 2 demodulators, when this is the case make the slave demod be listed first. Enumerating the slave first will help legacy applications to use the hardware. Ignore this patch for now. Stuff gets broken if applied. /Benjamin -- 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 23/35 linux-next] [media] constify of_device_id array
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick
---
drivers/media/i2c/adv7604.c | 2 +-
drivers/media/platform/fsl-viu.c | 2 +-
drivers/media/platform/soc_camera/rcar_vin.c | 2 +-
drivers/media/rc/gpio-ir-recv.c | 2 +-
drivers/media/rc/ir-hix5hd2.c| 2 +-
drivers/media/rc/st_rc.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d228b7c..5a7c938 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2598,7 +2598,7 @@ static struct i2c_device_id adv7604_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
-static struct of_device_id adv7604_of_id[] __maybe_unused = {
+static const struct of_device_id adv7604_of_id[] __maybe_unused = {
{ .compatible = "adi,adv7611", .data = &adv7604_chip_info[ADV7611] },
{ }
};
diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index bbf4281..5b76e3d 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -1664,7 +1664,7 @@ static int viu_resume(struct platform_device *op)
/*
* Initialization and module stuff
*/
-static struct of_device_id mpc512x_viu_of_match[] = {
+static const struct of_device_id mpc512x_viu_of_match[] = {
{
.compatible = "fsl,mpc5121-viu",
},
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 279ab9f..bbbaa0a 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1818,7 +1818,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
};
#ifdef CONFIG_OF
-static struct of_device_id rcar_vin_of_table[] = {
+static const struct of_device_id rcar_vin_of_table[] = {
{ .compatible = "renesas,vin-r8a7794", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,vin-r8a7793", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,vin-r8a7791", .data = (void *)RCAR_GEN2 },
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 229853d..707df54 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -59,7 +59,7 @@ static int gpio_ir_recv_get_devtree_pdata(struct device *dev,
return 0;
}
-static struct of_device_id gpio_ir_recv_of_match[] = {
+static const struct of_device_id gpio_ir_recv_of_match[] = {
{ .compatible = "gpio-ir-receiver", },
{ },
};
diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
index b0df629..0a11d55 100644
--- a/drivers/media/rc/ir-hix5hd2.c
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -327,7 +327,7 @@ static int hix5hd2_ir_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(hix5hd2_ir_pm_ops, hix5hd2_ir_suspend,
hix5hd2_ir_resume);
-static struct of_device_id hix5hd2_ir_table[] = {
+static const struct of_device_id hix5hd2_ir_table[] = {
{ .compatible = "hisilicon,hix5hd2-ir", },
{},
};
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 0e758ae..50ea09d 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -381,7 +381,7 @@ static int st_rc_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(st_rc_pm_ops, st_rc_suspend, st_rc_resume);
#ifdef CONFIG_OF
-static struct of_device_id st_rc_match[] = {
+static const struct of_device_id st_rc_match[] = {
{ .compatible = "st,comms-irb", },
{},
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dynamic video input/output list
On 03/16/2015 07:01 PM, Devin Heitmueller wrote: >> I'm looking to enhance video input/output enumeration support in >> GStreamer using VIDIOC_ENUMINPUT/VIDIOC_ENUMOUTPUT ioctls and after some >> discussions we wonder if the input/output list can change dynamically at >> runtime or not. >> >> So, is v4l2 allow this input/output list to be dynamic ? > > I sure how the spec allows it, because I've done it in the past. Just because you can do something doesn't mean the spec allows it :-) In this particular case nobody ever thought about whether this could change dynamically so the spec never talks about it. But at the moment it is definitely not allowed, even though the spec doesn't explicitly forbid it. All applications expect that the list of inputs/outputs is fixed. The spec could be extended to allow this, but then there also should be a new event introduced that the application can receive if the list changes so it can update the list. But frankly, I would prefer to always expose all possible inputs, including those of an optional onboard header, and if nothing is connected just mark those inputs as having status V4L2_IN_ST_NO_POWER. Note however that it is perfectly fine if the driver detects the presence of such an onboard header when it is loaded and then only exposes those extra inputs if the header is present. It just can't change the list later unless do you an rmmod and modprobe of the driver. It's probably what you do anyway. Regards, Hans > I have cards which have an onboard header for external A/V inputs, and I > am able to tell if the breakout cable is attached due to a dedicated > pin tied to a GPIO. Thus, I am able to dictate whether the card has > the A/V breakout cable attached and thus whether to expose only the > first input or all three inputs. > > That said, in this case the inputs in the list never moved around > because the optional entries were at the end of the list - the list > just got longer if those inputs were available. I'm not sure what > would happen if you had a configuration where you needed to remove > entries other than those at the end of the list. For example, if you > had a card with four possible inputs and you removed input 2, does the > list stay the same length and input 2 is now marked as invalid, or > does the length of the list become 3 and inputs 3 and 4 turn into > inputs 2 and 3? > > Devin > -- 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 v6] media: i2c: add support for omnivision's ov2659 sensor
Hi Hans,
Thanks for the review.
On Mon, Mar 16, 2015 at 9:24 AM, Hans Verkuil wrote:
> Hi Prabhakar,
>
> On 03/15/2015 11:34 AM, Lad Prabhakar wrote:
>> From: Benoit Parrot
>>
>> this patch adds support for omnivision's ov2659
>> sensor, the driver supports following features:
>> 1: Asynchronous probing
>> 2: DT support
>> 3: Media controller support
>>
>> Signed-off-by: Benoit Parrot
>> Signed-off-by: Lad, Prabhakar
>> Acked-by: Sakari Ailus
>> ---
>> Changes for v6:
>> a: fixed V4L2_CID_PIXEL_RATE control to use link_frequency
>> instead of xvclk_frequency.
>> b: Included Ack from Sakari
>>
>> v5: https://patchwork.kernel.org/patch/6000161/
>> v4: https://patchwork.kernel.org/patch/5961661/
>> v3: https://patchwork.kernel.org/patch/5959401/
>> v2: https://patchwork.kernel.org/patch/5859801/
>> v1: https://patchwork.linuxtv.org/patch/27919/
>>
>> .../devicetree/bindings/media/i2c/ov2659.txt | 38 +
>> MAINTAINERS| 10 +
>> drivers/media/i2c/Kconfig | 11 +
>> drivers/media/i2c/Makefile |1 +
>> drivers/media/i2c/ov2659.c | 1510
>>
>> include/media/ov2659.h | 33 +
>> 6 files changed, 1603 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2659.txt
>> create mode 100644 drivers/media/i2c/ov2659.c
>> create mode 100644 include/media/ov2659.h
>>
>> diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
>> new file mode 100644
>> index 000..3ae6629
>> --- /dev/null
>> +++ b/drivers/media/i2c/ov2659.c
>
>
>
>> +static const struct ov2659_pixfmt ov2659_formats[] = {
>> + {
>> + .code = MEDIA_BUS_FMT_YUYV8_2X8,
>> + .colorspace = V4L2_COLORSPACE_JPEG,
>> + .format_ctrl_regs = ov2659_format_yuyv,
>> + },
>> + {
>> + .code = MEDIA_BUS_FMT_UYVY8_2X8,
>> + .colorspace = V4L2_COLORSPACE_JPEG,
>> + .format_ctrl_regs = ov2659_format_uyvy,
>> + },
>> + {
>> + .code = MEDIA_BUS_FMT_RGB565_2X8_BE,
>> + .colorspace = V4L2_COLORSPACE_JPEG,
>> + .format_ctrl_regs = ov2659_format_rgb565,
>> + },
>> + {
>> + .code = MEDIA_BUS_FMT_SBGGR8_1X8,
>> + .colorspace = V4L2_COLORSPACE_SMPTE170M,
>> + .format_ctrl_regs = ov2659_format_bggr,
>> + },
>> +};
>
> The colorspaces defined here make no sense. Sensors should give you
> V4L2_COLORSPACE_SRGB. Certainly not COLORSPACE_JPEG (unless they encode
> to a JPEG for you) and SMPTE170M (SDTV) is unlikely as well, unless the
> documentation explicitly states that it uses that colorspace.
>
> Unfortunately, the product brief of this sensor does not mention the
> colorimetry information at all, nor does it give any information about
> the transfer function (aka gamma) used by the sensor. Since this sensor
> is advertised as an HDTV sensor I would guess the colorspace should either
> be SRGB or REC709, depending on the transfer function used.
>
Yes it needs to be V4L2_COLORSPACE_SRGB, Ill respin fixing this.
Cheers,
--Prabhakar Lad
> I see a lot of sensor drivers that wrongly use the JPEG colorspace. I'm
> planning
> to fix them, since that is really wrong.
>
> Regards,
>
> Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/35 linux-next] constify of_device_id array
This small patchset adds const to of_device_id arrays in drivers branch. Fabian Frederick (35): ata: constify of_device_id array regulator: constify of_device_id array thermal: constify of_device_id array tty/hvc_opal: constify of_device_id array tty: constify of_device_id array power: constify of_device_id array char: constify of_device_id array dma: constify of_device_id array iio: constify of_device_id array misc: constify of_device_id array usb: gadget: constify of_device_id array mtd: constify of_device_id array w1: constify of_device_id array ide: pmac: constify of_device_id array spi: constify of_device_id array video: constify of_device_id array coresight-replicator: constify of_device_id array macintosh: constify of_device_id array virtio_mmio: constify of_device_id array swim3: constify of_device_id array mfd: constify of_device_id array soc: ti: constify of_device_id array [media]: constify of_device_id array Input: constify of_device_id array PCI: constify of_device_id array hwmon: constify of_device_id array reset: sti: constify of_device_id array uio: constify of_device_id array gpu: constify of_device_id array devfreq: constify of_device_id array EDAC: constify of_device_id array clk: constify of_device_id array mmc: constify of_device_id array Staging: octeon: constify of_device_id array pinctrl: constify of_device_id array drivers/ata/pata_macio.c | 2 +- drivers/ata/pata_mpc52xx.c | 2 +- drivers/ata/pata_octeon_cf.c | 2 +- drivers/ata/pata_of_platform.c | 2 +- drivers/ata/sata_fsl.c | 2 +- drivers/ata/sata_mv.c| 2 +- drivers/ata/sata_rcar.c | 2 +- drivers/block/swim3.c| 2 +- drivers/char/hw_random/pasemi-rng.c | 2 +- drivers/char/hw_random/powernv-rng.c | 2 +- drivers/char/hw_random/ppc4xx-rng.c | 2 +- drivers/char/ipmi/ipmi_si_intf.c | 4 ++-- drivers/char/xillybus/xillybus_of.c | 2 +- drivers/clk/clk-palmas.c | 2 +- drivers/clk/st/clkgen-fsyn.c | 2 +- drivers/clk/st/clkgen-mux.c | 8 drivers/clk/st/clkgen-pll.c | 4 ++-- drivers/clk/ti/clk-dra7-atl.c| 2 +- drivers/clk/ti/clockdomain.c | 2 +- drivers/clk/versatile/clk-vexpress-osc.c | 2 +- drivers/coresight/coresight-replicator.c | 2 +- drivers/devfreq/event/exynos-ppmu.c | 2 +- drivers/devfreq/tegra-devfreq.c | 2 +- drivers/dma/bestcomm/bestcomm.c | 4 ++-- drivers/dma/k3dma.c | 2 +- drivers/dma/mmp_pdma.c | 2 +- drivers/dma/mmp_tdma.c | 2 +- drivers/dma/mpc512x_dma.c| 2 +- drivers/dma/mv_xor.c | 2 +- drivers/dma/sirf-dma.c | 2 +- drivers/dma/sun6i-dma.c | 2 +- drivers/edac/highbank_mc_edac.c | 2 +- drivers/edac/mpc85xx_edac.c | 4 ++-- drivers/edac/ppc4xx_edac.c | 2 +- drivers/edac/synopsys_edac.c | 2 +- drivers/gpio/gpio-mpc8xxx.c | 2 +- drivers/gpio/gpio-octeon.c | 2 +- drivers/gpio/gpio-tz1090-pdc.c | 2 +- drivers/gpio/gpio-tz1090.c | 2 +- drivers/gpio/gpio-zynq.c | 2 +- drivers/gpu/drm/armada/armada_crtc.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/exynos/exynos_mixer.c| 2 +- drivers/gpu/drm/panel/panel-ld9040.c | 2 +- drivers/gpu/drm/panel/panel-s6e8aa0.c| 2 +- drivers/gpu/drm/sti/sti_dvo.c| 2 +- drivers/gpu/drm/sti/sti_hqvdp.c | 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- drivers/gpu/drm/tilcdc/tilcdc_panel.c| 2 +- drivers/gpu/drm/tilcdc/tilcdc_slave.c| 4 ++-- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 4 ++-- drivers/gpu/host1x/dev.c | 2 +- drivers/gpu/host1x/mipi.c| 2 +- drivers/hwmon/pwm-fan.c | 2 +- drivers/hwmon/vexpress.c | 2 +- drivers/ide/pmac.c | 2 +- drivers/iio/common/ssp_sensors/ssp_dev.c | 2 +- drivers/input/misc/palmas-pwrbutton.c| 2 +- drivers/input/misc/regulator-haptic.c| 2 +- drivers/input/misc/tps65218-pwrbutton.c | 2 +- drivers/input/touchscreen/ar1021_i2c.c | 2 +- drivers/macintosh/mediabay.c | 2 +- drivers/macintosh/rack-meter.c | 2 +- drivers/media/i2c/adv7604.c | 2 +- drivers/media/platform/fsl-viu.c | 2 +- drivers/media/platform/soc_camera/rcar_vin.c |
Re: Dynamic video input/output list
> I'm looking to enhance video input/output enumeration support in > GStreamer using VIDIOC_ENUMINPUT/VIDIOC_ENUMOUTPUT ioctls and after some > discussions we wonder if the input/output list can change dynamically at > runtime or not. > > So, is v4l2 allow this input/output list to be dynamic ? I sure how the spec allows it, because I've done it in the past. I have cards which have an onboard header for external A/V inputs, and I am able to tell if the breakout cable is attached due to a dedicated pin tied to a GPIO. Thus, I am able to dictate whether the card has the A/V breakout cable attached and thus whether to expose only the first input or all three inputs. That said, in this case the inputs in the list never moved around because the optional entries were at the end of the list - the list just got longer if those inputs were available. I'm not sure what would happen if you had a configuration where you needed to remove entries other than those at the end of the list. For example, if you had a card with four possible inputs and you removed input 2, does the list stay the same length and input 2 is now marked as invalid, or does the length of the list become 3 and inputs 3 and 4 turn into inputs 2 and 3? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dynamic video input/output list
Hi everyone, I'm looking to enhance video input/output enumeration support in GStreamer using VIDIOC_ENUMINPUT/VIDIOC_ENUMOUTPUT ioctls and after some discussions we wonder if the input/output list can change dynamically at runtime or not. So, is v4l2 allow this input/output list to be dynamic ? Cheers -- Aurélien Zanelli -- 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: [PATCHv2 3/3] dw2102: TechnoTrend TT-connect S2-4600 DVB-S/S2 tuner
On 03/16/2015 07:22 PM, Olli Salonen wrote: TechnoTrend TT-connect S2-4600 is a USB2.0 DVB-S/S2 tuner using the popular Montage M88DS3103/M88TS2022 demod/tuner. The demodulator needs a firmware. Antti posted a firmware when releasing support for PCTV 461e, available here: http://palosaari.fi/linux/v4l-dvb/firmware/M88DS3103/ Patch v2: removed one unnecessary debug printout. Signed-off-by: Olli Salonen Reviewed-by: Antti Palosaari 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 2/3] dw2102: store i2c client for tuner into dw2102_state
On 03/16/2015 07:14 PM, Olli Salonen wrote: Prepare the dw2102 driver for tuner drivers that are implemented as I2C drivers (such as m88ts2022). The I2C client is stored in to the state and released at disconnect. Signed-off-by: Olli Salonen Reviewed-by: Antti Palosaari 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 1/3] dw2102: combine su3000_state and s6x0_state into dw2102_state
On 03/16/2015 07:14 PM, Olli Salonen wrote: Two separate state structs are defined for different devices inside the dw2102. Combine them, as both only contain one element. This will also make it easier to implement the next patch in the patch series. Signed-off-by: Olli Salonen Reviewed-by: Antti Palosaari 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
[PATCHv2 3/3] dw2102: TechnoTrend TT-connect S2-4600 DVB-S/S2 tuner
TechnoTrend TT-connect S2-4600 is a USB2.0 DVB-S/S2 tuner using the popular
Montage M88DS3103/M88TS2022 demod/tuner.
The demodulator needs a firmware. Antti posted a firmware when releasing
support for PCTV 461e, available here:
http://palosaari.fi/linux/v4l-dvb/firmware/M88DS3103/
Patch v2: removed one unnecessary debug printout.
Signed-off-by: Olli Salonen
---
drivers/media/dvb-core/dvb-usb-ids.h | 1 +
drivers/media/usb/dvb-usb/Kconfig| 6 +-
drivers/media/usb/dvb-usb/dw2102.c | 158 ++-
3 files changed, 161 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 80ab8d0..c6de073 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -245,6 +245,7 @@
#define USB_PID_TECHNOTREND_CONNECT_S2400 0x3006
#define USB_PID_TECHNOTREND_CONNECT_S2400_8KEEPROM 0x3009
#define USB_PID_TECHNOTREND_CONNECT_CT3650 0x300d
+#define USB_PID_TECHNOTREND_CONNECT_S2_4600 0x3011
#define USB_PID_TECHNOTREND_CONNECT_CT2_4650_CI0x3012
#define USB_PID_TECHNOTREND_TVSTICK_CT2_4400 0x3014
#define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY 0x005a
diff --git a/drivers/media/usb/dvb-usb/Kconfig
b/drivers/media/usb/dvb-usb/Kconfig
index 3364200..def1e06 100644
--- a/drivers/media/usb/dvb-usb/Kconfig
+++ b/drivers/media/usb/dvb-usb/Kconfig
@@ -278,9 +278,11 @@ config DVB_USB_DW2102
select DVB_STV6110 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0900 if MEDIA_SUBDRV_AUTOSELECT
select DVB_M88RS2000 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
+ select MEDIA_TUNER_TS2022 if MEDIA_SUBDRV_AUTOSELECT
help
- Say Y here to support the DvbWorld, TeVii, Prof DVB-S/S2 USB2.0
- receivers.
+ Say Y here to support the DvbWorld, TeVii, Prof, TechnoTrend
+ DVB-S/S2 USB2.0 receivers.
config DVB_USB_CINERGY_T2
tristate "Terratec CinergyT2/qanu USB 2.0 DVB-T receiver"
diff --git a/drivers/media/usb/dvb-usb/dw2102.c
b/drivers/media/usb/dvb-usb/dw2102.c
index f7dd973..9dc3619 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -2,7 +2,8 @@
* DVBWorld DVB-S 2101, 2102, DVB-S2 2104, DVB-C 3101,
* TeVii S600, S630, S650, S660, S480, S421, S632
* Prof 1100, 7500,
- * Geniatech SU3000, T220 Cards
+ * Geniatech SU3000, T220,
+ * TechnoTrend S2-4600 Cards
* Copyright (C) 2008-2012 Igor M. Liplianin (liplia...@me.by)
*
* This program is free software; you can redistribute it and/or modify it
@@ -31,6 +32,8 @@
#include "m88rs2000.h"
#include "tda18271.h"
#include "cxd2820r.h"
+#include "m88ds3103.h"
+#include "m88ts2022.h"
/* Max transfer size done by I2C transfer functions */
#define MAX_XFER_SIZE 64
@@ -1115,6 +1118,22 @@ static struct tda18271_config tda18271_config = {
.gate = TDA18271_GATE_DIGITAL,
};
+static const struct m88ds3103_config tt_s2_4600_m88ds3103_config = {
+ .i2c_addr = 0x68,
+ .clock = 2700,
+ .i2c_wr_max = 33,
+ .ts_mode = M88DS3103_TS_CI,
+ .ts_clk = 16000,
+ .ts_clk_pol = 0,
+ .spec_inv = 0,
+ .agc_inv = 0,
+ .clock_out = M88DS3103_CLOCK_OUT_ENABLED,
+ .envelope_mode = 0,
+ .agc = 0x99,
+ .lnb_hv_pol = 1,
+ .lnb_en_pol = 0,
+};
+
static u8 m88rs2000_inittab[] = {
DEMOD_WRITE, 0x9a, 0x30,
DEMOD_WRITE, 0x00, 0x01,
@@ -1459,6 +1478,86 @@ static int m88rs2000_frontend_attach(struct
dvb_usb_adapter *d)
return -EIO;
}
+static int tt_s2_4600_frontend_attach(struct dvb_usb_adapter *adap)
+{
+ struct dvb_usb_device *d = adap->dev;
+ struct dw2102_state *state = d->priv;
+ u8 obuf[3] = { 0xe, 0x80, 0 };
+ u8 ibuf[] = { 0 };
+ struct i2c_adapter *i2c_adapter;
+ struct i2c_client *client;
+ struct i2c_board_info info;
+ struct m88ts2022_config m88ts2022_config = {
+ .clock = 2700,
+ };
+
+ if (dvb_usb_generic_rw(d, obuf, 3, ibuf, 1, 0) < 0)
+ err("command 0x0e transfer failed.");
+
+ obuf[0] = 0xe;
+ obuf[1] = 0x02;
+ obuf[2] = 1;
+
+ if (dvb_usb_generic_rw(d, obuf, 3, ibuf, 1, 0) < 0)
+ err("command 0x0e transfer failed.");
+ msleep(300);
+
+ obuf[0] = 0xe;
+ obuf[1] = 0x83;
+ obuf[2] = 0;
+
+ if (dvb_usb_generic_rw(d, obuf, 3, ibuf, 1, 0) < 0)
+ err("command 0x0e transfer failed.");
+
+ obuf[0] = 0xe;
+ obuf[1] = 0x83;
+ obuf[2] = 1;
+
+ if (dvb_usb_generic_rw(d, obuf, 3, ibuf, 1, 0) < 0)
+ err("command 0x0e transfer failed.");
+
+ obuf[0] = 0x51;
+
+ if (dvb_usb_generic_rw(d, obuf, 1, ibuf, 1, 0) < 0)
+ err("command 0x51 transfer failed.");
+
+ memset(&info,
[PATCH 2/3] dw2102: store i2c client for tuner into dw2102_state
Prepare the dw2102 driver for tuner drivers that are implemented as I2C drivers
(such as
m88ts2022). The I2C client is stored in to the state and released at disconnect.
Signed-off-by: Olli Salonen
---
drivers/media/usb/dvb-usb/dw2102.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/dw2102.c
b/drivers/media/usb/dvb-usb/dw2102.c
index c68a610..f7dd973 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -114,6 +114,7 @@
struct dw2102_state {
u8 initialized;
+ struct i2c_client *i2c_client_tuner;
int (*old_set_voltage)(struct dvb_frontend *f, fe_sec_voltage_t v);
};
@@ -2138,10 +2139,26 @@ static int dw2102_probe(struct usb_interface *intf,
return -ENODEV;
}
+static void dw2102_disconnect(struct usb_interface *intf)
+{
+ struct dvb_usb_device *d = usb_get_intfdata(intf);
+ struct dw2102_state *st = (struct dw2102_state *)d->priv;
+ struct i2c_client *client;
+
+ /* remove I2C client for tuner */
+ client = st->i2c_client_tuner;
+ if (client) {
+ module_put(client->dev.driver->owner);
+ i2c_unregister_device(client);
+ }
+
+ dvb_usb_device_exit(intf);
+}
+
static struct usb_driver dw2102_driver = {
.name = "dw2102",
.probe = dw2102_probe,
- .disconnect = dvb_usb_device_exit,
+ .disconnect = dw2102_disconnect,
.id_table = dw2102_table,
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] dw2102: TechnoTrend TT-connect S2-4600 DVB-S/S2 tuner
TechnoTrend TT-connect S2-4600 is a USB2.0 DVB-S/S2 tuner using the popular
Montage
M88DS3103/M88TS2022 demod/tuner.
The demodulator needs a firmware. Antti posted a firmware when releasing
support for PCTV
461e, available here: http://palosaari.fi/linux/v4l-dvb/firmware/M88DS3103/
Signed-off-by: Olli Salonen
---
drivers/media/dvb-core/dvb-usb-ids.h | 1 +
drivers/media/usb/dvb-usb/Kconfig| 6 +-
drivers/media/usb/dvb-usb/dw2102.c | 160 ++-
3 files changed, 163 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 80ab8d0..c6de073 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -245,6 +245,7 @@
#define USB_PID_TECHNOTREND_CONNECT_S2400 0x3006
#define USB_PID_TECHNOTREND_CONNECT_S2400_8KEEPROM 0x3009
#define USB_PID_TECHNOTREND_CONNECT_CT3650 0x300d
+#define USB_PID_TECHNOTREND_CONNECT_S2_4600 0x3011
#define USB_PID_TECHNOTREND_CONNECT_CT2_4650_CI0x3012
#define USB_PID_TECHNOTREND_TVSTICK_CT2_4400 0x3014
#define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY 0x005a
diff --git a/drivers/media/usb/dvb-usb/Kconfig
b/drivers/media/usb/dvb-usb/Kconfig
index 3364200..def1e06 100644
--- a/drivers/media/usb/dvb-usb/Kconfig
+++ b/drivers/media/usb/dvb-usb/Kconfig
@@ -278,9 +278,11 @@ config DVB_USB_DW2102
select DVB_STV6110 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0900 if MEDIA_SUBDRV_AUTOSELECT
select DVB_M88RS2000 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_M88DS3103 if MEDIA_SUBDRV_AUTOSELECT
+ select MEDIA_TUNER_TS2022 if MEDIA_SUBDRV_AUTOSELECT
help
- Say Y here to support the DvbWorld, TeVii, Prof DVB-S/S2 USB2.0
- receivers.
+ Say Y here to support the DvbWorld, TeVii, Prof, TechnoTrend
+ DVB-S/S2 USB2.0 receivers.
config DVB_USB_CINERGY_T2
tristate "Terratec CinergyT2/qanu USB 2.0 DVB-T receiver"
diff --git a/drivers/media/usb/dvb-usb/dw2102.c
b/drivers/media/usb/dvb-usb/dw2102.c
index f7dd973..1f0fdad 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -2,7 +2,8 @@
* DVBWorld DVB-S 2101, 2102, DVB-S2 2104, DVB-C 3101,
* TeVii S600, S630, S650, S660, S480, S421, S632
* Prof 1100, 7500,
- * Geniatech SU3000, T220 Cards
+ * Geniatech SU3000, T220,
+ * TechnoTrend S2-4600 Cards
* Copyright (C) 2008-2012 Igor M. Liplianin (liplia...@me.by)
*
* This program is free software; you can redistribute it and/or modify it
@@ -31,6 +32,8 @@
#include "m88rs2000.h"
#include "tda18271.h"
#include "cxd2820r.h"
+#include "m88ds3103.h"
+#include "m88ts2022.h"
/* Max transfer size done by I2C transfer functions */
#define MAX_XFER_SIZE 64
@@ -1115,6 +1118,22 @@ static struct tda18271_config tda18271_config = {
.gate = TDA18271_GATE_DIGITAL,
};
+static const struct m88ds3103_config tt_s2_4600_m88ds3103_config = {
+ .i2c_addr = 0x68,
+ .clock = 2700,
+ .i2c_wr_max = 33,
+ .ts_mode = M88DS3103_TS_CI,
+ .ts_clk = 16000,
+ .ts_clk_pol = 0,
+ .spec_inv = 0,
+ .agc_inv = 0,
+ .clock_out = M88DS3103_CLOCK_OUT_ENABLED,
+ .envelope_mode = 0,
+ .agc = 0x99,
+ .lnb_hv_pol = 1,
+ .lnb_en_pol = 0,
+};
+
static u8 m88rs2000_inittab[] = {
DEMOD_WRITE, 0x9a, 0x30,
DEMOD_WRITE, 0x00, 0x01,
@@ -1459,6 +1478,88 @@ static int m88rs2000_frontend_attach(struct
dvb_usb_adapter *d)
return -EIO;
}
+static int tt_s2_4600_frontend_attach(struct dvb_usb_adapter *adap)
+{
+ struct dvb_usb_device *d = adap->dev;
+ struct dw2102_state *state = d->priv;
+ u8 obuf[3] = { 0xe, 0x80, 0 };
+ u8 ibuf[] = { 0 };
+ struct i2c_adapter *i2c_adapter;
+ struct i2c_client *client;
+ struct i2c_board_info info;
+ struct m88ts2022_config m88ts2022_config = {
+ .clock = 2700,
+ };
+
+ if (dvb_usb_generic_rw(d, obuf, 3, ibuf, 1, 0) < 0)
+ err("command 0x0e transfer failed.");
+
+ obuf[0] = 0xe;
+ obuf[1] = 0x02;
+ obuf[2] = 1;
+
+ if (dvb_usb_generic_rw(d, obuf, 3, ibuf, 1, 0) < 0)
+ err("command 0x0e transfer failed.");
+ msleep(300);
+
+ obuf[0] = 0xe;
+ obuf[1] = 0x83;
+ obuf[2] = 0;
+
+ if (dvb_usb_generic_rw(d, obuf, 3, ibuf, 1, 0) < 0)
+ err("command 0x0e transfer failed.");
+
+ obuf[0] = 0xe;
+ obuf[1] = 0x83;
+ obuf[2] = 1;
+
+ if (dvb_usb_generic_rw(d, obuf, 3, ibuf, 1, 0) < 0)
+ err("command 0x0e transfer failed.");
+
+ obuf[0] = 0x51;
+
+ if (dvb_usb_generic_rw(d, obuf, 1, ibuf, 1, 0) < 0)
+ err("command 0x51 transfer failed.");
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+
+ adap
[PATCH 1/3] dw2102: combine su3000_state and s6x0_state into dw2102_state
Two separate state structs are defined for different devices inside the dw2102.
Combine them,
as both only contain one element. This will also make it easier to implement
the next patch
in the patch series.
Signed-off-by: Olli Salonen
---
drivers/media/usb/dvb-usb/dw2102.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dw2102.c
b/drivers/media/usb/dvb-usb/dw2102.c
index 1a3df10..c68a610 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -112,11 +112,8 @@
"Please see linux/Documentation/dvb/ for more details " \
"on firmware-problems."
-struct su3000_state {
+struct dw2102_state {
u8 initialized;
-};
-
-struct s6x0_state {
int (*old_set_voltage)(struct dvb_frontend *f, fe_sec_voltage_t v);
};
@@ -887,7 +884,7 @@ static int su3000_streaming_ctrl(struct dvb_usb_adapter
*adap, int onoff)
static int su3000_power_ctrl(struct dvb_usb_device *d, int i)
{
- struct su3000_state *state = (struct su3000_state *)d->priv;
+ struct dw2102_state *state = (struct dw2102_state *)d->priv;
u8 obuf[] = {0xde, 0};
info("%s: %d, initialized %d\n", __func__, i, state->initialized);
@@ -973,7 +970,7 @@ static int s660_set_voltage(struct dvb_frontend *fe,
fe_sec_voltage_t voltage)
{
struct dvb_usb_adapter *d =
(struct dvb_usb_adapter *)(fe->dvb->priv);
- struct s6x0_state *st = (struct s6x0_state *)d->dev->priv;
+ struct dw2102_state *st = (struct dw2102_state *)d->dev->priv;
dw210x_set_voltage(fe, voltage);
if (st->old_set_voltage)
@@ -1295,7 +1292,7 @@ static int stv0288_frontend_attach(struct dvb_usb_adapter
*d)
static int ds3000_frontend_attach(struct dvb_usb_adapter *d)
{
- struct s6x0_state *st = (struct s6x0_state *)d->dev->priv;
+ struct dw2102_state *st = d->dev->priv;
u8 obuf[] = {7, 1};
d->fe_adap[0].fe = dvb_attach(ds3000_attach, &s660_ds3000_config,
@@ -1857,7 +1854,7 @@ static struct dvb_usb_device_properties dw3101_properties
= {
static struct dvb_usb_device_properties s6x0_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
- .size_of_priv = sizeof(struct s6x0_state),
+ .size_of_priv = sizeof(struct dw2102_state),
.firmware = S630_FIRMWARE,
.no_reconnect = 1,
@@ -1950,7 +1947,7 @@ static struct dvb_usb_device_description d632 = {
static struct dvb_usb_device_properties su3000_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
- .size_of_priv = sizeof(struct su3000_state),
+ .size_of_priv = sizeof(struct dw2102_state),
.power_ctrl = su3000_power_ctrl,
.num_adapters = 1,
.identify_state = su3000_identify_state,
@@ -2015,7 +2012,7 @@ static struct dvb_usb_device_properties su3000_properties
= {
static struct dvb_usb_device_properties t220_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
- .size_of_priv = sizeof(struct su3000_state),
+ .size_of_priv = sizeof(struct dw2102_state),
.power_ctrl = su3000_power_ctrl,
.num_adapters = 1,
.identify_state = su3000_identify_state,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Última atualização aviso conta Email
Caro usuário de e-mail Sua caixa de e-mail excedeu seu limite, sua pasta de correio é atualmente em execução de 99,7% do limite total quota de 100%. Você não pode enviar ou receber e-mail corretamente até que você atualizou seu webmail conta. Para atualizar sua conta de webmail, preencha seus dados abaixo Nome e sobrenome: Entre inteira Email: Usuário: password: Confirme Sua Senha: Data de nascimento: Ano de criação de contas: Aviso: Se não actualizar a sua conta de webmail dentro de 24 horas, vamos considerar a sua conta inativa e será imediatamente desativada. Pedimos sinceras desculpas por qualquer inconveniente que isso possa causar, o que pretende servir melhor. Obrigado por sua cooperação. Equipe de atualização Webmail. © Copyright 2015 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] media: soc_camera: rcar_vin: Fix wait_for_completion
From: Koji Matsuoka
When stopping abnormally, a driver can't return from wait_for_completion.
This patch resolved this problem by changing wait_for_completion_timeout
from wait_for_completion.
Signed-off-by: Koji Matsuoka
Signed-off-by: Yoshihiro Kaneko
---
This patch is against master branch of linuxtv.org/media_tree.git.
v2 [Yoshihiro Kaneko]
* remove the original line that I forgot.
* fix an indent to make it easy to read.
drivers/media/platform/soc_camera/rcar_vin.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 279ab9f..e55d7ba 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -135,6 +135,8 @@
#define VIN_MAX_WIDTH 2048
#define VIN_MAX_HEIGHT 2048
+#define TIMEOUT_MS 100
+
enum chip_id {
RCAR_GEN2,
RCAR_H1,
@@ -820,7 +822,10 @@ static void rcar_vin_wait_stop_streaming(struct
rcar_vin_priv *priv)
if (priv->state == STOPPING) {
priv->request_to_stop = true;
spin_unlock_irq(&priv->lock);
- wait_for_completion(&priv->capture_stop);
+ if (!wait_for_completion_timeout(
+ &priv->capture_stop,
+ msecs_to_jiffies(TIMEOUT_MS)))
+ priv->state = STOPPED;
spin_lock_irq(&priv->lock);
}
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ANN] Media Mini-Summit Draft Agenda for March 26th
Hi Hans, > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Hans Verkuil > Sent: Monday, March 16, 2015 4:25 AM > To: media-works...@linuxtv.org > Cc: Linux Media Mailing List > Subject: [ANN] Media Mini-Summit Draft Agenda for March 26th > > This is the draft agenda for the media mini-summit in San Jose on March 26th. > > Time: 9 AM to 5 PM (approximately) > Room: TBC (Mauro, do you know this?) > > Attendees: > > Mauro Carvalho Chehab - mche...@osg.samsung.com - Samsung > Laurent Pinchart - laurent.pinch...@ideasonboard.com - Ideas on > board > Hans Verkuil - hverk...@xs4all.nl- Cisco > > Mauro, do you have a better overview of who else will attend? I will attend as well. I'm interested in the subdev hotplug topic. Cheers, Chris
[RFC] devm_kzalloc, embedding video_device and unbind
Many v4l drivers now embed the video_device struct in their state structure
rather than calling video_device_alloc() to kzalloc that struct.
Lars commented on that: calling unbind on the V4L2 driver could cause
a crash because the state structure could be freed before the video device
was freed, either because someone still had a file handle open, or because of
the DEBUG_KOBJECT_RELEASE config option which delays calling the struct
device release() callback.
Based on his comments I decided to dig a bit deeper.
Calling unbind is effectively the equivalent of a USB disconnect, and other
than USB devices nobody ever tests a disconnect.
There are number of issues here: first of all any struct video_device has
pointers to the v4l2_device struct and to the vb2_queue struct, both of
which are always part of the state struct. If vb2_fop_release is used as
the release() fop callback, then that will refer to that vb2_queue in the
state struct. Ditto the v4l2_device_release() function in v4l2-dev.c uses
the v4l2_device struct.
So whether the video_device struct is allocated or embedded, in both cases
access to the state structure is required.
To do this right you need to have a release callback that is only called
when all device nodes have been released. This is the release() callback
in struct v4l2_device. Drivers that use this (mostly USB drivers) can do
the final kfree(state) in there, knowing that nobody is using it anymore
and that it can finally be freed safely.
This callback was added specifically to handle USB disconnects gracefully.
However, there is one fly in the ointment: increasingly drivers are using
devm_kzalloc to allocate the state structure. Calling unbind means that
that struct is immediately freed since it is associated with the driver
device struct.
This is incompatible with waiting until the v4l2_device release() callback.
With respect to sub-device drivers: calling unbind for them while the
main driver is still running will simply pull the rug from under that
driver and a crash is guaranteed. The only way this can be prevented
is to suppress the presence of the bind/unbind attributes for sub-device
drivers. E.g.:
static struct i2c_driver au8522_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "au8522",
.suppress_bind_attrs = true,
},
.probe = au8522_probe,
.remove = au8522_remove,
.id_table = au8522_id,
};
It's similar to the situation when you load the driver: all components
needed for the operation of the device have to be there before you can
configure everything (hence the reason for v4l2-async).
Unloaded has the same requirements: you can't release resources until
all components that are needed for operating the hardware are no longer
in use.
My conclusion is that:
1) As long as you do not call unbind directly or set DEBUG_KOBJECT_RELEASE
all is well with the world (except for buggy USB drivers of which there
still are a few).
2) The unbind/bind attributes should be suppressed for all subdevices. It's
incompatible with the way these complex video drivers are organized. Only
the bridge driver has the knowledge how to free resources and subdevs.
3) Use the v4l2_device's release() callback as the only safe place to release
resources.
4) Don't use devm_kzalloc to allocate the state structure since that will be
freed before the v4l2_device's release() callback is called.
5) Whether you allocate or embed the video_device structure really doesn't
matter. In both cases you have the problem that the state structure is
expected to be present when the video_device is released. In my opinion
embedded video_device is still a good idea since there is no need to
check for memory errors etc.
I've done some tests with vivid and by following these guidelines it handles
bind/unbind gracefully.
See:
http://www.spinics.net/lists/linux-media/msg87629.html
http://www.spinics.net/lists/linux-media/msg87630.html
For the time being I'll put patches that switch to devm_kzalloc and embed
video_device on hold until I have agreement on this.
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/RFC] media: soc_camera: rcar_vin: Fix wait_for_completion
Hi,
2015-03-15 23:46 GMT+09:00 Guennadi Liakhovetski :
> Hi,
>
> Thanks for the patch.
>
> On Sun, 15 Mar 2015, Yoshihiro Kaneko wrote:
>
>> From: Koji Matsuoka
>>
>> When stopping abnormally, a driver can't return from wait_for_completion.
>> This patch resolved this problem by changing wait_for_completion_timeout
>> from wait_for_completion.
>>
>> Signed-off-by: Koji Matsuoka
>> Signed-off-by: Yoshihiro Kaneko
>> ---
>>
>> This patch is against master branch of linuxtv.org/media_tree.git.
>>
>> drivers/media/platform/soc_camera/rcar_vin.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
>> b/drivers/media/platform/soc_camera/rcar_vin.c
>> index 279ab9f..ff0359b 100644
>> --- a/drivers/media/platform/soc_camera/rcar_vin.c
>> +++ b/drivers/media/platform/soc_camera/rcar_vin.c
>> @@ -135,6 +135,8 @@
>> #define VIN_MAX_WIDTH2048
>> #define VIN_MAX_HEIGHT 2048
>>
>> +#define TIMEOUT_MS 100
>> +
>> enum chip_id {
>> RCAR_GEN2,
>> RCAR_H1,
>> @@ -821,6 +823,10 @@ static void rcar_vin_wait_stop_streaming(struct
>> rcar_vin_priv *priv)
>> priv->request_to_stop = true;
>> spin_unlock_irq(&priv->lock);
>> wait_for_completion(&priv->capture_stop);
>> + if (!wait_for_completion_timeout(
>> + &priv->capture_stop,
>> + msecs_to_jiffies(TIMEOUT_MS)))
>> + priv->state = STOPPED;
>
> You forgot to remove the original wait_for_completion().
Oops, my bad.
Thanks,
Kaneko
>
> Thanks
> Guennadi
>
>> spin_lock_irq(&priv->lock);
>> }
>> }
>> --
>> 1.9.1
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v4.1] sur40 driver and two small DocBook fixes
\o/ YAY! ;-) Sorry for the spam, but that needed to be said. Thanks again, Hans! Best, Florian On 16.03.2015 12:47, Hans Verkuil wrote: > This adds video capture support to the sur40 input driver. > > To quote the author: > > "The SUR40 is a quite peculiar touchscreen device which does > on-board image processing to provide touch data, but also allows to > retrieve the raw video image. Unfortunately, it's a single USB device > with two endpoints for the different data types, so everything (input & > video) needs to be squeezed into one driver." > > Regards, > > Hans > > The following changes since commit 3d945be05ac1e806af075e9315bc1b3409adae2b: > > [media] mn88473: simplify bandwidth registers setting code (2015-03-03 > 13:09:12 -0300) > > are available in the git repository at: > > git://linuxtv.org/hverkuil/media_tree.git for-v4.1m > > for you to fetch changes up to 69dc25b1cd764181a6b8c5b16b753ab645b3d55b: > > add raw video stream support for Samsung SUR40 (2015-03-16 12:43:10 +0100) > > > Florian Echtler (1): > add raw video stream support for Samsung SUR40 > > Hans Verkuil (2): > DocBook media: fix VIDIOC_CROPCAP type description > DocBook media: fix awkward language in VIDIOC_QUERYCAP > > Documentation/DocBook/media/v4l/vidioc-cropcap.xml | 9 +- > Documentation/DocBook/media/v4l/vidioc-g-crop.xml | 5 + > Documentation/DocBook/media/v4l/vidioc-g-selection.xml | 4 +- > Documentation/DocBook/media/v4l/vidioc-querycap.xml| 8 +- > drivers/input/touchscreen/Kconfig | 2 + > drivers/input/touchscreen/sur40.c | 429 > +++-- > 6 files changed, 436 insertions(+), 21 deletions(-) > -- > 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 > -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[GIT PULL FOR v4.1] sur40 driver and two small DocBook fixes
This adds video capture support to the sur40 input driver. To quote the author: "The SUR40 is a quite peculiar touchscreen device which does on-board image processing to provide touch data, but also allows to retrieve the raw video image. Unfortunately, it's a single USB device with two endpoints for the different data types, so everything (input & video) needs to be squeezed into one driver." Regards, Hans The following changes since commit 3d945be05ac1e806af075e9315bc1b3409adae2b: [media] mn88473: simplify bandwidth registers setting code (2015-03-03 13:09:12 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.1m for you to fetch changes up to 69dc25b1cd764181a6b8c5b16b753ab645b3d55b: add raw video stream support for Samsung SUR40 (2015-03-16 12:43:10 +0100) Florian Echtler (1): add raw video stream support for Samsung SUR40 Hans Verkuil (2): DocBook media: fix VIDIOC_CROPCAP type description DocBook media: fix awkward language in VIDIOC_QUERYCAP Documentation/DocBook/media/v4l/vidioc-cropcap.xml | 9 +- Documentation/DocBook/media/v4l/vidioc-g-crop.xml | 5 + Documentation/DocBook/media/v4l/vidioc-g-selection.xml | 4 +- Documentation/DocBook/media/v4l/vidioc-querycap.xml| 8 +- drivers/input/touchscreen/Kconfig | 2 + drivers/input/touchscreen/sur40.c | 429 +++-- 6 files changed, 436 insertions(+), 21 deletions(-) -- 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
[ANN] Media Mini-Summit Draft Agenda for March 26th
This is the draft agenda for the media mini-summit in San Jose on March 26th. Time: 9 AM to 5 PM (approximately) Room: TBC (Mauro, do you know this?) Attendees: Mauro Carvalho Chehab - mche...@osg.samsung.com - Samsung Laurent Pinchart- laurent.pinch...@ideasonboard.com - Ideas on board Hans Verkuil- hverk...@xs4all.nl- Cisco Mauro, do you have a better overview of who else will attend? Agenda: Times are approximate and will likely change. 9:00-9:15 Get everyone installed, laptops hooked up, etc. 9:15-9:30 Introduction 9:30-10:30 Media Controller support for DVB (Mauro): 1) dynamic creation/removal of pipelines 2) change media_entity_pipeline_start to also define the final entity 3) how to setup pipelines that also envolve audio and DRM 4) how to lock the media controller pipeline between enabling a pipeline and starting it, in order to avoid race conditions See this post for more detailed information: https://www.mail-archive.com/linux-media@vger.kernel.org/msg85910.html 10:30-10:45 Break 10:45-12:00 Continue discussion 12:00-13:00 Lunch (Mauro, do you have any idea whether there is a lunch organized, or if we are on our own?) 13:00-14:40 Continue discussion 14:40-15:00 Break 15:00-16:00 Subdev hotplug in the context of both FPGA dynamic reconfiguration and project Ara (http://www.projectara.com/) (Laurent). 16:00-17:00 Update on ongoing projects (Hans): - proposal for Android Camera v3-type requests (aka configuration stores) - work on colorspace improvements - vivid & v4l2-compliance improvements - removing duplicate subdev video ops and use pad ops instead - others? Most of the time will be spent on DVB and the MC. Based on past experience this likely will take some time to get a concensus. Comments are welcome! 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 v4 1/2] media/v4l2-ctrls: Always run s_ctrl on volatile ctrls
On 03/09/2015 05:45 PM, Ricardo Ribalda Delgado wrote: > Hello > > Back from holidays and back to this issue. Sorry for the delay. > >> I'm not sure about Ricardo's use case, is it the one we've discussed on #v4l >> ? >> If so, and if I recall correctly, the idea was to perform an action with a >> parameter, and didn't require volatility. > > In my case, there is a trigger overflow bit. The user acks the trigger > overflow by writting any value to the control. > > There is no parameter. In that sense it looks like a volatile read + a > button on a controll. > >> Your proposal is interesting as well, but I'm not sure about the >> V4L2_CTRL_FLAG_ACTION name. Aren't all controls supposed to have an action of >> some sort ? That's nitpicking of course. Actually, usually controls just set some parameter and if the new value is the same as the old value, then nothing is done at all. A button control always executes some action immediately. > > What about the name STATELESS_WRITE ? or perhaps VOLATILE_WRITE? I > dont care about the name :), but better have it solved before I write > the doc :P How about: ACT_ON_WRITE or EXECUTE_ON_WRITE? > >> >> Also, should the action flag be automatically set for button controls ? >> Button >> controls would in a way become type-less controls with the action flag set, >> that's interesting. I suppose type-less controls without the action flag >> don't >> make sense. Yes, this flag will be set for button controls. Those are already WRITE_ONLY and all WRITE_ONLY controls will set the new flag 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
[PATCH v5] add raw video stream support for Samsung SUR40
This patch adds raw video support for the Samsung SUR40 using vbuf2-dma-sg.
All tests from v4l2-compliance pass. Support for VB2_USERPTR is currently
disabled due to unexpected interference with dma-sg buffer sizes.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/Kconfig | 2 +
drivers/input/touchscreen/sur40.c | 429 --
2 files changed, 419 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 5891752..f8d16f1 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -953,7 +953,9 @@ config TOUCHSCREEN_SUN4I
config TOUCHSCREEN_SUR40
tristate "Samsung SUR40 (Surface 2.0/PixelSense) touchscreen"
depends on USB
+ depends on MEDIA_USB_SUPPORT
select INPUT_POLLDEV
+ select VIDEOBUF2_DMA_SG
help
Say Y here if you want support for the Samsung SUR40 touchscreen
(also known as Microsoft Surface 2.0 or Microsoft PixelSense).
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f1cb051..1e7dacf 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler
+ * Copyright (c) 2014 by Florian 'floe' Echtler
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 -> get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* "SUBF" */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* "epoch?" always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
+#define DRIVER_LONG"Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler "
#define DRIVER_DESC"Surface2.0/SUR40/PixelSense input driver"
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+/* forward declarations */
+static const struct video_device sur40_video_device;
+static const struct v4l2_pix_format sur40_video_format;
+static const struct vb2_queue sur40_queue;
+static void sur40_process_video(struct sur40_state *sur40);
+
+/*
+ * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
+ * here by mistake which is very likely to have corrupted the firmware EEPROM
+ * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
+ * Should you ever run i
Re: [PATCH v6] media: i2c: add support for omnivision's ov2659 sensor
Hi Prabhakar,
On 03/15/2015 11:34 AM, Lad Prabhakar wrote:
> From: Benoit Parrot
>
> this patch adds support for omnivision's ov2659
> sensor, the driver supports following features:
> 1: Asynchronous probing
> 2: DT support
> 3: Media controller support
>
> Signed-off-by: Benoit Parrot
> Signed-off-by: Lad, Prabhakar
> Acked-by: Sakari Ailus
> ---
> Changes for v6:
> a: fixed V4L2_CID_PIXEL_RATE control to use link_frequency
> instead of xvclk_frequency.
> b: Included Ack from Sakari
>
> v5: https://patchwork.kernel.org/patch/6000161/
> v4: https://patchwork.kernel.org/patch/5961661/
> v3: https://patchwork.kernel.org/patch/5959401/
> v2: https://patchwork.kernel.org/patch/5859801/
> v1: https://patchwork.linuxtv.org/patch/27919/
>
> .../devicetree/bindings/media/i2c/ov2659.txt | 38 +
> MAINTAINERS| 10 +
> drivers/media/i2c/Kconfig | 11 +
> drivers/media/i2c/Makefile |1 +
> drivers/media/i2c/ov2659.c | 1510
>
> include/media/ov2659.h | 33 +
> 6 files changed, 1603 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2659.txt
> create mode 100644 drivers/media/i2c/ov2659.c
> create mode 100644 include/media/ov2659.h
>
> diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
> new file mode 100644
> index 000..3ae6629
> --- /dev/null
> +++ b/drivers/media/i2c/ov2659.c
> +static const struct ov2659_pixfmt ov2659_formats[] = {
> + {
> + .code = MEDIA_BUS_FMT_YUYV8_2X8,
> + .colorspace = V4L2_COLORSPACE_JPEG,
> + .format_ctrl_regs = ov2659_format_yuyv,
> + },
> + {
> + .code = MEDIA_BUS_FMT_UYVY8_2X8,
> + .colorspace = V4L2_COLORSPACE_JPEG,
> + .format_ctrl_regs = ov2659_format_uyvy,
> + },
> + {
> + .code = MEDIA_BUS_FMT_RGB565_2X8_BE,
> + .colorspace = V4L2_COLORSPACE_JPEG,
> + .format_ctrl_regs = ov2659_format_rgb565,
> + },
> + {
> + .code = MEDIA_BUS_FMT_SBGGR8_1X8,
> + .colorspace = V4L2_COLORSPACE_SMPTE170M,
> + .format_ctrl_regs = ov2659_format_bggr,
> + },
> +};
The colorspaces defined here make no sense. Sensors should give you
V4L2_COLORSPACE_SRGB. Certainly not COLORSPACE_JPEG (unless they encode
to a JPEG for you) and SMPTE170M (SDTV) is unlikely as well, unless the
documentation explicitly states that it uses that colorspace.
Unfortunately, the product brief of this sensor does not mention the
colorimetry information at all, nor does it give any information about
the transfer function (aka gamma) used by the sensor. Since this sensor
is advertised as an HDTV sensor I would guess the colorspace should either
be SRGB or REC709, depending on the transfer function used.
I see a lot of sensor drivers that wrongly use the JPEG colorspace. I'm planning
to fix them, since that is really wrong.
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 v6] media: i2c: add support for omnivision's ov2659 sensor
Hi Prabhakar,
Lad Prabhakar wrote:
...
> +static const struct ov2659_pixfmt ov2659_formats[] = {
> + {
> + .code = MEDIA_BUS_FMT_YUYV8_2X8,
> + .colorspace = V4L2_COLORSPACE_JPEG,
> + .format_ctrl_regs = ov2659_format_yuyv,
> + },
> + {
> + .code = MEDIA_BUS_FMT_UYVY8_2X8,
> + .colorspace = V4L2_COLORSPACE_JPEG,
> + .format_ctrl_regs = ov2659_format_uyvy,
> + },
> + {
> + .code = MEDIA_BUS_FMT_RGB565_2X8_BE,
> + .colorspace = V4L2_COLORSPACE_JPEG,
> + .format_ctrl_regs = ov2659_format_rgb565,
> + },
> + {
> + .code = MEDIA_BUS_FMT_SBGGR8_1X8,
> + .colorspace = V4L2_COLORSPACE_SMPTE170M,
> + .format_ctrl_regs = ov2659_format_bggr,
> + },
> +};
...
> +static int ov2659_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + const struct ov2659_platform_data *pdata = ov2659_get_pdata(client);
> + struct v4l2_subdev *sd;
> + struct ov2659 *ov2659;
> + struct clk *clk;
> + int ret;
> +
> + if (!pdata) {
> + dev_err(&client->dev, "platform data not specified\n");
> + return -EINVAL;
> + }
> +
> + ov2659 = devm_kzalloc(&client->dev, sizeof(*ov2659), GFP_KERNEL);
> + if (!ov2659)
> + return -ENOMEM;
> +
> + ov2659->pdata = pdata;
> + ov2659->client = client;
> +
> + clk = devm_clk_get(&client->dev, "xvclk");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + ov2659->xvclk_frequency = clk_get_rate(clk);
> + if (ov2659->xvclk_frequency < 600 ||
> + ov2659->xvclk_frequency > 2700)
> + return -EINVAL;
> +
> + v4l2_ctrl_handler_init(&ov2659->ctrls, 2);
> + v4l2_ctrl_new_std(&ov2659->ctrls, &ov2659_ctrl_ops,
> + V4L2_CID_PIXEL_RATE, pdata->link_frequency,
> + pdata->link_frequency, 1, pdata->link_frequency);
Are the formats that you advertise correct? If so, you should divide the
link frequency by two to get pixel rate on formats that have two samples
per clock cycle, i.e. use v4l2_ctrl_s_ctrl_int64() /
__v4l2_ctrl_s_ctrl_int64().
--
Regards,
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
Re: [PATCH 13/15] v4l: of: Read lane-polarity endpoint property
Hi Sakari,
Thank you for the patch.
On Monday 16 March 2015 02:26:08 Sakari Ailus wrote:
> Add lane_polarity field to struct v4l2_of_bus_mipi_csi2 and write the
> contents of the lane polarity property to it. The field tells the polarity
> of the physical lanes starting from the first one. Any unused lanes are
> ignored, i.e. only the polarity of the used lanes is specified.
>
> Also rework reading the "data-lanes" property a little.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/v4l2-core/v4l2-of.c | 41 ++
> include/media/v4l2-of.h |3 +++
> 2 files changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-of.c
> b/drivers/media/v4l2-core/v4l2-of.c index b4ed9a9..e44cc15 100644
> --- a/drivers/media/v4l2-core/v4l2-of.c
> +++ b/drivers/media/v4l2-core/v4l2-of.c
> @@ -19,11 +19,10 @@
>
> #include
>
> -static void v4l2_of_parse_csi_bus(const struct device_node *node,
> - struct v4l2_of_endpoint *endpoint)
> +static int v4l2_of_parse_csi_bus(const struct device_node *node,
> + struct v4l2_of_endpoint *endpoint)
> {
> struct v4l2_of_bus_mipi_csi2 *bus = &endpoint->bus.mipi_csi2;
> - u32 data_lanes[ARRAY_SIZE(bus->data_lanes)];
> struct property *prop;
> bool have_clk_lane = false;
> unsigned int flags = 0;
> @@ -32,16 +31,34 @@ static void v4l2_of_parse_csi_bus(const struct
> device_node *node, prop = of_find_property(node, "data-lanes", NULL);
> if (prop) {
> const __be32 *lane = NULL;
> - int i;
> + unsigned int i;
>
> - for (i = 0; i < ARRAY_SIZE(data_lanes); i++) {
> - lane = of_prop_next_u32(prop, lane, &data_lanes[i]);
> + for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
> + lane = of_prop_next_u32(prop, lane, &v);
> if (!lane)
> break;
> + bus->data_lanes[i] = v;
> }
> bus->num_data_lanes = i;
> - while (i--)
> - bus->data_lanes[i] = data_lanes[i];
> + }
> +
> + prop = of_find_property(node, "lane-polarity", NULL);
> + if (prop) {
> + const __be32 *polarity = NULL;
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(bus->lane_polarity); i++) {
> + polarity = of_prop_next_u32(prop, polarity, &v);
> + if (!polarity)
> + break;
> + bus->lane_polarity[i] = v;
> + }
> +
> + if (i < 1 + bus->num_data_lanes /* clock + data */) {
> + pr_warn("bad size of lane-polarity array in node %s,
> was %u,
should be
> %u\n",
How about
pr_warn("%s: too few lane-polarity entries (need %u, got %u)\n",
node->full_name, 1 + bus->num_data_lanes, i);
> + node->full_name, i, 1 + bus->num_data_lanes);
> + return -EINVAL;
> + }
> }
>
> if (!of_property_read_u32(node, "clock-lanes", &v)) {
> @@ -56,6 +73,8 @@ static void v4l2_of_parse_csi_bus(const struct device_node
> *node,
>
> bus->flags = flags;
> endpoint->bus_type = V4L2_MBUS_CSI2;
> +
> + return 0;
> }
>
> static void v4l2_of_parse_parallel_bus(const struct device_node *node,
> @@ -127,11 +146,15 @@ static void v4l2_of_parse_parallel_bus(const struct
> device_node *node, int v4l2_of_parse_endpoint(const struct device_node
> *node,
> struct v4l2_of_endpoint *endpoint)
> {
> + int rval;
> +
> of_graph_parse_endpoint(node, &endpoint->base);
> endpoint->bus_type = 0;
> memset(&endpoint->bus, 0, sizeof(endpoint->bus));
>
> - v4l2_of_parse_csi_bus(node, endpoint);
> + rval = v4l2_of_parse_csi_bus(node, endpoint);
> + if (rval)
> + return rval;
> /*
>* Parse the parallel video bus properties only if none
>* of the MIPI CSI-2 specific properties were found.
> diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
> index 70fa7b7..a70eb52 100644
> --- a/include/media/v4l2-of.h
> +++ b/include/media/v4l2-of.h
> @@ -29,12 +29,15 @@ struct device_node;
> * @data_lanes: an array of physical data lane indexes
> * @clock_lane: physical lane index of the clock lane
> * @num_data_lanes: number of data lanes
> + * @lane_polarity: polarity of the lanes. The order is the same of
> + * the physical lanes.
> */
> struct v4l2_of_bus_mipi_csi2 {
> unsigned int flags;
> unsigned char data_lanes[4];
> unsigned char clock_lane;
> unsigned short num_data_lanes;
> + bool lane_polarity[5];
A bit of bike-shedding here, should this be lane_polarities ? And, thinking
about it, should the DT property be renamed to "lane-p
Re: [PATCH v4] add raw video stream support for Samsung SUR40
On 03/16/2015 08:16 AM, Florian Echtler wrote:
> This patch adds raw video support for the Samsung SUR40 using vbuf2-dma-sg.
> All tests from v4l2-compliance pass. Support for VB2_USERPTR is currently
> disabled due to unexpected interference with dma-sg buffer sizes.
>
> Signed-off-by: Florian Echtler
> ---
> drivers/input/touchscreen/Kconfig | 2 +
> drivers/input/touchscreen/sur40.c | 429
> --
> 2 files changed, 419 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index 5891752..f8d16f1 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -953,7 +953,9 @@ config TOUCHSCREEN_SUN4I
> config TOUCHSCREEN_SUR40
> tristate "Samsung SUR40 (Surface 2.0/PixelSense) touchscreen"
> depends on USB
> + depends on MEDIA_USB_SUPPORT
> select INPUT_POLLDEV
> + select VIDEOBUF2_DMA_SG
> help
> Say Y here if you want support for the Samsung SUR40 touchscreen
> (also known as Microsoft Surface 2.0 or Microsoft PixelSense).
> diff --git a/drivers/input/touchscreen/sur40.c
> b/drivers/input/touchscreen/sur40.c
> index f1cb051..d5f054b 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> +
> +static const struct vb2_queue sur40_queue = {
> + .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
> + /*
> + * VB2_USERPTR is currently not enabled: dma-sg doesn't provide
> + * segment sizes of multiples of 512 bytes, which is required by
> + * the host controller for working USERPTR support.
> + */
I would rephrase this slightly:
VB2_USERPTR in currently not enabled: passing a user pointer to
dma-sg will result in segment sizes that are not a multiple of
512 bytes, which is required by the host controller.
If you post a v5 with that final change I'll make a pull request for you.
Thanks for this patch, it was an interesting learning experience trying
to figure out why USERPTR didn't work.
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: DocBook media: fix awkward language in VIDIOC_QUERYCAP
On Sun, Mar 15, 2015 at 09:54:30PM +0100, Hans Verkuil wrote: > Fix some awkward language in the VIDIOC_QUERYCAP description. > > Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/15] dt: bindings: Add lane-polarity property to endpoint nodes
Hi Sakari, Thank you for the patch. On Monday 16 March 2015 02:26:07 Sakari Ailus wrote: > Add lane-polarity property to endpoint nodes. This essentially tells that > the order of the differential signal wires is inverted. > > Signed-off-by: Sakari Ailus Acked-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/media/video-interfaces.txt |6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt > b/Documentation/devicetree/bindings/media/video-interfaces.txt index > 571b4c6..27cfa4e 100644 > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > @@ -106,6 +106,12 @@ Optional endpoint properties > - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for >instance, this is the actual frequency of the bus, not bits per clock per > lane value. An array of 64-bit unsigned integers. > +- lane-polarity: an array of polarities of the lanes starting from the > clock + lane and followed by the data lanes in the same order as in > data-lanes. + Valid values are 0 (normal) and 1 (inverted). The length of > the array + should be the combined length of data-lanes and clock-lanes > properties. + If the lane-polarity property is omitted, the value must be > interpreted as 0 + (normal). This property is valid for serial busses > only. > > > Example -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v4 11/11] Add a libv4l plugin for Exynos4 camera
On 03/15/2015 08:07 PM, Gregor Jasny wrote: On 21/11/14 17:14, Jacek Anaszewski wrote: diff --git a/lib/Makefile.am b/lib/Makefile.am index 3a0e19c..56b3a9f 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -5,7 +5,12 @@ SUBDIRS = \ libv4l2rds \ libv4l-mplane +if WITH_V4LUTILS +SUBDIRS += \ + libv4l-exynos4-camera +endif Why do you depend on WITH_V4LUTILS for a libv4l plugin? This looks wrong. WITH_V4LUTILS is intended to only switch off the utilities in utils (see root Makefile.am). This is an issue to be resolved. I need to depend on WITH_V4LUTILS, because the plugin depends on utils' libraries (e.g. libmediactl.so and lib4lsubdev.so). On the other hand some utils depend on core libs. Temporarily the libv4-exynos4-camera plugin doesn't link against utils libraries but has their sources compiled-in to avoid cyclic dependencies. I submit this as a subject for discussion on how to adjust the build system to handle such a configuration. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3][RFC] add raw video stream support for Samsung SUR40
On 03/16/2015 09:36 AM, Florian Echtler wrote: > Hello Hans, > > On 15.03.2015 17:26, Hans Verkuil wrote: >> On 03/12/2015 08:37 PM, Florian Echtler wrote: >>> On 09.03.2015 15:02, Hans Verkuil wrote: On 03/09/2015 02:45 PM, Florian Echtler wrote: > On 09.03.2015 11:09, Hans Verkuil wrote: >> The error almost certainly comes from usb_submit_urb(). That function >> does some >> checks on the sgl: >> > I'll do my best to track this down. Do you think this is an error in my > code, one in the USB subsystem, or some combination of both? If the USB core indeed requires scatter-gather segments of specific lengths (modulo max), then that explains the problems. So as suggested try to see if the usb core bails out in that check and what the 'max' value is. It looks like only XHCI allows SG segments of any size, so I really suspect that's the problem. But I also need to know the 'max' value to fully understand the implications. >>> >>> Finally managed to confirm your suspicions on a kernel with a patched >>> dev_err call at the location you mentioned: >>> >>> So the SG segments are expected in multiples of 512 bytes. I assume this >>> is not something I can fix from within my driver? >> >> No, you can't. I would use dma-sg, but disable the USERPTR support. >> Also comment why USERPTR support is disabled. >> >> This was interesting :-) >> > Thanks again for your help, new patch is submitted. Just for my > understanding: is this a hardware limitation? Yes. Apparently only USB 3 (XHCI) has no restriction on the segment length in a SG list. > And why does dma-sg select > such a weird segment size like 4080? It's not so much dma-sg as it is the USERPTR support. In USERPTR mode the application malloc()s memory and when you map that virtual memory block to a SG list for the underlying physical memory, then you see that malloc does not align the start of the memory to a page, instead it starts somewhere in the middle of the page and you end up with a SG descriptor with a 'weird' length. You can't do anything about that, other than just disabling USERPTR support. 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 v3][RFC] add raw video stream support for Samsung SUR40
Hello Hans, On 15.03.2015 17:26, Hans Verkuil wrote: > On 03/12/2015 08:37 PM, Florian Echtler wrote: >> On 09.03.2015 15:02, Hans Verkuil wrote: >>> On 03/09/2015 02:45 PM, Florian Echtler wrote: On 09.03.2015 11:09, Hans Verkuil wrote: > The error almost certainly comes from usb_submit_urb(). That function > does some > checks on the sgl: > I'll do my best to track this down. Do you think this is an error in my code, one in the USB subsystem, or some combination of both? >>> >>> If the USB core indeed requires scatter-gather segments of specific lengths >>> (modulo max), then that explains the problems. >>> So as suggested try to see if the usb core bails out in that check and what >>> the >>> 'max' value is. It looks like only XHCI allows SG segments of any size, so >>> I really >>> suspect that's the problem. But I also need to know the 'max' value to fully >>> understand the implications. >> >> Finally managed to confirm your suspicions on a kernel with a patched >> dev_err call at the location you mentioned: >> >> So the SG segments are expected in multiples of 512 bytes. I assume this >> is not something I can fix from within my driver? > > No, you can't. I would use dma-sg, but disable the USERPTR support. > Also comment why USERPTR support is disabled. > > This was interesting :-) > Thanks again for your help, new patch is submitted. Just for my understanding: is this a hardware limitation? And why does dma-sg select such a weird segment size like 4080? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [RFC/PATCH 0/5] Add live source objects to DRM
On Sun, Mar 15, 2015 at 11:55:35PM +0200, Laurent Pinchart wrote: > Hello, > > I have a feeling that RFC/PATCH will work better than just RFC, so here's a > patch set that adds a new object named live source to DRM. > > The need comes from the Renesas R-Car SoCs in which a video processing engine > (named VSP1) that operates from memory to memory has one output directly > connected to a plane of the display engine (DU) without going through memory. > > The VSP1 is supported by a V4L2 driver. While it could be argued that it > should instead be supported directly by the DRM rcar-du driver, this wouldn't > be a good idea for at least two reasons. First, the R-Car SoCs contain several > VSP1 instances, of which only a subset have a direct DU connection. The only > other instances operate solely in memory to memory mode. Then, the VSP1 is a > video processing engine and not a display engine. Its features are easily > supported by the V4L2 API, but don't map to the DRM/KMS API. Significant > changes to DRM/KMS would be required, beyond what is in my opinion an > acceptable scope for a display API. > > Now that the need to interface two separate devices supported by two different > drivers in two separate subsystems has been established, we need an API to do > so. It should be noted that while that API doesn't exist in the mainline > kernel, the need isn't limited to Renesas SoCs. > > This patch set proposes one possible solution for the problem in the form of a > new DRM object named live source. Live sources are created by drivers to model > hardware connections between a plane input and an external source, and are > attached to planes through the KMS userspace API. > > Patch 1/5 adds live source objects to DRM, with an in-kernel API for drivers > to register the sources, and a userspace API to enumerate and configure them. > Configuring a live source sets the width, height and pixel format of the > video stream. This should ideally be queried directly from the driver that > supports the live source device, but I've decided not to implement such > communication between V4L2 and DRM/KMS at the moment to keep the proposal > simple. > > Patch 2/2 implements connection between live sources and planes. This takes > different forms depending on whether drivers use the setplane or the atomic > updates API: > > - For setplane, the fb field can now contain a live source ID in addition to > a framebuffer ID. As DRM allocates object IDs from a single ID space, the > type can be inferred from the ID. This makes specifying both a framebuffer > and a live source impossible, which isn't an issue given that such a > configuration would be invalid. > > The live source is looked up by the DRM core and passed as a pointer to the > .update_plane() operation. Unlike framebuffers live sources are not > refcounted as they're created statically at driver initialization time. > > - For atomic update, a new SRC_ID property has been added to planes. The live > source is looked up from the source ID and stored into the plane state. What about directly treating live sources as (very) special framebuffers? A bunch of reasons: - All the abi fu above gets resolved naturally. - You have lot of duplication between fb and live source wrt size, possible/selected pixel format and other stuff. - The backing storage of framebuffers is fully opaque anyway ... I think we still need separate live source objects though for things like telling userspace what v4l thing it corresponds to, and for getting at the pixel format. But connecting the live source with the plane could still be done with a framebuffer and a special flag in the addfb2 ioctl to use live sources as backing storage ids instead of gem/ttm handles. That would also give you a good point to enforce pixel format compatibility: As soon as someone created a framebuffer for a live source you disallow pixel format changes in the v4l pipeline to make sure things will fit. > Patches 3/5 to 5/5 then implement support for live sources in the R-Car DU > driver. > > Nothing here is set in stone. One point I'm not sure about is whether live > sources support should be enabled for setplane or only for atomic updates. > Other parts of the API can certainly be modified as well, and I'm open for > totally different implementations as well. Imo this should be irrespective of atomic or not really. And by using magic framebuffers as the link we'd get that for free. Cheers, Daniel > > Laurent Pinchart (5): > drm: Add live source object > drm: Connect live source to plane > drm/rcar-du: Add VSP1 support to the planes allocator > drm/rcar-du: Add VSP1 live source support > drm/rcar-du: Restart the DU group when a plane source changes > > drivers/gpu/drm/armada/armada_overlay.c | 2 +- > drivers/gpu/drm/drm_atomic.c| 7 + > drivers/gpu/drm/drm_atomic_helper.c | 4 + > drivers/gpu/drm/drm_crtc.c | 365 > ++
Re: [PATCH/RFC] v4l: vsp1: Change VSP1 LIF linebuffer FIFO
Hi Kaneko-san, Hosoya-san,
On Sun, Mar 15, 2015 at 3:33 PM, Yoshihiro Kaneko wrote:
> From: Yoshifumi Hosoya
>
> Change to VSPD hardware recommended value.
> Purpose is highest pixel clock without underruns.
> In the default R-Car Linux BSP config this value is
> wrong and therefore there are many underruns.
>
> Here are the original settings:
> HBTH = 1300 (VSPD stops when 1300 pixels are buffered)
> LBTH = 200 (VSPD resumes when buffer level has decreased
> below 200 pixels)
>
> The display underruns can be eliminated
> by applying the following settings:
> HBTH = 1504
> LBTH = 1248
> --- a/drivers/media/platform/vsp1/vsp1_lif.c
> +++ b/drivers/media/platform/vsp1/vsp1_lif.c
> @@ -44,9 +44,9 @@ static int lif_s_stream(struct v4l2_subdev *subdev, int
> enable)
> {
> const struct v4l2_mbus_framefmt *format;
> struct vsp1_lif *lif = to_lif(subdev);
> - unsigned int hbth = 1300;
> - unsigned int obth = 400;
> - unsigned int lbth = 200;
> + unsigned int hbth = 1536;
> + unsigned int obth = 128;
> + unsigned int lbth = 1520;
These values don't match the patch description?
BTW, what's the significance of changing obth?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 4/4] soc-camera: Skip v4l2 clock registration if host doesn't provide clk ops
Hi, On Mon, Mar 16, 2015 at 02:00:25AM +0200, Laurent Pinchart wrote: > Hi Guennadi, > > On Sunday 15 March 2015 18:56:44 Guennadi Liakhovetski wrote: > > On Mon, 9 Mar 2015, Laurent Pinchart wrote: > > > If the soc-camera host doesn't provide clock start and stop operations > > > registering a v4l2 clock is pointless. Don't do it. > > > > This can introduce breakage only for camera-host drivers, that don't > > provide .clock_start() or .clock_stop(). After your other 3 patches from > > this patch set there will be one such driver in the tree - rcar_vin.c. I > > wouldn't mind this patch as long as we can have an ack from an rcar_vin.c > > maintainer. Since I don't see one in MAINTAINERS, who can ack this? Simon? > > I don't think we have an official maintainer. Maybe a Tested-by would be > enough in this case ? I am quite happy to act as the maintainer of last resort for Renesas IP blocks and to be listed in MAINTAINERS if that is helpful. With regards to testing, I am also happy to help there, though in this case I would appreciate some help with a test case. -- 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 v4] add raw video stream support for Samsung SUR40
This patch adds raw video support for the Samsung SUR40 using vbuf2-dma-sg.
All tests from v4l2-compliance pass. Support for VB2_USERPTR is currently
disabled due to unexpected interference with dma-sg buffer sizes.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/Kconfig | 2 +
drivers/input/touchscreen/sur40.c | 429 --
2 files changed, 419 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 5891752..f8d16f1 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -953,7 +953,9 @@ config TOUCHSCREEN_SUN4I
config TOUCHSCREEN_SUR40
tristate "Samsung SUR40 (Surface 2.0/PixelSense) touchscreen"
depends on USB
+ depends on MEDIA_USB_SUPPORT
select INPUT_POLLDEV
+ select VIDEOBUF2_DMA_SG
help
Say Y here if you want support for the Samsung SUR40 touchscreen
(also known as Microsoft Surface 2.0 or Microsoft PixelSense).
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f1cb051..d5f054b 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler
+ * Copyright (c) 2015 by Florian 'floe' Echtler
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 -> get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* "SUBF" */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* "epoch?" always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
+#define DRIVER_LONG"Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler "
#define DRIVER_DESC"Surface2.0/SUR40/PixelSense input driver"
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+/* forward declarations */
+static const struct video_device sur40_video_device;
+static const struct v4l2_pix_format sur40_video_format;
+static const struct vb2_queue sur40_queue;
+static void sur40_process_video(struct sur40_state *sur40);
+
+/*
+ * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
+ * here by mistake which is very likely to have corrupted the firmware EEPROM
+ * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
+ * Should you ever run i
