[SUSPECTED SPAM] Can you be our Supplier
Dear Sir/Madam, I am Becca MacKenzie, We are interested in your products and want to make you and your company our major suppliers but first we would like your to send us your best price list and Catalog if possible. We will be ordering in large quantity so we are looking forward in making a good relationship with you and your company. My contact email: becca.mackenzie...@outlook.com Regards Becca MacKenzie
Re: [PATCH v4 12/21] camss: vfe: Format conversion support using PIX interface
Hi Todor,
On Tue, Aug 8, 2017 at 3:30 PM, Todor Tomov wrote:
> Use VFE PIX input interface and do format conversion in VFE.
>
> Supported input format is UYVY (single plane YUV 4:2:2) and
> its different sample order variations.
>
> Supported output formats are:
> - NV12/NV21 (two plane YUV 4:2:0)
> - NV16/NV61 (two plane YUV 4:2:2)
>
> Signed-off-by: Todor Tomov
This is now commit 9b5833f7b82f1431 upstream.
> @@ -355,6 +471,38 @@ static void vfe_bus_disconnect_wm_from_rdi(struct
> vfe_device *vfe, u8 wm,
> vfe_reg_clr(vfe, VFE_0_BUS_XBAR_CFG_x(wm), reg);
> }
>
> +static void vfe_set_xbar_cfg(struct vfe_device *vfe, struct vfe_output
> *output,
> +u8 enable)
> +{
> + struct vfe_line *line = container_of(output, struct vfe_line, output);
> + u32 p = line->video_out.active_fmt.fmt.pix_mp.pixelformat;
> + u32 reg;
With gcc 4.1.2:
drivers/media/platform/qcom/camss-8x16/camss-vfe.c: In function
‘vfe_set_xbar_cfg’:
drivers/media/platform/qcom/camss-8x16/camss-vfe.c:614: warning:
‘reg’ may be used uninitialized in this function
This is a false positive, as output->wm_num is always either 1 or 2, hence the
index i can never have a value different from 0 or 1, and reg is thus always
initialized.
> + unsigned int i;
> +
> + for (i = 0; i < output->wm_num; i++) {
> + if (i == 0) {
> + reg = VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_LUMA <<
> +
> VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_SHIFT;
> + } else if (i == 1) {
> + reg = VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_EN;
> + if (p == V4L2_PIX_FMT_NV12 || p == V4L2_PIX_FMT_NV16)
> + reg |=
> VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_SWAP_INTER_INTRA;
> + }
> @@ -458,6 +728,10 @@ static void vfe_init_outputs(struct vfe_device *vfe)
> output->buf[0] = NULL;
> output->buf[1] = NULL;
> INIT_LIST_HEAD(&output->pending_bufs);
> +
> + output->wm_num = 1;
> + if (vfe->line[i].id == VFE_LINE_PIX)
> + output->wm_num = 2;
> }
> }
>
> --- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.h
> +++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.h
> @@ -30,8 +30,9 @@
> #define MSM_VFE_PAD_SRC 1
> #define MSM_VFE_PADS_NUM 2
>
> -#define MSM_VFE_LINE_NUM 3
> +#define MSM_VFE_LINE_NUM 4
> #define MSM_VFE_IMAGE_MASTERS_NUM 7
> +#define MSM_VFE_COMPOSITE_IRQ_NUM 4
>
> #define MSM_VFE_VFE0_UB_SIZE 1023
> #define MSM_VFE_VFE0_UB_SIZE_RDI (MSM_VFE_VFE0_UB_SIZE / 3)
> @@ -51,11 +52,13 @@ enum vfe_line_id {
> VFE_LINE_NONE = -1,
> VFE_LINE_RDI0 = 0,
> VFE_LINE_RDI1 = 1,
> - VFE_LINE_RDI2 = 2
> + VFE_LINE_RDI2 = 2,
> + VFE_LINE_PIX = 3
> };
>
> struct vfe_output {
> - u8 wm_idx;
> + u8 wm_num;
> + u8 wm_idx[3];
However, wm_idx[] reserves space for 3 entries, while currently only 2 are
needed. Why?
If this is meant to accommodate for a future extension, the false positive
will become a real issue.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[SUSPECTED SPAM] I am a Buyer
Dear Sir/Madam, I am Becca MacKenzie, We are interested in your products and want to make you and your company our major suppliers but first we would like your to send us your best price list and Catalog if possible. We will be ordering in large quantity so we are looking forward in making a good relationship with you and your company. For my quick response write only to my contact email: becca.mackenzie...@outlook.com Regards Becca MacKenzie
[PATCH] staging: atomisp: add a driver for ov5648 camera sensor
The ov5680 5-megapixel camera sensor from OmniVision supports up to 2592x1944
resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer with
10 bits per colour (SGRBG10_1X10).
This patch is a port of ov5680 driver from following
01org/ProductionKernelQuilts patches:
- 0004-ov2680-ov5648-Fork-lift-source-from-CTS.patch
- 0005-ov2680-ov5648-gminification.patch
- 0006-ov5648-Focus-support.patch
- 0007-Fix-resolution-issues-on-rear-camera.patch
- 0008-ov2680-ov5648-Enabled-the-set_exposure-functions.patch
- 0010-IRDA-cameras-mode-list-cleanup-unification.patch
- 0012-ov5648-Add-1296x972-binned-mode.patch
- 0014-ov5648-Adapt-to-Atomisp2-Gmin-VCM-framework.patch
- 0015-dw9714-Gmin-Atomisp-specific-VCM-driver.patch
- 0017-ov5648-Fix-deadlock-on-I2C-error.patch
- 0018-gc2155-Fix-deadlock-on-error.patch
- 0019-ov5648-Add-1280x960-binned-mode.patch
- 0020-ov5648-Make-1280x960-as-default-video-resolution.patch
- 0021-MALATA-Fix-testCameraToSurfaceTextureMetadata-CTS.patch
- 0023-OV5648-Added-5MP-video-resolution.patch
New changes introduced during the port:
- Rename entity types to entity functions
- Replace v4l2_subdev_fh by v4l2_subdev_pad_config
- Make use of media_bus_format enum
- Rename media_entity_init function to media_entity_pads_init
- Replace try_mbus_fmt by set_fmt
- Replace s_mbus_fmt by set_fmt
- Replace g_mbus_fmt by get_fmt
- Use s_ctrl/g_volatile_ctrl instead of ctrl core ops
- Update gmin platform API path
- Update and constify acpi_device_id
- Fix some checkpatch errors and warnings
- Remove FSF's mailing address from the sample GPL notice
I was not able to properly test this patch on my Lenovo Miix 310 due to other
issues with atomisp, the output is the same as ov2680 driver which is very
similar.
Signed-off-by: Devid Antonio Floni
---
drivers/staging/media/atomisp/i2c/Kconfig | 11 +
drivers/staging/media/atomisp/i2c/Makefile |1 +
drivers/staging/media/atomisp/i2c/ov5648.c | 1867
drivers/staging/media/atomisp/i2c/ov5648.h | 835 +
4 files changed, 2714 insertions(+)
create mode 100644 drivers/staging/media/atomisp/i2c/ov5648.c
create mode 100644 drivers/staging/media/atomisp/i2c/ov5648.h
diff --git a/drivers/staging/media/atomisp/i2c/Kconfig
b/drivers/staging/media/atomisp/i2c/Kconfig
index b80d29d..8ed2cf4 100644
--- a/drivers/staging/media/atomisp/i2c/Kconfig
+++ b/drivers/staging/media/atomisp/i2c/Kconfig
@@ -89,6 +89,17 @@ config VIDEO_OV2680
It currently only works with the atomisp driver.
+config VIDEO_OV5648
+ tristate "Omnivision OV5648 sensor support"
+ depends on I2C && VIDEO_V4L2
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the Omnivision
+ OV5648 raw camera.
+
+ ov5648 is a 5M raw sensor.
+
+ It currently only works with the atomisp driver.
+
#
# Kconfig for flash drivers
#
diff --git a/drivers/staging/media/atomisp/i2c/Makefile
b/drivers/staging/media/atomisp/i2c/Makefile
index be13fab..26195d7 100644
--- a/drivers/staging/media/atomisp/i2c/Makefile
+++ b/drivers/staging/media/atomisp/i2c/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_VIDEO_MT9M114)+= mt9m114.o
obj-$(CONFIG_VIDEO_GC2235) += gc2235.o
obj-$(CONFIG_VIDEO_OV2722) += ov2722.o
obj-$(CONFIG_VIDEO_OV2680) += ov2680.o
+obj-$(CONFIG_VIDEO_OV5648) += ov5648.o
obj-$(CONFIG_VIDEO_GC0310) += gc0310.o
obj-$(CONFIG_VIDEO_MSRLIST_HELPER) += libmsrlisthelper.o
diff --git a/drivers/staging/media/atomisp/i2c/ov5648.c
b/drivers/staging/media/atomisp/i2c/ov5648.c
new file mode 100644
index 000..4815a19
--- /dev/null
+++ b/drivers/staging/media/atomisp/i2c/ov5648.c
@@ -0,0 +1,1867 @@
+/*
+ * Support for OmniVision OV5648 5M camera sensor.
+ * Based on OmniVision OV2722 driver.
+ *
+ * Copyright (c) 2013 Intel Corporation. All Rights Reserved.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "../include/linux/atomisp_gmin_platform.h"
+
+#include "ov5648.h"
+
+#define OV5648_DEBUG_EN 0
+
+#define H_FLIP_DEFAULT 1
+#define V_FLIP_DEFAULT 0
+static int h_flag = H_FLIP_DEFAULT;
+static int v_flag = V_FLIP_DEFAULT;
+
+/* i2c read/write stuff */
+static int ov5648_read_reg(struct i2c_client *client,
+ u16 data_length, u16 reg, u16 *val)
+{
+ int err;
+ struct i2c_msg msg[2];
+ unsigned char data[6];
+
+ if (!client->adapter) {
+
[PATCH] build: Added missing functions nsecs_to_jiffies(64)
From: Jasmin Jessich
Several modules expect the functions nsecs_to_jiffies64 and
nsecs_to_jiffies to be available when they get loaded. For Kernels prior
to 3.16, this symbol is not exported in time.c .
Copied the functions to compat.h, so that they get already resolved during
compilation. Define also a macro with a name conversion, because the
mentioned functions are defined as extern in include/linux/jiffies.h,
which gives an error when the are re-defined as static.
Signed-off-by: Jasmin Jessich
---
v4l/compat.h | 37 +
1 file changed, 37 insertions(+)
diff --git a/v4l/compat.h b/v4l/compat.h
index 7a49551..3dedf26 100644
--- a/v4l/compat.h
+++ b/v4l/compat.h
@@ -2118,4 +2118,41 @@ static inline int pm_runtime_get_if_in_use(struct device
*dev)
.subvendor = (subvend), .subdevice = (subdev)
#endif
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 16, 0)
+/*
+ * copied from kernel/time/time.c
+ */
+static inline u64 nsecs_to_jiffies64_static(u64 n)
+{
+#if (NSEC_PER_SEC % HZ) == 0
+/* Common case, HZ = 100, 128, 200, 250, 256, 500, 512, 1000 etc. */
+return div_u64(n, NSEC_PER_SEC / HZ);
+#elif (HZ % 512) == 0
+/* overflow after 292 years if HZ = 1024 */
+return div_u64(n * HZ / 512, NSEC_PER_SEC / 512);
+#else
+/*
+ * Generic case - optimized for cases where HZ is a multiple of 3.
+ * overflow after 64.99 years, exact for HZ = 60, 72, 90, 120 etc.
+ */
+return div_u64(n * 9, (9ull * NSEC_PER_SEC + HZ / 2) / HZ);
+#endif
+}
+
+static inline unsigned long nsecs_to_jiffies_static(u64 n)
+{
+return (unsigned long)nsecs_to_jiffies64_static(n);
+}
+
+/*
+ * linux/jiffies.h defines nsecs_to_jiffies64 and nsecs_to_jiffies
+ * as externals. To get rid of the compiler error, we redefine the
+ * functions to the static variant just defined above.
+ */
+#define nsecs_to_jiffies64(_n) nsecs_to_jiffies64_static(_n)
+#define nsecs_to_jiffies(_n) nsecs_to_jiffies_static(_n)
+
+#endif
+
#endif /* _COMPAT_H */
--
2.7.4
[PATCH] media: i2c: OV5647: ensure clock lane in LP-11 state before streaming on
When I was supporting Rpi Camera Module on the ASUS Tinker board,
I found this driver have some issues with rockchip's mipi-csi driver.
It didn't place clock lane in LP-11 state before performing
D-PHY initialisation.
>From our experience, on some OV sensors,
LP-11 state is not achieved while BIT(5)-0x4800 is cleared.
So let's set BIT(5) and BIT(0) both while not streaming, in order to
coax the clock lane into LP-11 state.
0x4800 : MIPI CTRL 00
BIT(5) : clock lane gate enable
0: continuous
1: none-continuous
BIT(0) : manually set clock lane
0: Not used
1: used
Changes in V2:
modify commit messages
Signed-off-by: Jacob Chen
---
drivers/media/i2c/ov5647.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
index 95ce90f..247302d 100644
--- a/drivers/media/i2c/ov5647.c
+++ b/drivers/media/i2c/ov5647.c
@@ -253,6 +253,10 @@ static int ov5647_stream_on(struct v4l2_subdev *sd)
{
int ret;
+ ret = ov5647_write(sd, 0x4800, 0x04);
+ if (ret < 0)
+ return ret;
+
ret = ov5647_write(sd, 0x4202, 0x00);
if (ret < 0)
return ret;
@@ -264,6 +268,10 @@ static int ov5647_stream_off(struct v4l2_subdev *sd)
{
int ret;
+ ret = ov5647_write(sd, 0x4800, 0x25);
+ if (ret < 0)
+ return ret;
+
ret = ov5647_write(sd, 0x4202, 0x0f);
if (ret < 0)
return ret;
@@ -320,7 +328,10 @@ static int __sensor_init(struct v4l2_subdev *sd)
return ret;
}
- return ov5647_write(sd, 0x4800, 0x04);
+ /*
+* stream off to make the clock lane into LP-11 state.
+*/
+ return ov5647_stream_off(sd);
}
static int ov5647_sensor_power(struct v4l2_subdev *sd, int on)
--
2.7.4
Re: [PATCH] media: i2c: OV5647: gate clock lane before stream on
Hi Luis,
2017-08-07 22:48 GMT+08:00 Luis Oliveira :
> Hi all,
>
> I'm new here, I got to be Maintainer of this driver by the old Maintainer
> recommendation. Still getting the hang of it :)
>
> On 07-Aug-17 13:26, Philipp Zabel wrote:
>> Hi Jacob,
>>
>> On Mon, 2017-08-07 at 19:06 +0800, Jacob Chen wrote:
>> [...]
>> --- a/drivers/media/i2c/ov5647.c
>> +++ b/drivers/media/i2c/ov5647.c
>> @@ -253,6 +253,10 @@ static int ov5647_stream_on(struct v4l2_subdev *sd)
>> {
>> int ret;
>>
>> + ret = ov5647_write(sd, 0x4800, 0x04);
>> + if (ret < 0)
>> + return ret;
>> +
>>
>> So this clears BIT(1) (force clock lane to low power mode) and BIT(5)
>> (gate clock lane while idle) that were set by ov5647_stream_off() during
>> __sensor_init() due to the change below.
>>
>> Is there a reason, btw, that this driver is full of magic register
>> addresses and values? A few #defines would make this a lot more
>> readable.
>>
>
> For what I can see I agree that a few register name setting could be done.
>
>> ret = ov5647_write(sd, 0x4202, 0x00);
>> if (ret < 0)
>> return ret;
>> @@ -264,6 +268,10 @@ static int ov5647_stream_off(struct v4l2_subdev *sd)
>> {
>> int ret;
>>
>> + ret = ov5647_write(sd, 0x4800, 0x25);
>> + if (ret < 0)
>> + return ret;
>> +
>> ret = ov5647_write(sd, 0x4202, 0x0f);
>> if (ret < 0)
>> return ret;
>> @@ -320,7 +328,7 @@ static int __sensor_init(struct v4l2_subdev *sd)
>> return ret;
>> }
>>
>> - return ov5647_write(sd, 0x4800, 0x04);
>> + return ov5647_stream_off(sd);
>>
>> I see now that BIT(2) (keep bus in LP-11 while idle) is and was always
>> set. So the change is that initially, additionally to LP-11 mode, the
>> clock lane is gated and forced into low power mode, as well?
>>
>
> This is my interpretation as well.
>
>> }
>>
>> static int ov5647_sensor_power(struct v4l2_subdev *sd, int on)
>> --
>> 2.7.4
>>
>
> Can anyone comment on it?
>
> I saw there is a same discussion in
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9569031_&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=eMn12aiiNuIDjtRi5xEzC7tWJkpra2vl_XYFVvfxIGE&m=eortcRXje2uLyZNI_-Uw3Ur_z24tb-e4pZfom7WhdE0&s=6sLc76bhjR0IdaA3ArZ7F7slgtcyGz8pDTzAF_CBLno&e=
> There is a comment in i.MX CSI2 driver.
> "
> Configure MIPI Camera Sensor to put all Tx lanes in LP-11 state.
> This must be carried out by the MIPI sensor's s_power(ON) subdev
> op.
> "
> That's what this patch do, sensor driver should make sure that clock
> lanes are in stop state while not streaming.
This is not the same, as far as I can tell. BIT(5) is just clock lane
gating, as you describe above. To put the bus into LP-11 state, BIT(2)
needs to be set.
>>>
>>> Yeah, but i double that clock lane is not in LP11 when continue clock
>>> mode is enabled.
>
> I think by spec it shouldn't got to stopstate in continuous clock.
>
>>
>> If indeed LP-11 state is not achieved while the sensor is idle, as long
>> as BIT(5) is cleared, I think this patch is correct.
>>
>> regards
>> Philipp
>>
>
> As far as I understand, bit[5] set to 1 will force clock lane to be gated (in
> other words it will be forced to be in LP-11 if there are no packets to
> transmit). But also LP-11 must not be achieved with the BIT(5) cleared (free
> running mode)?
>
Yes. When the BIT(5) is cleared, clock lane will be in continuous mode
immediately,
unless BIT(0) is set.
> Sorry if I misunderstood something.
>
> regards,
> Luis
>
Re: [PATCH v2 00/10] media: rc: gpio-ir-recv: driver update
Hi Ladislav, > > > Serie was rebased on top of current linux.git, but something > > > happened there and my userspace decoder no longer works: driver > > > reports completely bogus timing such as (rc-5): > > > ^427, _1342, ^945, _183, ^1128, _671, ^1586, _91, ^1189, _1525, > > > ^1738, _1433, ^915, _1159, ^1464, _1525, ^213, _1067, ^793, _0 > > > (^ used for pulse and _ for space) > > > As it has nothing to do with my changes, I'm sending it anyway > > > for review, which I do not expect to happen until merge window > > > ends. > > > > This means that your patch is anyway untested. > > Previous version is pretty well tested. GPIO IR stopped working > after pulling other changes from linux.git yesterday. And does not > work even without this patch set. I'll try to bisect later as omiting > linux-media merge did not fix it either. OK > > In any case I don't see much use if patch 1/10 as it doesn't > > simplify much, but the rest (from 2 to 10) looks good to me. > > Just look at patch 9 and imagine how it would look without this > change. If you are still unconvinced I'll drop this change. You don't need to, that's just my personal taste and I'm not strong with it. Patch 1 is quite common and not a big deal anyway. If you like it you like you can leave it :) > > P.S. I don't see in this V2 the changelog from V1. Next time, > > please add the changelog. > > It was just a rebase with conflicts resolved. I do not see how > to describe it better than I did. You could write the above (i.e. V2 fixed rebase conflicts :) ). The reason is that as no change is stated, I have to anyway, as reviewer, compare side by side all patches to figure out if there is any difference (even if small) that is not expected. Thanks, Andi
lening bieden nu aanvragen
Groet u GELD BESCHIKBAAR OM TE LENEN. Krijg het geld / de lening die u nodig heeft bij Scotwest Credit Union Limited. Wij zijn particuliere kredietverstrekkers en investeerders en bieden zowel persoonlijke lening, startlening, educatief / agrarisch lening, onroerend goed / bouwlening, vastgoedlening, schuldvrije leningen, mobil home loan, hard money lening, beveiligde / ongedekte lening, investeringsfinanciering, uitbreiding lening, Jv kapitaal / Rehab leningen, Equity / herfinanciering leningen, enz. aan geïnteresseerde personen uit elk land. Wij bieden lening aan personen zowel nationaal als internationaal tegen een lage rente van 3%. Bent u door banken of andere kredietverstrekkers afgewezen, is Scotwest Credit Union Limited hier om u te helpen uw doel te archiveren. Als u een lening van elk type nodig hebt, neem dan contact met ons op via onderstaande e-mailadres en wij staan hier om u te helpen wat u nodig heeft: scot.wes...@gmail.com Uw volledige namen: Adres: Telefoonnummer: Benodigd leningbedrag: Looptijd: Bezetting: Maandelijks Inkomen Niveau: Geslacht: Geboortedatum: Staat: land: Postcode: Doel: Zodra u deze informatie verstrekt, kunnen wij u voorzien van de terugbetaling van de lening op basis van maandelijkse kosten Wij wachten op uw snelle reactie. Dank je. De heer R. Ashley
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: Mon Sep 11 05:00:16 CEST 2017 media-tree git hash:1efdf1776e2253b77413c997bed862410e4b6aaf media_build git hash: bbd9f669f0da6705fe44aff89281c0d6e7bfd73e v4l-utils git hash: 7f937d31ac2af7416c60cd5ff7b5153c85e23d3a gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.12.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-blackfin-bf561: 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.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: WARNINGS linux-3.12.67-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9.26-i686: OK linux-4.10.14-i686: OK linux-4.11-i686: OK linux-4.12.1-i686: OK linux-4.13-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12.67-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: WARNINGS linux-4.9.26-x86_64: WARNINGS linux-4.10.14-x86_64: WARNINGS linux-4.11-x86_64: WARNINGS linux-4.12.1-x86_64: WARNINGS linux-4.13-x86_64: OK apps: WARNINGS spec-git: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCH v4 12/21] camss: vfe: Format conversion support using PIX interface
Hi Geert,
On 10.09.2017 12:58, Geert Uytterhoeven wrote:
> Hi Todor,
>
> On Tue, Aug 8, 2017 at 3:30 PM, Todor Tomov wrote:
>> Use VFE PIX input interface and do format conversion in VFE.
>>
>> Supported input format is UYVY (single plane YUV 4:2:2) and
>> its different sample order variations.
>>
>> Supported output formats are:
>> - NV12/NV21 (two plane YUV 4:2:0)
>> - NV16/NV61 (two plane YUV 4:2:2)
>>
>> Signed-off-by: Todor Tomov
>
> This is now commit 9b5833f7b82f1431 upstream.
>
>> @@ -355,6 +471,38 @@ static void vfe_bus_disconnect_wm_from_rdi(struct
>> vfe_device *vfe, u8 wm,
>> vfe_reg_clr(vfe, VFE_0_BUS_XBAR_CFG_x(wm), reg);
>> }
>>
>> +static void vfe_set_xbar_cfg(struct vfe_device *vfe, struct vfe_output
>> *output,
>> +u8 enable)
>> +{
>> + struct vfe_line *line = container_of(output, struct vfe_line,
>> output);
>> + u32 p = line->video_out.active_fmt.fmt.pix_mp.pixelformat;
>> + u32 reg;
>
> With gcc 4.1.2:
>
> drivers/media/platform/qcom/camss-8x16/camss-vfe.c: In function
> ‘vfe_set_xbar_cfg’:
> drivers/media/platform/qcom/camss-8x16/camss-vfe.c:614: warning:
> ‘reg’ may be used uninitialized in this function
>
> This is a false positive, as output->wm_num is always either 1 or 2, hence the
> index i can never have a value different from 0 or 1, and reg is thus always
> initialized.
>
>> + unsigned int i;
>> +
>> + for (i = 0; i < output->wm_num; i++) {
>> + if (i == 0) {
>> + reg = VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_LUMA
>> <<
>> +
>> VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_SHIFT;
>> + } else if (i == 1) {
>> + reg = VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_EN;
>> + if (p == V4L2_PIX_FMT_NV12 || p == V4L2_PIX_FMT_NV16)
>> + reg |=
>> VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_SWAP_INTER_INTRA;
>> + }
>
>> @@ -458,6 +728,10 @@ static void vfe_init_outputs(struct vfe_device *vfe)
>> output->buf[0] = NULL;
>> output->buf[1] = NULL;
>> INIT_LIST_HEAD(&output->pending_bufs);
>> +
>> + output->wm_num = 1;
>> + if (vfe->line[i].id == VFE_LINE_PIX)
>> + output->wm_num = 2;
>> }
>> }
>>
>
>> --- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.h
>> +++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.h
>> @@ -30,8 +30,9 @@
>> #define MSM_VFE_PAD_SRC 1
>> #define MSM_VFE_PADS_NUM 2
>>
>> -#define MSM_VFE_LINE_NUM 3
>> +#define MSM_VFE_LINE_NUM 4
>> #define MSM_VFE_IMAGE_MASTERS_NUM 7
>> +#define MSM_VFE_COMPOSITE_IRQ_NUM 4
>>
>> #define MSM_VFE_VFE0_UB_SIZE 1023
>> #define MSM_VFE_VFE0_UB_SIZE_RDI (MSM_VFE_VFE0_UB_SIZE / 3)
>> @@ -51,11 +52,13 @@ enum vfe_line_id {
>> VFE_LINE_NONE = -1,
>> VFE_LINE_RDI0 = 0,
>> VFE_LINE_RDI1 = 1,
>> - VFE_LINE_RDI2 = 2
>> + VFE_LINE_RDI2 = 2,
>> + VFE_LINE_PIX = 3
>> };
>>
>> struct vfe_output {
>> - u8 wm_idx;
>> + u8 wm_num;
>> + u8 wm_idx[3];
>
> However, wm_idx[] reserves space for 3 entries, while currently only 2 are
> needed. Why?
>
> If this is meant to accommodate for a future extension, the false positive
> will become a real issue.
The third entry will be needed if we add any three planar pixel format support
to the driver. If this happens this will involve also changes in
vfe_set_xbar_cfg() to support it. It is fine to change wm_idx[3] to wm_idx[2]
until then. However this will not remove the false positive warning. I suppose
it is best to also change vfe_set_xbar_cfg() now so that there is no warning -
init reg to 0 in all cases?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
--
Best regards,
Todor Tomov
