RE: [PATCH V3 06/15] [media] marvell-ccic: add new formats support for marvell-ccic driver
Hi Guennadi,
Below is the update for widthy, widthuv and imgsz_w setting.
>-Original Message-
>From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
>Sent: Wednesday, January 02, 2013 12:56 AM
>To: Albert Wang
>Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang
>Subject: Re: [PATCH V3 06/15] [media] marvell-ccic: add new formats support for
>marvell-ccic driver
>
>On Sat, 15 Dec 2012, Albert Wang wrote:
>
>> From: Libin Yang
>>
>> This patch adds the new formats support for marvell-ccic.
>>
>> Signed-off-by: Albert Wang
>> Signed-off-by: Libin Yang
>> ---
>> drivers/media/platform/marvell-ccic/mcam-core.c | 175
>> ++-
>> drivers/media/platform/marvell-ccic/mcam-core.h |6 +
>> 2 files changed, 149 insertions(+), 32 deletions(-)
>>
>> diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
>b/drivers/media/platform/marvell-ccic/mcam-core.c
>> index 3cc1d0c..a679917 100755
>> --- a/drivers/media/platform/marvell-ccic/mcam-core.c
>> +++ b/drivers/media/platform/marvell-ccic/mcam-core.c
>
>[snip]
>
>> @@ -658,49 +708,85 @@ static inline void mcam_sg_restart(struct mcam_camera
>> *cam)
>> */
>> static void mcam_ctlr_image(struct mcam_camera *cam)
>> {
>> -int imgsz;
>> struct v4l2_pix_format *fmt = &cam->pix_format;
>> +u32 widthy = 0, widthuv = 0, imgsz_h, imgsz_w;
>> +
>> +cam_dbg(cam, "camera: bytesperline = %d; height = %d\n",
>> +fmt->bytesperline, fmt->sizeimage / fmt->bytesperline);
>> +imgsz_h = (fmt->height << IMGSZ_V_SHIFT) & IMGSZ_V_MASK;
>> +imgsz_w = fmt->bytesperline & IMGSZ_H_MASK;
>> +
>> +switch (fmt->pixelformat) {
>> +case V4L2_PIX_FMT_YUYV:
>> +case V4L2_PIX_FMT_UYVY:
>> +widthy = fmt->width * 2;
>> +widthuv = 0;
>> +break;
>> +case V4L2_PIX_FMT_JPEG:
>> +imgsz_h = (fmt->sizeimage / fmt->bytesperline) << IMGSZ_V_SHIFT;
>> +widthy = fmt->bytesperline;
>> +widthuv = 0;
>> +break;
>> +case V4L2_PIX_FMT_YUV422P:
>> +case V4L2_PIX_FMT_YUV420:
>> +case V4L2_PIX_FMT_YVU420:
>> +imgsz_w = (fmt->bytesperline * 4 / 3) & IMGSZ_H_MASK;
>> +widthy = fmt->width;
>> +widthuv = fmt->width / 2;
>
>I might be wrong, but the above doesn't look right to me. Firstly, YUV422P
>is a 4:2:2 format, whereas YUV420 and YVU420 are 4:2:0 formats, so, I
>would expect calculations for them to differ. Besides, bytesperline * 4 /
>3 doesn't look right for any of them. If this is what I think - total
>number of bytes per line, i.e., sizeimage / height, than shouldn't YAU422P
>have
>+ imgsz_w = fmt->bytesperline & IMGSZ_H_MASK;
>and the other two
>+ imgsz_w = (fmt->bytesperline * 3 / 2) & IMGSZ_H_MASK;
>? But maybe I'm wrong, please, double-check and confirm.
>
First of all, the setting bytesperline in this file is wrong. It should be
like the setting in the mcam-core-soc.c in the later patch. It's my fault
missing modifying the bytesperline when adding the new formats.
Besides the bytesperline in mcam-core-soc.c is a little wrong.
I will update it in the new version of patch.
For imgsz_w setting, this is for the CCIC input data format, which is from
sensor, while 'switch (fmt->pixelformat)' is CCIC output data format.
It seems a little confusing using fmt->pixelformat here. Using
mcam_formats->mbus_code seems more reasonable. Anyway,
each fmt->pixelformat must have one mcam_formats->mbus_code
correspondingly.
Although, our spec says it supports YUV420 input. Our HW team told me
we only use YUV422 and the length is width * 2. So it seems some
mbus_code is wrong set here.
It seems in this case such format will be never used as we can see
ov7670 does not support yuv420.
Regards,
Libin
--
To unsubscribe from this list: send the line "unsubscribe 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/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct
2013/1/10 Laurent Pinchart :
> Hi Vikas,
>
> Thank you for the patch.
>
> On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote:
>> On 3 January 2013 16:29, Tomasz Figa wrote:
>> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
>> >> From: Vikas Sajjan
>> >>
>> >> Signed-off-by: Vikas Sajjan
>> >> ---
>> >>
>> >> include/video/display.h |6 ++
>> >> 1 file changed, 6 insertions(+)
>> >>
>> >> diff --git a/include/video/display.h b/include/video/display.h
>> >> index b639fd0..fb2f437 100644
>> >> --- a/include/video/display.h
>> >> +++ b/include/video/display.h
>> >> @@ -117,6 +117,12 @@ struct dsi_video_source_ops {
>> >>
>> >> void (*enable_hs)(struct video_source *src, bool enable);
>> >>
>> >> + /* frame related */
>> >> + int (*get_frame_done)(struct video_source *src);
>> >> + int (*clear_frame_done)(struct video_source *src);
>> >> + int (*set_early_blank_mode)(struct video_source *src, int power);
>> >> + int (*set_blank_mode)(struct video_source *src, int power);
>> >> +
>> >
>> > I'm not sure if all those extra ops are needed in any way.
>> >
>> > Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only
>> > FB_BLANK_UNBLANK status, which basically equals to the already existing
>> > enable operation, while set_early_blank mode handles only
>> > FB_BLANK_POWERDOWN, being equal to disable callback.
>>
>> Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as
>> of now, but FB_BLANK_NORMAL will be supported in future.
>> If not for Exynos, i think it will be need for other SoCs which
>> support FB_BLANK_UNBLANK and FB_BLANK_NORMAL.
>
> Could you please explain in a bit more details what the set_early_blank_mode
> and set_blank_mode operations do ?
>
>> > Both get_frame_done and clear_frame_done do not look at anything used at
>> > the moment and if frame done status monitoring will be ever needed, I
>> > think a better way should be implemented.
>>
>> You are right, as of now Exynos MIPI DSI Panels are NOT using these
>> callbacks, but as you mentioned we will need frame done status monitoring
>> anyways, so i included these callbacks here. Will check, if we can implement
>> any better method.
>
> Do you expect the entity drivers (and in particular the panel drivers) to
> require frame done notification ? If so, could you explain your use case(s) ?
>
Hi Laurent,
As you know, there are two types of MIPI-DSI based lcd panels, RGB and
CPU mode. In case of CPU mode lcd panel, it has its own framebuffer
internally and the image in the framebuffer is transferred on lcd
panel in 60Hz itself. But for this, there is something we should
consider. The display controller with CPU mode doens't transfer image
data to MIPI-DSI controller itself. So we should set trigger bit of
the display controller to 1 to do it and also check whether the data
transmission in the framebuffer is done on lcd panel to avoid tearing
issue and some confliction issue(A) between read and write operations
like below,
lcd_panel_frame_done_interrrupt_handler()
{
...
if (mipi-dsi frame done)
trigger display controller;
...
}
A. the issue that LCD panel can access its own framebuffer while some
new data from MIPI-DSI controller is being written in the framebuffer.
But I think there might be better way to avoid such thing.
Thanks,
Inki Dae
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe 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/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct
Hi Laurent,
On 10 January 2013 05:05, Laurent Pinchart
wrote:
> Hi Vikas,
>
> Thank you for the patch.
>
> On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote:
>> On 3 January 2013 16:29, Tomasz Figa wrote:
>> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
>> >> From: Vikas Sajjan
>> >>
>> >> Signed-off-by: Vikas Sajjan
>> >> ---
>> >>
>> >> include/video/display.h |6 ++
>> >> 1 file changed, 6 insertions(+)
>> >>
>> >> diff --git a/include/video/display.h b/include/video/display.h
>> >> index b639fd0..fb2f437 100644
>> >> --- a/include/video/display.h
>> >> +++ b/include/video/display.h
>> >> @@ -117,6 +117,12 @@ struct dsi_video_source_ops {
>> >>
>> >> void (*enable_hs)(struct video_source *src, bool enable);
>> >>
>> >> + /* frame related */
>> >> + int (*get_frame_done)(struct video_source *src);
>> >> + int (*clear_frame_done)(struct video_source *src);
>> >> + int (*set_early_blank_mode)(struct video_source *src, int power);
>> >> + int (*set_blank_mode)(struct video_source *src, int power);
>> >> +
>> >
>> > I'm not sure if all those extra ops are needed in any way.
>> >
>> > Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only
>> > FB_BLANK_UNBLANK status, which basically equals to the already existing
>> > enable operation, while set_early_blank mode handles only
>> > FB_BLANK_POWERDOWN, being equal to disable callback.
>>
>> Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as
>> of now, but FB_BLANK_NORMAL will be supported in future.
>> If not for Exynos, i think it will be need for other SoCs which
>> support FB_BLANK_UNBLANK and FB_BLANK_NORMAL.
>
> Could you please explain in a bit more details what the set_early_blank_mode
> and set_blank_mode operations do ?
>
with reference to Mr. Inki Dae's patch and discussion
http://lkml.indiana.edu/hypermail/linux/kernel/1109.1/00413.html
http://lkml.indiana.edu/hypermail/linux/kernel/1109.1/02247.html
set_early_blank_mode:
- sets the framebuffer blank mode.
- this callback should be called prior to fb_blank() by a client
driver only if needed
set_blank_mode:
- sets framebuffer blank mode
- this callback should be called after fb_blank() by a client
driver only if needed.
In case of MIPI-DSI based video mode LCD Panel, for lcd power off, the
power off commands should be transferred to lcd panel with display and
mipi-dsi controller enabled, because the commands is set to lcd panel
at vsync porch period, hence set_early_blank_mode() was introduced and
should be called prior to fb_blank() as mentioned in the above 2
links.
I think Mr. Inki Dae can throw more light on this.
>> > Both get_frame_done and clear_frame_done do not look at anything used at
>> > the moment and if frame done status monitoring will be ever needed, I
>> > think a better way should be implemented.
>>
>> You are right, as of now Exynos MIPI DSI Panels are NOT using these
>> callbacks, but as you mentioned we will need frame done status monitoring
>> anyways, so i included these callbacks here. Will check, if we can implement
>> any better method.
>
> Do you expect the entity drivers (and in particular the panel drivers) to
> require frame done notification ? If so, could you explain your use case(s) ?
>
In our Exynos MIPI DSIM H/W, once MIPI DSIM transfers whole image
frame, interrupt will raised to indicate the same.
as part of the mipi_dsim_master_ops() we have get_dsim_frame_done()
and clear_dsim_frame_done() ops. But as of now we are also _NOT_ using
these ops in any particular use case. So i guess as of now we can park
it, later if we find any need for the same we can add it.
> --
> Regards,
>
> Laurent Pinchart
>
--
Thanks and Regards
Vikas Sajjan
SAMSUNG Research India - Banglore.
--
To unsubscribe from this list: send the line "unsubscribe 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/6 v5] media: V4L2: support asynchronous subdevice registration
Hi Guennadi,
Nice Work, Thanks for the patch.
On Tue, Jan 8, 2013 at 3:36 PM, Guennadi Liakhovetski
wrote:
> Currently bridge device drivers register devices for all subdevices
> synchronously, tupically, during their probing. E.g. if an I2C CMOS sensor
> is attached to a video bridge device, the bridge driver will create an I2C
> device and wait for the respective I2C driver to probe. This makes linking
> of devices straight forward, but this approach cannot be used with
> intrinsically asynchronous and unordered device registration systems like
> the Flattened Device Tree. To support such systems this patch adds an
> asynchronous subdevice registration framework to V4L2. To use it respective
> (e.g. I2C) subdevice drivers must request deferred probing as long as their
> bridge driver hasn't probed. The bridge driver during its probing submits a
> an arbitrary number of subdevice descriptor groups to the framework to
> manage. After that it can add callbacks to each of those groups to be
> called at various stages during subdevice probing, e.g. after completion.
> Then the bridge driver can request single groups to be probed, finish its
> own probing and continue its video subsystem configuration from its
> callbacks.
>
> Signed-off-by: Guennadi Liakhovetski
Tested-by: Lad, Prabhakar
Regards,
--Prabhakar Lad
> ---
> v5: Now really fix the case, when subdevices probe successfully before the
> bridge, thanks to Prabhakar for testing and reporting
>
> drivers/media/v4l2-core/Makefile |3 +-
> drivers/media/v4l2-core/v4l2-async.c | 294
> ++
> include/media/v4l2-async.h | 113 +
> 3 files changed, 409 insertions(+), 1 deletions(-)
> create mode 100644 drivers/media/v4l2-core/v4l2-async.c
> create mode 100644 include/media/v4l2-async.h
>
> diff --git a/drivers/media/v4l2-core/Makefile
> b/drivers/media/v4l2-core/Makefile
> index d065c01..b667ced 100644
> --- a/drivers/media/v4l2-core/Makefile
> +++ b/drivers/media/v4l2-core/Makefile
> @@ -5,7 +5,8 @@
> tuner-objs := tuner-core.o
>
> videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
> - v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o
> + v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o \
> + v4l2-async.o
> ifeq ($(CONFIG_COMPAT),y)
>videodev-objs += v4l2-compat-ioctl32.o
> endif
> diff --git a/drivers/media/v4l2-core/v4l2-async.c
> b/drivers/media/v4l2-core/v4l2-async.c
> new file mode 100644
> index 000..434c53d
> --- /dev/null
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -0,0 +1,294 @@
> +/*
> + * V4L2 asynchronous subdevice registration API
> + *
> + * Copyright (C) 2012, Guennadi Liakhovetski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static bool match_i2c(struct device *dev, struct v4l2_async_hw_device
> *hw_dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + return hw_dev->bus_type == V4L2_ASYNC_BUS_I2C &&
> + hw_dev->match.i2c.adapter_id == client->adapter->nr &&
> + hw_dev->match.i2c.address == client->addr;
> +}
> +
> +static bool match_platform(struct device *dev, struct v4l2_async_hw_device
> *hw_dev)
> +{
> + return hw_dev->bus_type == V4L2_ASYNC_BUS_PLATFORM &&
> + !strcmp(hw_dev->match.platform.name, dev_name(dev));
> +}
> +
> +static LIST_HEAD(subdev_list);
> +static LIST_HEAD(notifier_list);
> +static DEFINE_MUTEX(list_lock);
> +
> +static struct v4l2_async_subdev *v4l2_async_belongs(struct
> v4l2_async_notifier *notifier,
> + struct
> v4l2_async_subdev_list *asdl)
> +{
> + struct v4l2_async_subdev *asd = NULL;
> + bool (*match)(struct device *,
> + struct v4l2_async_hw_device *);
> +
> + list_for_each_entry (asd, ¬ifier->waiting, list) {
> + struct v4l2_async_hw_device *hw = &asd->hw;
> + switch (hw->bus_type) {
> + case V4L2_ASYNC_BUS_SPECIAL:
> + match = hw->match.special.match;
> + if (!match)
> + /* Match always */
> + return asd;
> + break;
> + case V4L2_ASYNC_BUS_PLATFORM:
> + match = match_platform;
> + break;
> + case V4L2_ASYNC_BUS_I2C:
> + match = match_i2c;
> + break;
> + default:
> + /* Oops */
> +
RE: [PATCHv16 0/7] of: add display helper
Hi Steffen, On Thu, Jan 10, 2013 at 01:45:41, Steffen Trumtrar wrote: > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK To clarify, This series was tested with DT boot (making use of the functionalities provided by this series) on AM335X EVM & AM335X EVM-SK. DA850 EVM was tested with non DT boot along with this series (to make sure that non-DT boot on DA850 EVM is not broken, and it needed the additional change that was mentioned earlier) Sorry that my initial reply did not express what I wanted to. Regards Afzal
Re: [PATCHv16 0/7] of: add display helper
Hi Steffen, On Thu, Jan 10, 2013 at 1:45 AM, Steffen Trumtrar wrote: > > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > > > So, any more criticism on the series? Any takers for the series as is? > I guess it could be merged via the fbdev-tree if David Airlie can agree > to the DRM patches ?! Does that sound about right? > > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK > > I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala > are using. I tested V16 patches with Exynos: smdk5250 board and it works fine for me. > Those are the people I know from the top of my head, that use > or at least did use the patches in one of its iterations. If I forgot > anyone, please speak up and possibly add your new HW to the list of tested > devices. > > Thanks, > Steffen > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] update scan files for Ireland (ie-*)
Hi Oliver, Attached are two patches I've been trying to get applied to the tree for some time. Thanks, Jon Jonathan McCrohan (2): update scan files for Ireland (ie-*) update scan files for Ireland (ie-*) dvb-t/ie-CairnHill |6 +++--- dvb-t/ie-ClermontCarn |6 +++--- dvb-t/ie-Dungarvan |6 +++--- dvb-t/ie-HolywellHill |4 ++-- dvb-t/ie-Kippure |6 +++--- dvb-t/ie-Maghera |6 +++--- dvb-t/ie-MountLeinster |6 +++--- dvb-t/ie-Mullaghanish |6 +++--- dvb-t/ie-SpurHill |6 +++--- dvb-t/ie-ThreeRock |6 +++--- dvb-t/ie-Truskmore |6 +++--- dvb-t/ie-WoodcockHill |6 +++--- 12 files changed, 35 insertions(+), 35 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] update scan files for Ireland (ie-*)
ASO frequency changes; effective 24th Oct 2012. Signed-off-by: Jonathan McCrohan --- dvb-t/ie-CairnHill |2 +- dvb-t/ie-ClermontCarn |6 +++--- dvb-t/ie-Dungarvan |2 +- dvb-t/ie-HolywellHill |4 ++-- dvb-t/ie-Kippure |2 +- dvb-t/ie-Maghera |2 +- dvb-t/ie-MountLeinster |6 +++--- dvb-t/ie-Mullaghanish |2 +- dvb-t/ie-SpurHill |2 +- dvb-t/ie-ThreeRock |6 +++--- dvb-t/ie-Truskmore |2 +- dvb-t/ie-WoodcockHill |2 +- 12 files changed, 19 insertions(+), 19 deletions(-) diff --git a/dvb-t/ie-CairnHill b/dvb-t/ie-CairnHill index 002881a..5063ce9 100644 --- a/dvb-t/ie-CairnHill +++ b/dvb-t/ie-CairnHill @@ -1,5 +1,5 @@ # Ireland, Cairn Hill -# Generated from http://www.comreg.ie/_fileupload/File/Technical%20Parameters_20111004.xlsx +# Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 68200 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH47: Saorview MUX1 T 65800 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH44: Saorview MUX2 diff --git a/dvb-t/ie-ClermontCarn b/dvb-t/ie-ClermontCarn index 680ffce..df9d06b 100644 --- a/dvb-t/ie-ClermontCarn +++ b/dvb-t/ie-ClermontCarn @@ -1,5 +1,5 @@ # Ireland, Clermont Carn -# Generated from http://www.comreg.ie/_fileupload/File/Technical%20Parameters_20111004.xlsx +# Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 73000 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH53: Saorview MUX1 -T 76200 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH57: Saorview MUX2 +T 72200 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH52: Saorview MUX1 +T 75400 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH56: Saorview MUX2 diff --git a/dvb-t/ie-Dungarvan b/dvb-t/ie-Dungarvan index 7f5d6a3..5bdf714 100644 --- a/dvb-t/ie-Dungarvan +++ b/dvb-t/ie-Dungarvan @@ -1,5 +1,5 @@ # Ireland, Dungarvan -# Generated from http://www.comreg.ie/_fileupload/File/Technical%20Parameters_20111004.xlsx +# Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 74600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH55: Saorview MUX1 T 77800 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH59: Saorview MUX2 diff --git a/dvb-t/ie-HolywellHill b/dvb-t/ie-HolywellHill index 4557ec1..a3f55be 100644 --- a/dvb-t/ie-HolywellHill +++ b/dvb-t/ie-HolywellHill @@ -1,5 +1,5 @@ # Ireland, Holywell Hill -# Generated from http://www.comreg.ie/_fileupload/File/Technical%20Parameters_20111004.xlsx +# Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 54600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH30: Saorview MUX1 -T 50600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH25: Saorview MUX2 +T 57000 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH33: Saorview MUX2 diff --git a/dvb-t/ie-Kippure b/dvb-t/ie-Kippure index 723f7be..aeb5d8d 100644 --- a/dvb-t/ie-Kippure +++ b/dvb-t/ie-Kippure @@ -1,5 +1,5 @@ # Ireland, Kippure -# Generated from http://www.comreg.ie/_fileupload/File/Technical%20Parameters_20111004.xlsx +# Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 73800 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH54: Saorview MUX1 T 77000 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH58: Saorview MUX2 diff --git a/dvb-t/ie-Maghera b/dvb-t/ie-Maghera index 8144c38..a1da82a 100644 --- a/dvb-t/ie-Maghera +++ b/dvb-t/ie-Maghera @@ -1,5 +1,5 @@ # Ireland, Maghera -# Generated from http://www.comreg.ie/_fileupload/File/Technical%20Parameters_20111004.xlsx +# Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 69000 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH48: Saorview MUX1 T 74600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH55: Saorview MUX2 diff --git a/dvb-t/ie-MountLeinster b/dvb-t/ie-MountLeinster index 780ac0a..e5515c2 100644 --- a/dvb-t/ie-MountLeinster +++ b/dvb-t/ie-MountLeinster @@ -1,5 +1,5 @@ # Ireland, Mount Leinster -# Generated from http://www.comreg.ie/_fileupload/File/Technical%20Parameters_20111004.xlsx +# Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 66600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH45: Saorview MUX1 -T 61800 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH39: Saorview MUX2 +T 49000 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH23: Saorview MUX1 +T 51400 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH26: Saorview MUX2 diff --git a/dvb-t/ie-Mullaghanish b/dvb-t/ie-Mullaghanish index aae3e97..73e6ffe 100644 --- a/dvb-t/ie-Mullaghanish
[PATCH 2/2] update scan files for Ireland (ie-*)
Fix erroneous transmission parameters Signed-off-by: Jonathan McCrohan --- dvb-t/ie-CairnHill|4 ++-- dvb-t/ie-Dungarvan|4 ++-- dvb-t/ie-Kippure |4 ++-- dvb-t/ie-Maghera |4 ++-- dvb-t/ie-Mullaghanish |4 ++-- dvb-t/ie-SpurHill |4 ++-- dvb-t/ie-Truskmore|4 ++-- dvb-t/ie-WoodcockHill |4 ++-- 8 files changed, 16 insertions(+), 16 deletions(-) diff --git a/dvb-t/ie-CairnHill b/dvb-t/ie-CairnHill index 5063ce9..b36272f 100644 --- a/dvb-t/ie-CairnHill +++ b/dvb-t/ie-CairnHill @@ -1,5 +1,5 @@ # Ireland, Cairn Hill # Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 68200 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH47: Saorview MUX1 -T 65800 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH44: Saorview MUX2 +T 68200 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH47: Saorview MUX1 +T 65800 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH44: Saorview MUX2 diff --git a/dvb-t/ie-Dungarvan b/dvb-t/ie-Dungarvan index 5bdf714..f415097 100644 --- a/dvb-t/ie-Dungarvan +++ b/dvb-t/ie-Dungarvan @@ -1,5 +1,5 @@ # Ireland, Dungarvan # Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 74600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH55: Saorview MUX1 -T 77800 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH59: Saorview MUX2 +T 74600 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH55: Saorview MUX1 +T 77800 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH59: Saorview MUX2 diff --git a/dvb-t/ie-Kippure b/dvb-t/ie-Kippure index aeb5d8d..56ad12a 100644 --- a/dvb-t/ie-Kippure +++ b/dvb-t/ie-Kippure @@ -1,5 +1,5 @@ # Ireland, Kippure # Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 73800 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH54: Saorview MUX1 -T 77000 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH58: Saorview MUX2 +T 73800 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH54: Saorview MUX1 +T 77000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH58: Saorview MUX2 diff --git a/dvb-t/ie-Maghera b/dvb-t/ie-Maghera index a1da82a..11c08b7 100644 --- a/dvb-t/ie-Maghera +++ b/dvb-t/ie-Maghera @@ -1,5 +1,5 @@ # Ireland, Maghera # Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 69000 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH48: Saorview MUX1 -T 74600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH55: Saorview MUX2 +T 69000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH48: Saorview MUX1 +T 74600 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH55: Saorview MUX2 diff --git a/dvb-t/ie-Mullaghanish b/dvb-t/ie-Mullaghanish index 73e6ffe..35dc5dd 100644 --- a/dvb-t/ie-Mullaghanish +++ b/dvb-t/ie-Mullaghanish @@ -1,5 +1,5 @@ # Ireland, Mullaghanish # Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 47400 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH21: Saorview MUX1 -T 49800 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH24: Saorview MUX2 +T 47400 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH21: Saorview MUX1 +T 49800 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH24: Saorview MUX2 diff --git a/dvb-t/ie-SpurHill b/dvb-t/ie-SpurHill index a211e93..7566d82 100644 --- a/dvb-t/ie-SpurHill +++ b/dvb-t/ie-SpurHill @@ -1,5 +1,5 @@ # Ireland, Spur Hill # Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 66600 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH45: Saorview MUX1 -T 69800 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH49: Saorview MUX2 +T 66600 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH45: Saorview MUX1 +T 69800 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH49: Saorview MUX2 diff --git a/dvb-t/ie-Truskmore b/dvb-t/ie-Truskmore index db71c31..178bfe3 100644 --- a/dvb-t/ie-Truskmore +++ b/dvb-t/ie-Truskmore @@ -1,5 +1,5 @@ # Ireland, Truskmore # Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 73000 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH53: Saorview MUX1 -T 76200 8MHz 3/4 NONE QAM16 2k 1/32 NONE # CH57: Saorview MUX2 +T 73000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH53: Saorview MUX1 +T 76200 8MHz 3/4 NONE QAM64 8k 1/32 NONE # CH57: Saorview MUX2 diff --git a/dvb-t/ie-WoodcockHill b/dvb-t/ie-WoodcockHill index 513dda5..08c1d5b 100644 --- a/dvb-t/ie-WoodcockHill +++ b/dvb-t/ie-WoodcockHill @@ -1,5 +1,5 @@ # Ireland, Woodcock Hill # Generated from http://www.comreg.ie/_fileupload/Broadcast_Technical_Parameters.xlsx # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 68200
Re: global mutex in dvb_usercopy (dvbdev.c)
On 09.01.2013 22:30, Nikolaus Schulz wrote: On Tue, Jan 08, 2013 at 12:05:47PM +0530, Soby Mathew wrote: Hi Everyone, I have a doubt regarding about the global mutex lock in dvb_usercopy(drivers/media/dvb-core/dvbdev.c, line 382) . /* call driver */ mutex_lock(&dvbdev_mutex); if ((err = func(file, cmd, parg)) == -ENOIOCTLCMD) err = -EINVAL; mutex_unlock(&dvbdev_mutex); Why is this mutex needed? When I check similar functions like video_usercopy, this kind of global locking is not present when func() is called. I cannot say anything about video_usercopy(), but as it happens, there's a patch[1] queued for Linux 3.9 that will hopefully replace the mutex in dvb_usercopy() with more fine-grained locking. Nikolaus [1] http://git.linuxtv.org/media_tree.git/commit/30ad64b8ac539459f8975aa186421ef3db0bb5cb "Unfortunately, frontend ioctls can be blocked by the frontend thread for several seconds; this leads to unacceptable lock contention." Especially the stv0297 signal locking, as it turned out in situations of bad signal input or my cable providers outtage today it has slowed down dvb_ttpci (notable as OSD- output latency and possibly driver buffer overflows of budget source devices) that much that I had to disable tuning with parm --outputonly in vdr-plugin-dvbsddevice. Can anyone confirm that and have a look at the other frontend drivers for tuners needing as much driver control? I will try to apply the patch manually to Linux 3.2 and check with Latencytop tomorrow. y tom -- To unsubscribe from this list: send the line "unsubscribe 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 v1.2 1/4] v4l: Define video buffer flags for timestamp types
Hi Sakari, On Sunday 02 December 2012 22:53:51 Sakari Ailus wrote: > On Tue, Nov 27, 2012 at 05:04:29PM +0100, Laurent Pinchart wrote: > > On Thursday 22 November 2012 01:59:00 Sakari Ailus wrote: > > > On Wed, Nov 21, 2012 at 11:53:02PM +0100, Hans Verkuil wrote: > ,,, > > > > > What do you think? > > > > > > Fine for me. Sylwester also brought memory-to-memory devices (and > > > memory-to-memory processing whether the device is classified as such in > > > API or not) to my attention. For those devices it likely wouldn't matter > > > at all what's the system time when the frame is processed since the > > > frame wasn't captured at that time anyway. > > > > > > In those cases it might makes sense to use timestamp that e.g. comes > > > from the compressed stream, or pass encoder timestamps that are going to > > > be part of the compressed stream. I think MPEG-related use cases were > > > briefly mentioned in the timestamp discussion earlier. > > > > When uncompressing a stream you will get the MPEG embedded timestamp on > > the capture side. The timestamp returned to userspace at QBUF time on the > > output side will still be unused. I don't really see a use case for > > returning the timestamp at which the frame is expected to be processed by > > the codec, so we could just make the field reserved for future use in > > that case. > > Is the timestamp embedded in the compressed data itself in that case, or > where? Yes, it's embedded in the compressed stream. > Could this be codec-dependent? Of course, it would be too easy otherwise :-) > > > > > The driver stores the time at which > > > > > + the first data byte was actually sent out in the > > > > > + timestamp field. > > > > > > > > Same problem as with the capture time: does the timestamp refer to the > > > > first or last byte that's sent out? I think all output drivers set it > > > > to the time of the last byte (== when the DMA of the frame is > > > > finished). > > > > > > I haven't actually even seen a capture driver that would do otherwise, > > > but that could be just me not knowing many enough. :-) Would we actually > > > break something if we changed the definition to say that this is the > > > timestamp taken when the frame is done? > > > > For software timestamps we could do that, but for hardware timestamps the > > exact timestamping time may vary. > > Should we then do this for the timestamps that are obtained from the system > clock? We also haven't defined other kinds of tiemstamps yet. That sounds good to me. > For timestamp types that are hardware-dependent we could have exceptions. -- 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 01/23] uvc: Replace memcpy with struct assignment
Hi Ezequiel, On Thursday 27 December 2012 21:49:37 Mauro Carvalho Chehab wrote: > Em Thu, 27 Dec 2012 18:12:46 -0300 Ezequiel Garcia escreveu: > > On Tue, Oct 23, 2012 at 4:57 PM, Ezequiel Garcia wrote: > > > This kind of memcpy() is error-prone. Its replacement with a struct > > > assignment is prefered because it's type-safe and much easier to read. > > > > > > Found by coccinelle. Hand patched and reviewed. > > > Tested by compilation only. > > > > > > A simplified version of the semantic match that finds this problem is as > > > follows: (http://coccinelle.lip6.fr/) > > > > > > // > > > @@ > > > identifier struct_name; > > > struct struct_name to; > > > struct struct_name from; > > > expression E; > > > @@ > > > -memcpy(&(to), &(from), E); > > > +to = from; > > > // > > > > > > Cc: Laurent Pinchart > > > Signed-off-by: Peter Senna Tschudin > > > Signed-off-by: Ezequiel Garcia > > > --- > > > > > > drivers/media/usb/uvc/uvc_v4l2.c |6 +++--- > > > 1 files changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c > > > b/drivers/media/usb/uvc/uvc_v4l2.c index f00db30..4fc8737 100644 > > > --- a/drivers/media/usb/uvc/uvc_v4l2.c > > > +++ b/drivers/media/usb/uvc/uvc_v4l2.c > > > @@ -314,7 +314,7 @@ static int uvc_v4l2_set_format(struct uvc_streaming > > > *stream, > > > goto done; > > > } > > > > > > - memcpy(&stream->ctrl, &probe, sizeof probe); > > > + stream->ctrl = probe; > > > > > > stream->cur_format = format; > > > stream->cur_frame = frame; > > > @@ -386,7 +386,7 @@ static int uvc_v4l2_set_streamparm(struct > > > uvc_streaming *stream, > > > return -EBUSY; > > > } > > > > > > - memcpy(&probe, &stream->ctrl, sizeof probe); > > > + probe = stream->ctrl; > > > probe.dwFrameInterval = > > > uvc_try_frame_interval(stream->cur_frame, interval); > > > > > > @@ -397,7 +397,7 @@ static int uvc_v4l2_set_streamparm(struct > > > uvc_streaming *stream, > > > return ret; > > > } > > > > > > - memcpy(&stream->ctrl, &probe, sizeof probe); > > > + stream->ctrl = probe; > > > mutex_unlock(&stream->mutex); > > > > > > /* Return the actual frame period. */ > > > > It seems you've marked this one as "Changes requested" [1]. > > However, Laurent didn't request any change, > > but just pointed out we missed one memcpy replacement candidate. > > > > I believe it's safe to apply the patch (together with the other 20 > > patches) and we can fix the missing spot in another patch. > > The other patches got applied already. Well just do whatever Laurent asked > you and re-submit this one ;) Could you please resubmit this patch with the missed memcpy replaced by a struct assignment ? I'll then add it to my tree. -- 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 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct
Hi Vikas,
Thank you for the patch.
On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote:
> On 3 January 2013 16:29, Tomasz Figa wrote:
> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote:
> >> From: Vikas Sajjan
> >>
> >> Signed-off-by: Vikas Sajjan
> >> ---
> >>
> >> include/video/display.h |6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/include/video/display.h b/include/video/display.h
> >> index b639fd0..fb2f437 100644
> >> --- a/include/video/display.h
> >> +++ b/include/video/display.h
> >> @@ -117,6 +117,12 @@ struct dsi_video_source_ops {
> >>
> >> void (*enable_hs)(struct video_source *src, bool enable);
> >>
> >> + /* frame related */
> >> + int (*get_frame_done)(struct video_source *src);
> >> + int (*clear_frame_done)(struct video_source *src);
> >> + int (*set_early_blank_mode)(struct video_source *src, int power);
> >> + int (*set_blank_mode)(struct video_source *src, int power);
> >> +
> >
> > I'm not sure if all those extra ops are needed in any way.
> >
> > Looking and Exynos MIPI DSIM driver, set_blank_mode is handling only
> > FB_BLANK_UNBLANK status, which basically equals to the already existing
> > enable operation, while set_early_blank mode handles only
> > FB_BLANK_POWERDOWN, being equal to disable callback.
>
> Right, exynos_mipi_dsi_blank_mode() only supports FB_BLANK_UNBLANK as
> of now, but FB_BLANK_NORMAL will be supported in future.
> If not for Exynos, i think it will be need for other SoCs which
> support FB_BLANK_UNBLANK and FB_BLANK_NORMAL.
Could you please explain in a bit more details what the set_early_blank_mode
and set_blank_mode operations do ?
> > Both get_frame_done and clear_frame_done do not look at anything used at
> > the moment and if frame done status monitoring will be ever needed, I
> > think a better way should be implemented.
>
> You are right, as of now Exynos MIPI DSI Panels are NOT using these
> callbacks, but as you mentioned we will need frame done status monitoring
> anyways, so i included these callbacks here. Will check, if we can implement
> any better method.
Do you expect the entity drivers (and in particular the panel drivers) to
require frame done notification ? If so, could you explain your use case(s) ?
--
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: Fwd: update Finland DVB-T tuning files
On 01/09/13 16:26, Antti Palosaari wrote: Oliver, could you apply that one? http://git.schinagl.nl/cgi-bin/cgit.cgi/dvb_frequency_scanfiles.git applied to my local branch. Once I get git access fixed to linuxtv, i'll post all my patches to the new dtv-scan-files tree! oliver Antti Original Message Subject: update Finland DVB-T tuning files Date: Mon, 23 Jul 2012 23:57:02 +0300 From: Antti Palosaari To: Christoph Pfister ,linux-media Christoph, apply attached patch thanks! Antti -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3isp: Add support for interlaced input data
Hi William, On Tuesday 08 January 2013 14:49:41 William Swanson wrote: > On 01/07/2013 04:20 AM, Laurent Pinchart wrote: > > What do you get in the memory buffers ? Are fields captured in separate > > buffers or combined in a single buffer ? If they're combined, are they > > interleaved or sequential in memory ? > > I believe the data is combined in a single buffer, with alternate fields > interleaved. Could you please double-check that ? I'd like to be sure, not just believe :-) In that case the OMAP3 ISP driver should set the v4l2_pix_format::field to V4L2_FIELD_INTERLACED in the format-related ioctl when an interlaced format is used. I suppose this could be added later - Sakari, any opinion ? -- 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: global mutex in dvb_usercopy (dvbdev.c)
On Tue, Jan 08, 2013 at 12:05:47PM +0530, Soby Mathew wrote: > Hi Everyone, > I have a doubt regarding about the global mutex lock in > dvb_usercopy(drivers/media/dvb-core/dvbdev.c, line 382) . > > > /* call driver */ > mutex_lock(&dvbdev_mutex); > if ((err = func(file, cmd, parg)) == -ENOIOCTLCMD) > err = -EINVAL; > mutex_unlock(&dvbdev_mutex); > > > Why is this mutex needed? When I check similar functions like > video_usercopy, this kind of global locking is not present when func() > is called. I cannot say anything about video_usercopy(), but as it happens, there's a patch[1] queued for Linux 3.9 that will hopefully replace the mutex in dvb_usercopy() with more fine-grained locking. Nikolaus [1] http://git.linuxtv.org/media_tree.git/commit/30ad64b8ac539459f8975aa186421ef3db0bb5cb -- To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv16 0/7] of: add display helper
On Wed, Jan 09, 2013 at 09:15:41PM +0100, Steffen Trumtrar wrote: > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > > > So, any more criticism on the series? Any takers for the series as is? > I guess it could be merged via the fbdev-tree if David Airlie can agree > to the DRM patches ?! Does that sound about right? > > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK > > I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala > are using. Those are the people I know from the top of my head, that use > or at least did use the patches in one of its iterations. If I forgot > anyone, please speak up and possibly add your new HW to the list of tested > devices. I tested earlier versions on Tegra. The latest one was v15 I think. Thierry pgpNAKduiOz6G.pgp Description: PGP signature
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Jan 9 19:00:17 CET 2013 git hash:73ec66c000e9816806c7380ca3420f4e0638c40e gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: ERRORS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-i686: WARNINGS linux-3.8-rc1-i686: OK linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-x86_64: WARNINGS linux-3.8-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification 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: [PATCHv16 0/7] of: add display helper
Dear Steffen Trumtrar, > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > So, any more criticism on the series? Any takers for the series as is? > I guess it could be merged via the fbdev-tree if David Airlie can agree > to the DRM patches ?! Does that sound about right? > > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK > > I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala > are using. MX53QSB and another custom MX53 board. > Those are the people I know from the top of my head, that use > or at least did use the patches in one of its iterations. If I forgot > anyone, please speak up and possibly add your new HW to the list of tested > devices. > > Thanks, > Steffen Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe 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] em28xx: fix analog streaming with USB bulk transfers
Am 09.01.2013 21:52, schrieb Frank Schäfer:
> With the conversion to videobuf2, some unnecessary calls of
> em28xx_set_alternate() have been removed. It is now called at analog streaming
> start only.
> This has unveiled a bug that causes USB bulk transfers to fail with all urbs
> having status -EVOERFLOW.
> The reason is, that for bulk transfers usb_set_interface() needs to be called
> even if the previous alt setting was the same (side note: bulk transfers seem
> to work only with alt=0).
> While it seems to be NOT necessary for isoc transfers, it's reasonable to just
> call usb_set_interface() unconditionally in em28xx_set_alternate().
> Also add a comment that explains the issue to prevent regressions in the
> future.
The problem is, that I would really like to understand why the old code
was working...
Maybe the reason is hidden somewhere in videobuf2 or it's a firmware
issue or i'm just too tired at the moment.
Regards,
Frank
>
> Signed-off-by: Frank Schäfer
> ---
> drivers/media/usb/em28xx/em28xx-core.c | 43
>
> 1 Datei geändert, 22 Zeilen hinzugefügt(+), 21 Zeilen entfernt(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-core.c
> b/drivers/media/usb/em28xx/em28xx-core.c
> index 80f87bb..ce4f252 100644
> --- a/drivers/media/usb/em28xx/em28xx-core.c
> +++ b/drivers/media/usb/em28xx/em28xx-core.c
> @@ -811,12 +811,12 @@ int em28xx_resolution_set(struct em28xx *dev)
> /* Set USB alternate setting for analog video */
> int em28xx_set_alternate(struct em28xx *dev)
> {
> - int errCode, prev_alt = dev->alt;
> + int errCode;
> int i;
> unsigned int min_pkt_size = dev->width * 2 + 4;
>
> /* NOTE: for isoc transfers, only alt settings > 0 are allowed
> - for bulk transfers, use alt=0 as default value */
> + bulk transfers seem to work only with alt=0 ! */
> dev->alt = 0;
> if ((alt > 0) && (alt < dev->num_alt)) {
> em28xx_coredbg("alternate forced to %d\n", dev->alt);
> @@ -847,25 +847,26 @@ int em28xx_set_alternate(struct em28xx *dev)
> }
>
> set_alt:
> - if (dev->alt != prev_alt) {
> - if (dev->analog_xfer_bulk) {
> - dev->max_pkt_size = 512; /* USB 2.0 spec */
> - dev->packet_multiplier = EM28XX_BULK_PACKET_MULTIPLIER;
> - } else { /* isoc */
> - em28xx_coredbg("minimum isoc packet size: %u
> (alt=%d)\n",
> -min_pkt_size, dev->alt);
> - dev->max_pkt_size =
> - dev->alt_max_pkt_size_isoc[dev->alt];
> - dev->packet_multiplier = EM28XX_NUM_ISOC_PACKETS;
> - }
> - em28xx_coredbg("setting alternate %d with wMaxPacketSize=%u\n",
> -dev->alt, dev->max_pkt_size);
> - errCode = usb_set_interface(dev->udev, 0, dev->alt);
> - if (errCode < 0) {
> - em28xx_errdev("cannot change alternate number to %d
> (error=%i)\n",
> - dev->alt, errCode);
> - return errCode;
> - }
> + /* NOTE: for bulk transfers, we need to call usb_set_interface()
> + * even if the previous settings were the same. Otherwise streaming
> + * fails with all urbs having status = -EOVERFLOW ! */
> + if (dev->analog_xfer_bulk) {
> + dev->max_pkt_size = 512; /* USB 2.0 spec */
> + dev->packet_multiplier = EM28XX_BULK_PACKET_MULTIPLIER;
> + } else { /* isoc */
> + em28xx_coredbg("minimum isoc packet size: %u (alt=%d)\n",
> +min_pkt_size, dev->alt);
> + dev->max_pkt_size =
> + dev->alt_max_pkt_size_isoc[dev->alt];
> + dev->packet_multiplier = EM28XX_NUM_ISOC_PACKETS;
> + }
> + em28xx_coredbg("setting alternate %d with wMaxPacketSize=%u\n",
> +dev->alt, dev->max_pkt_size);
> + errCode = usb_set_interface(dev->udev, 0, dev->alt);
> + if (errCode < 0) {
> + em28xx_errdev("cannot change alternate number to %d
> (error=%i)\n",
> + dev->alt, errCode);
> + return errCode;
> }
> return 0;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv16 0/7] of: add display helper
On Wednesday 09 January 2013 21:15:41 Steffen Trumtrar wrote: > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > So, any more criticism on the series? Any takers for the series as is? > I guess it could be merged via the fbdev-tree if David Airlie can agree > to the DRM patches ?! Does that sound about right? > > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK > > I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala > are using. I've used the sh-mobile-lcdcfb driver. > Those are the people I know from the top of my head, that use or at least > did use the patches in one of its iterations. If I forgot anyone, please > speak up and possibly add your new HW to the list of tested devices. -- 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
[RFC PATCH] em28xx: fix analog streaming with USB bulk transfers
With the conversion to videobuf2, some unnecessary calls of
em28xx_set_alternate() have been removed. It is now called at analog streaming
start only.
This has unveiled a bug that causes USB bulk transfers to fail with all urbs
having status -EVOERFLOW.
The reason is, that for bulk transfers usb_set_interface() needs to be called
even if the previous alt setting was the same (side note: bulk transfers seem
to work only with alt=0).
While it seems to be NOT necessary for isoc transfers, it's reasonable to just
call usb_set_interface() unconditionally in em28xx_set_alternate().
Also add a comment that explains the issue to prevent regressions in the future.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-core.c | 43
1 Datei geändert, 22 Zeilen hinzugefügt(+), 21 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index 80f87bb..ce4f252 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -811,12 +811,12 @@ int em28xx_resolution_set(struct em28xx *dev)
/* Set USB alternate setting for analog video */
int em28xx_set_alternate(struct em28xx *dev)
{
- int errCode, prev_alt = dev->alt;
+ int errCode;
int i;
unsigned int min_pkt_size = dev->width * 2 + 4;
/* NOTE: for isoc transfers, only alt settings > 0 are allowed
-for bulk transfers, use alt=0 as default value */
+bulk transfers seem to work only with alt=0 ! */
dev->alt = 0;
if ((alt > 0) && (alt < dev->num_alt)) {
em28xx_coredbg("alternate forced to %d\n", dev->alt);
@@ -847,25 +847,26 @@ int em28xx_set_alternate(struct em28xx *dev)
}
set_alt:
- if (dev->alt != prev_alt) {
- if (dev->analog_xfer_bulk) {
- dev->max_pkt_size = 512; /* USB 2.0 spec */
- dev->packet_multiplier = EM28XX_BULK_PACKET_MULTIPLIER;
- } else { /* isoc */
- em28xx_coredbg("minimum isoc packet size: %u
(alt=%d)\n",
- min_pkt_size, dev->alt);
- dev->max_pkt_size =
- dev->alt_max_pkt_size_isoc[dev->alt];
- dev->packet_multiplier = EM28XX_NUM_ISOC_PACKETS;
- }
- em28xx_coredbg("setting alternate %d with wMaxPacketSize=%u\n",
- dev->alt, dev->max_pkt_size);
- errCode = usb_set_interface(dev->udev, 0, dev->alt);
- if (errCode < 0) {
- em28xx_errdev("cannot change alternate number to %d
(error=%i)\n",
- dev->alt, errCode);
- return errCode;
- }
+ /* NOTE: for bulk transfers, we need to call usb_set_interface()
+* even if the previous settings were the same. Otherwise streaming
+* fails with all urbs having status = -EOVERFLOW ! */
+ if (dev->analog_xfer_bulk) {
+ dev->max_pkt_size = 512; /* USB 2.0 spec */
+ dev->packet_multiplier = EM28XX_BULK_PACKET_MULTIPLIER;
+ } else { /* isoc */
+ em28xx_coredbg("minimum isoc packet size: %u (alt=%d)\n",
+ min_pkt_size, dev->alt);
+ dev->max_pkt_size =
+ dev->alt_max_pkt_size_isoc[dev->alt];
+ dev->packet_multiplier = EM28XX_NUM_ISOC_PACKETS;
+ }
+ em28xx_coredbg("setting alternate %d with wMaxPacketSize=%u\n",
+ dev->alt, dev->max_pkt_size);
+ errCode = usb_set_interface(dev->udev, 0, dev->alt);
+ if (errCode < 0) {
+ em28xx_errdev("cannot change alternate number to %d
(error=%i)\n",
+ dev->alt, errCode);
+ return errCode;
}
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv16 0/7] of: add display helper
On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > Hi! > > Finally, right in time before the end of the world on friday, v16 of the > display helpers. > So, any more criticism on the series? Any takers for the series as is? I guess it could be merged via the fbdev-tree if David Airlie can agree to the DRM patches ?! Does that sound about right? I think the series was tested at least with - imx6q: sabrelite, sabresd - imx53: tqma53/mba53 - omap: DA850 EVM, AM335x EVM, EVM-SK I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala are using. Those are the people I know from the top of my head, that use or at least did use the patches in one of its iterations. If I forgot anyone, please speak up and possibly add your new HW to the list of tested devices. Thanks, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv16 0/7] of: add display helper
Dear Steffen Trumtrar,
> Hi!
>
> On Wed, Jan 09, 2013 at 08:12:01PM +0100, Marek Vasut wrote:
> > Dear Steffen Trumtrar,
> >
> > I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After
> > adding the following piece of code (quick hack), this works just fine.
> > Thanks!
> >
> > diff --git a/drivers/staging/imx-drm/parallel-display.c
> > b/drivers/staging/imx- drm/parallel-display.c
> > index a8064fc..e45002a 100644
> > --- a/drivers/staging/imx-drm/parallel-display.c
> > +++ b/drivers/staging/imx-drm/parallel-display.c
> > @@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct
> > drm_connector *connector)
> >
> > static int imx_pd_connector_get_modes(struct drm_connector *connector)
> > {
> >
> > struct imx_parallel_display *imxpd = con_to_imxpd(connector);
> >
> > + struct device_node *np = imxpd->dev->of_node;
> >
> > int num_modes = 0;
> >
> > if (imxpd->edid) {
> >
> > @@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct
> > drm_connector *connector)
> >
> > num_modes++;
> >
> > }
> >
> > + if (np) {
> > + struct drm_display_mode *mode =
> > drm_mode_create(connector->dev); +
> > of_get_drm_display_mode(np, &imxpd->mode, 0);
> > + drm_mode_copy(mode, &imxpd->mode);
> > + mode->type |= DRM_MODE_TYPE_DRIVER |
> > DRM_MODE_TYPE_PREFERRED, + drm_mode_probed_add(connector,
> > mode);
> > + num_modes++;
> > + }
> > +
> >
> > return num_modes;
> >
> > }
>
> Nice! I haven't tried the parallel display, but I think Philipp Zabel might
> already have a patch for it. If not, I will definitly keep your patch in my
> topic branch.
Works like charm here.
Make sure to adjust the patch and check for the return value of
of_get_drm_display_mode(np, &imxpd->mode, 0); call, that's probably the only
issue that needs fixing in that hack. Checking if np != NULL might not hurt
either. I can roll you a real patch if it helps.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv16 0/7] of: add display helper
Hi!
On Wed, Jan 09, 2013 at 08:12:01PM +0100, Marek Vasut wrote:
> Dear Steffen Trumtrar,
>
> I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After
> adding
> the following piece of code (quick hack), this works just fine. Thanks!
>
> diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-
> drm/parallel-display.c
> index a8064fc..e45002a 100644
> --- a/drivers/staging/imx-drm/parallel-display.c
> +++ b/drivers/staging/imx-drm/parallel-display.c
> @@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct drm_connector
> *connector)
> static int imx_pd_connector_get_modes(struct drm_connector *connector)
> {
> struct imx_parallel_display *imxpd = con_to_imxpd(connector);
> + struct device_node *np = imxpd->dev->of_node;
> int num_modes = 0;
>
> if (imxpd->edid) {
> @@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct drm_connector
> *connector)
> num_modes++;
> }
>
> + if (np) {
> + struct drm_display_mode *mode =
> drm_mode_create(connector->dev);
> + of_get_drm_display_mode(np, &imxpd->mode, 0);
> + drm_mode_copy(mode, &imxpd->mode);
> + mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> + drm_mode_probed_add(connector, mode);
> + num_modes++;
> + }
> +
> return num_modes;
> }
>
Nice! I haven't tried the parallel display, but I think Philipp Zabel might
already have a patch for it. If not, I will definitly keep your patch in my
topic branch.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv16 0/7] of: add display helper
Dear Steffen Trumtrar,
> Hi!
>
> Finally, right in time before the end of the world on friday, v16 of the
> display helpers.
I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After adding
the following piece of code (quick hack), this works just fine. Thanks!
diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-
drm/parallel-display.c
index a8064fc..e45002a 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct drm_connector
*connector)
static int imx_pd_connector_get_modes(struct drm_connector *connector)
{
struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+ struct device_node *np = imxpd->dev->of_node;
int num_modes = 0;
if (imxpd->edid) {
@@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct drm_connector
*connector)
num_modes++;
}
+ if (np) {
+ struct drm_display_mode *mode = drm_mode_create(connector->dev);
+ of_get_drm_display_mode(np, &imxpd->mode, 0);
+ drm_mode_copy(mode, &imxpd->mode);
+ mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+ drm_mode_probed_add(connector, mode);
+ num_modes++;
+ }
+
return num_modes;
}
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/3] davinci: vpif: capture: add V4L2-async support
Hi Hans,
Thanks for the review!
On Wed, Jan 9, 2013 at 9:12 PM, Hans Verkuil wrote:
> On Wed 9 January 2013 14:41:25 Lad, Prabhakar wrote:
>> Add support for asynchronous subdevice probing, using the v4l2-async API.
>> The legacy synchronous mode is still supported too, which allows to
>> gradually update drivers and platforms. The selected approach adds a
>> notifier for each struct soc_camera_device instance, i.e. for each video
>> device node, even when there are multiple such instances registered with a
>> single soc-camera host simultaneously.
>
> This comment was obviously copy-and-pasted from somewhere else :-)
>
ah my bad :-)
>>
>> Signed-off-by: Lad, Prabhakar
>> Cc: Guennadi Liakhovetski
>> Cc: Hans Verkuil
>> Cc: Laurent Pinchart
>> Cc: Sakari Ailus
>> Cc: Mauro Carvalho Chehab
>> ---
>> drivers/media/platform/davinci/vpif_capture.c | 171
>> ++---
>> drivers/media/platform/davinci/vpif_capture.h |2 +
>> include/media/davinci/vpif_types.h|2 +
>> 3 files changed, 128 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/media/platform/davinci/vpif_capture.c
>> b/drivers/media/platform/davinci/vpif_capture.c
>> index 5892d2b..a8b6588 100644
>> --- a/drivers/media/platform/davinci/vpif_capture.c
>> +++ b/drivers/media/platform/davinci/vpif_capture.c
>> @@ -34,6 +34,8 @@
>> #include
>> #include
>> #include
>> +
>> +#include
>> #include
>> #include
>> #include
>> @@ -2054,6 +2056,96 @@ vpif_init_free_channel_objects:
>> return err;
>> }
>>
>> +int vpif_async_bound(struct v4l2_async_notifier *notifier,
>> + struct v4l2_async_subdev_list *asdl)
>> +{
>> + int i = 0;
>> +
>> + if (!asdl->subdev) {
>> + v4l2_err(vpif_dev->driver,
>> + "%s(): Subdevice driver hasn't set subdev pointer!\n",
>> + __func__);
>> + return -EINVAL;
>> + }
>> + v4l2_info(&vpif_obj.v4l2_dev, "registered sub device %s\n",
>> + asdl->subdev->name);
>
> This v4l2_info shouldn't be necessary: when the subdev is loaded it will
> already
> report that it is registered, so this would just duplicate things.
>
Ok
>> +
>> + for (i = 0; i < vpif_obj.config->subdev_count; i++)
>> + if (!strcmp(vpif_obj.config->subdev_info[i].name,
>> + asdl->subdev->name)) {
>> + vpif_obj.sd[i] = asdl->subdev;
>> + break;
>> + }
>> +
>> + if (i >= vpif_obj.config->subdev_count)
>> + return -EINVAL;
>> +
>> + return 0;
>
> This function feels unnecessary. What you basically do here is to fill in
> the vpif_obj.sd[i] pointer. Wouldn't it be easier if we added a function to
> v4l2-device.c that will return a v4l2_subdev pointer based on the subdev name
> or possibly that of a struct v4l2_async_hw_device by walking the subdevice
> list that is stored in v4l2_device?
>
> Then you could do something like this in vpif_probe_complete:
>
> for (i = 0; i < vpif_obj.config->subdev_count; i++)
> vpif_obj.sd[i] = v4l2_device_get_subdev_by_name(v4l2_dev,
> vpif_obj.config->subdev_info[i].name);
>
> and there would be no need for a bound callback.
>
> Passing a struct v4l2_async_hw_device can be useful too: then you can
> walk the list of subdevs passed in struct v4l2_async_notifier and you
> don't need to fiddle with subdev names.
>
> It's just a suggestion, but I think it will improve the code as the control
> flow is more logical that way (async callbacks are always harder to
> understand).
>
the bound callback, is being called on the subdev registration, the driver
is designed in such a way that there is subdev list and input list, and
each input may or may not have a subdev associated with it, when a input is
selected looping through the subdev list the appropriate is choose,
this was done by you :), the above code adds the subdev pointer in appropriate
index. To do this the bound callback would be required.
The second member of bound ie, asdl itself has pointer to subdev, so there isnt
a necessity to have a function returning a subdev by matching a name.
>> +}
>> +
>> +static int vpif_probe_complete(void)
>> +{
>> + struct common_obj *common;
>> + struct channel_obj *ch;
>> + int i, j, err, k;
>> +
>> + for (j = 0; j < VPIF_CAPTURE_MAX_DEVICES; j++) {
>> + ch = vpif_obj.dev[j];
>> + ch->channel_id = j;
>> + common = &(ch->common[VPIF_VIDEO_INDEX]);
>> + spin_lock_init(&common->irqlock);
>> + mutex_init(&common->lock);
>> + ch->video_dev->lock = &common->lock;
>> + /* Initialize prio member of channel object */
>> + v4l2_prio_init(&ch->prio);
>> + video_set_drvdata(ch->video_dev, ch);
>> +
>> + /* select input 0 */
>> + err = vpif_set_input(vpif_obj.conf
[PATCH] media_build: enable em28xx-dvb again for old kernels
The em28xx-dvb driver was disabled for old kernels due to lack of support
for gpio_request_one() required by LNA control in the PCTV290e driver.
Instead, this patch introduces a tiny backport patch that disables LNA
control for the PCTV290e USB stick.
The PCTV290e works fine with LNA disabled, and all the other em28xx-dvb
devices can be used again with old kernels.
Signed-off-by: Gianluca Gennari
---
backports/backports.txt | 1 +
backports/v2.6.33_no_gpio_request_one.patch | 25 +
v4l/versions.txt| 2 --
3 files changed, 26 insertions(+), 2 deletions(-)
create mode 100644 backports/v2.6.33_no_gpio_request_one.patch
diff --git a/backports/backports.txt b/backports/backports.txt
index 73ecbf6..f21cd53 100644
--- a/backports/backports.txt
+++ b/backports/backports.txt
@@ -60,6 +60,7 @@ add v2.6.34_fix_define_warnings.patch
[2.6.33]
add v2.6.33_input_handlers_are_int.patch
add v2.6.33_pvrusb2_sysfs.patch
+add v2.6.33_no_gpio_request_one.patch
[2.6.32]
add v2.6.32_kfifo.patch
diff --git a/backports/v2.6.33_no_gpio_request_one.patch
b/backports/v2.6.33_no_gpio_request_one.patch
new file mode 100644
index 000..a114a6d
--- /dev/null
+++ b/backports/v2.6.33_no_gpio_request_one.patch
@@ -0,0 +1,25 @@
+---
+ drivers/media/usb/em28xx/em28xx-dvb.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
+@@ -672,7 +672,7 @@ static int em28xx_pctv_290e_set_lna(struct dvb_frontend
*fe)
+ {
+ struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+ struct em28xx *dev = fe->dvb->priv;
+-#ifdef CONFIG_GPIOLIB
++#if 0
+ struct em28xx_dvb *dvb = dev->dvb;
+ int ret;
+ unsigned long flags;
+@@ -1104,7 +1104,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
+ goto out_free;
+ }
+
+-#ifdef CONFIG_GPIOLIB
++#if 0
+ /* enable LNA for DVB-T, DVB-T2 and DVB-C */
+ result = gpio_request_one(dvb->lna_gpio,
+ GPIOF_OUT_INIT_LOW, NULL);
+
diff --git a/v4l/versions.txt b/v4l/versions.txt
index 406c8cf..0873c17 100644
--- a/v4l/versions.txt
+++ b/v4l/versions.txt
@@ -69,8 +69,6 @@ VIDEO_MT9P031
VIDEO_SMIAPP_PLL
# Depends on VIDEO_SMIAPP_PLL and requires gpio_request_one
VIDEO_SMIAPP
-# Depends on gpio functions/defines
-VIDEO_EM28XX_DVB
[2.6.33]
VIDEO_AK881X
--
1.8.0.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/3] davinci: vpif: capture: add V4L2-async support
On Wed 9 January 2013 14:41:25 Lad, Prabhakar wrote:
> Add support for asynchronous subdevice probing, using the v4l2-async API.
> The legacy synchronous mode is still supported too, which allows to
> gradually update drivers and platforms. The selected approach adds a
> notifier for each struct soc_camera_device instance, i.e. for each video
> device node, even when there are multiple such instances registered with a
> single soc-camera host simultaneously.
This comment was obviously copy-and-pasted from somewhere else :-)
>
> Signed-off-by: Lad, Prabhakar
> Cc: Guennadi Liakhovetski
> Cc: Hans Verkuil
> Cc: Laurent Pinchart
> Cc: Sakari Ailus
> Cc: Mauro Carvalho Chehab
> ---
> drivers/media/platform/davinci/vpif_capture.c | 171
> ++---
> drivers/media/platform/davinci/vpif_capture.h |2 +
> include/media/davinci/vpif_types.h|2 +
> 3 files changed, 128 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> b/drivers/media/platform/davinci/vpif_capture.c
> index 5892d2b..a8b6588 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -34,6 +34,8 @@
> #include
> #include
> #include
> +
> +#include
> #include
> #include
> #include
> @@ -2054,6 +2056,96 @@ vpif_init_free_channel_objects:
> return err;
> }
>
> +int vpif_async_bound(struct v4l2_async_notifier *notifier,
> + struct v4l2_async_subdev_list *asdl)
> +{
> + int i = 0;
> +
> + if (!asdl->subdev) {
> + v4l2_err(vpif_dev->driver,
> + "%s(): Subdevice driver hasn't set subdev pointer!\n",
> + __func__);
> + return -EINVAL;
> + }
> + v4l2_info(&vpif_obj.v4l2_dev, "registered sub device %s\n",
> + asdl->subdev->name);
This v4l2_info shouldn't be necessary: when the subdev is loaded it will already
report that it is registered, so this would just duplicate things.
> +
> + for (i = 0; i < vpif_obj.config->subdev_count; i++)
> + if (!strcmp(vpif_obj.config->subdev_info[i].name,
> + asdl->subdev->name)) {
> + vpif_obj.sd[i] = asdl->subdev;
> + break;
> + }
> +
> + if (i >= vpif_obj.config->subdev_count)
> + return -EINVAL;
> +
> + return 0;
This function feels unnecessary. What you basically do here is to fill in
the vpif_obj.sd[i] pointer. Wouldn't it be easier if we added a function to
v4l2-device.c that will return a v4l2_subdev pointer based on the subdev name
or possibly that of a struct v4l2_async_hw_device by walking the subdevice
list that is stored in v4l2_device?
Then you could do something like this in vpif_probe_complete:
for (i = 0; i < vpif_obj.config->subdev_count; i++)
vpif_obj.sd[i] = v4l2_device_get_subdev_by_name(v4l2_dev,
vpif_obj.config->subdev_info[i].name);
and there would be no need for a bound callback.
Passing a struct v4l2_async_hw_device can be useful too: then you can
walk the list of subdevs passed in struct v4l2_async_notifier and you
don't need to fiddle with subdev names.
It's just a suggestion, but I think it will improve the code as the control
flow is more logical that way (async callbacks are always harder to understand).
> +}
> +
> +static int vpif_probe_complete(void)
> +{
> + struct common_obj *common;
> + struct channel_obj *ch;
> + int i, j, err, k;
> +
> + for (j = 0; j < VPIF_CAPTURE_MAX_DEVICES; j++) {
> + ch = vpif_obj.dev[j];
> + ch->channel_id = j;
> + common = &(ch->common[VPIF_VIDEO_INDEX]);
> + spin_lock_init(&common->irqlock);
> + mutex_init(&common->lock);
> + ch->video_dev->lock = &common->lock;
> + /* Initialize prio member of channel object */
> + v4l2_prio_init(&ch->prio);
> + video_set_drvdata(ch->video_dev, ch);
> +
> + /* select input 0 */
> + err = vpif_set_input(vpif_obj.config, ch, 0);
> + if (err)
> + goto probe_out;
> +
> + err = video_register_device(ch->video_dev,
> + VFL_TYPE_GRABBER, (j ? 1 : 0));
> + if (err)
> + goto probe_out;
> + }
> +
> + v4l2_info(&vpif_obj.v4l2_dev, "VPIF capture driver initialized\n");
> + return 0;
> +
> +probe_out:
> + for (k = 0; k < j; k++) {
> + /* Get the pointer to the channel object */
> + ch = vpif_obj.dev[k];
> + /* Unregister video device */
> + video_unregister_device(ch->video_dev);
> + }
> + kfree(vpif_obj.sd);
> + for (i = 0; i < VPIF_CAPTURE_MAX_DEVICES; i++) {
> + ch = vpif_obj.dev[i];
> + /* Note: does nothing if ch->v
Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
Em Wed, 09 Jan 2013 11:02:23 + Simon Farnsworth escreveu: > On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote: > > On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth > > wrote: > > > The wireless folk use dBm (reference point 1 milliwatt), as that's the > > > reference point used in the 802.11 standard. > > > > > > Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no > > > reference > > > point (so suitable for carrier to noise etc, or for when the reference > > > point > > > is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point > > > is > > > 1mW, so that frontends report in dBm? > > > > > > Note that if the frontend internally uses a different reference point, the > > > conversion is always going to be adding or subtracting a constant. > > > > Hi Simon, > > > > Probably the biggest issue you're going to have is that very few of > > the consumer-grade demodulators actually report data in that format. > > And only a small subset of those actually provide the documentation in > > their datasheet. > > > > My specific concern is that we already see people complaining that their cable > system or aerial installer's meter comes up with one number, and our > documentation has completely different numbers. When we dig, this usually > turns out to be because our documentation is in dBm, while their installer is > using dBmV or dBµW, and no-one at the customer site knows the differences. > > If consumer demods don't report in a dB scale at all, we should drop dB as a > unit; if they do report in a true dB scale, but the reference point is > normally not documented, we need some way to distinguish demods where the > reference point is unknown, and demods where someone has taken the time to > find the reference point (which can be done with a signal generator). > > This is sounding more and more like an argument for adding > FE_SCALE_DECIBEL_MILLIWATT - it gives those applications that care a way to > tell the user that the signal strength reading from the application should > match up to the signal strength reading on your installer's kit. Said > applications could even choose to do the conversions for you, giving you all > four commonly seen units (dBm, dBmV at 50Ω, dBmV at 75Ω, dBµW). > > > For that matter, even the SNR field being reported in dB isn't going > > to allow you to reliably compare across different demodulator chips. > > If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't > > really mean demod Y performs better - just that it's reporting a > > better number. However it does allow you to compare the demod > > against itself either across multiple frequencies or under different > > signal conditions - which is what typical users really care about. > > I'm not expecting people to compare across demods - I only care about the > case where a user has got in a professional installer to help with their > setup. The problem I want to avoid is a Linux application saying "-48 dB > signal strength, 15 dB CNR", and the installer's kit saying "60 dBuV signal > strength, 20 dB CNR", when we have enough information for the Linux > application to say "-48 dBm (60 dBuV at 75Ω), 15 dB CNR", cueing the > professional to remember that not all dB use the same reference point, and > from there into accepting that Linux is reporting a similar signal strength > and CNR to his kit. > > This also has implications for things like VDR - if the scale is > FE_SCALE_DECIBEL but the measurement is absolute, the application probably > doesn't want to report the measurement as a dB measure, but as an arbitrary > scale; again, you don't want the application saying "50 dB", when the > professional installer tells you that you have "0 dBuV". Yes, it makes sense to document that the signal strength should be reported on either dBm or dBµW, if the scale is FE_SCALE_DECIBEL. I prefer to specify it in terms of Watt (or a submultiple) than in terms of voltage/impedance, as different Countries use different impedances on DTV cabling (typically, 50Ω or 75Ω). So, either dBm or dBµW works for me. As you said, applications can convert between those mesures as they wish, by simply adding some constant when displaying the power measure. As the wifi subsytem use dBm, I vote for using dBm for the signal measure at the subsystem (actually, 0.1 dBm). Comments? Regards, Mauro -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe 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] Initial scan files troubles and brainstorming
On 09-01-13 16:01, Mauro Carvalho Chehab wrote: Em Wed, 09 Jan 2013 15:44:30 +0100 Oliver Schinagl escreveu: Mauro, On 09-01-13 15:37, Mauro Carvalho Chehab wrote: Hi Oliver, Em Wed, 09 Jan 2013 13:24:13 +0100 Oliver Schinagl escreveu: If I understood it right, you want to split the scan files into a separate git tree and maintain it, right? I'm ok with that. I also migrated the dvb-apps changesets with the tables to: http://git.linuxtv.org/dtv-scan-tables.git Feel free to maintain it. Thank you, this will be the new name for it (I will locally rename it) and try my bestest to maintain it :) I will put a mention on the wiki 'how to submit scanfiles' (via the ML with tags in subject/pull requests) so people have a clear way how to submit them and I have a clear way to find them. Great! You should also have access to the dvb-apps hg tree. IMHO, it makes sense to remove the files from there, and add a pointer there (README?) to the new tree. I will remove the scanfiles from there, add/edit the readme that the tree is a dependancy? Please do it. You'll likely need to also add there at the tree a Makefile with an install target, in order to help distros to package it, and remove the corresponding scan files install Makefile targets at dvb-apps. Will do as soon as I figure out how to gain access and and configure my local git install. I'm quite new to this multiple private key stuff and can't get it to work for now (i'll look into that for now). I feel stupid enough for asking :p I'll first add my local patches and then see how i can 'fix' dvb-apps to remove the old stuff. -- To unsubscribe from this list: send the line "unsubscribe 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] Initial scan files troubles and brainstorming
Em Wed, 09 Jan 2013 15:44:30 +0100 Oliver Schinagl escreveu: > Mauro, > > On 09-01-13 15:37, Mauro Carvalho Chehab wrote: > > Hi Oliver, > > > > Em Wed, 09 Jan 2013 13:24:13 +0100 > > Oliver Schinagl escreveu: > > > >> If I understood it right, you want to split the scan files into a > >> separate > >> git tree and maintain it, right? > >> > >> I'm ok with that. > > > I also migrated the dvb-apps changesets with the tables to: > > http://git.linuxtv.org/dtv-scan-tables.git Feel free to maintain it. > Thank you, this will be the new name for it (I will locally rename it) > and try my bestest to maintain it :) > > I will put a mention on the wiki 'how to submit scanfiles' (via the ML > with tags in subject/pull requests) so people have a clear way how to > submit them and I have a clear way to find them. Great! > > > > You should also have access to the dvb-apps hg tree. IMHO, it makes sense > > to remove the files from there, and add a pointer there (README?) to the > > new tree. > I will remove the scanfiles from there, add/edit the readme that the > tree is a dependancy? Please do it. You'll likely need to also add there at the tree a Makefile with an install target, in order to help distros to package it, and remove the corresponding scan files install Makefile targets at dvb-apps. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
kaffeine.kde.org/scanfile.dvb.qz is obsolete [was: [RFC] Initial scan files troubles and brainstorming]
On 01/09/2013 03:41 PM, Mauro Carvalho Chehab wrote: > Christoph, > > Thank you for all the hard work over all those years! Yeah, I second this. I have a note though. Who is going to fix the URL in kaffeine? And how often is kaffeine.kde.org/scanfile.dvb.qz updated? Is this done automatically? As it is pretty outdated (9/2011), I don't think it is... Should this be moved somewhere else? thanks, -- js -- To unsubscribe from this list: send the line "unsubscribe 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] Initial scan files troubles and brainstorming
Mauro, On 09-01-13 15:37, Mauro Carvalho Chehab wrote: Hi Oliver, Em Wed, 09 Jan 2013 13:24:13 +0100 Oliver Schinagl escreveu: If I understood it right, you want to split the scan files into a separate git tree and maintain it, right? I'm ok with that. I also migrated the dvb-apps changesets with the tables to: http://git.linuxtv.org/dtv-scan-tables.git Feel free to maintain it. Thank you, this will be the new name for it (I will locally rename it) and try my bestest to maintain it :) I will put a mention on the wiki 'how to submit scanfiles' (via the ML with tags in subject/pull requests) so people have a clear way how to submit them and I have a clear way to find them. You should also have access to the dvb-apps hg tree. IMHO, it makes sense to remove the files from there, and add a pointer there (README?) to the new tree. I will remove the scanfiles from there, add/edit the readme that the tree is a dependancy? Regards, Mauro. Oliver -- To unsubscribe from this list: send the line "unsubscribe 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] Initial scan files troubles and brainstorming
Em Wed, 9 Jan 2013 06:08:44 -0500 Michael Krufky escreveu: > On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab > wrote: > > Em Wed, 09 Jan 2013 10:43:23 +0100 > > Oliver Schinagl escreveu: > > > >> On 08-01-13 21:01, Johannes Stezenbach wrote: > >> > On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: > >> >> On 07-01-13 11:46, Jiri Slaby wrote: > >> >>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote: > >> Unfortunatly, I have had zero replies. > >> >>> Hmm, it's sad there is a silence in this thread from linux-media guys > >> >>> :/. > >> >> In their defense, they are very very busy people ;) chatter on this > >> >> thread does bring it up however. > >> > This is such a nice thing to say :-) > >> > But it might be that Mauro thinks the dvb-apps maintainer should > >> > respond, but apparently there is no dvb-apps maintainer... > >> > Maybe you should ask Mauro directly to create an account for you > >> > to implement what you proposed. > >> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who > >> decides what I suggested is a good idea? I personally obviously think it > >> is ;) and even more so if dvb-apps are unmaintained. > >> > >> I guess the question now becomes 'who okay's this change? Who says > >> 'okay, lets do it this way. Once that is answered we can go from there ;) > > > > If I understood it right, you want to split the scan files into a separate > > git tree and maintain it, right? > > > > I'm ok with that. > > > > Regards, > > Mauro > > As a DVB maintainer, I am OK with this as well - It does indeed make > sense to separate the c code sources from the regional frequency > tables, and I'm sure we'll see much benefit from this change. Done. I created a tree for Oliver to maintain it and an account for him. I also created a new tree with just the DVB table commits to: http://git.linuxtv.org/dtv-scan-tables.git I kept there both szap and scan files, although maybe it makes sense to drop the szap table (channels-conf dir). It also makes sense to drop the tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid troubles on distros that may want to have both packages. Anyway, as Oliver has now access to both trees, I'll let him to handle and maintain it. Christoph, Thank you for all the hard work over all those years! Happy new year, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 2/3] tvp514x: support asynchronous probing
Both synchronous and asynchronous tvp514x subdevice probing is supported by
this patch.
Signed-off-by: Lad, Prabhakar
Cc: Guennadi Liakhovetski
Cc: Laurent Pinchart
Cc: Hans Verkuil
Cc: Sakari Ailus
Cc: Mauro Carvalho Chehab
---
drivers/media/i2c/tvp514x.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index aa94ebc..a4f0a70 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -34,6 +34,7 @@
#include
#include
+#include
#include
#include
#include
@@ -102,6 +103,7 @@ struct tvp514x_decoder {
struct v4l2_ctrl_handler hdl;
struct tvp514x_reg tvp514x_regs[ARRAY_SIZE(tvp514x_reg_list_default)];
const struct tvp514x_platform_data *pdata;
+ struct v4l2_async_subdev_list asdl;
int ver;
int streaming;
@@ -941,22 +943,22 @@ tvp514x_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct tvp514x_decoder *decoder;
struct v4l2_subdev *sd;
+ int ret;
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
return -EIO;
- if (!client->dev.platform_data) {
- v4l2_err(client, "No platform data!!\n");
- return -ENODEV;
- }
-
decoder = devm_kzalloc(&client->dev, sizeof(*decoder), GFP_KERNEL);
if (!decoder)
return -ENOMEM;
/* Initialize the tvp514x_decoder with default configuration */
*decoder = tvp514x_dev;
+ if (!client->dev.platform_data) {
+ v4l2_err(client, "No platform data!!\n");
+ return -EPROBE_DEFER;
+ }
/* Copy default register configuration */
memcpy(decoder->tvp514x_regs, tvp514x_reg_list_default,
sizeof(tvp514x_reg_list_default));
@@ -980,6 +982,11 @@ tvp514x_probe(struct i2c_client *client, const struct
i2c_device_id *id)
/* Register with V4L2 layer as slave device */
sd = &decoder->sd;
+ decoder->asdl.subdev = &decoder->sd;
+ decoder->asdl.dev = &client->dev;
+ ret = v4l2_async_subdev_bind(&decoder->asdl);
+ if (ret < 0)
+ return ret;
v4l2_i2c_subdev_init(sd, client, &tvp514x_ops);
v4l2_ctrl_handler_init(&decoder->hdl, 5);
@@ -1004,7 +1011,7 @@ tvp514x_probe(struct i2c_client *client, const struct
i2c_device_id *id)
v4l2_info(sd, "%s decoder driver registered !!\n", sd->name);
- return 0;
+ return v4l2_async_subdev_bound(&decoder->asdl);
}
@@ -1020,6 +1027,7 @@ static int tvp514x_remove(struct i2c_client *client)
struct v4l2_subdev *sd = i2c_get_clientdata(client);
struct tvp514x_decoder *decoder = to_decoder(sd);
+ v4l2_async_subdev_unbind(&decoder->asdl);
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(&decoder->hdl);
return 0;
--
1.7.4.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 RFC 3/3] ARM: da850/omap-l138: vpif capture convert to asynchronously register of subdev
Register the tvp514x decoder devices directly in board platform
data instead of letting the vpif capture driver register them at
their run-time. This uses the V4L2 asynchronous subdevice probing capability.
Signed-off-by: Lad, Prabhakar
Cc: Sekhar Nori
---
arch/arm/mach-davinci/board-da850-evm.c | 57 +++
1 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 0299915..089c127 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -49,6 +49,7 @@
#include
#include
+#include
#define DA850_EVM_PHY_ID "davinci_mdio-0:00"
#define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8)
@@ -732,6 +733,12 @@ static struct pca953x_platform_data
da850_evm_bb_expander_info = {
.names = da850_evm_bb_exp,
};
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1,
+};
+
static struct i2c_board_info __initdata da850_evm_i2c_devices[] = {
{
I2C_BOARD_INFO("tlv320aic3x", 0x18),
@@ -744,6 +751,14 @@ static struct i2c_board_info __initdata
da850_evm_i2c_devices[] = {
I2C_BOARD_INFO("tca6416", 0x21),
.platform_data = &da850_evm_bb_expander_info,
},
+ {
+ I2C_BOARD_INFO("tvp5146", 0x5c),
+ .platform_data = &tvp5146_pdata,
+ }, {
+ I2C_BOARD_INFO("tvp5146", 0x5d),
+ .platform_data = &tvp5146_pdata,
+ },
+
};
static struct davinci_i2c_platform_data da850_evm_i2c_0_pdata = {
@@ -1170,15 +1185,10 @@ static __init int da850_evm_init_cpufreq(void) { return
0; }
#if defined(CONFIG_DA850_UI_SD_VIDEO_PORT)
-#define TVP5147_CH0"tvp514x-0"
-#define TVP5147_CH1"tvp514x-1"
+#define TVP5147_CH0"tvp514x 1-005d"
+#define TVP5147_CH1"tvp514x 1-005c"
/* VPIF capture configuration */
-static struct tvp514x_platform_data tvp5146_pdata = {
- .clk_polarity = 0,
- .hs_polarity = 1,
- .vs_polarity = 1,
-};
#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
@@ -1229,6 +1239,37 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
},
};
+static struct v4l2_async_subdev tvp1_sd = {
+ .hw = {
+ .bus_type = V4L2_ASYNC_BUS_I2C,
+ .match.i2c = {
+ .adapter_id = 1,
+ .address = 0x5c,
+ },
+ },
+};
+
+static struct v4l2_async_subdev tvp2_sd = {
+ .hw = {
+ .bus_type = V4L2_ASYNC_BUS_I2C,
+ .match.i2c = {
+ .adapter_id = 1,
+ .address = 0x5d,
+ },
+ },
+};
+
+static struct v4l2_async_subdev *vpif_capture_async_subdevs[] = {
+ /* Single 2-element group */
+ &tvp1_sd,
+ &tvp2_sd,
+};
+
+static int vpif_capture_async_subdev_sizes[] = {
+ ARRAY_SIZE(vpif_capture_async_subdevs),
+ 0,
+};
+
static struct vpif_capture_config da850_vpif_capture_config = {
.subdev_info = da850_vpif_capture_sdev_info,
.subdev_count = ARRAY_SIZE(da850_vpif_capture_sdev_info),
@@ -1253,6 +1294,8 @@ static struct vpif_capture_config
da850_vpif_capture_config = {
},
},
.card_name = "DA850/OMAP-L138 Video Capture",
+ .asd = vpif_capture_async_subdevs,
+ .asd_sizes = vpif_capture_async_subdev_sizes,
};
/* VPIF display configuration */
--
1.7.4.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 RFC 1/3] davinci: vpif: capture: add V4L2-async support
Add support for asynchronous subdevice probing, using the v4l2-async API.
The legacy synchronous mode is still supported too, which allows to
gradually update drivers and platforms. The selected approach adds a
notifier for each struct soc_camera_device instance, i.e. for each video
device node, even when there are multiple such instances registered with a
single soc-camera host simultaneously.
Signed-off-by: Lad, Prabhakar
Cc: Guennadi Liakhovetski
Cc: Hans Verkuil
Cc: Laurent Pinchart
Cc: Sakari Ailus
Cc: Mauro Carvalho Chehab
---
drivers/media/platform/davinci/vpif_capture.c | 171 ++---
drivers/media/platform/davinci/vpif_capture.h |2 +
include/media/davinci/vpif_types.h|2 +
3 files changed, 128 insertions(+), 47 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 5892d2b..a8b6588 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -34,6 +34,8 @@
#include
#include
#include
+
+#include
#include
#include
#include
@@ -2054,6 +2056,96 @@ vpif_init_free_channel_objects:
return err;
}
+int vpif_async_bound(struct v4l2_async_notifier *notifier,
+ struct v4l2_async_subdev_list *asdl)
+{
+ int i = 0;
+
+ if (!asdl->subdev) {
+ v4l2_err(vpif_dev->driver,
+"%s(): Subdevice driver hasn't set subdev pointer!\n",
+ __func__);
+ return -EINVAL;
+ }
+ v4l2_info(&vpif_obj.v4l2_dev, "registered sub device %s\n",
+asdl->subdev->name);
+
+ for (i = 0; i < vpif_obj.config->subdev_count; i++)
+ if (!strcmp(vpif_obj.config->subdev_info[i].name,
+ asdl->subdev->name)) {
+ vpif_obj.sd[i] = asdl->subdev;
+ break;
+ }
+
+ if (i >= vpif_obj.config->subdev_count)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int vpif_probe_complete(void)
+{
+ struct common_obj *common;
+ struct channel_obj *ch;
+ int i, j, err, k;
+
+ for (j = 0; j < VPIF_CAPTURE_MAX_DEVICES; j++) {
+ ch = vpif_obj.dev[j];
+ ch->channel_id = j;
+ common = &(ch->common[VPIF_VIDEO_INDEX]);
+ spin_lock_init(&common->irqlock);
+ mutex_init(&common->lock);
+ ch->video_dev->lock = &common->lock;
+ /* Initialize prio member of channel object */
+ v4l2_prio_init(&ch->prio);
+ video_set_drvdata(ch->video_dev, ch);
+
+ /* select input 0 */
+ err = vpif_set_input(vpif_obj.config, ch, 0);
+ if (err)
+ goto probe_out;
+
+ err = video_register_device(ch->video_dev,
+ VFL_TYPE_GRABBER, (j ? 1 : 0));
+ if (err)
+ goto probe_out;
+ }
+
+ v4l2_info(&vpif_obj.v4l2_dev, "VPIF capture driver initialized\n");
+ return 0;
+
+probe_out:
+ for (k = 0; k < j; k++) {
+ /* Get the pointer to the channel object */
+ ch = vpif_obj.dev[k];
+ /* Unregister video device */
+ video_unregister_device(ch->video_dev);
+ }
+ kfree(vpif_obj.sd);
+ for (i = 0; i < VPIF_CAPTURE_MAX_DEVICES; i++) {
+ ch = vpif_obj.dev[i];
+ /* Note: does nothing if ch->video_dev == NULL */
+ video_device_release(ch->video_dev);
+ }
+ v4l2_device_unregister(&vpif_obj.v4l2_dev);
+
+ return err;
+}
+
+int vpif_async_complete(struct v4l2_async_notifier *notifier)
+{
+ return vpif_probe_complete();
+}
+
+void vpif_async_unbind(struct v4l2_async_notifier *notifier,
+ struct v4l2_async_subdev_list *asdl)
+{
+ /*FIXME: Do we need this callback ? */
+ v4l2_info(&vpif_obj.v4l2_dev, "unregistered sub device %s\n",
+asdl->subdev->name);
+ return;
+}
+
/**
* vpif_probe : This function probes the vpif capture driver
* @pdev: platform device pointer
@@ -2064,12 +2156,10 @@ vpif_init_free_channel_objects:
static __init int vpif_probe(struct platform_device *pdev)
{
struct vpif_subdev_info *subdevdata;
- struct vpif_capture_config *config;
- int i, j, k, err;
+ int i, j, err;
int res_idx = 0;
struct i2c_adapter *i2c_adap;
struct channel_obj *ch;
- struct common_obj *common;
struct video_device *vfd;
struct resource *res;
int subdev_count;
@@ -2146,10 +2236,9 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
}
- i2c_adap = i2c_get_adapter(1);
- config = pdev->dev.platform_data;
+ vpif_obj.config = pdev->dev.
[PATCH RFC 0/3] vpif capture support for async subdevice probing
This patch series adds support for vpif capture driver to support asynchronously register subdevices. The second patch add support for tvp514x decoder to support v4l-async and the last patch adds support for da850 evm to support v4l-async for vpif capture. This patch is based on v4l2-async patch (http://www.spinics.net/lists/linux-media/msg58420.html) from Guennadi. Need for this support: Currently bridge device drivers register devices for all subdevices synchronously, tupically, during their probing. E.g. if an I2C CMOS sensor is attached to a video bridge device, the bridge driver will create an I2C device and wait for the respective I2C driver to probe. This makes linking of devices straight forward, but this approach cannot be used with intrinsically asynchronous and unordered device registration systems like the Flattened Device Tree. Similar impletation is to be done for vpif disaply, based on review comments on this series. Lad, Prabhakar (3): davinci: vpif: capture: add V4L2-async support tvp514x: support asynchronous probing ARM: da850/omap-l138: vpif capture convert to asynchronously register of subdev arch/arm/mach-davinci/board-da850-evm.c | 57 +++- drivers/media/i2c/tvp514x.c | 20 ++- drivers/media/platform/davinci/vpif_capture.c | 171 ++--- drivers/media/platform/davinci/vpif_capture.h |2 + include/media/davinci/vpif_types.h|2 + 5 files changed, 192 insertions(+), 60 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] pci/cx88: use IS_ENABLED() macro
On Wed 9 January 2013 13:32:12 Peter Senna Tschudin wrote:
> replace:
> #if defined(CONFIG_VIDEO_CX88_DVB) || defined(CONFIG_VIDEO_CX88_DVB_MODULE)
> with:
> #if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
>
> This change was made for: CONFIG_VIDEO_CX88_DVB,
> CONFIG_VIDEO_CX88_BLACKBIRD, CONFIG_VIDEO_CX88_VP3054
>
> Reported-by: Mauro Carvalho Chehab
> Signed-off-by: Peter Senna Tschudin
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/pci/cx88/cx88.h | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
> index ba0dba4..feff53c 100644
> --- a/drivers/media/pci/cx88/cx88.h
> +++ b/drivers/media/pci/cx88/cx88.h
> @@ -363,7 +363,7 @@ struct cx88_core {
> unsigned int tuner_formats;
>
> /* config info -- dvb */
> -#if defined(CONFIG_VIDEO_CX88_DVB) || defined(CONFIG_VIDEO_CX88_DVB_MODULE)
> +#if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
> int(*prev_set_voltage)(struct dvb_frontend *fe,
> fe_sec_voltage_t voltage);
> #endif
> void (*gate_ctrl)(struct cx88_core *core, int
> open);
> @@ -562,8 +562,7 @@ struct cx8802_dev {
>
> /* for blackbird only */
> struct list_head devlist;
> -#if defined(CONFIG_VIDEO_CX88_BLACKBIRD) || \
> -defined(CONFIG_VIDEO_CX88_BLACKBIRD_MODULE)
> +#if IS_ENABLED(CONFIG_VIDEO_CX88_BLACKBIRD)
> struct video_device*mpeg_dev;
> u32mailbox;
> intwidth;
> @@ -574,13 +573,12 @@ struct cx8802_dev {
> struct cx2341x_handler cxhdl;
> #endif
>
> -#if defined(CONFIG_VIDEO_CX88_DVB) || defined(CONFIG_VIDEO_CX88_DVB_MODULE)
> +#if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
> /* for dvb only */
> struct videobuf_dvb_frontends frontends;
> #endif
>
> -#if defined(CONFIG_VIDEO_CX88_VP3054) || \
> -defined(CONFIG_VIDEO_CX88_VP3054_MODULE)
> +#if IS_ENABLED(CONFIG_VIDEO_CX88_VP3054)
> /* For VP3045 secondary I2C bus support */
> struct vp3054_i2c_state*vp3054;
> #endif
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] pci/cx88: use IS_ENABLED() macro
replace:
#if defined(CONFIG_VIDEO_CX88_DVB) || defined(CONFIG_VIDEO_CX88_DVB_MODULE)
with:
#if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
This change was made for: CONFIG_VIDEO_CX88_DVB,
CONFIG_VIDEO_CX88_BLACKBIRD, CONFIG_VIDEO_CX88_VP3054
Reported-by: Mauro Carvalho Chehab
Signed-off-by: Peter Senna Tschudin
---
drivers/media/pci/cx88/cx88.h | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index ba0dba4..feff53c 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h
@@ -363,7 +363,7 @@ struct cx88_core {
unsigned int tuner_formats;
/* config info -- dvb */
-#if defined(CONFIG_VIDEO_CX88_DVB) || defined(CONFIG_VIDEO_CX88_DVB_MODULE)
+#if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
int(*prev_set_voltage)(struct dvb_frontend *fe,
fe_sec_voltage_t voltage);
#endif
void (*gate_ctrl)(struct cx88_core *core, int
open);
@@ -562,8 +562,7 @@ struct cx8802_dev {
/* for blackbird only */
struct list_head devlist;
-#if defined(CONFIG_VIDEO_CX88_BLACKBIRD) || \
-defined(CONFIG_VIDEO_CX88_BLACKBIRD_MODULE)
+#if IS_ENABLED(CONFIG_VIDEO_CX88_BLACKBIRD)
struct video_device*mpeg_dev;
u32mailbox;
intwidth;
@@ -574,13 +573,12 @@ struct cx8802_dev {
struct cx2341x_handler cxhdl;
#endif
-#if defined(CONFIG_VIDEO_CX88_DVB) || defined(CONFIG_VIDEO_CX88_DVB_MODULE)
+#if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
/* for dvb only */
struct videobuf_dvb_frontends frontends;
#endif
-#if defined(CONFIG_VIDEO_CX88_VP3054) || \
-defined(CONFIG_VIDEO_CX88_VP3054_MODULE)
+#if IS_ENABLED(CONFIG_VIDEO_CX88_VP3054)
/* For VP3045 secondary I2C bus support */
struct vp3054_i2c_state*vp3054;
#endif
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe 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] pci/saa7134: use IS_ENABLED() macro
replace:
#if defined(CONFIG_VIDEO_CX88_DVB) || defined(CONFIG_VIDEO_CX88_DVB_MODULE)
with:
#if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
This change was made for: CONFIG_VIDEO_SAA7134_DVB
Reported-by: Mauro Carvalho Chehab
Signed-off-by: Peter Senna Tschudin
---
drivers/media/pci/saa7134/saa7134.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134.h
b/drivers/media/pci/saa7134/saa7134.h
index 0a3feaa..ace44fd 100644
--- a/drivers/media/pci/saa7134/saa7134.h
+++ b/drivers/media/pci/saa7134/saa7134.h
@@ -42,7 +42,7 @@
#include
#include
#include
-#if defined(CONFIG_VIDEO_SAA7134_DVB) ||
defined(CONFIG_VIDEO_SAA7134_DVB_MODULE)
+#if IS_ENABLED(CONFIG_VIDEO_SAA7134_DVB)
#include
#endif
@@ -644,7 +644,7 @@ struct saa7134_dev {
struct work_struct empress_workqueue;
intempress_started;
-#if defined(CONFIG_VIDEO_SAA7134_DVB) ||
defined(CONFIG_VIDEO_SAA7134_DVB_MODULE)
+#if IS_ENABLED(CONFIG_VIDEO_SAA7134_DVB)
/* SAA7134_MPEG_DVB only */
struct videobuf_dvb_frontends frontends;
int (*original_demod_sleep)(struct dvb_frontend *fe);
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] pci/ttpci/av7110.c: use IS_ENABLED() macro
replace:
#if defined(CONFIG_INPUT_EVDEV) || defined(CONFIG_INPUT_EVDEV_MODULE)
with:
#if IS_ENABLED(CONFIG_INPUT_EVDEV)
This change was made for: CONFIG_INPUT_EVDEV, CONFIG_DVB_SP8870
Reported-by: Mauro Carvalho Chehab
Signed-off-by: Peter Senna Tschudin
---
drivers/media/pci/ttpci/av7110.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/pci/ttpci/av7110.c b/drivers/media/pci/ttpci/av7110.c
index 2f54e2b..fc9e7e5 100644
--- a/drivers/media/pci/ttpci/av7110.c
+++ b/drivers/media/pci/ttpci/av7110.c
@@ -235,7 +235,7 @@ static void recover_arm(struct av7110 *av7110)
restart_feeds(av7110);
-#if defined(CONFIG_INPUT_EVDEV) || defined(CONFIG_INPUT_EVDEV_MODULE)
+#if IS_ENABLED(CONFIG_INPUT_EVDEV)
av7110_check_ir_config(av7110, true);
#endif
}
@@ -268,7 +268,7 @@ static int arm_thread(void *data)
if (!av7110->arm_ready)
continue;
-#if defined(CONFIG_INPUT_EVDEV) || defined(CONFIG_INPUT_EVDEV_MODULE)
+#if IS_ENABLED(CONFIG_INPUT_EVDEV)
av7110_check_ir_config(av7110, false);
#endif
@@ -1730,7 +1730,7 @@ static int alps_tdlb7_tuner_set_params(struct
dvb_frontend *fe)
static int alps_tdlb7_request_firmware(struct dvb_frontend* fe, const struct
firmware **fw, char* name)
{
-#if defined(CONFIG_DVB_SP8870) || defined(CONFIG_DVB_SP8870_MODULE)
+#if IS_ENABLED(CONFIG_DVB_SP8870)
struct av7110* av7110 = fe->dvb->priv;
return request_firmware(fw, name, &av7110->dev->pci->dev);
@@ -2725,7 +2725,7 @@ static int __devinit av7110_attach(struct saa7146_dev*
dev,
mutex_init(&av7110->ioctl_mutex);
-#if defined(CONFIG_INPUT_EVDEV) || defined(CONFIG_INPUT_EVDEV_MODULE)
+#if IS_ENABLED(CONFIG_INPUT_EVDEV)
av7110_ir_init(av7110);
#endif
printk(KERN_INFO "dvb-ttpci: found av7110-%d.\n", av7110_num);
@@ -2768,7 +2768,7 @@ static int __devexit av7110_detach(struct saa7146_dev*
saa)
struct av7110 *av7110 = saa->ext_priv;
dprintk(4, "%p\n", av7110);
-#if defined(CONFIG_INPUT_EVDEV) || defined(CONFIG_INPUT_EVDEV_MODULE)
+#if IS_ENABLED(CONFIG_INPUT_EVDEV)
av7110_ir_exit(av7110);
#endif
if (budgetpatch || av7110->full_ts) {
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe 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] Initial scan files troubles and brainstorming
On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab wrote: > Em Wed, 09 Jan 2013 10:43:23 +0100 > Oliver Schinagl escreveu: > >> On 08-01-13 21:01, Johannes Stezenbach wrote: >> > On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: >> >> On 07-01-13 11:46, Jiri Slaby wrote: >> >>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote: >> Unfortunatly, I have had zero replies. >> >>> Hmm, it's sad there is a silence in this thread from linux-media guys :/. >> >> In their defense, they are very very busy people ;) chatter on this >> >> thread does bring it up however. >> > This is such a nice thing to say :-) >> > But it might be that Mauro thinks the dvb-apps maintainer should >> > respond, but apparently there is no dvb-apps maintainer... >> > Maybe you should ask Mauro directly to create an account for you >> > to implement what you proposed. >> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who >> decides what I suggested is a good idea? I personally obviously think it >> is ;) and even more so if dvb-apps are unmaintained. >> >> I guess the question now becomes 'who okay's this change? Who says >> 'okay, lets do it this way. Once that is answered we can go from there ;) > > If I understood it right, you want to split the scan files into a separate > git tree and maintain it, right? > > I'm ok with that. > > Regards, > Mauro As a DVB maintainer, I am OK with this as well - It does indeed make sense to separate the c code sources from the regional frequency tables, and I'm sure we'll see much benefit from this change. Regards, Mike Krufky -- To unsubscribe from this list: send the line "unsubscribe 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] Initial scan files troubles and brainstorming
On Wed, Jan 09, 2013 at 10:43:23AM +0100, Oliver Schinagl wrote: > On 08-01-13 21:01, Johannes Stezenbach wrote: > >On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: > >>On 07-01-13 11:46, Jiri Slaby wrote: > >>>On 12/18/2012 11:01 PM, Oliver Schinagl wrote: > Unfortunatly, I have had zero replies. > >>>Hmm, it's sad there is a silence in this thread from linux-media guys :/. > >>In their defense, they are very very busy people ;) chatter on this > >>thread does bring it up however. > >This is such a nice thing to say :-) > >But it might be that Mauro thinks the dvb-apps maintainer should > >respond, but apparently there is no dvb-apps maintainer... > >Maybe you should ask Mauro directly to create an account for you > >to implement what you proposed. > Mauro is CC'ed and I'd ask of course for this (I kinda did) but who > decides what I suggested is a good idea? I personally obviously > think it is ;) and even more so if dvb-apps are unmaintained. Well, if you become the dvb-apps maintainer, then _you_ decide if it's a good idea. That's part of the defintion of "maintainer" :-) It doesn't hurt to listen to users, but if no one comments you can do whatever you want with it. But I'm only acting as kind of a webmaster, Mauro creates the accounts. So we have to wait for him to respond. > I guess the question now becomes 'who okay's this change? Who says > 'okay, lets do it this way. Once that is answered we can go from > there ;) I guess you could ask the maintainer of the dvb-apps package of your favourite distribution for opinions, and also check which other packages depend on dvb-apps. Johannes -- To unsubscribe from this list: send the line "unsubscribe 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 RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote: > On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth > wrote: > > The wireless folk use dBm (reference point 1 milliwatt), as that's the > > reference point used in the 802.11 standard. > > > > Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no > > reference > > point (so suitable for carrier to noise etc, or for when the reference point > > is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is > > 1mW, so that frontends report in dBm? > > > > Note that if the frontend internally uses a different reference point, the > > conversion is always going to be adding or subtracting a constant. > > Hi Simon, > > Probably the biggest issue you're going to have is that very few of > the consumer-grade demodulators actually report data in that format. > And only a small subset of those actually provide the documentation in > their datasheet. > My specific concern is that we already see people complaining that their cable system or aerial installer's meter comes up with one number, and our documentation has completely different numbers. When we dig, this usually turns out to be because our documentation is in dBm, while their installer is using dBmV or dBµW, and no-one at the customer site knows the differences. If consumer demods don't report in a dB scale at all, we should drop dB as a unit; if they do report in a true dB scale, but the reference point is normally not documented, we need some way to distinguish demods where the reference point is unknown, and demods where someone has taken the time to find the reference point (which can be done with a signal generator). This is sounding more and more like an argument for adding FE_SCALE_DECIBEL_MILLIWATT - it gives those applications that care a way to tell the user that the signal strength reading from the application should match up to the signal strength reading on your installer's kit. Said applications could even choose to do the conversions for you, giving you all four commonly seen units (dBm, dBmV at 50Ω, dBmV at 75Ω, dBµW). > For that matter, even the SNR field being reported in dB isn't going > to allow you to reliably compare across different demodulator chips. > If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't > really mean demod Y performs better - just that it's reporting a > better number. However it does allow you to compare the demod > against itself either across multiple frequencies or under different > signal conditions - which is what typical users really care about. I'm not expecting people to compare across demods - I only care about the case where a user has got in a professional installer to help with their setup. The problem I want to avoid is a Linux application saying "-48 dB signal strength, 15 dB CNR", and the installer's kit saying "60 dBuV signal strength, 20 dB CNR", when we have enough information for the Linux application to say "-48 dBm (60 dBuV at 75Ω), 15 dB CNR", cueing the professional to remember that not all dB use the same reference point, and from there into accepting that Linux is reporting a similar signal strength and CNR to his kit. This also has implications for things like VDR - if the scale is FE_SCALE_DECIBEL but the measurement is absolute, the application probably doesn't want to report the measurement as a dB measure, but as an arbitrary scale; again, you don't want the application saying "50 dB", when the professional installer tells you that you have "0 dBuV". -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.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: [RFC] Initial scan files troubles and brainstorming
Em Wed, 09 Jan 2013 10:43:23 +0100 Oliver Schinagl escreveu: > On 08-01-13 21:01, Johannes Stezenbach wrote: > > On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: > >> On 07-01-13 11:46, Jiri Slaby wrote: > >>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote: > Unfortunatly, I have had zero replies. > >>> Hmm, it's sad there is a silence in this thread from linux-media guys :/. > >> In their defense, they are very very busy people ;) chatter on this > >> thread does bring it up however. > > This is such a nice thing to say :-) > > But it might be that Mauro thinks the dvb-apps maintainer should > > respond, but apparently there is no dvb-apps maintainer... > > Maybe you should ask Mauro directly to create an account for you > > to implement what you proposed. > Mauro is CC'ed and I'd ask of course for this (I kinda did) but who > decides what I suggested is a good idea? I personally obviously think it > is ;) and even more so if dvb-apps are unmaintained. > > I guess the question now becomes 'who okay's this change? Who says > 'okay, lets do it this way. Once that is answered we can go from there ;) If I understood it right, you want to split the scan files into a separate git tree and maintain it, right? I'm ok with that. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [RFC]: video: exynos: Making s6e8ax0 panel driver compliant with CDF
From: Vikas Sajjan
Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
it also removes the dependency on backlight and lcd framework.
Signed-off-by: Vikas Sajjan
---
drivers/video/exynos/s6e8ax0.c | 602 ++--
1 file changed, 328 insertions(+), 274 deletions(-)
diff --git a/drivers/video/exynos/s6e8ax0.c b/drivers/video/exynos/s6e8ax0.c
index 05d080b..5d9be51 100644
--- a/drivers/video/exynos/s6e8ax0.c
+++ b/drivers/video/exynos/s6e8ax0.c
@@ -38,8 +38,7 @@
#define POWER_IS_OFF(pwr) ((pwr) == FB_BLANK_POWERDOWN)
#define POWER_IS_NRM(pwr) ((pwr) == FB_BLANK_NORMAL)
-#define lcd_to_master(a) (a->dsim_dev->master)
-#define lcd_to_master_ops(a) ((lcd_to_master(a))->master_ops)
+#define to_panel(p) container_of(p, struct s6e8ax0, entity)
enum {
DSIM_NONE_STATE = 0,
@@ -47,20 +46,34 @@ enum {
DSIM_FRAME_DONE = 2,
};
+/* This structure defines all the properties of a backlight */
+struct backlight_prop {
+ /* Current User requested brightness (0 - max_brightness) */
+ int brightness;
+ /* Maximal value for brightness (read-only) */
+ int max_brightness;
+};
+
+struct panel_platform_data {
+ unsigned intreset_delay;
+ unsigned intpower_on_delay;
+ unsigned intpower_off_delay;
+ const char *video_source_name;
+};
+
struct s6e8ax0 {
- struct device *dev;
- unsigned intpower;
- unsigned intid;
- unsigned intgamma;
- unsigned intacl_enable;
- unsigned intcur_acl;
-
- struct lcd_device *ld;
- struct backlight_device *bd;
-
- struct mipi_dsim_lcd_device *dsim_dev;
- struct lcd_platform_data*ddi_pd;
+ struct platform_device *pdev;
+ struct video_source *src;
+ struct display_entity entity;
+ unsigned intpower;
+ unsigned intid;
+ unsigned intgamma;
+ unsigned intacl_enable;
+ unsigned intcur_acl;
+ boolpanel_reverse;
+ struct panel_platform_data *plat_data;
struct mutexlock;
+ struct backlight_prop bl_prop;
bool enabled;
};
@@ -70,39 +83,42 @@ static struct regulator_bulk_data supplies[] = {
{ .supply = "vci", },
};
-static void s6e8ax0_regulator_enable(struct s6e8ax0 *lcd)
+static void s6e8ax0_regulator_enable(struct s6e8ax0 *panel)
{
int ret = 0;
- struct lcd_platform_data *pd = NULL;
+ struct panel_platform_data *plat_data = NULL;
+
+ plat_data = panel->plat_data;
- pd = lcd->ddi_pd;
- mutex_lock(&lcd->lock);
- if (!lcd->enabled) {
+ mutex_lock(&panel->lock);
+
+ if (!panel->enabled) {
ret = regulator_bulk_enable(ARRAY_SIZE(supplies), supplies);
if (ret)
goto out;
- lcd->enabled = true;
+ panel->enabled = true;
}
- msleep(pd->power_on_delay);
+ msleep(plat_data->power_on_delay);
out:
- mutex_unlock(&lcd->lock);
+ mutex_unlock(&panel->lock);
}
-static void s6e8ax0_regulator_disable(struct s6e8ax0 *lcd)
+static void s6e8ax0_regulator_disable(struct s6e8ax0 *panel)
{
int ret = 0;
- mutex_lock(&lcd->lock);
- if (lcd->enabled) {
+ mutex_lock(&panel->lock);
+
+ if (panel->enabled) {
ret = regulator_bulk_disable(ARRAY_SIZE(supplies), supplies);
if (ret)
goto out;
- lcd->enabled = false;
+ panel->enabled = false;
}
out:
- mutex_unlock(&lcd->lock);
+ mutex_unlock(&panel->lock);
}
static const unsigned char s6e8ax0_22_gamma_30[] = {
@@ -283,10 +299,8 @@ static const unsigned char *s6e8ax0_22_gamma_table[] = {
s6e8ax0_22_gamma_300,
};
-static void s6e8ax0_panel_cond(struct s6e8ax0 *lcd)
+static void s6e8ax0_panel_cond(struct s6e8ax0 *panel)
{
- struct mipi_dsim_master_ops *ops = lcd_to_master_ops(lcd);
-
static const unsigned char data_to_send[] = {
0xf8, 0x3d, 0x35, 0x00, 0x00, 0x00, 0x93, 0x00, 0x3c, 0x7d,
0x08, 0x27, 0x7d, 0x3f, 0x00, 0x00, 0x00, 0x20, 0x04, 0x08,
@@ -300,239 +314,218 @@ static void s6e8ax0_panel_cond(struct s6e8ax0 *lcd)
0xc1, 0x01, 0x41, 0xc1, 0x00, 0xc1, 0xf6, 0xf6, 0xc1
};
- if (lcd->dsim_dev->panel_reverse)
- ops->cmd_write(lcd_to_master(lcd), MIPI_DSI_DCS_LONG_WRITE,
+ if (panel->panel_reverse)
+ panel->src->ops.dsi->dcs_write(panel->src,
MIPI_DSI_DCS_LONG_WRITE,
data_to_send_panel_reverse,
ARRAY_SIZE(data_to_send_panel_reverse));
else
[PATCH] Make s6e8ax0 panel driver compliant with CDF
From: Vikas Sajjan Have made necessary chanages in s6e8ax0 panel driver, made an effort to remove dependency on backlight and lcd framework, but its NOT fully done. s6e8ax0_get_brightness() and s6e8ax0_set_brightness() functionalities have NOT been modified. as backlight support in CDF are _NOT_ implemented yet. Thought of adding these "get and set" as part of display_entity_control_ops(), but didn't modify as of now. Any thoughts on the same will be helpful. removed the lcd_ops "set_power and get_power" and added as part of panel_set_state. I _SHALL_ test these modificaions once i get the s6e8ax0 panel. Vikas Sajjan (1): [RFC]: video: exynos: Making s6e8ax0 panel driver compliant with CDF drivers/video/exynos/s6e8ax0.c | 582 ++-- 1 file changed, 314 insertions(+), 268 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Initial scan files troubles and brainstorming
On 08-01-13 21:01, Johannes Stezenbach wrote: On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: On 07-01-13 11:46, Jiri Slaby wrote: On 12/18/2012 11:01 PM, Oliver Schinagl wrote: Unfortunatly, I have had zero replies. Hmm, it's sad there is a silence in this thread from linux-media guys :/. In their defense, they are very very busy people ;) chatter on this thread does bring it up however. This is such a nice thing to say :-) But it might be that Mauro thinks the dvb-apps maintainer should respond, but apparently there is no dvb-apps maintainer... Maybe you should ask Mauro directly to create an account for you to implement what you proposed. Mauro is CC'ed and I'd ask of course for this (I kinda did) but who decides what I suggested is a good idea? I personally obviously think it is ;) and even more so if dvb-apps are unmaintained. I guess the question now becomes 'who okay's this change? Who says 'okay, lets do it this way. Once that is answered we can go from there ;) Thanks, Johannes -- To unsubscribe from this list: send the line "unsubscribe 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: [RFC v2 0/5] Common Display Framework
Hi Laurent, CDF will also be helpful in supporting Panels with integrated audio (HDMI/DP) if we can add audio related control operations to display_entity_control_ops. Video controls will be called by crtc in DRM/V4L and audio controls from Alsa. Secondly, if I need to support get_modes operation in hdmi/dp panel, I need to implement edid parser inside the panel driver. It will be meaningful to add get_edid control operation for hdmi/dp. regards, Rahul Sharma. On Tue, Jan 8, 2013 at 9:43 PM, Rob Clark wrote: > On Tue, Jan 8, 2013 at 2:25 AM, Laurent Pinchart > wrote: >> Hi Rob, >> >> On Thursday 27 December 2012 09:54:55 Rob Clark wrote: >>> What I've done to avoid that so far is that the master device registers the >>> drivers for it's output sub-devices before registering it's own device. >> >> I'm not sure to follow you here. The master device doesn't register anything, >> do you mean the master device driver ? If so, how does the master device >> driver register its own device ? Devices are not registered by their driver. > > sorry, that should have read "master driver registers drivers for it's > sub-devices.." > > BR, > -R > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
