Re: [PATCH] V4L: s5c73m3: Add format propagation for TRY formats
Hi Laurent,
Thank you for the review.
On 08/09/2013 12:58 AM, Laurent Pinchart wrote:
> Hello,
>
> On Wednesday 24 July 2013 16:57:32 Sylwester Nawrocki wrote:
>> From: Andrzej Hajda
>>
>> Resolution set on ISP pad of S5C73M3-OIF subdev should be
>> propagated to source pad for TRY and ACTIVE formats.
>> The patch adds missing propagation for TRY format.
> I might be missing something, but where's the propagation for the ACTIVE
> format ?
In case of active format there are no separate containers
for the format of each pad, instead they shares common fields,
precisely .oif_pix_size and .mbus_code.
This way there is no need for extra code for format propagation.
Regards
Andrzej
>
>> Signed-off-by: Andrzej Hajda
>> Signed-off-by: Kyungmin Park
>> Signed-off-by: Sylwester Nawrocki
>> ---
>> drivers/media/i2c/s5c73m3/s5c73m3-core.c |5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
>> b/drivers/media/i2c/s5c73m3/s5c73m3-core.c index 825ea86..b76ec0e 100644
>> --- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
>> +++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
>> @@ -,6 +,11 @@ static int s5c73m3_oif_set_fmt(struct v4l2_subdev
>> *sd, if (fmt->which == V4L2_SUBDEV_FORMAT_TRY) {
>> mf = v4l2_subdev_get_try_format(fh, fmt->pad);
>> *mf = fmt->format;
>> +if (fmt->pad == OIF_ISP_PAD) {
>> +mf = v4l2_subdev_get_try_format(fh, OIF_SOURCE_PAD);
>> +mf->width = fmt->format.width;
>> +mf->height = fmt->format.height;
>> +}
>> } else {
>> switch (fmt->pad) {
>> case OIF_ISP_PAD:
--
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 0/3] Experimental patches for ISDB-T on Mygica X8502/X8507
Hi El 08/08/13 13:51, Mauro Carvalho Chehab escribió: This is a first set of experimental patches for Mygica X8502/X8507. The last patch is just a very dirty hack, for testing purposes. I intend to get rid of it, but it is there to replace exactly the same changes that Alfredo reported to work on Kernel 3.2. I intend to remove it on a final series, eventually replacing by some other changes at mb86a20s. Alfredo, Please test, and send your tested-by, if this works for you. tested-by: Alfredo Delaiti two comments: two "breaks": @@ -1106,6 +1112,8 @@ static int dvb_register(struct cx23885_tsport *port) &i2c_bus2->i2c_adap, &mygica_x8506_xc5000_config); } + cx23885_set_frontend_hook(port, fe0->dvb.frontend); + break; break; and I would add this on cx23885-cards.c (is not a patch): case CX23885_BOARD_MYGICA_X8506: case CX23885_BOARD_MAGICPRO_PROHDTVE2: case CX23885_BOARD_MYGICA_X8507: /* GPIO-0 (0)Analog / (1)Digital TV */ /* GPIO-1 reset XC5000 */ -/* GPIO-2 reset LGS8GL5 / LGS8G75 */ +/* GPIO-2 reset LGS8GL5 / LGS8G75 / MB86A20S */ cx23885_gpio_enable(dev, GPIO_0 | GPIO_1 | GPIO_2, 1); cx23885_gpio_clear(dev, GPIO_1 | GPIO_2); mdelay(100); cx23885_gpio_set(dev, GPIO_0 | GPIO_1 | GPIO_2); mdelay(100); break; Thanks again Mauro, Alfredo Thanks! Mauro Mauro Carvalho Chehab (3): cx23885-dvb: use a better approach to hook set_frontend cx23885: Add DTV support for Mygica X8502/X8507 boards mb86a20s: hack it to emulate what x8502 driver does drivers/media/dvb-frontends/mb86a20s.c| 100 ++ drivers/media/pci/cx23885/Kconfig | 1 + drivers/media/pci/cx23885/cx23885-cards.c | 4 +- drivers/media/pci/cx23885/cx23885-dvb.c | 49 --- drivers/media/pci/cx23885/cx23885.h | 2 + 5 files changed, 147 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] media: Check for active links on pads with MEDIA_PAD_FL_MUST_CONNECT flag
Hi Sakari,
Thank you for the patch.
On Friday 19 July 2013 20:55:07 Sakari Ailus wrote:
> Do not allow streaming if a pad with MEDIA_PAD_FL_MUST_CONNECT flag is not
> connected by an active link.
>
> This patch makes it possible to avoid drivers having to check for the most
> common case of link state validation: a sink pad that must be connected.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/media-entity.c | 34 +++---
> 1 file changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> index cb30ffb..4e58f8a 100644
> --- a/drivers/media/media-entity.c
> +++ b/drivers/media/media-entity.c
> @@ -20,6 +20,7 @@
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
> USA */
>
> +#include
> #include
> #include
> #include
> @@ -227,6 +228,7 @@ __must_check int media_entity_pipeline_start(struct
> media_entity *entity, media_entity_graph_walk_start(&graph, entity);
>
> while ((entity = media_entity_graph_walk_next(&graph))) {
> + DECLARE_BITMAP(active, entity->num_pads);
> unsigned int i;
>
> entity->stream_count++;
> @@ -240,21 +242,39 @@ __must_check int media_entity_pipeline_start(struct
> media_entity *entity, if (!entity->ops || !entity->ops->link_validate)
> continue;
>
> + bitmap_zero(active, entity->num_pads);
> +
> for (i = 0; i < entity->num_links; i++) {
> struct media_link *link = &entity->links[i];
> -
> - /* Is this pad part of an enabled link? */
> - if (!(link->flags & MEDIA_LNK_FL_ENABLED))
> - continue;
> -
> - /* Are we the sink or not? */
> - if (link->sink->entity != entity)
> + struct media_pad *pad = link->sink->entity == entity
> + ? link->sink : link->source;
> +
> + /*
> + * Pads that either do not need to connect or
> + * are connected through an enabled link are
> + * fine.
> + */
> + if (!(pad->flags & MEDIA_PAD_FL_MUST_CONNECT)
> + || link->flags & MEDIA_LNK_FL_ENABLED)
> + bitmap_set(active, pad->index, 1);
> +
> + /*
> + * Link validation will only take place for
> + * sink ends of the link that are enabled.
> + */
> + if (link->sink != pad
> + || !(link->flags & MEDIA_LNK_FL_ENABLED))
> continue;
>
> ret = entity->ops->link_validate(link);
> if (ret < 0 && ret != -ENOIOCTLCMD)
> goto error;
> }
> +
> + if (!bitmap_full(active, entity->num_pads)) {
> + ret = -EPIPE;
> + goto error;
> + }
I'm afraid that won't work if one of the pads has no links. In that case the
bitmap won't be full. I think you will have to iterate separately on the links
to validate them, and on the pads to check the flags.
> }
>
> mutex_unlock(&mdev->graph_mutex);
--
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] V4L: s5c73m3: Add format propagation for TRY formats
Hello,
On Wednesday 24 July 2013 16:57:32 Sylwester Nawrocki wrote:
> From: Andrzej Hajda
>
> Resolution set on ISP pad of S5C73M3-OIF subdev should be
> propagated to source pad for TRY and ACTIVE formats.
> The patch adds missing propagation for TRY format.
I might be missing something, but where's the propagation for the ACTIVE
format ?
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Kyungmin Park
> Signed-off-by: Sylwester Nawrocki
> ---
> drivers/media/i2c/s5c73m3/s5c73m3-core.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
> b/drivers/media/i2c/s5c73m3/s5c73m3-core.c index 825ea86..b76ec0e 100644
> --- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
> +++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
> @@ -,6 +,11 @@ static int s5c73m3_oif_set_fmt(struct v4l2_subdev
> *sd, if (fmt->which == V4L2_SUBDEV_FORMAT_TRY) {
> mf = v4l2_subdev_get_try_format(fh, fmt->pad);
> *mf = fmt->format;
> + if (fmt->pad == OIF_ISP_PAD) {
> + mf = v4l2_subdev_get_try_format(fh, OIF_SOURCE_PAD);
> + mf->width = fmt->format.width;
> + mf->height = fmt->format.height;
> + }
> } else {
> switch (fmt->pad) {
> case OIF_ISP_PAD:
--
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 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code
On 08/08/2013 04:10 PM, Tomasz Figa wrote:
> On Thursday 08 of August 2013 15:47:19 Stephen Warren wrote:
>> On 08/08/2013 03:19 PM, Tomasz Figa wrote:
>>> On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote:
On 08/05/2013 06:26 AM, Marek Szyprowski wrote:
> MFC driver use custom bindings for managing reserved memory. Those
> bindings are not really specific to MFC device and no even well
> discussed. They can be easily replaced with generic, platform
> independent code for handling reserved and contiguous memory.
>
> Two additional child devices for each memory port (AXI master) are
> introduced to let one assign some properties to each of them. Later
> one
> can also use them to assign properties related to SYSMMU
> controllers,
> which can be used to manage the limited dma window provided by those
> memory ports.
...
> +Two child nodes must be defined for MFC device. Their names must be
> +following: "memport-r" and "memport-l" ("right" and "left").
> Required
Node names shouldn't have semantic meaning.
>>>
>>> What about bus-master-0 and bus-master-1?
>>
>> Just "bus-master" for each might make sense. Use reg properties to
>> differentiate the two?
>
> What this reg property would mean in this case?
>
> My understanding of reg property was that it should be used for real
> addresses or IDs and for all other cases node names should be suffixed
> with "-ID".
Presumably it would hold the ID of the HW block as defined in the
documentation. Or, it could be somewhat arbitrary.
--
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] smiapp: re-use clamp_t instead of min(..., max(...))
Hi Sakari, On Wednesday 24 July 2013 18:55:38 Sakari Ailus wrote: > On Wed, Jul 24, 2013 at 06:49:24PM +0300, Andy Shevchenko wrote: > > On Wed, Jul 24, 2013 at 6:45 PM, Sakari Ailus wrote: > > > > [] > > > > >> + max_m = clamp_t(u32, max_m, > > >> sensor->limits[SMIAPP_LIMIT_SCALER_M_MIN], + > > >> sensor->limits[SMIAPP_LIMIT_SCALER_M_MAX]); > > > > > > Do you need clamp_t()? Wouldn't plain clamp() do? > > > > The *_t variants are preferred due to they are faster (no type checking). > > > > > I can change it if you're ok with that. > > > > I don't know why you may choose clamp instead of clamp_t here. Are you > > going to change variable types? > > Probably not. But clamp() would serve as a sanity check vs. clamp_t() which > just does the thing. I'd prefer clamp() --- the compiler will not spend much > time on it anyway. Should I take this patch in my tree ? If so, could you please repost it with clamp() instead of clamp_t(), and your SoB or Acked-by ? -- 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 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code
On Thursday 08 of August 2013 15:47:19 Stephen Warren wrote: > On 08/08/2013 03:19 PM, Tomasz Figa wrote: > > Hi Stephen, > > > > On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote: > >> On 08/05/2013 06:26 AM, Marek Szyprowski wrote: > >>> MFC driver use custom bindings for managing reserved memory. Those > >>> bindings are not really specific to MFC device and no even well > >>> discussed. They can be easily replaced with generic, platform > >>> independent code for handling reserved and contiguous memory. > >>> > >>> Two additional child devices for each memory port (AXI master) are > >>> introduced to let one assign some properties to each of them. Later > >>> one > >>> can also use them to assign properties related to SYSMMU > >>> controllers, > >>> which can be used to manage the limited dma window provided by those > >>> memory ports. > >>> > >>> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt > >>> b/Documentation/devicetree/bindings/media/s5p-mfc.txt > >>> > >>> +The MFC device is connected to system bus with two memory ports > >>> (AXI > >>> +masters) for better performance. Those memory ports are modelled as > >>> +separate child devices, so one can assign some properties to them > >>> (like +memory region for dma buffer allocation or sysmmu > >>> controller). > >>> + > >>> > >>> Required properties: > >>>- compatible : value should be either one among the following > >>> > >>> (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs > >>> (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs > >>> > >>> + and additionally "simple-bus" to correctly initialize child > >>> + devices for memory ports (AXI masters) > >> > >> simple-bus is wrong here; the child nodes aren't independent entities > >> that can be instantiated separately from their parent and without > >> depending on their parent. > > > > I fully agree, but I can't think of anything better. Could you suggest > > a solution that would cover our use case: > > > > The MFC IP has two separate bus masters (called here and there > > memports). On some SoCs, each master must use different memory bank > > to meet memory bandwidth requirements for higher bitrate video > > streams. This can be seen as MFC having two DMA subdevices, which > > have different DMA windows. > > > > On Linux, this is handled by binding two appropriate CMA memory > > regions to the memports, so the driver can do DMA allocations on > > behalf of particular memport and get appropriate memory for it. > > I don't see what that has to do with simple-bus. Well, this is not the first binding doing things this way, unless I don't understand something. See the recently posted mvebu bindings. Using simple-bus for this has the nice property of allowing both non-DT and DT cases to be handled in exactly the same way in MFC driver. > Whatever parses the > node of the MFC can directly read from any contained property or child > node; there's no need to try and get the core DT tree parser to > enumerate the children. > > If you actually need a struct platform_device for each of these child > nodes (which sounds wrong, but I'm not familiar with the code) We need struct device for each memport and CMA region bound to both of them. This is a requirement of the Linux DMA mapping API, and well, it represents real hardware structure anyway. > , then > simply have the driver call of_platform_populate() itself at the > appropriate time. This sounds fine to me. > But that's not going to work well unless the child > nodes have compatible values, which doesn't seem right given their > purpose. > >>> - - samsung,mfc-r : Base address of the first memory bank used by > >>> MFC > >>> - for DMA contiguous memory allocation and its size. > >>> - > >>> - - samsung,mfc-l : Base address of the second memory bank used by > >>> MFC > >>> - for DMA contiguous memory allocation and its size. > >> > >> These properties shouldn't be removed, but simply marked deprecated. > >> The driver will need to continue to support them so that old DTs > >> work with new kernels. The binding must therefore continue to > >> document them so that the old DT content still makes sense. > > > > I tend to disagree on this. For Samsung platforms we've been trying to > > avoid DT bindings changes as much as possible, but I'd rather say that > > device tree was coupled with kernel version it came from, so Samsung- > > specific bindings haven't been fully stabilized yet, especially since > > we are still at discussion stage when it's about defining processes > > for binding staging and stabilization. > > Well, that's why everyone is shouting at ARM for abusing DT... IMHO this is not fully fair. We have a lot of development happenning on ARM. Things usually can't be done perfectly on first iteration, while we often want things working reasonably ASAP. This is why I'm really all for staging/stable separation. I believe things need to be te
Re: [PATCH 6/6] experimental: arm: dts: dra7xx: Add a DT node for VPE
Hi Archit,
Thank you for the patch.
On Friday 02 August 2013 19:33:43 Archit Taneja wrote:
> Add a DT node for VPE in dra7.dtsi. This is experimental because we might
> need to split the VPE address space a bit more, and also because the IRQ
> line described is accessible the IRQ crossbar driver is added for DRA7XX.
>
> Cc: Rajendra Nayak
> Cc: Sricharan R
> Signed-off-by: Archit Taneja
> ---
> arch/arm/boot/dts/dra7.dtsi | 11 +++
Documentation is missing :-) As this is an experimental patch you can probably
document the bindings later.
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index ce9a0f0..3237972 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -484,6 +484,17 @@
> dmas = <&sdma 70>, <&sdma 71>;
> dma-names = "tx0", "rx0";
> };
> +
> + vpe {
> + compatible = "ti,vpe";
> + ti,hwmods = "vpe";
> + reg = <0x489d 0xd000>, <0x489dd000 0x400>;
> + reg-names = "vpe", "vpdma";
> + interrupts = <0 159 0x4>;
> + #address-cells = <1>;
> + #size-cells = <0>;
Are #address-cells and #size-cells really needed ?
> + };
> +
> };
>
> clocks {
--
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 v4 01/13] [media] exynos5-is: Adding media device driver for exynos5
On 08/07/2013 11:03 AM, Arun Kumar K wrote: From: Shaik Ameer Basha This patch adds support for media device for EXYNOS5 SoCs. The current media device supports the following ips to connect through the media controller framework. * MIPI-CSIS Support interconnection(subdev interface) between devices * FIMC-LITE Support capture interface from device(Sensor, MIPI-CSIS) to memory Support interconnection(subdev interface) between devices * FIMC-IS Camera post-processing IP having multiple sub-nodes. G-Scaler will be added later to the current media device. The media device creates two kinds of pipelines for connecting the above mentioned IPs. The pipeline0 is uses Sensor, MIPI-CSIS and FIMC-LITE which captures image data and dumps to memory. Pipeline1 uses FIMC-IS components for doing post-processing operations on the captured image and give scaled YUV output. Pipeline0 ++ +---+ +---+ ++ | Sensor | --> | MIPI-CSIS | --> | FIMC-LITE | --> | Memory | ++ +---+ +---+ ++ Pipeline1 ++ ++ +---+ +---+ | Memory | --> | ISP | --> |SCC| --> |SCP| ++ ++ +---+ +---+ Signed-off-by: Shaik Ameer Basha Signed-off-by: Arun Kumar K --- .../devicetree/bindings/media/exynos5-mdev.txt | 148 +++ drivers/media/platform/exynos5-is/exynos5-mdev.c | 1189 drivers/media/platform/exynos5-is/exynos5-mdev.h | 164 +++ 3 files changed, 1501 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/exynos5-mdev.txt create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.c create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.h diff --git a/Documentation/devicetree/bindings/media/exynos5-mdev.txt b/Documentation/devicetree/bindings/media/exynos5-mdev.txt new file mode 100644 index 000..8b2ffb9 --- /dev/null +++ b/Documentation/devicetree/bindings/media/exynos5-mdev.txt @@ -0,0 +1,148 @@ +Samsung EXYNOS5 SoC Camera Subsystem + + +The Exynos5 SoC Camera subsystem comprises of multiple sub-devices +represented by separate device tree nodes. Currently this includes: FIMC-LITE, +MIPI CSIS and FIMC-IS. + +The sub-subdevices are defined as child nodes of the common 'camera' node which +also includes common properties of the whole subsystem not really specific to +any single sub-device, like common camera port pins or the CAMCLK clock outputs +for external image sensors attached to an SoC. + +Common 'camera' node + + +Required properties: + +- compatible : must be "samsung,exynos5-fimc", "simple-bus" +- clocks : list of clock specifiers, corresponding to entries in + the clock-names property; +- clock-names : must contain "sclk_bayer" entry and matching clock property + entry I guess "and matching clock property entry" could be removed. +The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used +to define a required pinctrl state named "default" and optional pinctrl states: How about only supporting "default" pinctrl state in this initial DT binding/driver version ? The optional states could be added later, my concern is that except the camera port A, B there is also the RGB camera bay. Thus using "idle", "active-a", active-b" won't work any more. We need to find some better solution for that. Besides now when you removed the clock provider, there is not much you could do with those optional pinctrl states. Those were originally meant to be used in the clk_prepare/clk_unprepare ops. So, e.g. when sensor disables the clock the host driver sets a clock output pin into idle state, e.g. input with pull down. But maybe Exynos5 SoCs got improved comparing to e.g. Exynos4 so the clock output pin is put into high impedance state when the sclk_cam clock is disabled ? However that seems unlikely. +"idle", "active-a", active-b". These optional states can be used to switch the +camera port pinmux at runtime. The "idle" state should configure both the camera +ports A and B into high impedance state, especially the CAMCLK clock output +should be inactive. For the "active-a" state the camera port A must be activated +and the port B deactivated and for the state "active-b" it should be the other +way around. + +The 'camera' node must include at least one 'fimc-lite' child node. This shouldn't be necessary, i.e. making the individual device nodes child nodes of the camera node. Think of GScaler which can be used either by the camera or the display/HDMI subsystem. Although csis and fimc-lite are purely camera specific I'm inclined to move them out of the camera node and couple them with this node either manually through 'compatible' values or explicitly through phandles. +'parallel-ports' node +--
Re: [PATCH 1/6] v4l: ti-vpe: Create a vpdma helper library
Hi Archit,
Thank you for the patch.
On Friday 02 August 2013 19:33:38 Archit Taneja wrote:
> The primary function of VPDMA is to move data between external memory and
> internal processing modules(in our case, VPE) that source or sink data.
> VPDMA is capable of buffering this data and then delivering the data as
> demanded to the modules as programmed. The modules that source or sink data
> are referred to as clients or ports. A channel is setup inside the VPDMA to
> connect a specific memory buffer to a specific client. The VPDMA
> centralizes the DMA control functions and buffering required to allow all
> the clients to minimize the effect of long latency times.
>
> Add the following to the VPDMA helper:
>
> - A data struct which describe VPDMA channels. For now, these channels are
> the ones used only by VPE, the list of channels will increase when
> VIP(Video Input Port) also uses the VPDMA library. This channel information
> will be used to populate fields required by data descriptors.
>
> - Data structs which describe the different data types supported by VPDMA.
> This data type information will be used to populate fields required by data
> descriptors and used by the VPE driver to map a V4L2 format to the
> corresponding VPDMA data type.
>
> - Provide VPDMA register offset definitions, functions to read, write and
> modify VPDMA registers.
>
> - Functions to create and submit a VPDMA list. A list is a group of
> descriptors that makes up a set of DMA transfers that need to be completed.
> Each descriptor will either perform a DMA transaction to fetch input
> buffers and write to output buffers(data descriptors), or configure the
> MMRs of sub blocks of VPE(configuration descriptors), or provide control
> information to VPDMA (control descriptors).
>
> - Functions to allocate, map and unmap buffers needed for the descriptor
> list, payloads containing MMR values and motion vector buffers. These use
> the DMA mapping APIs to ensure exclusive access to VPDMA.
>
> - Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt on
> the VPE interrupt line when a descriptor list is parsed completely and the
> DMA transactions are completed. This requires masking the events in VPDMA
> registers and configuring some top level VPE interrupt registers.
>
> - Enable some VPDMA specific parameters: frame start event(when to start DMA
> for a client) and line mode(whether each line fetched should be mirrored or
> not).
>
> - Function to load firmware required by VPDMA. VPDMA requires a firmware for
> it's internal list manager. We add the required request_firmware apis to
> fetch this firmware from user space.
>
> - Function to dump VPDMA registers.
>
> - A function to initialize VPDMA, this will be called by the VPE driver with
> it's platform device pointer, this function will take care of loading VPDMA
> firmware and returning a handle back to the VPE driver. The VIP driver will
> also call the same init function to initialize it's own VPDMA instance.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/media/platform/ti-vpe/vpdma.c | 589 ++
> drivers/media/platform/ti-vpe/vpdma.h | 154
> drivers/media/platform/ti-vpe/vpdma_priv.h | 119 ++
> 3 files changed, 862 insertions(+)
> create mode 100644 drivers/media/platform/ti-vpe/vpdma.c
> create mode 100644 drivers/media/platform/ti-vpe/vpdma.h
> create mode 100644 drivers/media/platform/ti-vpe/vpdma_priv.h
>
> diff --git a/drivers/media/platform/ti-vpe/vpdma.c
> b/drivers/media/platform/ti-vpe/vpdma.c new file mode 100644
> index 000..b15b3dd
> --- /dev/null
> +++ b/drivers/media/platform/ti-vpe/vpdma.c
> @@ -0,0 +1,589 @@
[snip]
> +static int get_field(u32 value, u32 mask, int shift)
> +{
> + return (value & (mask << shift)) >> shift;
> +}
> +
> +static int get_field_reg(struct vpdma_data *vpdma, int offset,
> + u32 mask, int shift)
I would call this read_field_reg().
> +{
> + return get_field(read_reg(vpdma, offset), mask, shift);
> +}
> +
> +static void insert_field(u32 *valp, u32 field, u32 mask, int shift)
> +{
> + u32 val = *valp;
> +
> + val &= ~(mask << shift);
> + val |= (field & mask) << shift;
> + *valp = val;
> +}
get_field() and insert_field() are used in a single location, you can manually
inline them.
> +static void insert_field_reg(struct vpdma_data *vpdma, int offset, u32
> field,
> + u32 mask, int shift)
> +{
> + u32 val = read_reg(vpdma, offset);
> +
> + insert_field(&val, field, mask, shift);
> +
> + write_reg(vpdma, offset, val);
> +}
[snip]
> +/*
> + * Allocate a DMA buffer
> + */
> +int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
> +{
> + buf->size = size;
> + buf->mapped = 0;
> + buf->addr = kzalloc(size, GFP_KERNEL);
You should use the dma allocation API (depending on your needs,
dma_alloc_coherent for instance) to allocate DMA-able buffers.
> + if (!buf->addr)
> +
Re: [PATCH 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code
On 08/08/2013 03:19 PM, Tomasz Figa wrote:
> Hi Stephen,
>
> On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote:
>> On 08/05/2013 06:26 AM, Marek Szyprowski wrote:
>>> MFC driver use custom bindings for managing reserved memory. Those
>>> bindings are not really specific to MFC device and no even well
>>> discussed. They can be easily replaced with generic, platform
>>> independent code for handling reserved and contiguous memory.
>>>
>>> Two additional child devices for each memory port (AXI master) are
>>> introduced to let one assign some properties to each of them. Later
>>> one
>>> can also use them to assign properties related to SYSMMU controllers,
>>> which can be used to manage the limited dma window provided by those
>>> memory ports.
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
>>> b/Documentation/devicetree/bindings/media/s5p-mfc.txt
>>>
>>> +The MFC device is connected to system bus with two memory ports (AXI
>>> +masters) for better performance. Those memory ports are modelled as
>>> +separate child devices, so one can assign some properties to them
>>> (like +memory region for dma buffer allocation or sysmmu controller).
>>> +
>>>
>>> Required properties:
>>>- compatible : value should be either one among the following
>>>
>>> (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
>>> (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
>>>
>>> + and additionally "simple-bus" to correctly initialize child
>>> + devices for memory ports (AXI masters)
>>
>> simple-bus is wrong here; the child nodes aren't independent entities
>> that can be instantiated separately from their parent and without
>> depending on their parent.
>
> I fully agree, but I can't think of anything better. Could you suggest a
> solution that would cover our use case:
>
> The MFC IP has two separate bus masters (called here and there memports).
> On some SoCs, each master must use different memory bank to meet memory
> bandwidth requirements for higher bitrate video streams. This can be seen
> as MFC having two DMA subdevices, which have different DMA windows.
>
> On Linux, this is handled by binding two appropriate CMA memory regions to
> the memports, so the driver can do DMA allocations on behalf of particular
> memport and get appropriate memory for it.
I don't see what that has to do with simple-bus. Whatever parses the
node of the MFC can directly read from any contained property or child
node; there's no need to try and get the core DT tree parser to
enumerate the children.
If you actually need a struct platform_device for each of these child
nodes (which sounds wrong, but I'm not familiar with the code), then
simply have the driver call of_platform_populate() itself at the
appropriate time. But that's not going to work well unless the child
nodes have compatible values, which doesn't seem right given their purpose.
>>> - - samsung,mfc-r : Base address of the first memory bank used by MFC
>>> - for DMA contiguous memory allocation and its size.
>>> -
>>> - - samsung,mfc-l : Base address of the second memory bank used by
>>> MFC
>>> - for DMA contiguous memory allocation and its size.
>>
>> These properties shouldn't be removed, but simply marked deprecated. The
>> driver will need to continue to support them so that old DTs work with
>> new kernels. The binding must therefore continue to document them so
>> that the old DT content still makes sense.
>
> I tend to disagree on this. For Samsung platforms we've been trying to
> avoid DT bindings changes as much as possible, but I'd rather say that
> device tree was coupled with kernel version it came from, so Samsung-
> specific bindings haven't been fully stabilized yet, especially since we
> are still at discussion stage when it's about defining processes for
> binding staging and stabilization.
Well, that's why everyone is shouting at ARM for abusing DT...
> I would rather see this patch as part of work on Samsung DT binding
> janitoring or maybe even sanitizing in some cases, like this one, when the
> old (and IMHO bad) MFC binding was introduced without proper review. I
> don't think we want to support this kind of brokenness anymore, especially
> considering the hacks which would be required by such support (see
> original implementation of this binding and code required in board file).
>
>>> +Two child nodes must be defined for MFC device. Their names must be
>>> +following: "memport-r" and "memport-l" ("right" and "left"). Required
>>
>> Node names shouldn't have semantic meaning.
>
> What about bus-master-0 and bus-master-1?
Just "bus-master" for each might make sense. Use reg properties to
differentiate the two?
--
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] v4l: ti-vpe: Create a vpdma helper library
Hi Archit,
On Monday 05 August 2013 16:56:46 Archit Taneja wrote:
> On Monday 05 August 2013 01:43 PM, Tomi Valkeinen wrote:
> > On 02/08/13 17:03, Archit Taneja wrote:
> >> +struct vpdma_data_format vpdma_yuv_fmts[] = {
> >> + [VPDMA_DATA_FMT_Y444] = {
> >> + .data_type = DATA_TYPE_Y444,
> >> + .depth = 8,
> >> + },
> >
> > This, and all the other tables, should probably be consts?
>
> That's true, I'll fix those.
>
> >> +static void insert_field(u32 *valp, u32 field, u32 mask, int shift)
> >> +{
> >> + u32 val = *valp;
> >> +
> >> + val &= ~(mask << shift);
> >> + val |= (field & mask) << shift;
> >> + *valp = val;
> >> +}
> >
> > I think "insert" normally means, well, inserting a thing in between
> > something. What you do here is overwriting.
> >
> > Why not just call it "write_field"?
>
> sure, will change it.
>
> >> + * Allocate a DMA buffer
> >> + */
> >> +int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
> >> +{
> >> + buf->size = size;
> >> + buf->mapped = 0;
> >
> > Maybe true/false is clearer here that 0/1.
>
> okay.
>
> >> +/*
> >> + * submit a list of DMA descriptors to the VPE VPDMA, do not wait for
> >> completion + */
> >> +int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list
> >> *list) +{
> >> + /* we always use the first list */
> >> + int list_num = 0;
> >> + int list_size;
> >> +
> >> + if (vpdma_list_busy(vpdma, list_num))
> >> + return -EBUSY;
> >> +
> >> + /* 16-byte granularity */
> >> + list_size = (list->next - list->buf.addr) >> 4;
> >> +
> >> + write_reg(vpdma, VPDMA_LIST_ADDR, (u32) list->buf.dma_addr);
> >> + wmb();
> >
> > What is the wmb() for?
>
> VPDMA_LIST_ADDR needs to be written before VPDMA_LIST_ATTR, otherwise
> VPDMA doesn't work. wmb() ensures the ordering.
write_reg() calls iowrite32(), which already includes an __iowmb().
> >> + write_reg(vpdma, VPDMA_LIST_ATTR,
> >> + (list_num << VPDMA_LIST_NUM_SHFT) |
> >> + (list->type << VPDMA_LIST_TYPE_SHFT) |
> >> + list_size);
> >> +
> >> + return 0;
> >> +}
> >>
> >> +static void vpdma_firmware_cb(const struct firmware *f, void *context)
> >> +{
> >> + struct vpdma_data *vpdma = context;
> >> + struct vpdma_buf fw_dma_buf;
> >> + int i, r;
> >> +
> >> + dev_dbg(&vpdma->pdev->dev, "firmware callback\n");
> >> +
> >> + if (!f || !f->data) {
> >> + dev_err(&vpdma->pdev->dev, "couldn't get firmware\n");
> >> + return;
> >> + }
> >> +
> >> + /* already initialized */
> >> + if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
> >> + VPDMA_LIST_RDY_SHFT)) {
> >> + vpdma->ready = true;
> >> + return;
> >> + }
> >> +
> >> + r = vpdma_buf_alloc(&fw_dma_buf, f->size);
> >> + if (r) {
> >> + dev_err(&vpdma->pdev->dev,
> >> + "failed to allocate dma buffer for firmware\n");
> >> + goto rel_fw;
> >> + }
> >> +
> >> + memcpy(fw_dma_buf.addr, f->data, f->size);
> >> +
> >> + vpdma_buf_map(vpdma, &fw_dma_buf);
> >> +
> >> + write_reg(vpdma, VPDMA_LIST_ADDR, (u32) fw_dma_buf.dma_addr);
> >> +
> >> + for (i = 0; i < 100; i++) { /* max 1 second */
> >> + msleep_interruptible(10);
> >
> > You call interruptible version here, but you don't handle the
> > interrupted case. I believe the loop will just continue looping, even if
> > the user interrupted.
>
> Okay. I think I don't understand the interruptible version correctly. We
> don't need to msleep_interruptible here, we aren't waiting on any wake
> up event, we just want to wait till a bit gets set.
>
> I am thinking of implementing something similar to wait_for_bit_change()
> in 'drivers/video/omap2/dss/dsi.c'
--
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: 'Siano Mobile Silicon' firmware doesn't load in 3.10.x
On Thu, Aug 08, 2013 at 05:52:53PM +0200, mario tillmann wrote: > With the latest kernel 3.10.x I get an error message when loading the firmware > sms1xxx-hcw-55xxx-dvbt-02.fw: > > smscore_load_firmware_family2: line: 986: sending > MSG_SMS_DATA_VALIDITY_REQ expecting 0xcfed1755 > smscore_onresponse: line: 1565: MSG_SMS_DATA_VALIDITY_RES, checksum = > 0xcfed1755 > > This error is reported for 32/64 bit systems. > > If I can assist in debugging, please let me know. This is a media driver, I would suggest the linux-media mailing list would know much more than the usb mailing list does (cc:ed). -- 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/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code
Hi Stephen,
On Thursday 08 of August 2013 15:00:52 Stephen Warren wrote:
> On 08/05/2013 06:26 AM, Marek Szyprowski wrote:
> > MFC driver use custom bindings for managing reserved memory. Those
> > bindings are not really specific to MFC device and no even well
> > discussed. They can be easily replaced with generic, platform
> > independent code for handling reserved and contiguous memory.
> >
> > Two additional child devices for each memory port (AXI master) are
> > introduced to let one assign some properties to each of them. Later
> > one
> > can also use them to assign properties related to SYSMMU controllers,
> > which can be used to manage the limited dma window provided by those
> > memory ports.
> >
> > diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
> > b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> >
> > +The MFC device is connected to system bus with two memory ports (AXI
> > +masters) for better performance. Those memory ports are modelled as
> > +separate child devices, so one can assign some properties to them
> > (like +memory region for dma buffer allocation or sysmmu controller).
> > +
> >
> > Required properties:
> >- compatible : value should be either one among the following
> >
> > (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
> > (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
> >
> > + and additionally "simple-bus" to correctly initialize child
> > + devices for memory ports (AXI masters)
>
> simple-bus is wrong here; the child nodes aren't independent entities
> that can be instantiated separately from their parent and without
> depending on their parent.
I fully agree, but I can't think of anything better. Could you suggest a
solution that would cover our use case:
The MFC IP has two separate bus masters (called here and there memports).
On some SoCs, each master must use different memory bank to meet memory
bandwidth requirements for higher bitrate video streams. This can be seen
as MFC having two DMA subdevices, which have different DMA windows.
On Linux, this is handled by binding two appropriate CMA memory regions to
the memports, so the driver can do DMA allocations on behalf of particular
memport and get appropriate memory for it.
> > - - samsung,mfc-r : Base address of the first memory bank used by MFC
> > - for DMA contiguous memory allocation and its size.
> > -
> > - - samsung,mfc-l : Base address of the second memory bank used by
> > MFC
> > - for DMA contiguous memory allocation and its size.
>
> These properties shouldn't be removed, but simply marked deprecated. The
> driver will need to continue to support them so that old DTs work with
> new kernels. The binding must therefore continue to document them so
> that the old DT content still makes sense.
I tend to disagree on this. For Samsung platforms we've been trying to
avoid DT bindings changes as much as possible, but I'd rather say that
device tree was coupled with kernel version it came from, so Samsung-
specific bindings haven't been fully stabilized yet, especially since we
are still at discussion stage when it's about defining processes for
binding staging and stabilization.
I would rather see this patch as part of work on Samsung DT binding
janitoring or maybe even sanitizing in some cases, like this one, when the
old (and IMHO bad) MFC binding was introduced without proper review. I
don't think we want to support this kind of brokenness anymore, especially
considering the hacks which would be required by such support (see
original implementation of this binding and code required in board file).
> > +Two child nodes must be defined for MFC device. Their names must be
> > +following: "memport-r" and "memport-l" ("right" and "left"). Required
>
> Node names shouldn't have semantic meaning.
What about bus-master-0 and bus-master-1?
> > +properties:
> > + - compatible : value should be "samsung,memport"
>
> There's no need to define compatible properties for things which aren't
> separate devices.
I agree.
> > + - dma-memory-region : optional property with a phandle to
> > respective memory + region (see
devicetree/bindings/memory.txt), if
> > no region
> > + is defined, sysmmu controller must be used for
managing
> > + limited dma window of each memory port.
>
> What's the benefit of putting this property in a sub-node; surely you
> can put the property in the main MFC node yet follow the same conceptual
> schema for its content as a dma-memory-region node?
See my use case description above.
Best regards,
Tomasz
--
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: Can I put a V4L2 soc camera driver under other subsystem directory?
On Thu, Aug 8, 2013 at 1:52 PM, Guennadi Liakhovetski wrote: > Hi Bryan, > > On Wed, 7 Aug 2013, Bryan Wu wrote: > >> Hi Guennadi and LMML, >> >> I'm working on a camera controller driver for Tegra, which is using >> soc_camera. But we also need to use Tegra specific host1x interface >> like syncpt APIs. >> >> Since host1x is quite Tegra specific framework which is in >> drivers/gpu/host1x and has several host1x's client driver like graphic >> 2D driver, my v4l2 soc_camera driver is also a host1x client driver. >> Right now host1x does not expose any global include header files like >> API in the kernel, because no other users. So we plan to put all >> host1x related driver together, is that OK for us to put our Tegra >> soc_camera driver into drivers/gpu/host1x/camera or similar? >> >> I guess besides it will introduce some extra maintenance it should be OK, >> right? > > Exactly, there's already been a precedent: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg56213.html > > It hasn't been finalised yet though. > OK, cool. I will try to provide the first version soon. Thanks a lot, -Bryan -- 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: How to express planar formats with mediabus format code?
Hi, On Tuesday 06 August 2013 17:18:14 Su Jiaquan wrote: > Hi Guennadi, > > Thanks for the reply! Please see my description inline. > > On Mon, Aug 5, 2013 at 5:02 AM, Guennadi Liakhovetski wrote: > > On Sun, 4 Aug 2013, Su Jiaquan wrote: > >> Hi, > >> > >> I know the title looks crazy, but here is our problem: > >> > >> In our SoC based ISP, the hardware can be divide to several blocks. > >> Some blocks can do color space conversion(raw to YUV interleave/planar), > >> others can do the pixel re-order(interleave/planar/semi-planar > >> conversion, UV planar switch). We use one subdev to describe each of > >> them, then came the problem: How can we express the planar formats with > >> mediabus format code? > > > > Could you please explain more exactly what you mean? How are those your > > blocks connected? How do they exchange data? If they exchange data over a > > serial bus, then I don't think planar formats make sense, right? Or do > > your blocks really output planes one after another, reordering data > > internally? That would be odd... If OTOH your blocks output data to RAM, > > and the next block takes data from there, then you use V4L2_PIX_FMT_* > > formats to describe them and any further processing block should be a > > mem2mem device. Wouldn't this work? > > These two hardware blocks are both located inside of ISP, and is connected > by a hardware data bus. > > Actually, there are three blocks inside ISP: One is close to sensor, and can > do color space conversion(RGB->YUV), we call it IPC; The other two are at > back end, which are basically DMA Engine, and they are identical. When data > flow out of IPC, it can go into each one of these DMA Engines and finally > into RAM. Whether the DMA Engine is turned on/off and the output format can > be controlled independently. Since they are DMA Engines, they have some > basic pixel reordering ability(i.e. interleave->planar/semi-planar). > > In our H/W design, when we want to get YUV semi-planar format, the IPC > output should be configured to interleave, and the DMA engine will do the > interleave->semi-planar job. If we want planar / interleave format, the IPC > will output planar format directly, DMA engine simply send the data to RAM, > and don't do any re-order. So in the planar output case, media-bus formats > can't express the format of the data between IPC and DMA Engine, that's the > problem we meet. If the format between the two subdevs is really planar, I don't see any problem defining a media bus pixel code for it. You will have to properly document the format of course. I'm a bit surprised that the IPC could output planar data. It would need to buffer a whole image to do so, do you need to give it a temporary system RAM buffer ? > We want to adopt a formal solution before we send our patch to the > community, that's where our headache comes. -- 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 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code
On 08/05/2013 06:26 AM, Marek Szyprowski wrote:
> MFC driver use custom bindings for managing reserved memory. Those bindings
> are not really specific to MFC device and no even well discussed. They can
> be easily replaced with generic, platform independent code for handling
> reserved and contiguous memory.
>
> Two additional child devices for each memory port (AXI master) are
> introduced to let one assign some properties to each of them. Later one
> can also use them to assign properties related to SYSMMU controllers,
> which can be used to manage the limited dma window provided by those
> memory ports.
> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
> b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> +The MFC device is connected to system bus with two memory ports (AXI
> +masters) for better performance. Those memory ports are modelled as
> +separate child devices, so one can assign some properties to them (like
> +memory region for dma buffer allocation or sysmmu controller).
> +
> Required properties:
>- compatible : value should be either one among the following
> (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
> (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
> + and additionally "simple-bus" to correctly initialize child
> + devices for memory ports (AXI masters)
simple-bus is wrong here; the child nodes aren't independent entities
that can be instantiated separately from their parent and without
depending on their parent.
> - - samsung,mfc-r : Base address of the first memory bank used by MFC
> - for DMA contiguous memory allocation and its size.
> -
> - - samsung,mfc-l : Base address of the second memory bank used by MFC
> - for DMA contiguous memory allocation and its size.
These properties shouldn't be removed, but simply marked deprecated. The
driver will need to continue to support them so that old DTs work with
new kernels. The binding must therefore continue to document them so
that the old DT content still makes sense.
> +Two child nodes must be defined for MFC device. Their names must be
> +following: "memport-r" and "memport-l" ("right" and "left"). Required
Node names shouldn't have semantic meaning.
> +properties:
> + - compatible : value should be "samsung,memport"
There's no need to define compatible properties for things which aren't
separate devices.
> + - dma-memory-region : optional property with a phandle to respective memory
> + region (see devicetree/bindings/memory.txt), if no
> region
> + is defined, sysmmu controller must be used for managing
> + limited dma window of each memory port.
What's the benefit of putting this property in a sub-node; surely you
can put the property in the main MFC node yet follow the same conceptual
schema for its content as a dma-memory-region node?
--
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 v9] V4L2: soc_camera: Renesas R-Car VIN driver
Hello.
On 07/26/2013 12:23 AM, Sergei Shtylyov wrote:
From: Vladimir Barinov
Add Renesas R-Car VIN (Video In) V4L2 driver.
Based on the patch by Phil Edworthy .
Signed-off-by: Vladimir Barinov
[Sergei: removed deprecated IRQF_DISABLED flag, reordered/renamed 'enum chip_id'
values, reordered rcar_vin_id_table[] entries, removed senseless parens from
to_buf_list() macro, used ALIGN() macro in rcar_vin_setup(), added {} to the
*if* statement and used 'bool' values instead of 0/1 where necessary, removed
unused macros, done some reformatting and clarified some comments.]
Signed-off-by: Sergei Shtylyov
Guennadi, Mauro, if you don't have issues with this version, perhaps we
still can merge it to 3.11 using "the new drivers can't cause regressions, so
mergeable any time" rule?
WBR, Sergei
--
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: Can I put a V4L2 soc camera driver under other subsystem directory?
Hi Bryan, On Wed, 7 Aug 2013, Bryan Wu wrote: > Hi Guennadi and LMML, > > I'm working on a camera controller driver for Tegra, which is using > soc_camera. But we also need to use Tegra specific host1x interface > like syncpt APIs. > > Since host1x is quite Tegra specific framework which is in > drivers/gpu/host1x and has several host1x's client driver like graphic > 2D driver, my v4l2 soc_camera driver is also a host1x client driver. > Right now host1x does not expose any global include header files like > API in the kernel, because no other users. So we plan to put all > host1x related driver together, is that OK for us to put our Tegra > soc_camera driver into drivers/gpu/host1x/camera or similar? > > I guess besides it will introduce some extra maintenance it should be OK, > right? Exactly, there's already been a precedent: http://www.mail-archive.com/linux-media@vger.kernel.org/msg56213.html It hasn't been finalised yet though. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v3 02/13] [media] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation
On 08/05/2013 04:37 PM, Sylwester Nawrocki wrote: > On 08/05/2013 06:53 PM, Stephen Warren wrote: >> On 08/03/2013 03:41 PM, Sylwester Nawrocki wrote: >>> On 08/02/2013 05:02 PM, Arun Kumar K wrote: The patch adds the DT binding documentation for Samsung Exynos5 SoC series imaging subsystem (FIMC-IS). >> diff --git a/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt new file mode 100644 index 000..49a373a --- /dev/null +++ b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt @@ -0,0 +1,52 @@ +Samsung EXYNOS5 SoC series Imaging Subsystem (FIMC-IS) +-- + +The camera subsystem on Samsung Exynos5 SoC has some changes relative +to previous SoC versions. Exynos5 has almost similar MIPI-CSIS and +FIMC-LITE IPs but has a much improved version of FIMC-IS which can +handle sensor controls and camera post-processing operations. The +Exynos5 FIMC-IS has a dedicated ARM Cortex A5 processor, many +post-processing blocks (ISP, DRC, FD, ODC, DIS, 3DNR) and two +dedicated scalers (SCC and SCP). >> >> So there are a lot of blocks mentioned there, yet the binding doesn't >> seem to describe most of it. Is the binding complete? > > Thanks for the review Stephen. > > No, the binding certainly isn't complete, it doesn't describe the all > available IP blocks. There are separate MMIO address regions for each ... > So while we could list all the devices, we decided not to do so. > Because it is not needed by the current software and we may miss some > details for case where the whole subsystem is controlled by the host > CPU (however such scenario is extremely unlikely AFAICT) which then > would be impossible or hard to change. Yes, that's probably a good approach. > I guess we should list all available devices, similarly as it's done > in Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt. > > And then should they just be disabled through the status property > if they are not needed in the Linux driver ? I guess it is more > sensible than marking them as optional and then not listing them > in dts at all ? If you can define complete bindings for those nodes, it might make sense to do that. If the devices are perhaps complex to represent and hence you might not be able to come up with complete bindings for them right now, it may indeed be better to simply not mention the devices you don't care about for now. +pmu subnode +--- + +Required properties: + - reg : should contain PMU physical base address and size of the memory + mapped registers. >> >> I think you need a compatible value for this. How else is the node >> identified? The node name probably should not be used for identification. > > Of course the node name is currently used for identification. There is no > compatible property because this pmu node is used to get hold of only part > of the Power Management Unit registers, specific to the FIMC-IS. > The PMU has more registers that also other drivers would be interested in, > e.g. clocks or USB. I believe the correct way to solve this is for there to be a standalone PMU node at the appropriate location in DT, and for the FIMC bindings to reference that other node by phandle. Right now, the FIMC driver SW can manually follow the phandle, look at the reg property, and map that itself. Later down the road, you could instantiate a true PMU driver, and have the FIMC driver look up that driver, and call APIs on it. This change can be made without requiring any changes to the DT binding. That way, you aren't introducing a fake PMU node into the FIMC bindings just to satisfy internal Linux driver details. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Aug 8 19:00:17 CEST 2013 git branch: test git hash: dfb9f94e8e5e7f73c8e2bcb7d4fb1de57e7c333d gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 1/3] cx23885-dvb: use a better approach to hook set_frontend
When the frontend drivers got converted to DVBv5 API, the original
hook that tracked when a frontend is set got removed, being replaced
by an approach that would use the gate control. That doesn't work
fine with some boards. Also, the code were called more times than
desired.
Replace it by a logic that will hook the dvb set_frontend ops,
with works with both DVBv3 and DVBv5 calls.
Tested on a Mygica X8502 OEM board.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/pci/cx23885/cx23885-dvb.c | 25 +
drivers/media/pci/cx23885/cx23885.h | 2 ++
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index bb291c6..c0613fb 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -119,8 +119,6 @@ static void dvb_buf_release(struct videobuf_queue *q,
cx23885_free_buffer(q, (struct cx23885_buffer *)vb);
}
-static int cx23885_dvb_set_frontend(struct dvb_frontend *fe);
-
static void cx23885_dvb_gate_ctrl(struct cx23885_tsport *port, int open)
{
struct videobuf_dvb_frontends *f;
@@ -135,12 +133,6 @@ static void cx23885_dvb_gate_ctrl(struct cx23885_tsport
*port, int open)
if (fe && fe->dvb.frontend && fe->dvb.frontend->ops.i2c_gate_ctrl)
fe->dvb.frontend->ops.i2c_gate_ctrl(fe->dvb.frontend, open);
-
- /*
-* FIXME: Improve this path to avoid calling the
-* cx23885_dvb_set_frontend() every time it passes here.
-*/
- cx23885_dvb_set_frontend(fe->dvb.frontend);
}
static struct videobuf_queue_ops dvb_qops = {
@@ -561,9 +553,21 @@ static int cx23885_dvb_set_frontend(struct dvb_frontend
*fe)
cx23885_gpio_set(dev, GPIO_0);
break;
}
+
+ /* Call the real set_frontend */
+ if (port->set_frontend)
+ return port->set_frontend(fe);
+
return 0;
}
+static void cx23885_set_frontend_hook(struct cx23885_tsport *port,
+struct dvb_frontend *fe)
+{
+ port->set_frontend = fe->ops.set_frontend;
+ fe->ops.set_frontend = cx23885_dvb_set_frontend;
+}
+
static struct lgs8gxx_config magicpro_prohdtve2_lgs8g75_config = {
.prod = LGS8GXX_PROD_LGS8G75,
.demod_address = 0x19,
@@ -771,6 +775,8 @@ static int dvb_register(struct cx23885_tsport *port)
0x60, &dev->i2c_bus[1].i2c_adap,
&hauppauge_hvr127x_config);
}
+ if (dev->board == CX23885_BOARD_HAUPPAUGE_HVR1275)
+ cx23885_set_frontend_hook(port, fe0->dvb.frontend);
break;
case CX23885_BOARD_HAUPPAUGE_HVR1255:
case CX23885_BOARD_HAUPPAUGE_HVR1255_22111:
@@ -1106,6 +1112,8 @@ static int dvb_register(struct cx23885_tsport *port)
&i2c_bus2->i2c_adap,
&mygica_x8506_xc5000_config);
}
+ cx23885_set_frontend_hook(port, fe0->dvb.frontend);
+ break;
break;
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
i2c_bus = &dev->i2c_bus[0];
@@ -1119,6 +1127,7 @@ static int dvb_register(struct cx23885_tsport *port)
&i2c_bus2->i2c_adap,
&magicpro_prohdtve2_xc5000_config);
}
+ cx23885_set_frontend_hook(port, fe0->dvb.frontend);
break;
case CX23885_BOARD_HAUPPAUGE_HVR1850:
i2c_bus = &dev->i2c_bus[0];
diff --git a/drivers/media/pci/cx23885/cx23885.h
b/drivers/media/pci/cx23885/cx23885.h
index 5687d3f..038caf5 100644
--- a/drivers/media/pci/cx23885/cx23885.h
+++ b/drivers/media/pci/cx23885/cx23885.h
@@ -320,6 +320,8 @@ struct cx23885_tsport {
/* Workaround for a temp dvb_frontend that the tuner can attached to */
struct dvb_frontend analog_fe;
+
+ int (*set_frontend)(struct dvb_frontend *fe);
};
struct cx23885_kernel_ir {
--
1.8.3.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 0/3] Experimental patches for ISDB-T on Mygica X8502/X8507
This is a first set of experimental patches for Mygica X8502/X8507. The last patch is just a very dirty hack, for testing purposes. I intend to get rid of it, but it is there to replace exactly the same changes that Alfredo reported to work on Kernel 3.2. I intend to remove it on a final series, eventually replacing by some other changes at mb86a20s. Alfredo, Please test, and send your tested-by, if this works for you. Thanks! Mauro Mauro Carvalho Chehab (3): cx23885-dvb: use a better approach to hook set_frontend cx23885: Add DTV support for Mygica X8502/X8507 boards mb86a20s: hack it to emulate what x8502 driver does drivers/media/dvb-frontends/mb86a20s.c| 100 ++ drivers/media/pci/cx23885/Kconfig | 1 + drivers/media/pci/cx23885/cx23885-cards.c | 4 +- drivers/media/pci/cx23885/cx23885-dvb.c | 49 --- drivers/media/pci/cx23885/cx23885.h | 2 + 5 files changed, 147 insertions(+), 9 deletions(-) -- 1.8.3.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 2/3] cx23885: Add DTV support for Mygica X8502/X8507 boards
Those boards were missing the ISDB-T support.
Most of the work on this patch were done by Alfredo.
My work here were to port this patch from Kernel 3.2 to upstream,
fix the issue caused by the set_frontend bad hook, and add the
Kconfig bits.
Tested on a X8502 board rebranded as:
"Leadership - Placa PCI-e de Captura de Vídeo Híbrida" - product code 3800.
Thanks-to: Alfredo Jesús Delaiti
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/pci/cx23885/Kconfig | 1 +
drivers/media/pci/cx23885/cx23885-cards.c | 4 +++-
drivers/media/pci/cx23885/cx23885-dvb.c | 24
3 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx23885/Kconfig
b/drivers/media/pci/cx23885/Kconfig
index b3688aa..5104c80 100644
--- a/drivers/media/pci/cx23885/Kconfig
+++ b/drivers/media/pci/cx23885/Kconfig
@@ -29,6 +29,7 @@ config VIDEO_CX23885
select DVB_STV0367 if MEDIA_SUBDRV_AUTOSELECT
select DVB_TDA10071 if MEDIA_SUBDRV_AUTOSELECT
select DVB_A8293 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_MB86A20S if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MT2063 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MT2131 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC2028 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 7e923f8..6f49f99 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -528,11 +528,12 @@ struct cx23885_board cx23885_boards[] = {
} },
},
[CX23885_BOARD_MYGICA_X8507] = {
- .name = "Mygica X8507",
+ .name = "Mygica X8502/X8507 ISDB-T",
.tuner_type = TUNER_XC5000,
.tuner_addr = 0x61,
.tuner_bus = 1,
.porta = CX23885_ANALOG_VIDEO,
+ .portb = CX23885_MPEG_DVB,
.input = {
{
.type = CX23885_VMUX_TELEVISION,
@@ -1677,6 +1678,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
break;
case CX23885_BOARD_MYGICA_X8506:
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+ case CX23885_BOARD_MYGICA_X8507:
ts1->gen_ctrl_val = 0x5; /* Parallel */
ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index c0613fb..971e4ff 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -69,6 +69,7 @@
#include "stb6100_cfg.h"
#include "tda10071.h"
#include "a8293.h"
+#include "mb86a20s.h"
static unsigned int debug;
@@ -492,6 +493,15 @@ static struct xc5000_config mygica_x8506_xc5000_config = {
.if_khz = 5380,
};
+static struct mb86a20s_config mygica_x8507_mb86a20s_config = {
+ .demod_address = 0x10,
+};
+
+static struct xc5000_config mygica_x8507_xc5000_config = {
+ .i2c_address = 0x61,
+ .if_khz = 4000,
+};
+
static struct stv090x_config prof_8000_stv090x_config = {
.device = STV0903,
.demod_mode = STV090x_SINGLE,
@@ -548,6 +558,7 @@ static int cx23885_dvb_set_frontend(struct dvb_frontend *fe)
}
break;
case CX23885_BOARD_MYGICA_X8506:
+ case CX23885_BOARD_MYGICA_X8507:
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
/* Select Digital TV */
cx23885_gpio_set(dev, GPIO_0);
@@ -1114,6 +1125,19 @@ static int dvb_register(struct cx23885_tsport *port)
}
cx23885_set_frontend_hook(port, fe0->dvb.frontend);
break;
+ case CX23885_BOARD_MYGICA_X8507:
+ i2c_bus = &dev->i2c_bus[0];
+ i2c_bus2 = &dev->i2c_bus[1];
+ fe0->dvb.frontend = dvb_attach(mb86a20s_attach,
+ &mygica_x8507_mb86a20s_config,
+ &i2c_bus->i2c_adap);
+ if (fe0->dvb.frontend != NULL) {
+ dvb_attach(xc5000_attach,
+ fe0->dvb.frontend,
+ &i2c_bus2->i2c_adap,
+ &mygica_x8507_xc5000_config);
+ }
+ cx23885_set_frontend_hook(port, fe0->dvb.frontend);
break;
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
i2c_bus = &dev->i2c_bus[0];
--
1.8.3.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] mb86a20s: hack it to emulate what x8502 driver does
This is just a dirty hack that replaces the init sequence to the one
found on Mygica X8502, as reported by Alfredo.
This patch should never be merged as-is upstream, as it likely breaks
support for other devices.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 100 +
1 file changed, 100 insertions(+)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.c
index 856374b..3cf547b 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -204,6 +204,106 @@ static struct regdata mb86a20s_init2[] = {
{ 0xec, 0x0f },
{ 0xeb, 0x1f },
{ 0x28, 0x6a }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x00 },
+
+ /* HACK: Init sequence as found on X8502 driver */
+
+ { 0x09, 0x3a },
+ { 0x50, 0xd1 }, { 0x51, 0x22 },
+ { 0x39, 0x00 },
+ { 0x28, 0x2a }, { 0x29, 0x00 }, { 0x2a, 0xfd }, { 0x2b, 0xc8 },
+ { 0x3c, 0x38 },
+ { 0x28, 0x20 }, { 0x29, 0x3e }, { 0x2a, 0xde }, { 0x2b, 0x4d },
+ { 0x28, 0x22 }, { 0x29, 0x00 }, { 0x2a, 0x1f }, { 0x2b, 0xf0 },
+ { 0x04, 0x08 }, { 0x05, 0x03 },
+ { 0x04, 0x0e }, { 0x05, 0x00 },
+ { 0x04, 0x0f }, { 0x05, 0x32 },
+ { 0x04, 0x0b }, { 0x05, 0x78 },
+ { 0x04, 0x00 }, { 0x05, 0x00 },
+ { 0x04, 0x01 }, { 0x05, 0x1e },
+ { 0x04, 0x02 }, { 0x05, 0x07 },
+ { 0x04, 0x03 }, { 0x05, 0xd0 },
+ { 0x04, 0x09 }, { 0x05, 0x00 },
+ { 0x04, 0x0a }, { 0x05, 0xff },
+ { 0x04, 0x27 }, { 0x05, 0x00 },
+ { 0x04, 0x28 }, { 0x05, 0x00 },
+ { 0x04, 0x1e }, { 0x05, 0x00 },
+ { 0x04, 0x29 }, { 0x05, 0x64 },
+ { 0x04, 0x32 }, { 0x05, 0x64 },
+ { 0x04, 0x14 }, { 0x05, 0x02 },
+ { 0x04, 0x04 }, { 0x05, 0x00 },
+ { 0x04, 0x05 }, { 0x05, 0x22 },
+ { 0x04, 0x06 }, { 0x05, 0x0e },
+ { 0x04, 0x07 }, { 0x05, 0xd8 },
+ { 0x04, 0x12 }, { 0x05, 0x00 },
+ { 0x04, 0x13 }, { 0x05, 0xff },
+ { 0x50, 0xa7 }, { 0x51, 0x00 },
+ { 0x50, 0xa8 }, { 0x51, 0xff },
+ { 0x50, 0xa9 }, { 0x51, 0xff },
+ { 0x50, 0xaa }, { 0x51, 0x00 },
+ { 0x50, 0xab }, { 0x51, 0xff },
+ { 0x50, 0xac }, { 0x51, 0xff },
+ { 0x50, 0xad }, { 0x51, 0x00 },
+ { 0x50, 0xae }, { 0x51, 0xff },
+ { 0x50, 0xaf }, { 0x51, 0xff },
+ { 0x50, 0xdc }, { 0x51, 0x3f },
+ { 0x50, 0xdd }, { 0x51, 0xff },
+ { 0x50, 0xde }, { 0x51, 0x3f },
+ { 0x50, 0xdf }, { 0x51, 0xff },
+ { 0x50, 0xe0 }, { 0x51, 0x3f },
+ { 0x50, 0xe1 }, { 0x51, 0xff },
+ { 0x50, 0xb0 }, { 0x51, 0x07 },
+ { 0x50, 0xb2 }, { 0x51, 0x3f },
+ { 0x50, 0xb3 }, { 0x51, 0xff },
+ { 0x50, 0xb4 }, { 0x51, 0x3f },
+ { 0x50, 0xb5 }, { 0x51, 0xff },
+ { 0x50, 0xb6 }, { 0x51, 0x3f },
+ { 0x50, 0xb7 }, { 0x51, 0xff },
+ { 0x50, 0x51 }, { 0x51, 0x04 },
+ { 0x50, 0x50 }, { 0x51, 0x02 },
+ { 0x50, 0xd5 }, { 0x51, 0x00 },
+ { 0x50, 0xd6 }, { 0x51, 0x1f },
+ { 0x50, 0xd2 }, { 0x51, 0x03 },
+ { 0x50, 0xd7 }, { 0x51, 0x3f },
+ { 0x28, 0x74 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0xff },
+ { 0x28, 0x46 }, { 0x29, 0x00 }, { 0x2a, 0x1a }, { 0x2b, 0x0c },
+ { 0x04, 0x40 },
+ { 0x05, 0x00 },
+ { 0x28, 0x00 }, { 0x2b, 0x08 },
+ { 0x28, 0x05 }, { 0x2b, 0x00 },
+ { 0x28, 0x06 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x1f },
+ { 0x28, 0x07 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x18 },
+ { 0x28, 0x08 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x18 },
+ { 0x28, 0x09 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x30 },
+ { 0x28, 0x0a }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x37 },
+ { 0x28, 0x0b }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x02 },
+ { 0x28, 0x0c }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x09 },
+ { 0x28, 0x0d }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x06 },
+ { 0x28, 0x0e }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x7b },
+ { 0x28, 0x0f }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x76 },
+ { 0x28, 0x10 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x7d },
+ { 0x28, 0x11 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x08 },
+ { 0x28, 0x12 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0b },
+ { 0x28, 0x13 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x00 },
+ { 0x28, 0x14 }, { 0x29, 0x00 }, { 0x2a, 0x01 }, { 0x2b, 0xf2 },
+ { 0x28, 0x15 }, { 0x29, 0x00 }, { 0x2a, 0x01 }, { 0x2b, 0xf3 },
+ { 0x28, 0x16 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x05 },
+ { 0x28, 0x17 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x16 },
+ { 0x28, 0x18 }, { 0x29, 0x00 }, { 0x2a, 0x00 }, { 0x2b, 0x0f },
+ { 0x28, 0x19 }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xef },
+ { 0x28, 0x1a }, { 0x29, 0x00 }, { 0x2a, 0x07 }, { 0x2b, 0xd8 },
+ { 0x28, 0x1b }, { 0x29, 0x00 }, { 0x2a, 0x07
Re: [PATCH] mt9v032: Use the common clock framework
Hi Sylwester, On Wednesday 07 August 2013 17:03:18 Sylwester Nawrocki wrote: > On 07/26/2013 05:55 PM, Laurent Pinchart wrote: > > On Friday 26 July 2013 15:36:22 Sylwester Nawrocki wrote: > >> On 07/26/2013 03:15 PM, Laurent Pinchart wrote: > >>> On Friday 26 July 2013 15:11:08 Sylwester Nawrocki wrote: > On 07/05/2013 12:55 PM, Laurent Pinchart wrote: > > Configure the device external clock using the common clock framework > > instead of a board code callback function. > > > > Signed-off-by: Laurent Pinchart > > --- > >drivers/media/i2c/mt9v032.c | 16 ++-- > >include/media/mt9v032.h | 4 > >2 files changed, 10 insertions(+), 10 deletions(-) [snip] > >> Do you rely on the fact that __clk_get()/__clk_put() doesn't get > >> reference on the clock supplier module (to avoid locking modules in > >> memory) ? I was planning on adding module_get()/module_put() inside > >> __clk_get()/__clk_out() for the common clock API implementation. > > > > I'm currently relying on that, but I'm aware it's not a good idea. We need > > to find a solution to fix the problem in the context of the v4l2-async > > framework. > > There are few possible options I can see could be a resolution for that: > > 1. making the common clock API not getting reference on the clock supplier >module; then dynamic clock deregistration needs to be handled, which has >its own share of problems; > > 2. using sysfs unbind attribute of the subdev and/or the host drivers to >release the circular references or create some additional sysfs entry >for this - however requiring additional actions from user space to do >something that worked before without them can be simply considered as >an regression; Well, we've never had working DT support for those systems, so that's hardly a regression :-) > 3. not keeping reference to a clock all times only when it is actively >used, e.g. in subdev's s_power handler; this is in practice what >v4l2-clk does, just would be coded using standard clk API calls; > > Any of these options isn't ideal but 3) seems to me most reasonable of them. For now it might be, but I'm not sure whether it would scale. We will likely have similar issues with other kind of resources in the future. I would be enclined to investigate the second option. > I thought it would be better than using the v4l2-clk API, which is supposed > to be a temporary measure only, for platforms that already have the common > clock API support. > > I was wondering whether you don't need to also set the clock's frequency in > this patch. I guess the sensor driver should at least call clk_get_rate() to > see if current frequency is suitable for the device ? Yes indeed. I'm not sure how I've missed that. I'll fix it. -- 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] V4L: async: Make sure subdevs are stored in a list before being moved
Hi Laurent,
On 08/07/2013 12:41 PM, Laurent Pinchart wrote:
> Subdevices have an async_list field used to store them in the global
> list of subdevices or in the notifier done lists. List entries are moved
> from the former to the latter in v4l2_async_test_notify() using
> list_move(). However, v4l2_async_test_notify() can be called right away
> when the subdev is registered with v4l2_async_register_subdev(), in
> which case the entry is not stored in any list.
>
> Although this behaviour is not correct, the code doesn't crash at the
> moment as the async_list field is initialized as a list head, despite
> being a list entry.
>
> Add the subdev to the global subdevs list a registration time before
> matching them with the notifiers to make sure the list_move() call will
> get a subdev that is stored in a list, and remove the list head
> initialization for the subdev async_list field.
>
> Signed-off-by: Laurent Pinchart
Shouldn't we initialize the async_list field in v4l2_subdev_init() ?
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c
index 996c248..31b2375 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -460,6 +460,7 @@ EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate);
void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops
*ops)
{
INIT_LIST_HEAD(&sd->list);
+ INIT_LIST_HEAD(&sd->async_list);
BUG_ON(!ops);
sd->ops = ops;
sd->v4l2_dev = NULL;
> ---
> drivers/media/v4l2-core/v4l2-async.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-async.c
> b/drivers/media/v4l2-core/v4l2-async.c
> index b350ab9..4485dfe 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -122,7 +122,7 @@ static void v4l2_async_cleanup(struct v4l2_subdev *sd)
> {
> v4l2_device_unregister_subdev(sd);
> /* Subdevice driver will reprobe and put the subdev back onto the list
> */
> - list_del_init(&sd->async_list);
> + list_del(&sd->async_list);
It is not safe to do so, since v4l2_async_cleanup() can be called multiple
times and list_del() leaves async_list in an undefined state. I'm actually
observing a crash with this change.
> sd->asd = NULL;
> sd->dev = NULL;
> }
> @@ -238,7 +238,11 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
>
> mutex_lock(&list_lock);
>
> - INIT_LIST_HEAD(&sd->async_list);
> + /*
> + * Add the subdev to the global subdevs list. It will be moved to the
> + * notifier done list by v4l2_async_test_notify().
> + */
> + list_add(&sd->async_list, &subdev_list);
>
> list_for_each_entry(notifier, ¬ifier_list, list) {
> struct v4l2_async_subdev *asd = v4l2_async_belongs(notifier,
> sd);
> @@ -249,9 +253,6 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
> }
> }
>
> - /* None matched, wait for hot-plugging */
> - list_add(&sd->async_list, &subdev_list);
> -
> mutex_unlock(&list_lock);
>
> return 0;
>
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] v4l: async: Make it safe to unregister unregistered notifier
On 08/08/2013 05:04 PM, Laurent Pinchart wrote: > Calling v4l2_async_notifier_unregister() on a notifier that hasn't been > registered leads to a crash. To simplify drivers, make it safe to > unregister a notifier that has not been registered. > > Signed-off-by: Laurent Pinchart Tested-by: Sylwester Nawrocki Acked-by: Sylwester Nawrocki > --- > drivers/media/v4l2-core/v4l2-async.c | 6 ++ > 1 file changed, 6 insertions(+) > > Compared to v1, I've modified the NULL check to match the coding style used in > the rest of the file (!... instead of ... != NULL). > > diff --git a/drivers/media/v4l2-core/v4l2-async.c > b/drivers/media/v4l2-core/v4l2-async.c > index b350ab9..10bb62c 100644 > --- a/drivers/media/v4l2-core/v4l2-async.c > +++ b/drivers/media/v4l2-core/v4l2-async.c > @@ -192,6 +192,9 @@ void v4l2_async_notifier_unregister(struct > v4l2_async_notifier *notifier) > struct device *dev[n_subdev]; > int i = 0; > > + if (!notifier->v4l2_dev) > + return; > + > mutex_lock(&list_lock); > > list_del(¬ifier->list); > @@ -225,6 +228,9 @@ void v4l2_async_notifier_unregister(struct > v4l2_async_notifier *notifier) > } > put_device(d); > } > + > + notifier->v4l2_dev = NULL; > + > /* >* Don't care about the waiting list, it is initialised and populated >* upon notifier registration. > Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2-ctrl: fix setting volatile controls
Hi Hans,
Thank you for the patch.
On Thursday 08 August 2013 12:58:52 Hans Verkuil wrote:
> The V4L2 specification allows setting volatile controls as that is needed
> if you want to be able to set all controls in one go using
> VIDIOC_S_EXT_CTRLS.
>
> However, such new values should be ignored by the control framework
> since it makes no sense to set a volatile control. While the new value
> will be ignored anyway, it does generate a bogus 'change value' control
> event that should be suppressed.
>
> This patch changes the code to skip setting volatile controls, except for
> one particular case where an autocluster switches to manual mode, because
> that causes the volatile controls to become non-volatile, so the new
> specified values should be retained.
>
> Note that the values returned by VIDIOC_S_CTRL and VIDIOC_S_EXT_CTRLS for
> such skipped volatile controls will be the currently cached values and not
> the latest volatile value. This is something that might have to be fixed
> as well in the future should that be necessary. I think it is overkill,
> though.
This restriction is not documented in Documentation/video4linux/v4l2-
controls.txt. Do we really want to assume that all volatile controls are read-
only and/or inactive ?
> Signed-off-by: Hans Verkuil
> Cc: pa...@osciak.com
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c index fccd08b..a7cd830 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -2592,6 +2592,7 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh,
> struct v4l2_ctrl_handler *hdl, cs->error_idx = cs->count;
> for (i = 0; !ret && i < cs->count; i++) {
> struct v4l2_ctrl *master;
> + bool set_volatiles = false;
> u32 idx = i;
>
> if (helpers[i].mref == NULL)
> @@ -2627,14 +2628,24 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh,
> struct v4l2_ctrl_handler *hdl, } while (tmp_idx);
> /* If the new value == the manual value, then copy
> the current volatile values. */
> - if (new_auto_val == master->manual_mode_value)
> + if (new_auto_val == master->manual_mode_value) {
> update_from_auto_cluster(master);
> + set_volatiles = true;
> + }
> }
>
> /* Copy the new caller-supplied control values.
> user_to_new() sets 'is_new' to 1. */
> do {
> - ret = user_to_new(cs->controls + idx,
> helpers[idx].ctrl);
> + /*
> + * Skip attempts to set volatile controls since those
> are
> + * ignored anyway. The exception is when an autocluster
> is
> + * switched to manual mode, since in that case the
> specified
> + * 'volatile' controls are actually the new manual
> + * non-volatile values.
> + */
> + if (set_volatiles || !(helpers[idx].ctrl->flags &
> V4L2_CTRL_FLAG_VOLATILE)) + ret =
> user_to_new(cs->controls +
idx,
> helpers[idx].ctrl);
> idx = helpers[idx].next;
> } while (!ret && idx);
>
> @@ -2697,6 +2708,9 @@ static int set_ctrl(struct v4l2_fh *fh, struct
> v4l2_ctrl *ctrl, if (ctrl->type == V4L2_CTRL_TYPE_STRING)
> return -EINVAL;
>
> + if (ctrl->flags & V4L2_CTRL_FLAG_VOLATILE)
> + return 0;
> +
> /* Reset the 'is_new' flags of the cluster */
> for (i = 0; i < master->ncontrols; i++)
> if (master->cluster[i])
--
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/6] V4L2: mx3_camera: convert to managed resource allocation
Hi Guennadi ,
On 8 August 2013 20:22, Guennadi Liakhovetski wrote:
> Use devm_* resource allocators to simplify the driver's probe and clean up
> paths.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
> drivers/media/platform/soc_camera/mx3_camera.c | 47
> +---
> 1 files changed, 10 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/mx3_camera.c
> b/drivers/media/platform/soc_camera/mx3_camera.c
> index 1047e3e..e526096 100644
> --- a/drivers/media/platform/soc_camera/mx3_camera.c
> +++ b/drivers/media/platform/soc_camera/mx3_camera.c
> @@ -1151,23 +1151,19 @@ static int mx3_camera_probe(struct platform_device
> *pdev)
> struct soc_camera_host *soc_host;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - err = -ENODEV;
> - goto egetres;
> - }
> + base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
>
> - mx3_cam = vzalloc(sizeof(*mx3_cam));
> + mx3_cam = devm_kzalloc(&pdev->dev, sizeof(*mx3_cam), GFP_KERNEL);
> if (!mx3_cam) {
> dev_err(&pdev->dev, "Could not allocate mx3 camera object\n");
This print is also redundant as kzalloc prints error on failure.
--
With warm regards,
Sachin
--
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] v4l: Fix colorspace conversion error in sample code
The sample code erroneously scales the y1, pb and pr variables from the [0.0 .. 1.0] and [-0.5 .. 0.5] ranges to [0 .. 255] and [-128 .. 127]. Fix it. Signed-off-by: Laurent Pinchart --- Documentation/DocBook/media/v4l/pixfmt.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 99b8d2a..4babd4d 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -391,9 +391,9 @@ clamp (double x) else return r; } -y1 = (255 / 219.0) * (Y1 - 16); -pb = (255 / 224.0) * (Cb - 128); -pr = (255 / 224.0) * (Cr - 128); +y1 = (Y1 - 16) / 219.0; +pb = (Cb - 128) / 224.0; +pr = (Cr - 128) / 224.0; r = 1.0 * y1 + 0 * pb + 1.402 * pr; g = 1.0 * y1 - 0.344 * pb - 0.714 * pr; -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] V4L2: soc-camera: fix requesting regulators in synchronous case
With synchronous subdevice probing regulators should be requested by the
soc-camera core in soc_camera_pdrv_probe(). Subdevice drivers, supporting
asynchronous probing, call soc_camera_power_init() to request regulators.
Erroneously, the same regulator array is used in the latter case as in
the former, which leads to a failure. This patch fixes it by preventing
the second regulator request from being executed.
Signed-off-by: Guennadi Liakhovetski
---
Since currently only one sensor driver, used with soc-camera supports
asynchronous probing and no platforms in the mainline are using it,
this fix is only theoretical, no platform in the mainline can trigger it.
But I did observe it when working with mx3_camera + mt9m111. Just to say,
that there's no need in stable for this.
drivers/media/platform/soc_camera/soc_camera.c | 33 +++
1 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index 2dd0e52..9a96cf1 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -136,7 +136,7 @@ EXPORT_SYMBOL(soc_camera_power_off);
int soc_camera_power_init(struct device *dev, struct soc_camera_subdev_desc
*ssdd)
{
-
+ /* Should not have any effect in synchronous case */
return devm_regulator_bulk_get(dev, ssdd->num_regulators,
ssdd->regulators);
}
@@ -1311,6 +1311,7 @@ eusrfmt:
static int soc_camera_i2c_init(struct soc_camera_device *icd,
struct soc_camera_desc *sdesc)
{
+ struct soc_camera_subdev_desc *ssdd;
struct i2c_client *client;
struct soc_camera_host *ici;
struct soc_camera_host_desc *shd = &sdesc->host_desc;
@@ -1333,7 +1334,21 @@ static int soc_camera_i2c_init(struct soc_camera_device
*icd,
return -ENODEV;
}
- shd->board_info->platform_data = &sdesc->subdev_desc;
+ ssdd = kzalloc(sizeof(*ssdd), GFP_KERNEL);
+ if (!ssdd) {
+ ret = -ENOMEM;
+ goto ealloc;
+ }
+
+ memcpy(ssdd, &sdesc->subdev_desc, sizeof(*ssdd));
+ /*
+* In synchronous case we request regulators ourselves in
+* soc_camera_pdrv_probe(), make sure the subdevice driver doesn't try
+* to allocate them again.
+*/
+ ssdd->num_regulators = 0;
+ ssdd->regulators = NULL;
+ shd->board_info->platform_data = ssdd;
snprintf(clk_name, sizeof(clk_name), "%d-%04x",
shd->i2c_adapter_id, shd->board_info->addr);
@@ -1359,8 +1374,10 @@ static int soc_camera_i2c_init(struct soc_camera_device
*icd,
return 0;
ei2cnd:
v4l2_clk_unregister(icd->clk);
-eclkreg:
icd->clk = NULL;
+eclkreg:
+ kfree(ssdd);
+ealloc:
i2c_put_adapter(adap);
return ret;
}
@@ -1370,15 +1387,18 @@ static void soc_camera_i2c_free(struct
soc_camera_device *icd)
struct i2c_client *client =
to_i2c_client(to_soc_camera_control(icd));
struct i2c_adapter *adap;
+ struct soc_camera_subdev_desc *ssdd;
icd->control = NULL;
if (icd->sasc)
return;
adap = client->adapter;
+ ssdd = client->dev.platform_data;
v4l2_device_unregister_subdev(i2c_get_clientdata(client));
i2c_unregister_device(client);
i2c_put_adapter(adap);
+ kfree(ssdd);
v4l2_clk_unregister(icd->clk);
icd->clk = NULL;
}
@@ -1994,9 +2014,10 @@ static int soc_camera_pdrv_probe(struct platform_device
*pdev)
/*
* In the asynchronous case ssdd->num_regulators == 0 yet, so, the below
-* regulator allocation is a dummy. They will be really requested later
-* in soc_camera_async_bind(). Also note, that in that case regulators
-* are attached to the I2C device and not to the camera platform device.
+* regulator allocation is a dummy. They are actually requested by the
+* subdevice driver, using soc_camera_power_init(). Also note, that in
+* that case regulators are attached to the I2C device and not to the
+* camera platform device.
*/
ret = devm_regulator_bulk_get(&pdev->dev, ssdd->num_regulators,
ssdd->regulators);
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] V4L2: soc-camera: more asynchronous conversions
This patch set converts the mx3-camera host and the mt9m111 sensor drivers to asynchronous probing. Also an Oops in the mt9t031 driver is fixed for the case, where an asynchronous probing is attempted. Guennadi Liakhovetski (6): V4L2: soc-camera: fix requesting regulators in synchronous case V4L2: mx3_camera: convert to managed resource allocation V4L2: mx3_camera: print V4L2_MBUS_FMT_* codes in hexadecimal format V4L2: mx3_camera: add support for asynchronous subdevice registration V4L2: mt9t031: don't Oops if asynchronous probing is attempted V4L2: mt9m111: switch to asynchronous subdevice probing drivers/media/i2c/soc_camera/mt9m111.c | 38 + drivers/media/i2c/soc_camera/mt9t031.c |7 ++- drivers/media/platform/soc_camera/mx3_camera.c | 67 +--- drivers/media/platform/soc_camera/soc_camera.c | 33 ++-- include/linux/platform_data/camera-mx3.h |4 ++ 5 files changed, 87 insertions(+), 62 deletions(-) -- 1.7.2.5 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] V4L2: mt9t031: don't Oops if asynchronous probing is attempted
The mt9t031 driver hasn't yet been updated to support asynchronous
subdevice probing. If such a probing is attempted, the driver is allowed
to fail, but it shouldn't Oops. This patch fixes such a potential NULL
pointer dereference.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/i2c/soc_camera/mt9t031.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/mt9t031.c
b/drivers/media/i2c/soc_camera/mt9t031.c
index 47d18d0..ee7bb0f 100644
--- a/drivers/media/i2c/soc_camera/mt9t031.c
+++ b/drivers/media/i2c/soc_camera/mt9t031.c
@@ -594,9 +594,12 @@ static int mt9t031_s_power(struct v4l2_subdev *sd, int on)
ret = soc_camera_power_on(&client->dev, ssdd, mt9t031->clk);
if (ret < 0)
return ret;
- vdev->dev.type = &mt9t031_dev_type;
+ if (vdev)
+ /* Not needed during probing, when vdev isn't available
yet */
+ vdev->dev.type = &mt9t031_dev_type;
} else {
- vdev->dev.type = NULL;
+ if (vdev)
+ vdev->dev.type = NULL;
soc_camera_power_off(&client->dev, ssdd, mt9t031->clk);
}
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] V4L2: mx3_camera: print V4L2_MBUS_FMT_* codes in hexadecimal format
V4L2_MBUS_FMT_* codes are defined in v4l2-mediabus.h as hexadecimal
constants. Print them in the same form for easier recognition.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/platform/soc_camera/mx3_camera.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx3_camera.c
b/drivers/media/platform/soc_camera/mx3_camera.c
index e526096..83592e4 100644
--- a/drivers/media/platform/soc_camera/mx3_camera.c
+++ b/drivers/media/platform/soc_camera/mx3_camera.c
@@ -672,7 +672,7 @@ static int mx3_camera_get_formats(struct soc_camera_device
*icd, unsigned int id
fmt = soc_mbus_get_fmtdesc(code);
if (!fmt) {
dev_warn(icd->parent,
-"Unsupported format code #%u: %d\n", idx, code);
+"Unsupported format code #%u: 0x%x\n", idx, code);
return 0;
}
@@ -688,7 +688,7 @@ static int mx3_camera_get_formats(struct soc_camera_device
*icd, unsigned int id
xlate->host_fmt = &mx3_camera_formats[0];
xlate->code = code;
xlate++;
- dev_dbg(dev, "Providing format %s using code %d\n",
+ dev_dbg(dev, "Providing format %s using code 0x%x\n",
mx3_camera_formats[0].name, code);
}
break;
@@ -698,7 +698,7 @@ static int mx3_camera_get_formats(struct soc_camera_device
*icd, unsigned int id
xlate->host_fmt = &mx3_camera_formats[1];
xlate->code = code;
xlate++;
- dev_dbg(dev, "Providing format %s using code %d\n",
+ dev_dbg(dev, "Providing format %s using code 0x%x\n",
mx3_camera_formats[1].name, code);
}
break;
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] V4L2: mx3_camera: convert to managed resource allocation
Use devm_* resource allocators to simplify the driver's probe and clean up
paths.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/platform/soc_camera/mx3_camera.c | 47 +---
1 files changed, 10 insertions(+), 37 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx3_camera.c
b/drivers/media/platform/soc_camera/mx3_camera.c
index 1047e3e..e526096 100644
--- a/drivers/media/platform/soc_camera/mx3_camera.c
+++ b/drivers/media/platform/soc_camera/mx3_camera.c
@@ -1151,23 +1151,19 @@ static int mx3_camera_probe(struct platform_device
*pdev)
struct soc_camera_host *soc_host;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- err = -ENODEV;
- goto egetres;
- }
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
- mx3_cam = vzalloc(sizeof(*mx3_cam));
+ mx3_cam = devm_kzalloc(&pdev->dev, sizeof(*mx3_cam), GFP_KERNEL);
if (!mx3_cam) {
dev_err(&pdev->dev, "Could not allocate mx3 camera object\n");
- err = -ENOMEM;
- goto ealloc;
+ return -ENOMEM;
}
- mx3_cam->clk = clk_get(&pdev->dev, NULL);
- if (IS_ERR(mx3_cam->clk)) {
- err = PTR_ERR(mx3_cam->clk);
- goto eclkget;
- }
+ mx3_cam->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(mx3_cam->clk))
+ return PTR_ERR(mx3_cam->clk);
mx3_cam->pdata = pdev->dev.platform_data;
mx3_cam->platform_flags = mx3_cam->pdata->flags;
@@ -1201,13 +1197,6 @@ static int mx3_camera_probe(struct platform_device *pdev)
INIT_LIST_HEAD(&mx3_cam->capture);
spin_lock_init(&mx3_cam->lock);
- base = ioremap(res->start, resource_size(res));
- if (!base) {
- pr_err("Couldn't map %x@%x\n", resource_size(res), res->start);
- err = -ENOMEM;
- goto eioremap;
- }
-
mx3_cam->base = base;
soc_host= &mx3_cam->soc_host;
@@ -1218,10 +1207,8 @@ static int mx3_camera_probe(struct platform_device *pdev)
soc_host->nr= pdev->id;
mx3_cam->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
- if (IS_ERR(mx3_cam->alloc_ctx)) {
- err = PTR_ERR(mx3_cam->alloc_ctx);
- goto eallocctx;
- }
+ if (IS_ERR(mx3_cam->alloc_ctx))
+ return PTR_ERR(mx3_cam->alloc_ctx);
err = soc_camera_host_register(soc_host);
if (err)
@@ -1234,14 +1221,6 @@ static int mx3_camera_probe(struct platform_device *pdev)
ecamhostreg:
vb2_dma_contig_cleanup_ctx(mx3_cam->alloc_ctx);
-eallocctx:
- iounmap(base);
-eioremap:
- clk_put(mx3_cam->clk);
-eclkget:
- vfree(mx3_cam);
-ealloc:
-egetres:
return err;
}
@@ -1251,12 +1230,8 @@ static int mx3_camera_remove(struct platform_device
*pdev)
struct mx3_camera_dev *mx3_cam = container_of(soc_host,
struct mx3_camera_dev, soc_host);
- clk_put(mx3_cam->clk);
-
soc_camera_host_unregister(soc_host);
- iounmap(mx3_cam->base);
-
/*
* The channel has either not been allocated,
* or should have been released
@@ -1266,8 +1241,6 @@ static int mx3_camera_remove(struct platform_device *pdev)
vb2_dma_contig_cleanup_ctx(mx3_cam->alloc_ctx);
- vfree(mx3_cam);
-
dmaengine_put();
return 0;
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] V4L2: mx3_camera: add support for asynchronous subdevice registration
The soc-camera core does all the work on supporting asynchronous
subdevice probing, host drivers only have to pass a subdevice list to
soc-camera. Typically this list is provided by the platform.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/platform/soc_camera/mx3_camera.c | 16 +---
include/linux/platform_data/camera-mx3.h |4
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx3_camera.c
b/drivers/media/platform/soc_camera/mx3_camera.c
index 83592e4..8f9f621 100644
--- a/drivers/media/platform/soc_camera/mx3_camera.c
+++ b/drivers/media/platform/soc_camera/mx3_camera.c
@@ -1144,6 +1144,7 @@ static struct soc_camera_host_ops mx3_soc_camera_host_ops
= {
static int mx3_camera_probe(struct platform_device *pdev)
{
+ struct mx3_camera_pdata *pdata = pdev->dev.platform_data;
struct mx3_camera_dev *mx3_cam;
struct resource *res;
void __iomem *base;
@@ -1155,6 +1156,9 @@ static int mx3_camera_probe(struct platform_device *pdev)
if (IS_ERR(base))
return PTR_ERR(base);
+ if (!pdata)
+ return -EINVAL;
+
mx3_cam = devm_kzalloc(&pdev->dev, sizeof(*mx3_cam), GFP_KERNEL);
if (!mx3_cam) {
dev_err(&pdev->dev, "Could not allocate mx3 camera object\n");
@@ -1165,8 +1169,8 @@ static int mx3_camera_probe(struct platform_device *pdev)
if (IS_ERR(mx3_cam->clk))
return PTR_ERR(mx3_cam->clk);
- mx3_cam->pdata = pdev->dev.platform_data;
- mx3_cam->platform_flags = mx3_cam->pdata->flags;
+ mx3_cam->pdata = pdata;
+ mx3_cam->platform_flags = pdata->flags;
if (!(mx3_cam->platform_flags & MX3_CAMERA_DATAWIDTH_MASK)) {
/*
* Platform hasn't set available data widths. This is bad.
@@ -1185,7 +1189,7 @@ static int mx3_camera_probe(struct platform_device *pdev)
if (mx3_cam->platform_flags & MX3_CAMERA_DATAWIDTH_15)
mx3_cam->width_flags |= 1 << 14;
- mx3_cam->mclk = mx3_cam->pdata->mclk_10khz * 1;
+ mx3_cam->mclk = pdata->mclk_10khz * 1;
if (!mx3_cam->mclk) {
dev_warn(&pdev->dev,
"mclk_10khz == 0! Please, fix your platform data. "
@@ -1210,6 +1214,11 @@ static int mx3_camera_probe(struct platform_device *pdev)
if (IS_ERR(mx3_cam->alloc_ctx))
return PTR_ERR(mx3_cam->alloc_ctx);
+ if (pdata->asd_sizes) {
+ soc_host->asd = pdata->asd;
+ soc_host->asd_sizes = pdata->asd_sizes;
+ }
+
err = soc_camera_host_register(soc_host);
if (err)
goto ecamhostreg;
@@ -1249,6 +1258,7 @@ static int mx3_camera_remove(struct platform_device *pdev)
static struct platform_driver mx3_camera_driver = {
.driver = {
.name = MX3_CAM_DRV_NAME,
+ .owner = THIS_MODULE,
},
.probe = mx3_camera_probe,
.remove = mx3_camera_remove,
diff --git a/include/linux/platform_data/camera-mx3.h
b/include/linux/platform_data/camera-mx3.h
index f226ee3..a910dad 100644
--- a/include/linux/platform_data/camera-mx3.h
+++ b/include/linux/platform_data/camera-mx3.h
@@ -33,6 +33,8 @@
#define MX3_CAMERA_DATAWIDTH_MASK (MX3_CAMERA_DATAWIDTH_4 |
MX3_CAMERA_DATAWIDTH_8 | \
MX3_CAMERA_DATAWIDTH_10 |
MX3_CAMERA_DATAWIDTH_15)
+struct v4l2_async_subdev;
+
/**
* struct mx3_camera_pdata - i.MX3x camera platform data
* @flags: MX3_CAMERA_* flags
@@ -43,6 +45,8 @@ struct mx3_camera_pdata {
unsigned long flags;
unsigned long mclk_10khz;
struct device *dma_dev;
+ struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
+ int *asd_sizes; /* 0-terminated array of asd group
sizes */
};
#endif
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] V4L2: mt9m111: switch to asynchronous subdevice probing
Convert the mt9m111 driver to asynchronous subdevice probing. Synchronous
probing is also still possible.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/i2c/soc_camera/mt9m111.c | 38 +--
1 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/mt9m111.c
b/drivers/media/i2c/soc_camera/mt9m111.c
index de3605d..6f40566 100644
--- a/drivers/media/i2c/soc_camera/mt9m111.c
+++ b/drivers/media/i2c/soc_camera/mt9m111.c
@@ -946,6 +946,10 @@ static int mt9m111_probe(struct i2c_client *client,
if (!mt9m111)
return -ENOMEM;
+ mt9m111->clk = v4l2_clk_get(&client->dev, "mclk");
+ if (IS_ERR(mt9m111->clk))
+ return -EPROBE_DEFER;
+
/* Default HIGHPOWER context */
mt9m111->ctx = &context_b;
@@ -963,8 +967,10 @@ static int mt9m111_probe(struct i2c_client *client,
&mt9m111_ctrl_ops, V4L2_CID_EXPOSURE_AUTO, 1, 0,
V4L2_EXPOSURE_AUTO);
mt9m111->subdev.ctrl_handler = &mt9m111->hdl;
- if (mt9m111->hdl.error)
- return mt9m111->hdl.error;
+ if (mt9m111->hdl.error) {
+ ret = mt9m111->hdl.error;
+ goto out_clkput;
+ }
/* Second stage probe - when a capture adapter is there */
mt9m111->rect.left = MT9M111_MIN_DARK_COLS;
@@ -975,18 +981,25 @@ static int mt9m111_probe(struct i2c_client *client,
mt9m111->lastpage = -1;
mutex_init(&mt9m111->power_lock);
- mt9m111->clk = v4l2_clk_get(&client->dev, "mclk");
- if (IS_ERR(mt9m111->clk)) {
- ret = PTR_ERR(mt9m111->clk);
- goto eclkget;
- }
+ ret = soc_camera_power_init(&client->dev, ssdd);
+ if (ret < 0)
+ goto out_hdlfree;
ret = mt9m111_video_probe(client);
- if (ret) {
- v4l2_clk_put(mt9m111->clk);
-eclkget:
- v4l2_ctrl_handler_free(&mt9m111->hdl);
- }
+ if (ret < 0)
+ goto out_hdlfree;
+
+ mt9m111->subdev.dev = &client->dev;
+ ret = v4l2_async_register_subdev(&mt9m111->subdev);
+ if (ret < 0)
+ goto out_hdlfree;
+
+ return 0;
+
+out_hdlfree:
+ v4l2_ctrl_handler_free(&mt9m111->hdl);
+out_clkput:
+ v4l2_clk_put(mt9m111->clk);
return ret;
}
@@ -995,6 +1008,7 @@ static int mt9m111_remove(struct i2c_client *client)
{
struct mt9m111 *mt9m111 = to_mt9m111(client);
+ v4l2_async_unregister_subdev(&mt9m111->subdev);
v4l2_clk_put(mt9m111->clk);
v4l2_device_unregister_subdev(&mt9m111->subdev);
v4l2_ctrl_handler_free(&mt9m111->hdl);
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] qv4l2: fix input parameters
Signed-off-by: Bård Eirik Winther
---
utils/qv4l2/qv4l2.cpp | 112 ++
1 file changed, 96 insertions(+), 16 deletions(-)
diff --git a/utils/qv4l2/qv4l2.cpp b/utils/qv4l2/qv4l2.cpp
index 892d9c3..644abe6 100644
--- a/utils/qv4l2/qv4l2.cpp
+++ b/utils/qv4l2/qv4l2.cpp
@@ -1146,33 +1146,113 @@ void ApplicationWindow::closeEvent(QCloseEvent *event)
ApplicationWindow *g_mw;
+static void usage()
+{
+ printf(" Usage:\n"
+ " qv4l2 [-R] [-h] [-d ] [-r ] [-V ]\n"
+ "\n -d, --device= use device as the video device\n"
+ " if is a number, then /dev/video
is used\n"
+ " -r, --radio-device= use device as the radio
device\n"
+ " if is a number, then /dev/radio
is used\n"
+ " -V, --vbi-device= use device as the vbi device\n"
+ " if is a number, then /dev/vbi
is used\n"
+ " -h, --help display this help message\n"
+ " -R, --raw open device in raw mode.\n");
+}
+
+static void usageError(const char *msg)
+{
+ printf("Missing parameter for %s\n", msg);
+ usage();
+}
+
+static QString getDeviceName(QString dev, QString &name)
+{
+ bool ok;
+ name.toInt(&ok);
+ return ok ? QString("%1%2").arg(dev).arg(name) : name;
+}
+
int main(int argc, char **argv)
{
QApplication a(argc, argv);
- QString device = "/dev/video0";
bool raw = false;
- bool help = false;
- int i;
+ QString device;
+ QString video_device;
+ QString radio_device;
+ QString vbi_device;
a.setWindowIcon(QIcon(":/qv4l2.png"));
g_mw = new ApplicationWindow();
g_mw->setWindowTitle("V4L2 Test Bench");
- for (i = 1; i < argc; i++) {
- const char *arg = a.argv()[i];
- if (!strcmp(arg, "-r"))
+ QStringList args = a.arguments();
+ for (int i = 1; i < args.size(); i++) {
+
+ if (args[i] == "-d" || args[i] == "--device") {
+ ++i;
+ if (i >= args.size()) {
+ usageError("--device");
+ return 0;
+ }
+
+ video_device = args.at(i);
+ if (video_device.startsWith("-")) {
+ usageError("--device");
+ return 0;
+ }
+ break;
+
+ } else if (args[i] == "-r" || args[i] == "--radio-device") {
+ ++i;
+ if (i >= args.size()) {
+ usageError("--radio-device");
+ return 0;
+ }
+
+ radio_device = args.at(i);
+ if (radio_device.startsWith("-")) {
+ usageError("--radio-device");
+ return 0;
+ }
+ break;
+
+ } else if (args[i] == "-V" || args[i] == "--vbi-device") {
+ ++i;
+ if (i >= args.size()) {
+ usageError("--vbi-device");
+ return 0;
+ }
+
+ vbi_device = args.at(i);
+ if (vbi_device.startsWith("-")) {
+ usageError("--vbi-device");
+ return 0;
+ }
+ break;
+
+ } else if (args[i] == "-h" || args[i] == "--help") {
+ usage();
+ return 0;
+
+ } else if (args[i] == "-R" || args[i] == "--raw") {
raw = true;
- else if (!strcmp(arg, "-h"))
- help = true;
- else if (arg[0] != '-')
- device = arg;
- }
- if (help) {
- printf("qv4l2 [-r] [-h] [device node]\n\n"
- "-h\tthis help message\n"
- "-r\topen device node in raw mode\n");
- return 0;
+ break;
+ } else {
+ printf("Unknown argument %s\n",
args[i].toAscii().data());
+ return 0;
+ }
}
+
+ if (video_device != NULL)
+ device = getDeviceName("/dev/video", video_device);
+ else if (radio_device != NULL)
+ device = getDeviceName("/dev/radio", radio_device);
+ else if (vbi_device != NULL)
+ device = getDeviceName("/dev/vbi", vbi_device);
+ else
+ device = "/dev/video0";
+
g_mw->setDevice(device, raw);
g_mw->show();
a.connect(&a, SIGNAL(lastW
[PATCH 1/2] qv4l2: fix missing status tips
Signed-off-by: Bård Eirik Winther
---
utils/qv4l2/general-tab.cpp | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/utils/qv4l2/general-tab.cpp b/utils/qv4l2/general-tab.cpp
index c404a3b..2605397 100644
--- a/utils/qv4l2/general-tab.cpp
+++ b/utils/qv4l2/general-tab.cpp
@@ -236,7 +236,9 @@ GeneralTab::GeneralTab(const QString &device, v4l2 &fd, int
n, QWidget *parent)
m_freq = new QLineEdit(parent);
m_freq->setValidator(val);
m_freq->setWhatsThis(QString("Frequency\nLow: %1\nHigh: %2")
- .arg(m_tuner.rangelow /
factor).arg(m_tuner.rangehigh / factor));
+.arg(m_tuner.rangelow / factor)
+.arg((double)m_tuner.rangehigh / factor,
0, 'f', 2));
+ m_freq->setStatusTip(m_freq->whatsThis());
connect(m_freq, SIGNAL(lostFocus()), SLOT(freqChanged()));
connect(m_freq, SIGNAL(returnPressed()), SLOT(freqChanged()));
updateFreq();
@@ -306,7 +308,9 @@ GeneralTab::GeneralTab(const QString &device, v4l2 &fd, int
n, QWidget *parent)
m_freq = new QLineEdit(parent);
m_freq->setValidator(val);
m_freq->setWhatsThis(QString("Frequency\nLow: %1\nHigh: %2")
- .arg(m_modulator.rangelow /
factor).arg(m_modulator.rangehigh / factor));
+.arg(m_tuner.rangelow / factor)
+.arg((double)m_tuner.rangehigh / factor,
0, 'f', 2));
+ m_freq->setStatusTip(m_freq->whatsThis());
connect(m_freq, SIGNAL(lostFocus()), SLOT(freqChanged()));
connect(m_freq, SIGNAL(returnPressed()), SLOT(freqChanged()));
updateFreq();
@@ -899,6 +903,7 @@ void GeneralTab::updateAudioInput()
what += ", has AVL";
if (audio.mode & V4L2_AUDMODE_AVL)
what += ", AVL is on";
+ m_audioInput->setStatusTip(what);
m_audioInput->setWhatsThis(what);
}
@@ -951,6 +956,7 @@ void GeneralTab::updateStandard()
(double)vs.frameperiod.numerator / vs.frameperiod.denominator,
vs.frameperiod.numerator, vs.frameperiod.denominator,
vs.framelines);
+ m_tvStandard->setStatusTip(what);
m_tvStandard->setWhatsThis(what);
updateVidCapFormat();
}
@@ -1014,6 +1020,7 @@ void GeneralTab::updateTimings()
what.sprintf("Video Timings (%u)\n"
"Frame %ux%u\n",
p.index, p.timings.bt.width, p.timings.bt.height);
+ m_videoTimings->setStatusTip(what);
m_videoTimings->setWhatsThis(what);
updateVidCapFormat();
}
--
1.8.4.rc1
--
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] qv4l2: fix input parameters and missing status tips
- Fixes some of the missing status tips in the general tab. - Fixes the frequency hint, now displaying correct value hints. - Fixes the program parameters. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/9] qv4l2: scaling, pixel aspect ratio and render fixes
On 08/08/2013 02:31 PM, Bård Eirik Winther wrote: > The PATCHv2 only rebases for master pull. That applies properly, thanks! Hans > > This adds scaling and aspect ratio support to the qv4l2 CaptureWin. > In that regard it fixes a lot of other issues that would otherwise make > scaling > render incorrectly. It also fixes some issues with the original OpenGL patch > series, > as well as adding tweaks and improvements left out in the original patches. > > > Some of the changes/improvements: > - CaptureWin have scaling support for video frames for all renderers > - CaptureWin support pixel aspect ratio scaling > - Aspect ratio and scaling can be changed during capture > - Reset and disable scaling options > - CaptureWin's setMinimumSize is now resize, which resizes the window to the > frame size given > and minimum size is set automatically > - The YUY2 shader programs are rewritten and has the resizing issue fixed > - The Show Frames option in Capture menu can be toggled during capture > - Added a hotkey: > CTRL + F : (size to video 'F'rame) >When either the main window or capture window is selected >this will reset the scaling to fit the frame size. >This option is also available in the Capture menu. > > Pixel Aspect Ratio Modes: > - Autodetect (if not supported this assumes square pixels) > - Square > - NTSC/PAL-M/PAL-60 > - NTSC/PAL-M/PAL-60, Anamorphic > - PAL/SECAM > - PAL/SECAM, Anamorphic > > Perfomance: > All tests are done using the 3.10 kernel with OpenGL enabled and desktop > effects disabled. > Testing was done on an Intel i7-2600S (with Turbo Boost disabled) > using the integrated Intel HD 2000 graphics processor. The mothreboard is > an ASUS P8H77-I > with 2x2GB CL 9-9-9-24 DDR3 RAM. The capture card is a Cisco test card with > 4 HDMI > inputs connected using PCIe2.0x8. All video input streams used for testing > are > progressive HD (1920x1080) with 60fps. > > FPS for every input for a given number of streams > (BGR3, YU12 and YV12 are emulated using the CPU): > 1 STREAM 2 STREAMS 3 STREAMS 4 STREAMS > RGB3 6060 60 60 > BGR3 6060 60 58 > YUYV 6060 60 60 > YU12 6060 60 60 > YV12 6060 60 60 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: Drop meaningless video_is_registered() call in v4l2_open()
Hi, As a person who debugged the problem I would like add my comments. On 08/07/2013 07:49 PM, Hans Verkuil wrote: > On 08/07/2013 06:49 PM, Sylwester Nawrocki wrote: >> Hi Hans, >> >> On 08/02/2013 03:00 PM, Hans Verkuil wrote: >>> Hi Sylwester, >>> >>> The patch is good, but I have some issues with the commit message itself. >> >> Thanks a lot for the detailed explanation, I just wrote this a bit >> longish changelog to possibly get some feedback and to better understand >> what is exactly going on. Currently the v4l2-core looks like a racing >> disaster to me. >> >>> On 08/02/2013 02:27 PM, Sylwester Nawrocki wrote: As it currently stands this code doesn't protect against any races between video device open() and its unregistration. Races could be avoided by doing the video_is_registered() check protected by the core mutex, while the video device unregistration is also done with this mutex held. >>> >>> The video_unregister_device() is called completely asynchronously, >>> particularly in the case of usb drivers. So it was never the goal of >>> the video_is_registered() to be fool proof, since that isn't possible, >>> nor is that necessary. >>> >>> The goal was that the v4l2 core would use it for the various file >>> operations and ioctls as a quick check whether the device was unregistered >>> and to return the correct error. This prevents drivers from having to do >>> the same thing. >> >> OK, I think I just myself used this video_is_registered() flag for some >> more stuff, by surrounding it with mutex_lock/mutex_unlock and putting >> more stuff in between, like media_entity_cleanup(). > > You can't do that, because there are most likely still filehandles open > or even ioctls being executed. Cleanup happens in the release function(s) > when the kref goes to 0. > >> And this probably led >> me astray for a while, thinking that video_is_registered() was intended >> to be used synchronously. >> For example see fimc_lite_subdev_unregistered() in drivers/media/platform/ >> exynos4-is/fimc-lite.c. >> >> But as you said video_is_registered() is fully asynchronous. >> >> Actually I'm trying to fix a nasty race between deferred driver probing >> and video device open(). The problem is that video open() callback can >> be called after driver remove() callback was invoked. > > How is that possible? The video_device_register must be the last thing in > the probe function. If it succeeds, then the probe must succeed as well. > > Note that I now realize that this might fail in the case of multiple device > nodes being registered. We never had problems with that in the past, but in > theory you can the race condition you mention in that scenario. The correct > approach here would probably be to always return 0 in probe() if only some > of the video_device_register calls fail. > > Anyway, assuming that only one device node is created, then I can't see how > you can get a race condition here. Any open() call will increase the module's > refcount, making it impossible to unload. The problem is that increasing refcount does not prevent the driver from unbinding via sysfs unbind attribute. Drivers/core are not handling such situation correctly. For example during v4l2 open callback driver_data is not protected by any lock so it can disappear in the most inconvenient time and cause system crash/hang (proven by real tests). The patch introducing unbind attribute suggests that it could be used in production systems ( https://lkml.org/lkml/2005/6/24/27 ) so I suppose the situation should be better handled. device_lock is used by unbind, so maybe it could be used also by callbacks? Regards Andrzej > > As far as I can tell, once you call rmmod it should no longer be possible to > open() an device node whose struct file_operations owner is that module (i.e. > the owner field of the file_operations struct points to that module). Looking > at the way fs/char_dev is implemented, that seems to be correctly handled by > the kernel core. > >> >> This issue is actually not only related to deferred probing. It can be >> also triggered by driver module removal or through driver's sysfs "unbind" >> attribute. >> >> Let's assume following scenario: >> >> - a driver module is loaded >> - driver probe is called, it registers video device, >> - udev opens /dev/video >> - after mutex_unlock(&videodev_lock); call in v4l2_open() in v4l2-core/ >> v4l2-dev.c something fails in probe() > > And that shouldn't happen. That's the crucial bit: under which scenario does > this happen for you? If there is a control path where you do create a working > device node, but the probe fails, then that will indeed cause all sorts of > problems. But it shouldn't get in that situation (except I think in the case > of multiple device nodes, which is something I need to think about). > >> and it unwinds, probe callback >> exits and the driver code code calls dev_set_drvdata(dev, NULL); as >> shown below. >>
Re: [PATCH v2] videobuf2-core: Verify planes lengths for output buffers
Hi Marek,
On Thursday 08 August 2013 14:14:30 Marek Szyprowski wrote:
> On 8/7/2013 12:44 PM, Laurent Pinchart wrote:
> > On Monday 12 November 2012 12:35:35 Laurent Pinchart wrote:
> > > On Friday 09 November 2012 15:33:22 Pawel Osciak wrote:
> > > > On Tue, Oct 16, 2012 at 8:37 AM, Laurent Pinchart wrote:
> > > > > For output buffers application provide to the kernel the number of
> > > > > bytes they stored in each plane of the buffer. Verify that the value
> > > > > is smaller than or equal to the plane length.
> > > > >
> > > > > Signed-off-by: Laurent Pinchart
> > > > > Acked-by: Hans Verkuil
> > > > > ---
> > > >
> > > > Acked-by: Pawel Osciak
> > >
> > > You're listed, as well as Marek and Kyungmin, as videobuf2 maintainers.
> > > When you ack a videobuf2 patch, should we assume that you will take it
> > > in your git tree ?
> >
> > Ping ? I'd like to get this patch in v3.12, should I send a pull request ?
>
> Acked-by: Marek Szyprowski
>
> Feel free to include it in your pull-request. I'm sorry for so huge
> delay in my response.
No worries. I'll send a pull request to Mauro.
> > > > > drivers/media/v4l2-core/videobuf2-core.c | 39 +++
> > > > > 1 files changed, 39 insertions(+), 0 deletions(-)
> > > > >
> > > > > Changes compared to v1:
> > > > >
> > > > > - Sanity check the data_offset value for each plane.
> > > > >
> > > > > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > > > > b/drivers/media/v4l2-core/videobuf2-core.c index 432df11..479337d
> > > > > 100644
> > > > > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > > > > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > > > > @@ -296,6 +296,41 @@ static int __verify_planes_array(struct
> > > > > vb2_buffer
> > > > > *vb, const struct v4l2_buffer>
> > > > >
> > > > > }
> > > > >
> > > > > /**
> > > > >
> > > > > + * __verify_length() - Verify that the bytesused value for each
> > > > > plane
> > > > > fits in
> > > > > + * the plane length and that the data offset doesn't exceed the
> > > > > bytesused value.
> > > > > + */
> > > > > +static int __verify_length(struct vb2_buffer *vb, const struct
> > > > > v4l2_buffer *b)
> > > > > +{
> > > > > + unsigned int length;
> > > > > + unsigned int plane;
> > > > > +
> > > > > + if (!V4L2_TYPE_IS_OUTPUT(b->type))
> > > > > + return 0;
> > > > > +
> > > > > + if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
> > > > > + for (plane = 0; plane < vb->num_planes; ++plane) {
> > > > > + length = (b->memory == V4L2_MEMORY_USERPTR)
> > > > > + ? b->m.planes[plane].length
> > > > > + : vb->v4l2_planes[plane].length;
> > > > > +
> > > > > + if (b->m.planes[plane].bytesused > length)
> > > > > + return -EINVAL;
> > > > > + if (b->m.planes[plane].data_offset >=
> > > > > + b->m.planes[plane].bytesused)
> > > > > + return -EINVAL;
> > > > > + }
> > > > > + } else {
> > > > > + length = (b->memory == V4L2_MEMORY_USERPTR)
> > > > > + ? b->length : vb->v4l2_planes[0].length;
> > > > > +
> > > > > + if (b->bytesused > length)
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +/**
> > > > >
> > > > > * __buffer_in_use() - return true if the buffer is in use and
> > > > > * the queue cannot be freed (by the means of REQBUFS(0)) call
> > > > > */
> > > > >
> > > > > @@ -975,6 +1010,10 @@ static int __buf_prepare(struct vb2_buffer
> > > > > *vb,
> > > > > const struct v4l2_buffer *b)>
> > > > >
> > > > > struct vb2_queue *q = vb->vb2_queue;
> > > > > int ret;
> > > > >
> > > > > + ret = __verify_length(vb, b);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > >
> > > > > switch (q->memory) {
> > > > >
> > > > > case V4L2_MEMORY_MMAP:
> > > > > ret = __qbuf_mmap(vb, b);
--
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
[PATCHv2 7/9] qv4l2: added resize to frame size in Capture menu
This will resize the CaptureWin to the original frame size.
It also works with maximized windows.
Signed-off-by: Bård Eirik Winther
---
utils/qv4l2/capture-win.cpp | 12
utils/qv4l2/capture-win.h | 3 +++
utils/qv4l2/qv4l2.cpp | 6 --
utils/qv4l2/qv4l2.h | 1 +
4 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/utils/qv4l2/capture-win.cpp b/utils/qv4l2/capture-win.cpp
index 33f7084..3bd6549 100644
--- a/utils/qv4l2/capture-win.cpp
+++ b/utils/qv4l2/capture-win.cpp
@@ -61,6 +61,18 @@ void CaptureWin::buildWindow(QWidget *videoSurface)
vbox->setSpacing(b);
}
+void CaptureWin::resetSize()
+{
+ if (isMaximized())
+ showNormal();
+
+ int w = m_curWidth;
+ int h = m_curHeight;
+ m_curWidth = -1;
+ m_curHeight = -1;
+ resize(w, h);
+}
+
QSize CaptureWin::getMargins()
{
int l, t, r, b;
diff --git a/utils/qv4l2/capture-win.h b/utils/qv4l2/capture-win.h
index dd19f2d..eea0335 100644
--- a/utils/qv4l2/capture-win.h
+++ b/utils/qv4l2/capture-win.h
@@ -78,6 +78,9 @@ public:
void enableScaling(bool enable);
static QSize scaleFrameSize(QSize window, QSize frame);
+public slots:
+ void resetSize();
+
protected:
void closeEvent(QCloseEvent *event);
void buildWindow(QWidget *videoSurface);
diff --git a/utils/qv4l2/qv4l2.cpp b/utils/qv4l2/qv4l2.cpp
index 6258a93..3da99da 100644
--- a/utils/qv4l2/qv4l2.cpp
+++ b/utils/qv4l2/qv4l2.cpp
@@ -142,11 +142,14 @@ ApplicationWindow::ApplicationWindow() :
m_scalingAct->setCheckable(true);
m_scalingAct->setChecked(true);
connect(m_scalingAct, SIGNAL(toggled(bool)), this,
SLOT(enableScaling(bool)));
+ m_resetScalingAct = new QAction("Resize to Frame Size", this);
+ m_resetScalingAct->setStatusTip("Resizes the capture window to match
frame size");
QMenu *captureMenu = menuBar()->addMenu("&Capture");
captureMenu->addAction(m_capStartAct);
captureMenu->addAction(m_showFramesAct);
captureMenu->addAction(m_scalingAct);
+ captureMenu->addAction(m_resetScalingAct);
if (CaptureWinGL::isSupported()) {
m_renderMethod = QV4L2_RENDER_GL;
@@ -211,8 +214,6 @@ void ApplicationWindow::setDevice(const QString &device,
bool rawOpen)
newCaptureWin();
- m_capture->setMinimumSize(150, 50);
-
QWidget *w = new QWidget(m_tabs);
m_genTab = new GeneralTab(device, *this, 4, w);
@@ -360,6 +361,7 @@ void ApplicationWindow::newCaptureWin()
m_capture->enableScaling(m_scalingAct->isChecked());
connect(m_capture, SIGNAL(close()), this, SLOT(closeCaptureWin()));
+ connect(m_resetScalingAct, SIGNAL(triggered()), m_capture,
SLOT(resetSize()));
}
void ApplicationWindow::capVbiFrame()
diff --git a/utils/qv4l2/qv4l2.h b/utils/qv4l2/qv4l2.h
index 1402673..179cecb 100644
--- a/utils/qv4l2/qv4l2.h
+++ b/utils/qv4l2/qv4l2.h
@@ -187,6 +187,7 @@ private:
QAction *m_showAllAudioAct;
QAction *m_audioBufferAct;
QAction *m_scalingAct;
+ QAction *m_resetScalingAct;
QString m_filename;
QSignalMapper *m_sigMapper;
QTabWidget *m_tabs;
--
1.8.4.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 8/9] qv4l2: add hotkey for reset scaling to frame size
Adds hotkey CTRL + F for both CaptureWin and main Capture menu.
Resets the scaling of CaptureWin to fit frame size.
Signed-off-by: Bård Eirik Winther
---
utils/qv4l2/capture-win.cpp | 3 +++
utils/qv4l2/capture-win.h | 1 +
utils/qv4l2/qv4l2.cpp | 1 +
3 files changed, 5 insertions(+)
diff --git a/utils/qv4l2/capture-win.cpp b/utils/qv4l2/capture-win.cpp
index 3bd6549..3abb6cb 100644
--- a/utils/qv4l2/capture-win.cpp
+++ b/utils/qv4l2/capture-win.cpp
@@ -38,6 +38,8 @@ CaptureWin::CaptureWin() :
setWindowTitle("V4L2 Capture");
m_hotkeyClose = new QShortcut(Qt::CTRL+Qt::Key_W, this);
connect(m_hotkeyClose, SIGNAL(activated()), this, SLOT(close()));
+ m_hotkeyScaleReset = new QShortcut(Qt::CTRL+Qt::Key_F, this);
+ connect(m_hotkeyScaleReset, SIGNAL(activated()), this,
SLOT(resetSize()));
}
CaptureWin::~CaptureWin()
@@ -48,6 +50,7 @@ CaptureWin::~CaptureWin()
layout()->removeWidget(this);
delete layout();
delete m_hotkeyClose;
+ delete m_hotkeyScaleReset;
}
void CaptureWin::buildWindow(QWidget *videoSurface)
diff --git a/utils/qv4l2/capture-win.h b/utils/qv4l2/capture-win.h
index eea0335..1bfb1e1 100644
--- a/utils/qv4l2/capture-win.h
+++ b/utils/qv4l2/capture-win.h
@@ -104,6 +104,7 @@ signals:
private:
QShortcut *m_hotkeyClose;
+ QShortcut *m_hotkeyScaleReset;
int m_curWidth;
int m_curHeight;
};
diff --git a/utils/qv4l2/qv4l2.cpp b/utils/qv4l2/qv4l2.cpp
index 3da99da..7be9f1a 100644
--- a/utils/qv4l2/qv4l2.cpp
+++ b/utils/qv4l2/qv4l2.cpp
@@ -144,6 +144,7 @@ ApplicationWindow::ApplicationWindow() :
connect(m_scalingAct, SIGNAL(toggled(bool)), this,
SLOT(enableScaling(bool)));
m_resetScalingAct = new QAction("Resize to Frame Size", this);
m_resetScalingAct->setStatusTip("Resizes the capture window to match
frame size");
+ m_resetScalingAct->setShortcut(Qt::CTRL+Qt::Key_F);
QMenu *captureMenu = menuBar()->addMenu("&Capture");
captureMenu->addAction(m_capStartAct);
--
1.8.4.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 9/9] qv4l2: add pixel aspect ratio support for CaptureWin
Signed-off-by: Bård Eirik Winther
---
utils/qv4l2/capture-win.cpp | 36 ++--
utils/qv4l2/capture-win.h | 6
utils/qv4l2/general-tab.cpp | 68 +
utils/qv4l2/general-tab.h | 4 +++
utils/qv4l2/qv4l2.cpp | 22 +++
utils/qv4l2/qv4l2.h | 1 +
6 files changed, 123 insertions(+), 14 deletions(-)
diff --git a/utils/qv4l2/capture-win.cpp b/utils/qv4l2/capture-win.cpp
index 3abb6cb..7538756 100644
--- a/utils/qv4l2/capture-win.cpp
+++ b/utils/qv4l2/capture-win.cpp
@@ -30,6 +30,7 @@
#define MIN_WIN_SIZE_HEIGHT 120
bool CaptureWin::m_enableScaling = true;
+double CaptureWin::m_pixelAspectRatio = 1.0;
CaptureWin::CaptureWin() :
m_curWidth(-1),
@@ -76,6 +77,14 @@ void CaptureWin::resetSize()
resize(w, h);
}
+int CaptureWin::actualFrameWidth(int width)
+{
+ if (m_enableScaling)
+ return (int)((double)width * m_pixelAspectRatio);
+
+ return width;
+}
+
QSize CaptureWin::getMargins()
{
int l, t, r, b;
@@ -108,7 +117,7 @@ void CaptureWin::resize(int width, int height)
m_curHeight = height;
QSize margins = getMargins();
- width += margins.width();
+ width = actualFrameWidth(width) + margins.width();
height += margins.height();
QDesktopWidget *screen = QApplication::desktop();
@@ -130,25 +139,36 @@ void CaptureWin::resize(int width, int height)
QSize CaptureWin::scaleFrameSize(QSize window, QSize frame)
{
- int actualFrameWidth = frame.width();;
- int actualFrameHeight = frame.height();
+ int actualWidth;
+ int actualHeight = frame.height();
if (!m_enableScaling) {
window.setWidth(frame.width());
window.setHeight(frame.height());
+ actualWidth = frame.width();
+ } else {
+ actualWidth = CaptureWin::actualFrameWidth(frame.width());
}
double newW, newH;
if (window.width() >= window.height()) {
- newW = (double)window.width() / actualFrameWidth;
- newH = (double)window.height() / actualFrameHeight;
+ newW = (double)window.width() / actualWidth;
+ newH = (double)window.height() / actualHeight;
} else {
- newH = (double)window.width() / actualFrameWidth;
- newW = (double)window.height() / actualFrameHeight;
+ newH = (double)window.width() / actualWidth;
+ newW = (double)window.height() / actualHeight;
}
double resized = std::min(newW, newH);
- return QSize((int)(actualFrameWidth * resized), (int)(actualFrameHeight
* resized));
+ return QSize((int)(actualWidth * resized), (int)(actualHeight *
resized));
+}
+
+void CaptureWin::setPixelAspectRatio(double ratio)
+{
+ m_pixelAspectRatio = ratio;
+ QResizeEvent *event = new QResizeEvent(QSize(width(), height()),
QSize(width(), height()));
+ QCoreApplication::sendEvent(this, event);
+ delete event;
}
void CaptureWin::closeEvent(QCloseEvent *event)
diff --git a/utils/qv4l2/capture-win.h b/utils/qv4l2/capture-win.h
index 1bfb1e1..e8f0ada 100644
--- a/utils/qv4l2/capture-win.h
+++ b/utils/qv4l2/capture-win.h
@@ -76,6 +76,7 @@ public:
static bool isSupported() { return false; }
void enableScaling(bool enable);
+ void setPixelAspectRatio(double ratio);
static QSize scaleFrameSize(QSize window, QSize frame);
public slots:
@@ -99,6 +100,11 @@ protected:
*/
static bool m_enableScaling;
+ /**
+* @note Aspect ratio it taken care of by scaling, frame size is for
square pixels only!
+*/
+ static double m_pixelAspectRatio;
+
signals:
void close();
diff --git a/utils/qv4l2/general-tab.cpp b/utils/qv4l2/general-tab.cpp
index 5cfaf07..c404a3b 100644
--- a/utils/qv4l2/general-tab.cpp
+++ b/utils/qv4l2/general-tab.cpp
@@ -53,6 +53,7 @@ GeneralTab::GeneralTab(const QString &device, v4l2 &fd, int
n, QWidget *parent)
m_tvStandard(NULL),
m_qryStandard(NULL),
m_videoTimings(NULL),
+ m_pixelAspectRatio(NULL),
m_qryTimings(NULL),
m_freq(NULL),
m_vidCapFormats(NULL),
@@ -210,6 +211,23 @@ GeneralTab::GeneralTab(const QString &device, v4l2 &fd,
int n, QWidget *parent)
connect(m_qryTimings, SIGNAL(clicked()),
SLOT(qryTimingsClicked()));
}
+ if (!isRadio() && !isVbi()) {
+ m_pixelAspectRatio = new QComboBox(parent);
+ m_pixelAspectRatio->addItem("Autodetect");
+ m_pixelAspectRatio->addItem("Square");
+ m_pixelAspectRatio->addItem("NTSC/PAL-M/PAL-60");
+ m_pixelAspectRatio->addItem("NTSC/PAL-M/PAL-60, Anamorphic");
+ m_pixelAspectRatio->addItem("PAL/SECAM");
+ m_pixelAspectRatio->addItem("PAL/SECAM, Anamorphic");
+
+
[PATCHv2 5/9] qv4l2: create function getMargins
Created a function to get the total margins (window frame) in pixels
outside the actual video frame beeing displayed.
Signed-off-by: Bård Eirik Winther
---
utils/qv4l2/capture-win.cpp | 14 ++
utils/qv4l2/capture-win.h | 1 +
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/utils/qv4l2/capture-win.cpp b/utils/qv4l2/capture-win.cpp
index 2d57909..8722066 100644
--- a/utils/qv4l2/capture-win.cpp
+++ b/utils/qv4l2/capture-win.cpp
@@ -54,16 +54,22 @@ void CaptureWin::buildWindow(QWidget *videoSurface)
vbox->setSpacing(b);
}
+QSize CaptureWin::getMargins()
+{
+ int l, t, r, b;
+ layout()->getContentsMargins(&l, &t, &r, &b);
+ return QSize(l + r, t + b + m_information.minimumSizeHint().height() +
layout()->spacing());
+}
+
void CaptureWin::setMinimumSize(int minw, int minh)
{
QDesktopWidget *screen = QApplication::desktop();
QRect resolution = screen->screenGeometry();
QSize maxSize = maximumSize();
- int l, t, r, b;
- layout()->getContentsMargins(&l, &t, &r, &b);
- minw += l + r;
- minh += t + b + m_information.minimumSizeHint().height() +
layout()->spacing();
+ QSize margins = getMargins();
+ minw += margins.width();
+ minh += margins.height();
if (minw > resolution.width())
minw = resolution.width();
diff --git a/utils/qv4l2/capture-win.h b/utils/qv4l2/capture-win.h
index ca60244..f662bd3 100644
--- a/utils/qv4l2/capture-win.h
+++ b/utils/qv4l2/capture-win.h
@@ -78,6 +78,7 @@ public:
protected:
void closeEvent(QCloseEvent *event);
void buildWindow(QWidget *videoSurface);
+ QSize getMargins();
/**
* @brief A label that can is used to display capture information.
--
1.8.4.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/9] qv4l2: fix black screen with opengl after capture
Fixes the issue when the window was beeing resized/moved
and the frame image would become black.
Signed-off-by: Bård Eirik Winther
---
utils/qv4l2/capture-win-gl.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/utils/qv4l2/capture-win-gl.cpp b/utils/qv4l2/capture-win-gl.cpp
index 6071410..c8238c5 100644
--- a/utils/qv4l2/capture-win-gl.cpp
+++ b/utils/qv4l2/capture-win-gl.cpp
@@ -253,6 +253,12 @@ void CaptureWinGLEngine::paintGL()
changeShader();
if (m_frameData == NULL) {
+ glBegin(GL_QUADS);
+ glTexCoord2f(0.0f, 0.0f); glVertex2f(0.0, 0);
+ glTexCoord2f(1.0f, 0.0f); glVertex2f(m_frameWidth, 0);
+ glTexCoord2f(1.0f, 1.0f); glVertex2f(m_frameWidth,
m_frameHeight);
+ glTexCoord2f(0.0f, 1.0f); glVertex2f(0, m_frameHeight);
+ glEnd();
return;
}
--
1.8.4.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/9] qv4l2: fix YUY2 shader
Fixed the YUY2 shaders to support scaling.
The new solution has cleaner shader code and texture upload
uses a better format for OpenGL.
Signed-off-by: Bård Eirik Winther
---
utils/qv4l2/capture-win-gl.cpp | 68 ++
1 file changed, 35 insertions(+), 33 deletions(-)
diff --git a/utils/qv4l2/capture-win-gl.cpp b/utils/qv4l2/capture-win-gl.cpp
index c499f1f..6071410 100644
--- a/utils/qv4l2/capture-win-gl.cpp
+++ b/utils/qv4l2/capture-win-gl.cpp
@@ -1,5 +1,5 @@
/*
- * The YUY2 shader code was copied and simplified from face-responder. The
code is under public domain:
+ * The YUY2 shader code is based on face-responder. The code is under public
domain:
*
https://bitbucket.org/nateharward/face-responder/src/0c3b4b957039d9f4bf1da09b9471371942de2601/yuv42201_laplace.frag?at=master
*
* All other OpenGL code:
@@ -446,47 +446,51 @@ QString CaptureWinGLEngine::shader_YUY2_invariant(__u32
format)
{
switch (format) {
case V4L2_PIX_FMT_YUYV:
- return QString("y = (luma_chroma.r - 0.0625) * 1.1643;"
- "if (mod(xcoord, 2.0) == 0.0) {"
- " u = luma_chroma.a;"
- " v = texture2D(tex, vec2(pixelx + texl_w,
pixely)).a;"
+ return QString("if (mod(xcoord, 2.0) == 0.0) {"
+ " luma_chroma = texture2D(tex, vec2(pixelx,
pixely));"
+ " y = (luma_chroma.r - 0.0625) * 1.1643;"
"} else {"
- " v = luma_chroma.a;"
- " u = texture2D(tex, vec2(pixelx - texl_w,
pixely)).a;"
+ " luma_chroma = texture2D(tex, vec2(pixelx -
texl_w, pixely));"
+ " y = (luma_chroma.b - 0.0625) * 1.1643;"
"}"
+ "u = luma_chroma.g - 0.5;"
+ "v = luma_chroma.a - 0.5;"
);
case V4L2_PIX_FMT_YVYU:
- return QString("y = (luma_chroma.r - 0.0625) * 1.1643;"
- "if (mod(xcoord, 2.0) == 0.0) {"
- " v = luma_chroma.a;"
- " u = texture2D(tex, vec2(pixelx + texl_w,
pixely)).a;"
+ return QString("if (mod(xcoord, 2.0) == 0.0) {"
+ " luma_chroma = texture2D(tex, vec2(pixelx,
pixely));"
+ " y = (luma_chroma.r - 0.0625) * 1.1643;"
"} else {"
- " u = luma_chroma.a;"
- " v = texture2D(tex, vec2(pixelx - texl_w,
pixely)).a;"
+ " luma_chroma = texture2D(tex, vec2(pixelx -
texl_w, pixely));"
+ " y = (luma_chroma.b - 0.0625) * 1.1643;"
"}"
+ "u = luma_chroma.a - 0.5;"
+ "v = luma_chroma.g - 0.5;"
);
case V4L2_PIX_FMT_UYVY:
- return QString("y = (luma_chroma.a - 0.0625) * 1.1643;"
- "if (mod(xcoord, 2.0) == 0.0) {"
- " u = luma_chroma.r;"
- " v = texture2D(tex, vec2(pixelx + texl_w,
pixely)).r;"
+ return QString("if (mod(xcoord, 2.0) == 0.0) {"
+ " luma_chroma = texture2D(tex, vec2(pixelx,
pixely));"
+ " y = (luma_chroma.g - 0.0625) * 1.1643;"
"} else {"
- " v = luma_chroma.r;"
- " u = texture2D(tex, vec2(pixelx - texl_w,
pixely)).r;"
+ " luma_chroma = texture2D(tex, vec2(pixelx -
texl_w, pixely));"
+ " y = (luma_chroma.a - 0.0625) * 1.1643;"
"}"
+ "u = luma_chroma.r - 0.5;"
+ "v = luma_chroma.b - 0.5;"
);
case V4L2_PIX_FMT_VYUY:
- return QString("y = (luma_chroma.a - 0.0625) * 1.1643;"
- "if (mod(xcoord, 2.0) == 0.0) {"
- " v = luma_chroma.r;"
- " u = texture2D(tex, vec2(pixelx + texl_w,
pixely)).r;"
+ return QString("if (mod(xcoord, 2.0) == 0.0) {"
+ " luma_chroma = texture2D(tex, vec2(pixelx,
pixely));"
+ " y = (luma_chroma.g - 0.0625) * 1.1643;"
"} else {"
- " u = luma_chroma.r;"
- " v = texture2D(tex, vec2(pixelx - texl_w,
pixely)).r;"
+
[PATCHv2 1/9] qv4l2: generalized opengl include guards
Created a general QtGL makefile condition and using config.h
to check in code if QtGL is present.
Signed-off-by: Bård Eirik Winther
---
configure.ac | 6 --
utils/qv4l2/Makefile.am| 4 ++--
utils/qv4l2/capture-win-gl.cpp | 12 ++--
utils/qv4l2/capture-win-gl.h | 6 --
4 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4cb6cf2..1e24c91 100644
--- a/configure.ac
+++ b/configure.ac
@@ -132,7 +132,9 @@ else
fi
PKG_CHECK_MODULES(QTGL, [QtOpenGL >= 4.4 gl], [qt_pkgconfig_gl=true],
[qt_pkgconfig_gl=false])
-if test "x$qt_pkgconfig_gl" = "xfalse"; then
+if test "x$qt_pkgconfig_gl" = "xtrue"; then
+ AC_DEFINE([HAVE_QTGL], [1], [qt has opengl support])
+else
AC_MSG_WARN(Qt4 OpenGL or higher is not available)
fi
@@ -249,9 +251,9 @@ AM_CONDITIONAL([WITH_LIBDVBV5], [test x$enable_libdvbv5 =
xyes])
AM_CONDITIONAL([WITH_LIBV4L], [test x$enable_libv4l != xno])
AM_CONDITIONAL([WITH_V4LUTILS], [test x$enable_v4lutils != xno])
AM_CONDITIONAL([WITH_QV4L2], [test ${qt_pkgconfig} = true -a x$enable_qv4l2 !=
xno])
-AM_CONDITIONAL([WITH_QV4L2_GL], [test WITH_QV4L2 -a ${qt_pkgconfig_gl} = true])
AM_CONDITIONAL([WITH_V4L_PLUGINS], [test x$enable_libv4l != xno -a
x$enable_shared != xno])
AM_CONDITIONAL([WITH_V4L_WRAPPERS], [test x$enable_libv4l != xno -a
x$enable_shared != xno])
+AM_CONDITIONAL([WITH_QTGL], [test ${qt_pkgconfig_gl} = true])
# append -static to libtool compile and link command to enforce static libs
AS_IF([test x$enable_libdvbv5 != xyes], [AC_SUBST([ENFORCE_LIBDVBV5_STATIC],
["-static"])])
diff --git a/utils/qv4l2/Makefile.am b/utils/qv4l2/Makefile.am
index 3aed18c..58ac097 100644
--- a/utils/qv4l2/Makefile.am
+++ b/utils/qv4l2/Makefile.am
@@ -7,8 +7,8 @@ nodist_qv4l2_SOURCES = moc_qv4l2.cpp moc_general-tab.cpp
moc_capture-win.cpp moc
qv4l2_LDADD = ../../lib/libv4l2/libv4l2.la
../../lib/libv4lconvert/libv4lconvert.la ../libv4l2util/libv4l2util.la \
../libmedia_dev/libmedia_dev.la
-if WITH_QV4L2_GL
-qv4l2_CPPFLAGS = $(QTGL_CFLAGS) -DENABLE_GL
+if WITH_QTGL
+qv4l2_CPPFLAGS = $(QTGL_CFLAGS)
qv4l2_LDFLAGS = $(QTGL_LIBS)
else
qv4l2_CPPFLAGS = $(QT_CFLAGS)
diff --git a/utils/qv4l2/capture-win-gl.cpp b/utils/qv4l2/capture-win-gl.cpp
index 52412c7..c499f1f 100644
--- a/utils/qv4l2/capture-win-gl.cpp
+++ b/utils/qv4l2/capture-win-gl.cpp
@@ -26,7 +26,7 @@
CaptureWinGL::CaptureWinGL()
{
-#ifdef ENABLE_GL
+#ifdef HAVE_QTGL
CaptureWin::buildWindow(&m_videoSurface);
#endif
CaptureWin::setWindowTitle("V4L2 Capture (OpenGL)");
@@ -38,14 +38,14 @@ CaptureWinGL::~CaptureWinGL()
void CaptureWinGL::stop()
{
-#ifdef ENABLE_GL
+#ifdef HAVE_QTGL
m_videoSurface.stop();
#endif
}
void CaptureWinGL::setFrame(int width, int height, __u32 format, unsigned char
*data, const QString &info)
{
-#ifdef ENABLE_GL
+#ifdef HAVE_QTGL
m_videoSurface.setFrame(width, height, format, data);
#endif
m_information.setText(info);
@@ -53,7 +53,7 @@ void CaptureWinGL::setFrame(int width, int height, __u32
format, unsigned char *
bool CaptureWinGL::hasNativeFormat(__u32 format)
{
-#ifdef ENABLE_GL
+#ifdef HAVE_QTGL
return m_videoSurface.hasNativeFormat(format);
#else
return false;
@@ -62,14 +62,14 @@ bool CaptureWinGL::hasNativeFormat(__u32 format)
bool CaptureWinGL::isSupported()
{
-#ifdef ENABLE_GL
+#ifdef HAVE_QTGL
return true;
#else
return false;
#endif
}
-#ifdef ENABLE_GL
+#ifdef HAVE_QTGL
CaptureWinGLEngine::CaptureWinGLEngine() :
m_frameHeight(0),
m_frameWidth(0),
diff --git a/utils/qv4l2/capture-win-gl.h b/utils/qv4l2/capture-win-gl.h
index 08e72b2..6e64269 100644
--- a/utils/qv4l2/capture-win-gl.h
+++ b/utils/qv4l2/capture-win-gl.h
@@ -18,10 +18,12 @@
#ifndef CAPTURE_WIN_GL_H
#define CAPTURE_WIN_GL_H
+#include
+
#include "qv4l2.h"
#include "capture-win.h"
-#ifdef ENABLE_GL
+#ifdef HAVE_QTGL
#define GL_GLEXT_PROTOTYPES
#include
#include
@@ -88,7 +90,7 @@ public:
bool hasNativeFormat(__u32 format);
static bool isSupported();
-#ifdef ENABLE_GL
+#ifdef HAVE_QTGL
CaptureWinGLEngine m_videoSurface;
#endif
};
--
1.8.4.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 4/9] qv4l2: show frames option can be toggled during capture
Signed-off-by: Bård Eirik Winther
---
utils/qv4l2/qv4l2.cpp | 84 +++
utils/qv4l2/qv4l2.h | 2 +-
2 files changed, 46 insertions(+), 40 deletions(-)
diff --git a/utils/qv4l2/qv4l2.cpp b/utils/qv4l2/qv4l2.cpp
index 6f39726..e33254d 100644
--- a/utils/qv4l2/qv4l2.cpp
+++ b/utils/qv4l2/qv4l2.cpp
@@ -404,7 +404,7 @@ void ApplicationWindow::capVbiFrame()
m_capStartAct->setChecked(false);
return;
}
- if (m_showFrames) {
+ if (showFrames()) {
for (unsigned y = 0; y < m_vbiHeight; y++) {
__u8 *p = data + y * m_vbiWidth;
__u8 *q = m_capImage->bits() + y *
m_capImage->bytesPerLine();
@@ -448,7 +448,7 @@ void ApplicationWindow::capVbiFrame()
m_tv = tv;
}
status = QString("Frame: %1 Fps: %2").arg(++m_frame).arg(m_fps);
- if (m_showFrames)
+ if (showFrames())
m_capture->setFrame(m_capImage->width(), m_capImage->height(),
m_capDestFormat.fmt.pix.pixelformat,
m_capImage->bits(), status);
@@ -491,7 +491,7 @@ void ApplicationWindow::capFrame()
if (m_saveRaw.openMode())
m_saveRaw.write((const char *)m_frameData, s);
- if (!m_showFrames)
+ if (!showFrames())
break;
if (m_mustConvert)
err = v4lconvert_convert(m_convertData,
&m_capSrcFormat, &m_capDestFormat,
@@ -515,7 +515,7 @@ void ApplicationWindow::capFrame()
if (again)
return;
- if (m_showFrames) {
+ if (showFrames()) {
if (m_mustConvert)
err = v4lconvert_convert(m_convertData,
&m_capSrcFormat, &m_capDestFormat,
(unsigned char
*)m_buffers[buf.index].start, buf.bytesused,
@@ -544,7 +544,7 @@ void ApplicationWindow::capFrame()
if (again)
return;
- if (m_showFrames) {
+ if (showFrames()) {
if (m_mustConvert)
err = v4lconvert_convert(m_convertData,
&m_capSrcFormat, &m_capDestFormat,
(unsigned char
*)buf.m.userptr, buf.bytesused,
@@ -590,10 +590,10 @@ void ApplicationWindow::capFrame()
.arg((m_totalAudioLatency.tv_sec * 1000 +
m_totalAudioLatency.tv_usec / 1000) / m_frame));
}
#endif
- if (displaybuf == NULL && m_showFrames)
+ if (displaybuf == NULL && showFrames())
status.append(" Error: Unsupported format.");
- if (m_showFrames)
+ if (showFrames())
m_capture->setFrame(m_capImage->width(), m_capImage->height(),
m_capDestFormat.fmt.pix.pixelformat,
displaybuf, status);
@@ -776,6 +776,15 @@ void ApplicationWindow::stopCapture()
refresh();
}
+bool ApplicationWindow::showFrames()
+{
+ if (m_showFramesAct->isChecked() && !m_capture->isVisible())
+ m_capture->show();
+ if (!m_showFramesAct->isChecked() && m_capture->isVisible())
+ m_capture->hide();
+ return m_showFramesAct->isChecked();
+}
+
void ApplicationWindow::startOutput(unsigned)
{
}
@@ -849,7 +858,6 @@ void ApplicationWindow::capStart(bool start)
m_capImage = NULL;
return;
}
- m_showFrames = m_showFramesAct->isChecked();
m_frame = m_lastFrame = m_fps = 0;
m_capMethod = m_genTab->capMethod();
@@ -857,7 +865,6 @@ void ApplicationWindow::capStart(bool start)
v4l2_format fmt;
v4l2_std_id std;
- m_showFrames = false;
g_fmt_sliced_vbi(fmt);
g_std(std);
fmt.fmt.sliced.service_set = (std & V4L2_STD_625_50) ?
@@ -896,14 +903,14 @@ void ApplicationWindow::capStart(bool start)
m_vbiHeight = fmt.fmt.vbi.count[0] +
fmt.fmt.vbi.count[1];
m_vbiSize = m_vbiWidth * m_vbiHeight;
m_frameData = new unsigned char[m_vbiSize];
- if (m_showFrames) {
- m_capture->setMinimumSize(m_vbiWidth, m_vbiHeight);
- m_capImage = new QImage(m_vbiWidth, m_vbiHeight,
dstFmt);
- m_capImage->fill(0);
- m_capture->setFrame(m_capImage->width(),
m_capImage->height(),
-
m_capDestFormat.fmt.pix.pixelformat, m_capImage->bits(), "No frame");
+ m_capture->setMinimumSize(m_vbiWidth, m_vbiHeight);
+ m_capImage = new QImage(m_vbiWidth, m_vbiHeight, dstFmt);
+ m_capImage->fill(0);
+ m_capture->setFrame(m_capIm
[PATCHv2 0/9] qv4l2: scaling, pixel aspect ratio and render fixes
The PATCHv2 only rebases for master pull. This adds scaling and aspect ratio support to the qv4l2 CaptureWin. In that regard it fixes a lot of other issues that would otherwise make scaling render incorrectly. It also fixes some issues with the original OpenGL patch series, as well as adding tweaks and improvements left out in the original patches. Some of the changes/improvements: - CaptureWin have scaling support for video frames for all renderers - CaptureWin support pixel aspect ratio scaling - Aspect ratio and scaling can be changed during capture - Reset and disable scaling options - CaptureWin's setMinimumSize is now resize, which resizes the window to the frame size given and minimum size is set automatically - The YUY2 shader programs are rewritten and has the resizing issue fixed - The Show Frames option in Capture menu can be toggled during capture - Added a hotkey: CTRL + F : (size to video 'F'rame) When either the main window or capture window is selected this will reset the scaling to fit the frame size. This option is also available in the Capture menu. Pixel Aspect Ratio Modes: - Autodetect (if not supported this assumes square pixels) - Square - NTSC/PAL-M/PAL-60 - NTSC/PAL-M/PAL-60, Anamorphic - PAL/SECAM - PAL/SECAM, Anamorphic Perfomance: All tests are done using the 3.10 kernel with OpenGL enabled and desktop effects disabled. Testing was done on an Intel i7-2600S (with Turbo Boost disabled) using the integrated Intel HD 2000 graphics processor. The mothreboard is an ASUS P8H77-I with 2x2GB CL 9-9-9-24 DDR3 RAM. The capture card is a Cisco test card with 4 HDMI inputs connected using PCIe2.0x8. All video input streams used for testing are progressive HD (1920x1080) with 60fps. FPS for every input for a given number of streams (BGR3, YU12 and YV12 are emulated using the CPU): 1 STREAM 2 STREAMS 3 STREAMS 4 STREAMS RGB3 6060 60 60 BGR3 6060 60 58 YUYV 6060 60 60 YU12 6060 60 60 YV12 6060 60 60 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 6/9] qv4l2: add video scaling for CaptureWin
Signed-off-by: Bård Eirik Winther
---
utils/qv4l2/capture-win-gl.cpp | 26 ++--
utils/qv4l2/capture-win-gl.h | 7
utils/qv4l2/capture-win-qt.cpp | 23 ++-
utils/qv4l2/capture-win-qt.h | 5 +++
utils/qv4l2/capture-win.cpp| 93 --
utils/qv4l2/capture-win.h | 14 ++-
utils/qv4l2/qv4l2.cpp | 24 ---
utils/qv4l2/qv4l2.h| 2 +
8 files changed, 160 insertions(+), 34 deletions(-)
diff --git a/utils/qv4l2/capture-win-gl.cpp b/utils/qv4l2/capture-win-gl.cpp
index c8238c5..27ff3d3 100644
--- a/utils/qv4l2/capture-win-gl.cpp
+++ b/utils/qv4l2/capture-win-gl.cpp
@@ -43,6 +43,15 @@ void CaptureWinGL::stop()
#endif
}
+void CaptureWinGL::resizeEvent(QResizeEvent *event)
+{
+#ifdef HAVE_QTGL
+ QSize margins = getMargins();
+ m_videoSurface.setSize(width() - margins.width(), height() -
margins.height());
+#endif
+ event->accept();
+}
+
void CaptureWinGL::setFrame(int width, int height, __u32 format, unsigned char
*data, const QString &info)
{
#ifdef HAVE_QTGL
@@ -109,11 +118,22 @@ void CaptureWinGLEngine::initializeGL()
checkError("InitializeGL");
}
+void CaptureWinGLEngine::setSize(int width, int height)
+{
+ QSize sizedFrame = CaptureWin::scaleFrameSize(QSize(width, height),
QSize(m_frameWidth, m_frameHeight));
+
+ width = sizedFrame.width();
+ height = sizedFrame.height();
+
+ if (width > 0 && height > 0) {
+ setMaximumSize(width, height);
+ resizeGL(width, height);
+ }
+}
void CaptureWinGLEngine::resizeGL(int width, int height)
{
- // Resizing is disabled by setting viewport equal to frame size
- glViewport(0, 0, m_frameWidth, m_frameHeight);
+ glViewport(0, 0, width, height);
}
void CaptureWinGLEngine::setFrame(int width, int height, __u32 format,
unsigned char *data)
@@ -123,8 +143,6 @@ void CaptureWinGLEngine::setFrame(int width, int height,
__u32 format, unsigned
m_frameWidth = width;
m_frameHeight = height;
m_frameFormat = format;
-
- QGLWidget::setMaximumSize(m_frameWidth, m_frameHeight);
}
m_frameData = data;
diff --git a/utils/qv4l2/capture-win-gl.h b/utils/qv4l2/capture-win-gl.h
index 6e64269..0c3ff8b 100644
--- a/utils/qv4l2/capture-win-gl.h
+++ b/utils/qv4l2/capture-win-gl.h
@@ -23,6 +23,8 @@
#include "qv4l2.h"
#include "capture-win.h"
+#include
+
#ifdef HAVE_QTGL
#define GL_GLEXT_PROTOTYPES
#include
@@ -42,6 +44,7 @@ public:
void stop();
void setFrame(int width, int height, __u32 format, unsigned char *data);
bool hasNativeFormat(__u32 format);
+ void setSize(int width, int height);
protected:
void paintGL();
@@ -90,6 +93,10 @@ public:
bool hasNativeFormat(__u32 format);
static bool isSupported();
+protected:
+ void resizeEvent(QResizeEvent *event);
+
+private:
#ifdef HAVE_QTGL
CaptureWinGLEngine m_videoSurface;
#endif
diff --git a/utils/qv4l2/capture-win-qt.cpp b/utils/qv4l2/capture-win-qt.cpp
index 63c77d5..f746379 100644
--- a/utils/qv4l2/capture-win-qt.cpp
+++ b/utils/qv4l2/capture-win-qt.cpp
@@ -24,6 +24,8 @@ CaptureWinQt::CaptureWinQt() :
{
CaptureWin::buildWindow(&m_videoSurface);
+ m_scaledFrame.setWidth(0);
+ m_scaledFrame.setHeight(0);
}
CaptureWinQt::~CaptureWinQt()
@@ -31,6 +33,19 @@ CaptureWinQt::~CaptureWinQt()
delete m_frame;
}
+void CaptureWinQt::resizeEvent(QResizeEvent *event)
+{
+ if (m_frame->bits() == NULL)
+ return;
+
+ QPixmap img = QPixmap::fromImage(*m_frame);
+ m_scaledFrame = scaleFrameSize(QSize(m_videoSurface.width(),
m_videoSurface.height()),
+ QSize(m_frame->width(),
m_frame->height()));
+ img = img.scaled(m_scaledFrame.width(), m_scaledFrame.height(),
Qt::IgnoreAspectRatio);
+ m_videoSurface.setPixmap(img);
+ QWidget::resizeEvent(event);
+}
+
void CaptureWinQt::setFrame(int width, int height, __u32 format, unsigned char
*data, const QString &info)
{
QImage::Format dstFmt;
@@ -41,6 +56,8 @@ void CaptureWinQt::setFrame(int width, int height, __u32
format, unsigned char *
if (m_frame->width() != width || m_frame->height() != height ||
m_frame->format() != dstFmt) {
delete m_frame;
m_frame = new QImage(width, height, dstFmt);
+ m_scaledFrame = scaleFrameSize(QSize(m_videoSurface.width(),
m_videoSurface.height()),
+ QSize(m_frame->width(),
m_frame->height()));
}
if (data == NULL || !supported)
@@ -49,7 +66,11 @@ void CaptureWinQt::setFrame(int width, int height, __u32
format, unsigned char *
memcpy(m_frame->bits(), data, m_frame->numBytes());
m_information.setText(info);
- m_videoSurface.setPixmap(QP
Re: [PATCH v2] videobuf2-core: Verify planes lengths for output buffers
On 8/7/2013 12:44 PM, Laurent Pinchart wrote:
On Monday 12 November 2012 12:35:35 Laurent Pinchart wrote:
> On Friday 09 November 2012 15:33:22 Pawel Osciak wrote:
> > On Tue, Oct 16, 2012 at 8:37 AM, Laurent Pinchart wrote:
> > > For output buffers application provide to the kernel the number of bytes
> > > they stored in each plane of the buffer. Verify that the value is
> > > smaller than or equal to the plane length.
> > >
> > > Signed-off-by: Laurent Pinchart
> > > Acked-by: Hans Verkuil
> > > ---
> >
> > Acked-by: Pawel Osciak
>
> You're listed, as well as Marek and Kyungmin, as videobuf2 maintainers. When
> you ack a videobuf2 patch, should we assume that you will take it in your
> git tree ?
Ping ? I'd like to get this patch in v3.12, should I send a pull request ?
Acked-by: Marek Szyprowski
Feel free to include it in your pull-request. I'm sorry for so huge
delay in my response.
> > > drivers/media/v4l2-core/videobuf2-core.c | 39 +++
> > > 1 files changed, 39 insertions(+), 0 deletions(-)
> > >
> > > Changes compared to v1:
> > >
> > > - Sanity check the data_offset value for each plane.
> > >
> > > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > > b/drivers/media/v4l2-core/videobuf2-core.c index 432df11..479337d 100644
> > > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > > @@ -296,6 +296,41 @@ static int __verify_planes_array(struct vb2_buffer
> > > *vb, const struct v4l2_buffer>
> > >
> > > }
> > >
> > > /**
> > > + * __verify_length() - Verify that the bytesused value for each plane
> > > fits in
> > > + * the plane length and that the data offset doesn't exceed the
> > > bytesused value.
> > > + */
> > > +static int __verify_length(struct vb2_buffer *vb, const struct
> > > v4l2_buffer *b)
> > > +{
> > > + unsigned int length;
> > > + unsigned int plane;
> > > +
> > > + if (!V4L2_TYPE_IS_OUTPUT(b->type))
> > > + return 0;
> > > +
> > > + if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
> > > + for (plane = 0; plane < vb->num_planes; ++plane) {
> > > + length = (b->memory == V4L2_MEMORY_USERPTR)
> > > + ? b->m.planes[plane].length
> > > + : vb->v4l2_planes[plane].length;
> > > +
> > > + if (b->m.planes[plane].bytesused > length)
> > > + return -EINVAL;
> > > + if (b->m.planes[plane].data_offset >=
> > > + b->m.planes[plane].bytesused)
> > > + return -EINVAL;
> > > + }
> > > + } else {
> > > + length = (b->memory == V4L2_MEMORY_USERPTR)
> > > + ? b->length : vb->v4l2_planes[0].length;
> > > +
> > > + if (b->bytesused > length)
> > > + return -EINVAL;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/**
> > > * __buffer_in_use() - return true if the buffer is in use and
> > > * the queue cannot be freed (by the means of REQBUFS(0)) call
> > > */
> > > @@ -975,6 +1010,10 @@ static int __buf_prepare(struct vb2_buffer *vb,
> > > const struct v4l2_buffer *b)>
> > > struct vb2_queue *q = vb->vb2_queue;
> > > int ret;
> > >
> > > + ret = __verify_length(vb, b);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > switch (q->memory) {
> > > case V4L2_MEMORY_MMAP:
> > > ret = __qbuf_mmap(vb, b);
Best regards
--
Marek Szyprowski
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-utils/master] qv4l2: add aspect ratio support
On 08/08/2013 01:32 PM, Bård Eirik Winther wrote: > Hi. > > Bad news. While rebasing my cropping support branch I noticed that Hans has > merged in the wrong patch series for the scaling. My bad, sorry. I've reverted the changes. > The one Hans have merged is one of our internal revisions, as only v1 is > present on the mailing list. > I sent out a full patch series on Tuesday that consists of 9 parts, wheras > the part you have merged is only 7 (from YUY2 shader to aspect ratio). The reason I got confused was that the newer patch series no longer applies. Can you rebase it and post again? Thanks! Hans > > B. > -- > 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
[GIT PULL FOR v3.12] Patches for 3.12
Hi Mauro,
Improvements for saa7115/gm7113c, moving the tea575x driver from sound to
drivers/media
(where it really belongs), and some streamlining for dv_timings handling: all
dv_timings
related helper code is now in a new module, so it's no longer in v4l2-common. I
also
added some helper functions/macros to simplify driver development.
Regards,
Hans
The following changes since commit dfb9f94e8e5e7f73c8e2bcb7d4fb1de57e7c333d:
[media] stk1160: Build as a module if SND is m and audio support is selected
(2013-08-01 14:55:25 -0300)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git for-v3.12
for you to fetch changes up to e4313121621be741481838090ba2b31a2b1395dc:
saa7115: Implement i2c_board_info.platform_data (2013-08-08 13:14:49 +0200)
Hans Verkuil (8):
v4l2-dv-timings.h: remove duplicate V4L2_DV_BT_DMT_1366X768P60
v4l2-dv-timings: add new helper module.
v4l2: move dv-timings related code to v4l2-dv-timings.c
DocBook/media/v4l: il_* fields always 0 for progressive formats
videodev2.h: defines to calculate blanking and frame sizes
v4l2: use new V4L2_DV_BT_BLANKING/FRAME defines
v4l2: use new V4L2_DV_BT_BLANKING/FRAME defines
ths8200/ad9389b: use new dv_timings helpers.
Jon Arne Jørgensen (3):
saa7115: Fix saa711x_set_v4lstd for gm7113c
saa7115: Do not load saa7115_init_misc for gm7113c
saa7115: Implement i2c_board_info.platform_data
Ondrej Zary (2):
tea575x: Move header from sound to media
tea575x: Move from sound to media
Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml | 6 +-
drivers/media/i2c/ad9389b.c | 115
+++--
drivers/media/i2c/adv7604.c | 9 +-
drivers/media/i2c/saa7115.c | 167
++
drivers/media/i2c/saa711x_regs.h | 19 +++
drivers/media/i2c/ths7303.c | 6 +-
drivers/media/i2c/ths8200.c | 64 +++
drivers/media/platform/blackfin/bfin_capture.c | 9 +-
drivers/media/platform/davinci/vpif_capture.c| 10 +-
drivers/media/platform/davinci/vpif_display.c| 10 +-
drivers/media/radio/Kconfig | 12 +-
drivers/media/radio/Makefile | 1 +
drivers/media/radio/radio-maxiradio.c| 2 +-
drivers/media/radio/radio-sf16fmr2.c | 2 +-
drivers/media/radio/radio-shark.c| 2 +-
sound/i2c/other/tea575x-tuner.c => drivers/media/radio/tea575x.c | 2 +-
drivers/media/usb/hdpvr/hdpvr-video.c| 7 +-
drivers/media/v4l2-core/Makefile | 1 +
drivers/media/v4l2-core/v4l2-common.c| 357
--
drivers/media/v4l2-core/v4l2-dv-timings.c| 548
+++
include/media/saa7115.h | 64 +++
include/{sound/tea575x-tuner.h => media/tea575x.h} | 0
include/media/v4l2-common.h | 13 --
include/media/v4l2-dv-timings.h | 126
++
include/uapi/linux/v4l2-dv-timings.h | 8 -
include/uapi/linux/videodev2.h | 10 ++
sound/i2c/other/Makefile | 2 -
sound/pci/Kconfig| 9 +-
sound/pci/es1968.c | 2 +-
sound/pci/fm801.c| 2 +-
30 files changed, 979 insertions(+), 606 deletions(-)
rename sound/i2c/other/tea575x-tuner.c => drivers/media/radio/tea575x.c (99%)
create mode 100644 drivers/media/v4l2-core/v4l2-dv-timings.c
rename include/{sound/tea575x-tuner.h => media/tea575x.h} (100%)
create mode 100644 include/media/v4l2-dv-timings.h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v4 1/1] [media] blackfin: add video display device driver
Hi Scott,
Sorry for the delayed review. Please ping me you don't see a reply from me
within a
week. I normally process patches on Monday and/or Friday, so you can keep that
in mind
when you decide it's time for a ping.
Thanks for posting the v4l2-compliance output. It looks like this is tested on
a 3.5
kernel, is that correct?
I also see that you are using an older v4l2-compliance version, please use the
latest version from v4l-utils.git.
On 07/19/2013 09:27 PM, Scott Jiang wrote:
> This is a V4L2 driver for Blackfin video display (E)PPI interface.
> This module is common for BF537/BF561/BF548/BF609.
>
> Signed-off-by: Scott Jiang
> ---
> drivers/media/platform/blackfin/Kconfig| 15 +-
> drivers/media/platform/blackfin/Makefile |1 +
> drivers/media/platform/blackfin/bfin_display.c | 929
>
> include/media/blackfin/bfin_display.h | 38 +
> 4 files changed, 981 insertions(+), 2 deletions(-)
> create mode 100644 drivers/media/platform/blackfin/bfin_display.c
> create mode 100644 include/media/blackfin/bfin_display.h
>
> diff --git a/drivers/media/platform/blackfin/Kconfig
> b/drivers/media/platform/blackfin/Kconfig
> index cc23997..10aa435 100644
> --- a/drivers/media/platform/blackfin/Kconfig
> +++ b/drivers/media/platform/blackfin/Kconfig
> @@ -9,7 +9,18 @@ config VIDEO_BLACKFIN_CAPTURE
> To compile this driver as a module, choose M here: the
> module will be called bfin_capture.
>
> +config VIDEO_BLACKFIN_DISPLAY
> + tristate "Blackfin Video Display Driver"
> + depends on VIDEO_V4L2 && BLACKFIN && I2C
> + select VIDEOBUF2_DMA_CONTIG
> + help
> + V4L2 driver for Blackfin video display (E)PPI interface.
> + This module is common for BF537/BF561/BF548/BF609.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called bfin_display.
> +
> config VIDEO_BLACKFIN_PPI
> tristate
> - depends on VIDEO_BLACKFIN_CAPTURE
> - default VIDEO_BLACKFIN_CAPTURE
> + depends on VIDEO_BLACKFIN_CAPTURE || VIDEO_BLACKFIN_DISPLAY
> + default VIDEO_BLACKFIN_CAPTURE || VIDEO_BLACKFIN_DISPLAY
> diff --git a/drivers/media/platform/blackfin/Makefile
> b/drivers/media/platform/blackfin/Makefile
> index 30421bc..015c8f0 100644
> --- a/drivers/media/platform/blackfin/Makefile
> +++ b/drivers/media/platform/blackfin/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_VIDEO_BLACKFIN_CAPTURE) += bfin_capture.o
> +obj-$(CONFIG_VIDEO_BLACKFIN_DISPLAY) += bfin_display.o
> obj-$(CONFIG_VIDEO_BLACKFIN_PPI) += ppi.o
> diff --git a/drivers/media/platform/blackfin/bfin_display.c
> b/drivers/media/platform/blackfin/bfin_display.c
> new file mode 100644
> index 000..a1e00c0
> --- /dev/null
> +++ b/drivers/media/platform/blackfin/bfin_display.c
> @@ -0,0 +1,929 @@
> +/*
> + * Analog Devices video display driver for (E)PPI interface
> + *
> + * Copyright (c) 2011 - 2013 Analog Devices Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +
> +#define DISPLAY_DRV_NAME"bfin_display"
> +#define DISP_MIN_NUM_BUF2
> +
> +struct bfin_disp_format {
> + char *desc;
> + u32 pixelformat;
> + enum v4l2_mbus_pixelcode mbus_code;
> + int bpp; /* bits per pixel */
> + int dlen; /* data length for ppi in bits */
> +};
> +
> +struct bfin_disp_buffer {
> + struct vb2_buffer vb;
> + struct list_head list;
> +};
> +
> +struct bfin_disp_device {
> + /* display device instance */
> + struct v4l2_device v4l2_dev;
> + /* v4l2 control handler */
> + struct v4l2_ctrl_handler ctrl_handler;
> + /* device node data */
> + struct video_device video_dev;
> + /* sub device instance */
> + struct v4l2_subdev *sd;
> + /* display config */
> + struct bfin_display_config *cfg;
> + /* ppi interface */
> + struct ppi_if *ppi;
> + /* current output */
> + unsigned int cur_output;
> + /* current selected standard */
> + v4l2_std_id std;
> + /* current selected dv_timings */
> + s
Re: [git:v4l-utils/master] qv4l2: add aspect ratio support
Hi. Bad news. While rebasing my cropping support branch I noticed that Hans has merged in the wrong patch series for the scaling. The one Hans have merged is one of our internal revisions, as only v1 is present on the mailing list. I sent out a full patch series on Tuesday that consists of 9 parts, wheras the part you have merged is only 7 (from YUY2 shader to aspect ratio). B. -- 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] v4l2-ctrl: fix setting volatile controls
The V4L2 specification allows setting volatile controls as that is needed
if you want to be able to set all controls in one go using VIDIOC_S_EXT_CTRLS.
However, such new values should be ignored by the control framework
since it makes no sense to set a volatile control. While the new value
will be ignored anyway, it does generate a bogus 'change value' control event
that should be suppressed.
This patch changes the code to skip setting volatile controls, except for
one particular case where an autocluster switches to manual mode, because
that causes the volatile controls to become non-volatile, so the new
specified values should be retained.
Note that the values returned by VIDIOC_S_CTRL and VIDIOC_S_EXT_CTRLS for
such skipped volatile controls will be the currently cached values and not
the latest volatile value. This is something that might have to be fixed
as well in the future should that be necessary. I think it is overkill,
though.
Signed-off-by: Hans Verkuil
Cc: pa...@osciak.com
---
drivers/media/v4l2-core/v4l2-ctrls.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index fccd08b..a7cd830 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2592,6 +2592,7 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct
v4l2_ctrl_handler *hdl,
cs->error_idx = cs->count;
for (i = 0; !ret && i < cs->count; i++) {
struct v4l2_ctrl *master;
+ bool set_volatiles = false;
u32 idx = i;
if (helpers[i].mref == NULL)
@@ -2627,14 +2628,24 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct
v4l2_ctrl_handler *hdl,
} while (tmp_idx);
/* If the new value == the manual value, then copy
the current volatile values. */
- if (new_auto_val == master->manual_mode_value)
+ if (new_auto_val == master->manual_mode_value) {
update_from_auto_cluster(master);
+ set_volatiles = true;
+ }
}
/* Copy the new caller-supplied control values.
user_to_new() sets 'is_new' to 1. */
do {
- ret = user_to_new(cs->controls + idx,
helpers[idx].ctrl);
+ /*
+* Skip attempts to set volatile controls since those
are
+* ignored anyway. The exception is when an autocluster
is
+* switched to manual mode, since in that case the
specified
+* 'volatile' controls are actually the new manual
+* non-volatile values.
+*/
+ if (set_volatiles || !(helpers[idx].ctrl->flags &
V4L2_CTRL_FLAG_VOLATILE))
+ ret = user_to_new(cs->controls + idx,
helpers[idx].ctrl);
idx = helpers[idx].next;
} while (!ret && idx);
@@ -2697,6 +2708,9 @@ static int set_ctrl(struct v4l2_fh *fh, struct v4l2_ctrl
*ctrl,
if (ctrl->type == V4L2_CTRL_TYPE_STRING)
return -EINVAL;
+ if (ctrl->flags & V4L2_CTRL_FLAG_VOLATILE)
+ return 0;
+
/* Reset the 'is_new' flags of the cluster */
for (i = 0; i < master->ncontrols; i++)
if (master->cluster[i])
--
1.8.4.rc1
--
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 v4 0/3] saa7115: Implement i2c_board_info.platform_data
On 08/03/2013 03:19 PM, Jon Arne Jørgensen wrote: > This patch set adds handling of the i2c_board_info struct to the saa7115 > driver. > The main goal of this patch is to give the different devices with the gm7113c > chip an opportunity to configure the chip to their needs. > > I've only implemented the overrides I know are necessary to get the stk1160 > and the smi2021 drivers to work. > > This is the forth version of this patch series. > There are only minor changes since version 3 of this patch series. > I've mostly just changed some comments, and removed some debug statements > in the last patch in the series. > > The third version of the RFC was posted on 2013/7/4 and can be found here: > http://lkml.indiana.edu/hypermail/linux/kernel/1307.0/01931.html > > The second version of the RFC was posted on 2013/5/31 and can be found here: > http://lkml.indiana.edu/hypermail/linux/kernel/1305.3/03747.html > > The first version of the RFC can be found here: > https://lkml.org/lkml/2013/5/29/558 > > Jon Arne Jørgensen (3): > saa7115: Fix saa711x_set_v4lstd for gm7113c > saa7115: Do not load saa7115_init_misc for gm7113c > saa7115: Implement i2c_board_info.platform_data > > drivers/media/i2c/saa7115.c | 167 > +++ > drivers/media/i2c/saa711x_regs.h | 19 + > include/media/saa7115.h | 64 +++ > 3 files changed, 216 insertions(+), 34 deletions(-) > For this patch series: Reviewed-by: Hans Verkuil I'll merge this Monday at the latest. Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
