[PATCH] [media] sh_mobile_ceu_camera: remove deprecated IRQF_DISABLED

[Michael Opdenacker]

This patch proposes to remove the use of the IRQF_DISABLED flag

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com
---
 drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c 
b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
index 8df22f7..150bd4d 100644
--- a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
+++ b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
@@ -1800,7 +1800,7 @@ static int sh_mobile_ceu_probe(struct platform_device 
*pdev)
 
/* request irq */
err = devm_request_irq(pdev-dev, pcdev-irq, sh_mobile_ceu_irq,
-  IRQF_DISABLED, dev_name(pdev-dev), pcdev);
+  0, dev_name(pdev-dev), pcdev);
if (err) {
dev_err(pdev-dev, Unable to register CEU interrupt.\n);
goto exit_release_mem;
-- 
1.8.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] radio-si4713: remove deprecated IRQF_DISABLED

[Michael Opdenacker]

This patch proposes to remove the use of the IRQF_DISABLED flag

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com
---
 drivers/media/radio/si4713-i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/radio/si4713-i2c.c b/drivers/media/radio/si4713-i2c.c
index fe16088..9ec48cc 100644
--- a/drivers/media/radio/si4713-i2c.c
+++ b/drivers/media/radio/si4713-i2c.c
@@ -1456,7 +1456,7 @@ static int si4713_probe(struct i2c_client *client,
 
if (client-irq) {
rval = request_irq(client-irq,
-   si4713_handler, IRQF_TRIGGER_FALLING | IRQF_DISABLED,
+   si4713_handler, IRQF_TRIGGER_FALLING,
client-name, sdev);
if (rval  0) {
v4l2_err(sdev-sd, Could not request IRQ\n);
-- 
1.8.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] ir-rx51: remove deprecated IRQF_DISABLED

[Michael Opdenacker]

This patch proposes to remove the use of the IRQF_DISABLED flag

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com
---
 drivers/media/rc/ir-rx51.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 31b955b..b1e19a2 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -201,8 +201,7 @@ static int lirc_rx51_init_port(struct lirc_rx51 *lirc_rx51)
 
lirc_rx51-irq_num = omap_dm_timer_get_irq(lirc_rx51-pulse_timer);
retval = request_irq(lirc_rx51-irq_num, lirc_rx51_interrupt_handler,
-IRQF_DISABLED | IRQF_SHARED,
-lirc_pulse_timer, lirc_rx51);
+IRQF_SHARED, lirc_pulse_timer, lirc_rx51);
if (retval) {
dev_err(lirc_rx51-dev, : Failed to request interrupt line\n);
goto err2;
-- 
1.8.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] winbond-cir: remove deprecated IRQF_DISABLED

[Michael Opdenacker]

This patch proposes to remove the use of the IRQF_DISABLED flag

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com
---
 drivers/media/rc/winbond-cir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 98bd496..904baf4 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1110,7 +1110,7 @@ wbcir_probe(struct pnp_dev *device, const struct 
pnp_device_id *dev_id)
}
 
err = request_irq(data-irq, wbcir_irq_handler,
- IRQF_DISABLED, DRVNAME, device);
+ 0, DRVNAME, device);
if (err) {
dev_err(dev, Failed to claim IRQ %u\n, data-irq);
err = -EBUSY;
-- 
1.8.1.2

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/2] V4L2 API for exposing flash subdevs as LED class device

[Sakari Ailus]

Hi Bryan,

On Thu, Oct 10, 2013 at 05:07:22PM -0700, Bryan Wu wrote:
 On Tue, May 21, 2013 at 3:54 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
  Hi Andrzej,
 
  On Tue, May 21, 2013 at 10:34:53AM +0200, Andrzej Hajda wrote:
  On 12.05.2013 23:12, Sakari Ailus wrote:
   On Wed, May 08, 2013 at 09:32:17AM +0200, Andrzej Hajda wrote:
   On 07.05.2013 17:07, Laurent Pinchart wrote:
   On Tuesday 07 May 2013 02:11:27 Kim, Milo wrote:
   On Monday, May 06, 2013 6:34 PM Andrzej Hajda wrote:
   This RFC proposes generic API for exposing flash subdevices via LED
   framework.
  
   Rationale
  
   Currently there are two frameworks which are used for exposing LED
   flash to user space:
   - V4L2 flash controls,
   - LED framework(with custom sysfs attributes).
  
   The list below shows flash drivers in mainline kernel with initial
   commit date and typical chip application (according to producer):
  
   LED API:
   lm3642: 2012-09-12, Cameras
   lm355x: 2012-09-05, Cameras
   max8997: 2011-12-14, Cameras (?)
   lp3944: 2009-06-19, Cameras, Lights, Indicators, Toys
   pca955x: 2008-07-16, Cameras, Indicators (?)
  
   V4L2 API:
   as3645a:  2011-05-05, Cameras
   adp1653: 2011-05-05, Cameras
  
   V4L2 provides richest functionality, but there is often demand from
   application developers to provide already established LED API. We 
   would
   like to have an unified user interface for flash devices. Some of 
   devices
   already have the LED API driver exposing limited set of a Flash IC
   functionality. In order to support all required features the LED API
   would have to be extended or the V4L2 API would need to be used. 
   However
   when switching from a LED to a V4L2 Flash driver existing LED API
   interface would need to be retained.
  
   Proposed solution
  
   This patch adds V4L2 helper functions to register existing V4L2 flash
   subdev as LED class device. After registration via 
   v4l2_leddev_register
   appropriate entry in /sys/class/leds/ is created. During 
   registration all
   V4L2 flash controls are enumerated and corresponding attributes are 
   added.
  
   I have attached also patch with new max77693-led driver using 
   v4l2_leddev.
   This patch requires presence of the patch max77693: added device 
   tree
   support: https://patchwork.kernel.org/patch/2414351/ .
  
   Additional features
  
   - simple API to access all V4L2 flash controls via sysfs,
   - V4L2 subdevice should not be registered by V4L2 device to use it,
   - LED triggers API can be used to control the device,
   - LED device is optional - it will be created only if V4L2_LEDDEV
 configuration option is enabled and the subdev driver calls
 v4l2_leddev_register.
  
   Doubts
  
   This RFC is a result of a uncertainty which API developers should 
   expose
   by their flash drivers. It is a try to gluing together both APIs. I 
   am not
   sure if it is the best solution, but I hope there will be some 
   discussion
   and hopefully some decisions will be taken which way we should 
   follow.
   The LED subsystem provides similar APIs for the Camera driver.
   With LED trigger event, flash and torch are enabled/disabled.
   I'm not sure this is applicable for you.
   Could you take a look at LED camera trigger feature?
  
   For the camera LED trigger,
   https://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/
   ?h=f or-nextid=48a1d032c954b9b06c3adbf35ef4735dd70ab757
  
   Example of camera flash driver,
   https://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/
   ?h=f or-nextid=313bf0b1a0eaeaac17ea8c4b748f16e28fce8b7a
   I think we should decide on one API. Implementing two APIs for a 
   single device
   is usually messy, and will result in different feature sets (and 
   different
   bugs) being implemented through each API, depending on the driver.
   Interactions between the APIs are also a pain point on the kernel side 
   to
   properly synchronize calls.
   I don't like having two APIs either. Especially we shouldn't have 
   multiple
   drivers implementing different APIs for the same device.
  
   That said, I wonder if it's possible to support camera-related use cases
   using the LED API: it's originally designed for quite different devices.
   Even if you could handle flash strobing using the LED API, the 
   functionality
   provided by the Media controller and subdev APIs will always be missing:
   device enumeration and association with the right camera.
  Is there a generic way to associate flash and camera subdevs in
  current V4L2 API? The only ways I see now are:
  - both belongs to the same media controller, but this is not enough if 
  there
  is more than one camera subdev in that controller,
 
  Yes, there is. That's the group_id field in struct media_entity_desc. The
  lens subdev is associated to the rest of the devices the same way.
 
  - using media links/pads - at first sight it seems to be 

Re: [RFC v3] [RFC] v4l2: Support for multiple selections

[Ricardo Ribalda Delgado]

Ping?

Any comment about this version? Shall I post a new one with the
modified device drivers?

Thanks!

On Tue, Oct 1, 2013 at 12:33 PM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
 Extend v4l2 selection API to support multiple selection areas, this way
 sensors that support multiple readout areas can work with multiple areas
 of insterest.

 The struct v4l2_selection and v4l2_subdev_selection has been extented
 with a new field rectangles. If it is value is different than zero the
 pr array is used instead of the r field.

 A new structure v4l2_ext_rect has been defined, containing 4 reserved
 fields for future improvements, as suggested by Hans.

 Two helper functiona are also added, to help the drivers that support
 a single selection.

 This Patch ONLY adds the modification to the core. Once it is agreed, a
 new version including changes on the drivers that handle the selection
 api will come.

 This patch includes all the comments by Hans Verkuil.

 Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
 ---
 v3:
 -Changes on compat-ioctl32
 -Remove checks on v4l2_selection_set_rect

  drivers/media/v4l2-core/v4l2-common.c | 36 +++
  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 63 
 +++
  drivers/media/v4l2-core/v4l2-ioctl.c  | 37 +---
  include/media/v4l2-common.h   |  6 +++
  include/uapi/linux/v4l2-subdev.h  | 10 -
  include/uapi/linux/videodev2.h| 21 +++--
  6 files changed, 162 insertions(+), 11 deletions(-)

 diff --git a/drivers/media/v4l2-core/v4l2-common.c 
 b/drivers/media/v4l2-core/v4l2-common.c
 index a95e5e2..f60a2ce 100644
 --- a/drivers/media/v4l2-core/v4l2-common.c
 +++ b/drivers/media/v4l2-core/v4l2-common.c
 @@ -886,3 +886,39 @@ void v4l2_get_timestamp(struct timeval *tv)
 tv-tv_usec = ts.tv_nsec / NSEC_PER_USEC;
  }
  EXPORT_SYMBOL_GPL(v4l2_get_timestamp);
 +
 +int v4l2_selection_get_rect(const struct v4l2_selection *s,
 +   struct v4l2_ext_rect *r)
 +{
 +   if (s-rectangles  1)
 +   return -EINVAL;
 +   if (s-rectangles == 1) {
 +   *r = s-pr[0];
 +   return 0;
 +   }
 +   if (s-r.width  0 || s-r.height  0)
 +   return -EINVAL;
 +   r-left = s-r.left;
 +   r-top = s-r.top;
 +   r-width = s-r.width;
 +   r-height = s-r.height;
 +   memset(r-reserved, 0, sizeof(r-reserved));
 +   return 0;
 +}
 +EXPORT_SYMBOL_GPL(v4l2_selection_get_rect);
 +
 +void v4l2_selection_set_rect(struct v4l2_selection *s,
 +   const struct v4l2_ext_rect *r)
 +{
 +   if (s-rectangles == 0) {
 +   s-r.left = r-left;
 +   s-r.top = r-top;
 +   s-r.width = r-width;
 +   s-r.height = r-height;
 +   return;
 +   }
 +   s-pr[0] = *r;
 +   s-rectangles = 1;
 +   return;
 +}
 +EXPORT_SYMBOL_GPL(v4l2_selection_set_rect);
 diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
 b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
 index 8f7a6a4..36ed3c3 100644
 --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
 +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
 @@ -777,6 +777,54 @@ static int put_v4l2_subdev_edid32(struct 
 v4l2_subdev_edid *kp, struct v4l2_subde
 return 0;
  }

 +struct v4l2_selection32 {
 +   __u32   type;
 +   __u32   target;
 +   __u32   flags;
 +   union {
 +   struct v4l2_rectr;
 +   compat_uptr_t   *pr;
 +   };
 +   __u32   rectangles;
 +   __u32   reserved[8];
 +} __packed;
 +
 +static int get_v4l2_selection32(struct v4l2_selection *kp,
 +   struct v4l2_selection32 __user *up)
 +{
 +   if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_selection32))
 +   || (copy_from_user(kp, up, sizeof(*kp
 +   return -EFAULT;
 +
 +   if (kp-rectangles) {
 +   compat_uptr_t usr_ptr;
 +   if (get_user(usr_ptr, up-pr))
 +   return -EFAULT;
 +   kp-pr = compat_ptr(usr_ptr);
 +   }
 +
 +   return 0;
 +
 +}
 +
 +static int put_v4l2_selection32(struct v4l2_selection *kp,
 +   struct v4l2_selection32 __user *up)
 +{
 +   compat_uptr_t usr_ptr = 0;
 +
 +   if ((kp-rectangles)  get_user(usr_ptr, up-pr))
 +   return -EFAULT;
 +
 +   if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_selection32))
 +   || (copy_to_user(kp, up, sizeof(*kp
 +   return -EFAULT;
 +
 +   if (kp-rectangles)
 +   put_user(usr_ptr, up-pr);
 +
 +   return 0;
 +
 +}

  #define VIDIOC_G_FMT32 _IOWR('V',  4, struct v4l2_format32)
  #define 

[PATCH] media/i2c: ths8200: fix build failure with gcc 4.5.4

[Russell King - ARM Linux]

v3.12-rc fails to build with this error:

drivers/media/i2c/ths8200.c:49:2: error: unknown field 'bt' specified in 
initializer
drivers/media/i2c/ths8200.c:50:3: error: field name not in record or union 
initializer
drivers/media/i2c/ths8200.c:50:3: error: (near initialization for 
'ths8200_timings_cap.reserved')
drivers/media/i2c/ths8200.c:51:3: error: field name not in record or union 
initializer
drivers/media/i2c/ths8200.c:51:3: error: (near initialization for 
'ths8200_timings_cap.reserved')
...

with gcc 4.5.4.  This error was not detected in builds prior to v3.12-rc.
This patch fixes this.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/media/i2c/ths8200.c |   18 +++---
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c
index a58a8f6..5ae2a4f 100644
--- a/drivers/media/i2c/ths8200.c
+++ b/drivers/media/i2c/ths8200.c
@@ -46,13 +46,17 @@ struct ths8200_state {
 
 static const struct v4l2_dv_timings_cap ths8200_timings_cap = {
.type = V4L2_DV_BT_656_1120,
-   .bt = {
-   .max_width = 1920,
-   .max_height = 1080,
-   .min_pixelclock = 2500,
-   .max_pixelclock = 14850,
-   .standards = V4L2_DV_BT_STD_CEA861,
-   .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE,
+   /* Allow gcc 4.5.4 to build this */
+   .reserved = { },
+   {
+   .bt = {
+   .max_width = 1920,
+   .max_height = 1080,
+   .min_pixelclock = 2500,
+   .max_pixelclock = 14850,
+   .standards = V4L2_DV_BT_STD_CEA861,
+   .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE,
+   },
},
 };
 

--
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

exynos4: index out of bounds if no pixelcode found

[Roel Kluin]

In case no valid pixelcode is found, an i of -1 after the loop is out of 
bounds for the array.

Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/drivers/media/platform/exynos4-is/fimc-lite-reg.c 
b/drivers/media/platform/exynos4-is/fimc-lite-reg.c
index 72a343e3b..d0dc7ee 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite-reg.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite-reg.c
@@ -133,7 +133,7 @@ void flite_hw_set_source_format(struct fimc_lite *dev, 
struct flite_frame *f)
int i = ARRAY_SIZE(src_pixfmt_map);
u32 cfg;
 
-   while (--i = 0) {
+   while (--i) {
if (src_pixfmt_map[i][0] == pixelcode)
break;
}
@@ -240,7 +240,7 @@ static void flite_hw_set_out_order(struct fimc_lite 
*dev, struct flite_frame *f)
u32 cfg = readl(dev-regs + FLITE_REG_CIODMAFMT);
int i = ARRAY_SIZE(pixcode);
 
-   while (--i = 0)
+   while (--i)
if (pixcode[i][0] == f-fmt-mbus_code)
break;
cfg = ~FLITE_REG_CIODMAFMT_YCBCR_ORDER_MASK;

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media/i2c: ths8200: fix build failure with gcc 4.5.4

[Gianluca Gennari]

Il 13/10/2013 12:13, Russell King - ARM Linux ha scritto:
 v3.12-rc fails to build with this error:
 
 drivers/media/i2c/ths8200.c:49:2: error: unknown field 'bt' specified in 
 initializer
 drivers/media/i2c/ths8200.c:50:3: error: field name not in record or union 
 initializer
 drivers/media/i2c/ths8200.c:50:3: error: (near initialization for 
 'ths8200_timings_cap.reserved')
 drivers/media/i2c/ths8200.c:51:3: error: field name not in record or union 
 initializer
 drivers/media/i2c/ths8200.c:51:3: error: (near initialization for 
 'ths8200_timings_cap.reserved')
 ...
 
 with gcc 4.5.4.  This error was not detected in builds prior to v3.12-rc.
 This patch fixes this.

Hi Russel,
this error is already fixed by this patch:

https://patchwork.linuxtv.org/patch/20002/

that has been already accepted and is queued for kernel 3.12.

Regards,
Gianluca

 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 ---
  drivers/media/i2c/ths8200.c |   18 +++---
  1 files changed, 11 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c
 index a58a8f6..5ae2a4f 100644
 --- a/drivers/media/i2c/ths8200.c
 +++ b/drivers/media/i2c/ths8200.c
 @@ -46,13 +46,17 @@ struct ths8200_state {
  
  static const struct v4l2_dv_timings_cap ths8200_timings_cap = {
   .type = V4L2_DV_BT_656_1120,
 - .bt = {
 - .max_width = 1920,
 - .max_height = 1080,
 - .min_pixelclock = 2500,
 - .max_pixelclock = 14850,
 - .standards = V4L2_DV_BT_STD_CEA861,
 - .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE,
 + /* Allow gcc 4.5.4 to build this */
 + .reserved = { },
 + {
 + .bt = {
 + .max_width = 1920,
 + .max_height = 1080,
 + .min_pixelclock = 2500,
 + .max_pixelclock = 14850,
 + .standards = V4L2_DV_BT_STD_CEA861,
 + .capabilities = V4L2_DV_BT_CAP_PROGRESSIVE,
 + },
   },
  };
  
 
 --
 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

[PATCH v2.1 1/4] media: Add pad flag MEDIA_PAD_FL_MUST_CONNECT

[Sakari Ailus]

Pads that set this flag must be connected by an active link for the entity
to stream.

Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 Documentation/DocBook/media/v4l/media-ioc-enum-links.xml |   10 ++
 include/uapi/linux/media.h   |1 +
 2 files changed, 11 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml 
b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
index 355df43..e357dc9 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
@@ -134,6 +134,16 @@
entryOutput pad, relative to the entity. Output pads source data
and are origins of links./entry
  /row
+ row
+   entryconstantMEDIA_PAD_FL_MUST_CONNECT/constant/entry
+   entryIf this flag is set and the pad is linked to any other
+   pad, then at least one of those links must be enabled for the
+   entity to be able to stream. There could be temporary reasons
+   (e.g. device configuration dependent) for the pad to need
+   enabled links even when this flag isn't set; the absence of the
+   flag doesn't imply there is none. The flag has no effect on pads
+   without connected links./entry
+ /row
/tbody
   /tgroup
 /table
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index ed49574..d847c76 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -98,6 +98,7 @@ struct media_entity_desc {
 
 #define MEDIA_PAD_FL_SINK  (1  0)
 #define MEDIA_PAD_FL_SOURCE(1  1)
+#define MEDIA_PAD_FL_MUST_CONNECT  (1  2)
 
 struct media_pad_desc {
__u32 entity;   /* entity ID */
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2.1 2/4] media: Check for active links on pads with MEDIA_PAD_FL_MUST_CONNECT flag

[Sakari Ailus]

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 sakari.ai...@iki.fi
Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Since v2:

- Change Sylwester's e-mail address

 .../DocBook/media/v4l/media-ioc-enum-links.xml |3 +-
 drivers/media/media-entity.c   |   41 
 2 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml 
b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
index e357dc9..cf85485 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
@@ -141,8 +141,7 @@
entity to be able to stream. There could be temporary reasons
(e.g. device configuration dependent) for the pad to need
enabled links even when this flag isn't set; the absence of the
-   flag doesn't imply there is none. The flag has no effect on pads
-   without connected links./entry
+   flag doesn't imply there is none./entry
  /row
/tbody
   /tgroup
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 2c286c3..37c334e 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -235,6 +235,8 @@ __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);
+   DECLARE_BITMAP(has_no_links, entity-num_pads);
unsigned int i;
 
entity-stream_count++;
@@ -248,21 +250,46 @@ __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);
+   bitmap_fill(has_no_links, 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;
+
+   /* Mark that a pad is connected by a link. */
+   bitmap_clear(has_no_links, pad-index, 1);
+
+   /*
+* 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;
}
+
+   /* Either no links or validated links are fine. */
+   bitmap_or(active, active, has_no_links, entity-num_pads);
+
+   if (!bitmap_full(active, entity-num_pads)) {
+   ret = -EPIPE;
+   goto error;
+   }
}
 
mutex_unlock(mdev-graph_mutex);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2.1 1/4] media: Add pad flag MEDIA_PAD_FL_MUST_CONNECT

[Sakari Ailus]

On Sun, Oct 13, 2013 at 01:58:43PM +0300, Sakari Ailus wrote:
 Pads that set this flag must be connected by an active link for the entity
 to stream.

Oh --- btw. what has changed since v2:

- Rmoved the last sentence of MEDIA_PAD_FL_MUST_CONNECT documentation. The
  sentence was about the flag having no effect on pads w/o links.

- Change Sylwester's e-mail address

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: exynos4: index out of bounds if no pixelcode found

[Sylwester Nawrocki]

Hi Roel,

On 10/13/2013 12:16 PM, Roel Kluin wrote:

In case no valid pixelcode is found, an i of -1 after the loop is out of
bounds for the array.

Signed-off-by: Roel Kluinroel.kl...@gmail.com


Thank you for the fix, I have applied this patch to my tree for 3.13.
However it seems to be mangled (at least line wrapped) and didn't
apply cleanly. The patchwork also didn't catch it properly:
https://patchwork.linuxtv.org/patch/20380/

I'd suggest using git send-email in future.

Thanks,
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] media/i2c: ths8200: fix build failure with gcc 4.5.4

[Russell King - ARM Linux]

On Sun, Oct 13, 2013 at 12:36:07PM +0200, Gianluca Gennari wrote:
 Il 13/10/2013 12:13, Russell King - ARM Linux ha scritto:
  v3.12-rc fails to build with this error:
  
  drivers/media/i2c/ths8200.c:49:2: error: unknown field 'bt' specified in 
  initializer
  drivers/media/i2c/ths8200.c:50:3: error: field name not in record or union 
  initializer
  drivers/media/i2c/ths8200.c:50:3: error: (near initialization for 
  'ths8200_timings_cap.reserved')
  drivers/media/i2c/ths8200.c:51:3: error: field name not in record or union 
  initializer
  drivers/media/i2c/ths8200.c:51:3: error: (near initialization for 
  'ths8200_timings_cap.reserved')
  ...
  
  with gcc 4.5.4.  This error was not detected in builds prior to v3.12-rc.
  This patch fixes this.
 
 Hi Russel,
 this error is already fixed by this patch:
 
 https://patchwork.linuxtv.org/patch/20002/
 
 that has been already accepted and is queued for kernel 3.12.

It would be a good idea to have the comment updated - given that gcc 4.5.4
also has a problem, it's not only a problem for gcc  4.4.6 as that patch
claims.
--
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: ivtv 1.4.2/1.4.3 broken in recent kernels?

[Andy Walls]

On Sat, 2013-10-12 at 19:23 -0400, Andy Walls wrote:
 On Thu, 2013-10-10 at 22:00 +0100, Rajil Saraswat wrote:
  On 10 October 2013 03:20, Andy Walls awa...@md.metrocast.net wrote:
   On Wed, 2013-09-18 at 02:19 +0530, Rajil Saraswat wrote:
   Hi,
  
I have a couple of PVR-500's which have additional tuners connected
   to them (using daughter cards).
  
   The PVR-500's don't have daughter cards with additional tuners AFAIK.
  
   There is this however:
   http://www.hauppauge.com/site/webstore2/webstore_avcable-pci.asp
  
[snip]
  
The audio is not usable on either
   1.4.2 or 1.4.3 ivtv drivers. The issue is described at
   http://ivtvdriver.org/pipermail/ivtv-users/2013-September/010462.html
  
   With your previous working kernel and with the non-working kernel, what
   is the output of
  
   $ v4l2-ctl -d /dev/videoX --log-status
  
   after you have set up the inputs properly and have a known good signal
   going into the input in question?
  
   I'm speculating this is a problem with the cx25840 driver or the wm8775
   driver, since they change more often than the ivtv driver.
  
  Yes, thats right it is a set of extra inputs and not a separate tuner
  card. I played a video stream fro both kernels. Here are the logs
  
  Working kernel 2.6.35
   v4l2-ctl -d /dev/video1 --log-status
  
  Status Log:
  
 [50885.487963] ivtv1: =  START STATUS CARD #1
  =
 [50885.487967] ivtv1: Version: 1.4.1 Card: WinTV PVR 500 (unit #2)
 [snip]
 [50885.545429] cx25840 2-0044: Video signal:  present
 [50885.545431] cx25840 2-0044: Detected format:   PAL-BDGHI
 [50885.545433] cx25840 2-0044: Specified standard:PAL-BDGHI
 [50885.545435] cx25840 2-0044: Specified video input: Composite 4
 [50885.545437] cx25840 2-0044: Specified audioclock freq: 48000 Hz
 [snip]
 [50885.553121] ivtv1: ==  END STATUS CARD #1
  ==
  
  For the non-working kernel 2.6.37
  
 [  212.730996] ivtv1: =  START STATUS  =
 [  212.731001] ivtv1: Version: 1.4.3 Card: WinTV PVR 500 (unit #2)
 [snip]
 [  212.787820] cx25840 2-0044: Video signal:  present
 [  212.787822] cx25840 2-0044: Detected format:   PAL-BDGHI
 [  212.787823] cx25840 2-0044: Specified standard:PAL-BDGHI
 [  212.787824] cx25840 2-0044: Specified video input: Composite 4
 [snip]
 
 Hmm.  I have a PVR-500, with the extra input cable hooked up to unit #2
 of the PVR-500 and a DTV-to-CVBS converter box connected.
 
 My CVBS signal shows up when I am set to PVR-500  'Input 2, Composite 1'
 which is cx25840 'Composite 3'.  This makes sense for unit #2 of a
 PVR-500. It must have the white connector wired differently from unit #1
 of the PVR-500 (and from the PVR-150), since the PVR-500 unit #2 doesn't
 have a CVBS input connector on the main card.
 
 Are you sure you have the input like this and obtain good video from
 PVR-500 unit #2, when it is set to 'Input 4, Composite 2', cx25840
 'Composite 4'?
 
 Could you try recording with PVR unit #2 set to 'Input 2, Composite 1',
 cx25840 'Composite 3'?  
 
 These are the questions in my mind:
 
 Is your PVR-500 unit #2 wired differently than mine?
 Are the older kernels more forgiving when capturing audio with the wrong
 input set? (Try both Input 2 and Input 4 with both kernels.)


OK, I just tested with my Wii game console connected to the PVR-500 unit
#2, Fedora 17, kernel 3.6.10-2.fc17.x86_64.

1. With the unit set to 'Input 2, Composite 1', cx25840 'Composite 3':
Good video, good audio

2. With the unit set to 'Input 4, Composite 2', cx25840 'Composite 4':
No video, distorted audio.

AFAICT:
You're using the wrong input.
You weren't checking the video, only the audio.

I consider this problem resolved.


  Unfortunately, i cannot do a git bisect since it is a remote system
  with a slow internet connection.

Is this system for personal or professional use?  I don't know of any
home users who have remote sites.

If for professional use, I'd suggest your employer pay a consultant, if
the company/university/whatever can't do a git bisect on a development
system in house.

-Andy

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media/i2c: ths8200: fix build failure with gcc 4.5.4

[Gianluca Gennari]

Il 13/10/2013 13:16, Russell King - ARM Linux ha scritto:
 On Sun, Oct 13, 2013 at 12:36:07PM +0200, Gianluca Gennari wrote:
 Il 13/10/2013 12:13, Russell King - ARM Linux ha scritto:
 v3.12-rc fails to build with this error:

 drivers/media/i2c/ths8200.c:49:2: error: unknown field 'bt' specified in 
 initializer
 drivers/media/i2c/ths8200.c:50:3: error: field name not in record or union 
 initializer
 drivers/media/i2c/ths8200.c:50:3: error: (near initialization for 
 'ths8200_timings_cap.reserved')
 drivers/media/i2c/ths8200.c:51:3: error: field name not in record or union 
 initializer
 drivers/media/i2c/ths8200.c:51:3: error: (near initialization for 
 'ths8200_timings_cap.reserved')
 ...

 with gcc 4.5.4.  This error was not detected in builds prior to v3.12-rc.
 This patch fixes this.

 Hi Russel,
 this error is already fixed by this patch:

 https://patchwork.linuxtv.org/patch/20002/

 that has been already accepted and is queued for kernel 3.12.
 
 It would be a good idea to have the comment updated - given that gcc 4.5.4
 also has a problem, it's not only a problem for gcc  4.4.6 as that patch
 claims.
 

Yep, the fact is that there are 2 different compatibility problems:
- gcc  4.4.6 requires additional curly brackets to initialize anonymous
structs (see v4l2-dv-timings.h);
- some gcc version requires that structure members are initialized in
the same order they are defined, even if you specify the member name;

The second issue is the one you are facing, but I don't know how to
track it down to a specific gcc version. If you can get the exact
version number and provide a patch, you're welcome!

Regards,
Gianluca
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media/i2c: ths8200: fix build failure with gcc 4.5.4

[Russell King - ARM Linux]

On Sun, Oct 13, 2013 at 02:55:49PM +0200, Gianluca Gennari wrote:
 Il 13/10/2013 13:16, Russell King - ARM Linux ha scritto:
  On Sun, Oct 13, 2013 at 12:36:07PM +0200, Gianluca Gennari wrote:
  Il 13/10/2013 12:13, Russell King - ARM Linux ha scritto:
  v3.12-rc fails to build with this error:
 
  drivers/media/i2c/ths8200.c:49:2: error: unknown field 'bt' specified in 
  initializer
  drivers/media/i2c/ths8200.c:50:3: error: field name not in record or 
  union initializer
  drivers/media/i2c/ths8200.c:50:3: error: (near initialization for 
  'ths8200_timings_cap.reserved')
  drivers/media/i2c/ths8200.c:51:3: error: field name not in record or 
  union initializer
  drivers/media/i2c/ths8200.c:51:3: error: (near initialization for 
  'ths8200_timings_cap.reserved')
  ...
 
  with gcc 4.5.4.  This error was not detected in builds prior to v3.12-rc.
  This patch fixes this.
 
  Hi Russel,
  this error is already fixed by this patch:
 
  https://patchwork.linuxtv.org/patch/20002/
 
  that has been already accepted and is queued for kernel 3.12.
  
  It would be a good idea to have the comment updated - given that gcc 4.5.4
  also has a problem, it's not only a problem for gcc  4.4.6 as that patch
  claims.
  
 
 Yep, the fact is that there are 2 different compatibility problems:
 - gcc  4.4.6 requires additional curly brackets to initialize anonymous
 structs (see v4l2-dv-timings.h);

gcc 4.5.4 also requires that - merely adding the initializer for
.reserved doesn't fix it on this gcc version (it continues to
complain about unknown field 'bt').

 - some gcc version requires that structure members are initialized in
 the same order they are defined, even if you specify the member name;
 
 The second issue is the one you are facing, but I don't know how to
 track it down to a specific gcc version. If you can get the exact
 version number and provide a patch, you're welcome!

The exact version number is gcc 4.5.4.  It's the released 4.5.4 version
built straight from the FSF's gcc-core-4.5.4.tar.bz2.
--
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

Possible race condition on videobuf2?

[Ricardo Ribalda Delgado]

Hello

These days I have been testing an app that uses the old read/write
API. It is interfacing a videobuf2-sg driver.

Once in a while I get an oops on the vb2_perform_fileio function.

After digging a while I have been able to fix the bug like this:

int vb2_fop_release(struct file *file)
 {
  struct video_device *vdev = video_devdata(file);
+ struct mutex *lock = vdev-queue-lock ? vdev-queue-lock : vdev-lock;

+ if (lock)
+ mutex_lock(lock);
  if (file-private_data == vdev-queue-owner) {
  vb2_queue_release(vdev-queue);
  vdev-queue-owner = NULL;
  }
+ if (lock)
+ mutex_unlock(lock);
  return v4l2_fh_release(file);
 }
 EXPORT_SYMBOL_GPL(vb2_fop_release);

(or at least, I havent seen the oops since then).

I was wondering if this a real bug on vb2 and I shall post a proper
patch or the device driver is doing something out of spec.

vb2_perform_fileio+0x372 corresponds to

  memset(fileio-b, 0, sizeof(fileio-b));

My theory is that:

fileio = q-fileio;
if (!fileio){
...
q-fileio = NULL;

can be prone to race conditions if the lock is not held on release.


[ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
0260
[ 308.297759] IP: [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.297794] PGD 159719067 PUD 158119067 PMD 0
[ 308.297812] Oops:  #1 SMP
[ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
spi_xilinx spi_bitbang qt5023
[ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
[ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
PM_2.1.0.309 X64 05/23/2013
[ 308.297952] task: 8801564e1690 ti: 88014dc02000 task.ti:
88014dc02000
[ 308.297962] RIP: 0010:[a07a9fd2] [a07a9fd2]
vb2_perform_fileio+0x372/0x610 [videobuf2_core]
[ 308.297985] RSP: 0018:88014dc03df8 EFLAGS: 00010202
[ 308.297995] RAX:  RBX: 880158a23000 RCX: dead00100100
[ 308.298003] RDX:  RSI: dead00200200 RDI: 
[ 308.298012] RBP: 88014dc03e58 R08:  R09: 0001
[ 308.298020] R10: ea00051e8380 R11: 88014dc03fd8 R12: 880158a23070
[ 308.298029] R13: 8801549040b8 R14: 00198000 R15: 01887e60
[ 308.298040] FS: 7f65130d5700() GS:88015ed0()
knlGS:
[ 308.298049] CS: 0010 DS:  ES:  CR0: 80050033
[ 308.298057] CR2: 0260 CR3: 00015963 CR4: 07e0
[ 308.298064] Stack:
[ 308.298071] 880156416c00 00198000 
88010001
[ 308.298087] 88014dc03f50 810a79ca 00020001
880154904718
[ 308.298101] 880156416c00 00198000 880154904338
88014dc03f50
[ 308.298116] Call Trace:
[ 308.298143] [a07aa3c4] vb2_read+0x14/0x20 [videobuf2_core]
[ 308.298198] [a07aa494] vb2_fop_read+0xc4/0x120 [videobuf2_core]
[ 308.298252] [8154ee9e] v4l2_read+0x7e/0xc0
[ 308.298296] [8116e639] vfs_read+0xa9/0x160
[ 308.298312] [8116e882] SyS_read+0x52/0xb0
[ 308.298328] [81784179] tracesys+0xd0/0xd5
[ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
44 c5 48 8b 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
89
[ 308.298487] RIP [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.298507] RSP 88014dc03df8
[ 308.298514] CR2: 0260
[ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
-- 
Ricardo Ribalda
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx + ov2640 and v4l2-clk

[Frank Schäfer]

[snip]

Am 12.10.2013 05:45, schrieb Mauro Carvalho Chehab:

 Changing the input will likely power on the device. The design of the
 old suspend callback were to call it when the device is not being used.
 Any try to use the device makes it to wake up, as it makes no sense to
 use a device in standby state.

 Also, changing the power states is a requirement, when switching the
 mode between analog, digital TV (or capture without tuner - although I
 think em28xx will turn the analog tuner on in this case, even not being
 required).

 The patches that just rename the previous standby callback to s_power 
 callback did a crap job, as it didn't consider the nuances of the API
 used on that time nor they didn't change the drivers to move the GPIO
 bits into s_power().

 Looking with today's view, it would likely be better if those patches
 were just adding a power callback without touching the standby callback.

The main problem is, that since commit 622b828ab7 (v4l2_subdev: rename
tuner s_standby operation to core s_power) all subdevices are powered
down, not only the tuners.
But other subdevices may not wake up automatically when needed, so this
commit should also have introduced (s_power, 1) calls.
At least for em28xx it seems that this din't cause any regressions up to
now, because none of the subdevs used by this driver did anything
essential in its s_power callbacks (most of them don't support it at all).
But it's of course a ticking bomb.
The introduction of v4l2-clk enabling/disabling in the sensor subdevs'
(soc_cameras') s_power callbacks now let this bomb in em28xx explode.
This time, it only caused scary warnings/traces, but it could be
non-working (never waking up) devices next time.

 I suspect that the solution would be to fork s_power into two different
 callbacks: one asymetric to just put the device into suspend mode (as
 before), and another symmetric one, where the device needs to be explicitly
 enabled before its usage and disabled at suspend or driver exit.


Or, if we want to keep the API as is, we have to introduce (s_power, 1)
calls in the affected drivers to avoid regressions due to future subdev
changes.

Regards,
Frank

--
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: Possible race condition on videobuf2?

[Hans Verkuil]

Hi Ricardo,

On 10/13/2013 03:03 PM, Ricardo Ribalda Delgado wrote:
 Hello
 
 These days I have been testing an app that uses the old read/write
 API. It is interfacing a videobuf2-sg driver.
 
 Once in a while I get an oops on the vb2_perform_fileio function.
 
 After digging a while I have been able to fix the bug like this:
 
 int vb2_fop_release(struct file *file)
  {
   struct video_device *vdev = video_devdata(file);
 + struct mutex *lock = vdev-queue-lock ? vdev-queue-lock : vdev-lock;
 
 + if (lock)
 + mutex_lock(lock);
   if (file-private_data == vdev-queue-owner) {
   vb2_queue_release(vdev-queue);
   vdev-queue-owner = NULL;
   }
 + if (lock)
 + mutex_unlock(lock);
   return v4l2_fh_release(file);
  }
  EXPORT_SYMBOL_GPL(vb2_fop_release);
 
 (or at least, I havent seen the oops since then).
 
 I was wondering if this a real bug on vb2 and I shall post a proper
 patch or the device driver is doing something out of spec.
 
 vb2_perform_fileio+0x372 corresponds to
 
   memset(fileio-b, 0, sizeof(fileio-b));
 
 My theory is that:
 
 fileio = q-fileio;
 if (!fileio){
 ...
 q-fileio = NULL;
 
 can be prone to race conditions if the lock is not held on release.

This would not surprise me.

I have a number of vb2 patches in this branch:

http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/vb2-thread

Among others it replaces the 'q-fileio = NULL' hack by a proper solution.

It will be interesting to see if my patch series in that branch would fix your
problem as well.

That said, I do think vb2_fop_release should take the lock regardless, although
I would put the mutex_lock inside the 'if' that checks the owner.

Regards,

Hans

 
 
 [ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
 0260
 [ 308.297759] IP: [a07a9fd2] vb2_perform_fileio+0x372/0x610
 [videobuf2_core]
 [ 308.297794] PGD 159719067 PUD 158119067 PMD 0
 [ 308.297812] Oops:  #1 SMP
 [ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
 qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
 qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
 spi_xilinx spi_bitbang qt5023
 [ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
 [ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
 PM_2.1.0.309 X64 05/23/2013
 [ 308.297952] task: 8801564e1690 ti: 88014dc02000 task.ti:
 88014dc02000
 [ 308.297962] RIP: 0010:[a07a9fd2] [a07a9fd2]
 vb2_perform_fileio+0x372/0x610 [videobuf2_core]
 [ 308.297985] RSP: 0018:88014dc03df8 EFLAGS: 00010202
 [ 308.297995] RAX:  RBX: 880158a23000 RCX: 
 dead00100100
 [ 308.298003] RDX:  RSI: dead00200200 RDI: 
 
 [ 308.298012] RBP: 88014dc03e58 R08:  R09: 
 0001
 [ 308.298020] R10: ea00051e8380 R11: 88014dc03fd8 R12: 
 880158a23070
 [ 308.298029] R13: 8801549040b8 R14: 00198000 R15: 
 01887e60
 [ 308.298040] FS: 7f65130d5700() GS:88015ed0()
 knlGS:
 [ 308.298049] CS: 0010 DS:  ES:  CR0: 80050033
 [ 308.298057] CR2: 0260 CR3: 00015963 CR4: 
 07e0
 [ 308.298064] Stack:
 [ 308.298071] 880156416c00 00198000 
 88010001
 [ 308.298087] 88014dc03f50 810a79ca 00020001
 880154904718
 [ 308.298101] 880156416c00 00198000 880154904338
 88014dc03f50
 [ 308.298116] Call Trace:
 [ 308.298143] [a07aa3c4] vb2_read+0x14/0x20 [videobuf2_core]
 [ 308.298198] [a07aa494] vb2_fop_read+0xc4/0x120 [videobuf2_core]
 [ 308.298252] [8154ee9e] v4l2_read+0x7e/0xc0
 [ 308.298296] [8116e639] vfs_read+0xa9/0x160
 [ 308.298312] [8116e882] SyS_read+0x52/0xb0
 [ 308.298328] [81784179] tracesys+0xd0/0xd5
 [ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
 44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
 44 c5 48 8b 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
 89
 [ 308.298487] RIP [a07a9fd2] vb2_perform_fileio+0x372/0x610
 [videobuf2_core]
 [ 308.298507] RSP 88014dc03df8
 [ 308.298514] CR2: 0260
 [ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
 

--
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: ivtv 1.4.2/1.4.3 broken in recent kernels?

[Rajil Saraswat]

 OK, I just tested with my Wii game console connected to the PVR-500 unit
 #2, Fedora 17, kernel 3.6.10-2.fc17.x86_64.

 1. With the unit set to 'Input 2, Composite 1', cx25840 'Composite 3':
 Good video, good audio

 2. With the unit set to 'Input 4, Composite 2', cx25840 'Composite 4':
 No video, distorted audio.


This is what i used to changed the input

v4l2-ctl -d /dev/video1 --set-input 4

With this 2.6.35 gives me perfect video/audio. Kernel 3.10.7 on the
other hand gives good video but distorted audio. On this cards primary
input (/dev/video0), i use the radio so i cant use input 2 of this
card. My composite cable is connected to the 'extra-input' card which
should be composite 2.

My understanding is input 4 is #2 composite, and input 2 is #1
composite. Is that not right?

This is what i tried in kernel 2.6.35:

1. v4l2-ctl -d /dev/video1 --set-input 2
Video input set to 2 (Composite 1: ok)
No video

2. v4l2-ctl -d /dev/video1 --set-input 4
Video input set to 4 (Composite 2: ok)
Good video

As i mentioned in kernel 2.6.35, mythtv/mplayer give me both good
video/audio if i use 2 above.

 AFAICT:
 You're using the wrong input.
 You weren't checking the video, only the audio.

What inputs do you think i should use with v4l2-ctl?


  Unfortunately, i cannot do a git bisect since it is a remote system
  with a slow internet connection.

 Is this system for personal or professional use?  I don't know of any
 home users who have remote sites.

Your know one user now!. Yes it is for personal use. It was for my old
folks who live in another country and i manage their mythtv/htpc
remotely.

-Rajil
--
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: ivtv 1.4.2/1.4.3 broken in recent kernels?

[Andy Walls]

On Sun, 2013-10-13 at 20:14 +0100, Rajil Saraswat wrote:
  OK, I just tested with my Wii game console connected to the PVR-500 unit
  #2, Fedora 17, kernel 3.6.10-2.fc17.x86_64.
 
  1. With the unit set to 'Input 2, Composite 1', cx25840 'Composite 3':
  Good video, good audio
 
  2. With the unit set to 'Input 4, Composite 2', cx25840 'Composite 4':
  No video, distorted audio.
 
 
 This is what i used to changed the input
 
 v4l2-ctl -d /dev/video1 --set-input 4
 
 With this 2.6.35 gives me perfect video/audio. Kernel 3.10.7 on the
 other hand gives good video but distorted audio. On this cards primary
 input (/dev/video0), i use the radio so i cant use input 2 of this
 card. My composite cable is connected to the 'extra-input' card which
 should be composite 2.
 
 My understanding is input 4 is #2 composite, and input 2 is #1
 composite. Is that not right?

For my PVR-500, it doesn't appear to be.  Here's how I believ it is
wired up:

PVR-500 Left/First half (aka Unit #1)
Tuner TV Composite out  --- CX25843 Analog Input 7--+ 
SVideo 1(rear bracket)  --- CX25843 Analog Inputs 1,5 --+
Composite 1 (rear bracket)  --- CX25843 Analog Input 3--+-- CX25843 
VIP out -- CX23416 VIP In
SVideo 2(white connector)   --- CX25843 Analog Inputs 2,6 --+
Composite 2 (white connector)   --- CX25843 Analog Input 4--+

Tuner SIF audio out   --- CX25843 Analog Input 8
+  

 |  
Tuner TV mono-audio out   --- WM8775 AIN1 L,R --+  
 |  
Audio 1 L,R (rear bracket)--- WM8775 AIN2 L,R --+- WM8775 I2S out -- 
CX25843 I2S 1 In -+- CX25843 I2S out -- CX23416 I2S In
Audio 2 L,R (white connector) --- WM8775 AIN3 L,R --+
Tuner FM audio out L,R--- WM8775 AIN4 L,R --+


PVR-500 Right/Second half (aka Unit #2)
Tuner TV Composite out  --- CX25843 Analog Input 7--+ 
SVideo 1(white connector)   --- CX25843 Analog Inputs 1,5 --+
Composite 1 (white connector)   --- CX25843 Analog Input 3--+-- CX25843 
VIP out -- CX23416 VIP In

Tuner SIF audio out   --- CX25843 Analog Input 8
+  

 |  
Tuner TV mono-audio out   --- WM8775 AIN1 L,R --+  
 |  
Audio 1 L,R (white connector) --- WM8775 AIN2 L,R --+- WM8775 I2S out -- 
CX25843 I2S 1 In -+- CX25843 I2S out -- CX23416 I2S In

So for my PVR-500,
unit #1 Composite 1 is on the card's bracket.
unit #1 Composite 2 is on the white connector.
unit #2 Composite 1 is on the white connector.
unit #2 Composite 2 is not available


 This is what i tried in kernel 2.6.35:
 
 1. v4l2-ctl -d /dev/video1 --set-input 2
 Video input set to 2 (Composite 1: ok)
 No video
 
 2. v4l2-ctl -d /dev/video1 --set-input 4
 Video input set to 4 (Composite 2: ok)
 Good video

If /dev/video1 referes to unit #2 of your PVR-500 (according to v4l2-ctl
-d /dev/video1 --log-status) then it appears your unit is wired
differently than mine.


 As i mentioned in kernel 2.6.35, mythtv/mplayer give me both good
 video/audio if i use 2 above.

$ git diff --color v2.6.35 v2.6.37 drivers/media/video/wm8775.c

Shows me no really good reason why the wm8775 driver should have broken.

$ git diff --color v2.6.35 v2.6.37 drivers/media/video/cx25840/*[ch]

Show a few conceptually simple changes to the cx25840 driver.  Something
may have broken, but I doubt it.

$ git diff --color v2.6.35 v2.6.37 drivers/media/video/cx2341x.c

Shows changes to the control handling.  The ones regarding audio
sampling frequency may be at fault.

$ git diff --color v2.6.35 v2.6.37 drivers/media/video/ivtv/ivtv*[ch]

Shows changes to the irq handling and the control handling.  Again the
controls realted to audio mode and audio sampling rate stand out as
potential causes.

None of the above changes would explain to me why audio on input 3 of
the WM8775 works (for me) but audio on input 4 of the WM8775 does not
work (for you).

I'll have to try additional tests with unit #1 of my PVR-500 later this
week.

  AFAICT:
  You're using the wrong input.
  You weren't checking the video, only the audio.
 
 What inputs do you think i should use with v4l2-ctl?

I have no recommendation at the moment.

If you can do a git bisect please try.
There are 11,117 commits to bisect: that's 15 steps.  Each
bisect/compile/install/test iteration I would estimate takes about 2
hours.

If I can reproduce your problem on a PVR-150 or on unit #1 of my
PVR-500, then I can try to bisect.  But I have no idea when I would have
time to perform the bisection.


   Unfortunately, i cannot do a git bisect since it is a remote system
   with a slow internet connection.
 
  Is this system for personal or professional use?  I don't know of any
  home users who have remote sites.
 
 Your know one 

cannot ret error from probe - switch tuner to I2C driver model

[Antti Palosaari]

kernel: usb 1-2: rtl2832u_tuner_attach:
kernel: e4000 5-0064: e4000_probe:
kernel: usb 1-2: rtl2832u_tuner_attach: client ptr 88030a849000

See attached patch.

Is there any way to return error to caller?

Abuse platform data ptr from struct i2c_board_info and call 
i2c_unregister_device() ?

regards
Antti

---
 drivers/media/tuners/e4000.c| 31 +++
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 18 --
 2 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index 54e2d8a..f4e0567 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -442,6 +442,37 @@ err:
 }
 EXPORT_SYMBOL(e4000_attach);
 
+static int e4000_probe(struct i2c_client *client, const struct i2c_device_id 
*did)
+{
+   dev_info(client-dev, %s:\n, __func__);
+   return -ENODEV;
+}
+
+static int e4000_remove(struct i2c_client *client)
+{
+   dev_info(client-dev, %s:\n, __func__);
+   return 0;
+}
+
+static const struct i2c_device_id e4000_id[] = {
+   {e4000, 0},
+   {}
+};
+
+MODULE_DEVICE_TABLE(i2c, e4000_id);
+
+static struct i2c_driver e4000_driver = {
+   .driver = {
+   .owner  = THIS_MODULE,
+   .name   = e4000,
+   },
+   .probe  = e4000_probe,
+   .remove = e4000_remove,
+   .id_table   = e4000_id,
+};
+
+module_i2c_driver(e4000_driver);
+
 MODULE_DESCRIPTION(Elonics E4000 silicon tuner driver);
 MODULE_AUTHOR(Antti Palosaari cr...@iki.fi);
 MODULE_LICENSE(GPL);
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index defc491..fbbe867 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -898,8 +898,22 @@ static int rtl2832u_tuner_attach(struct dvb_usb_adapter 
*adap)
adap-fe[0]-ops.tuner_ops.get_rf_strength;
return 0;
case TUNER_RTL2832_E4000:
-   fe = dvb_attach(e4000_attach, adap-fe[0], d-i2c_adap,
-   rtl2832u_e4000_config);
+// fe = dvb_attach(e4000_attach, adap-fe[0], d-i2c_adap,
+// rtl2832u_e4000_config);
+   {
+   static const struct i2c_board_info info = {
+   .type = e4000,
+   .addr = 0x64,
+   };
+   struct i2c_client *client;
+
+   fe = NULL;
+   client = i2c_new_device(d-i2c_adap, info);
+   if (IS_ERR_OR_NULL(client))
+   dev_err(d-udev-dev, e4000 probe failed\n);
+
+   dev_dbg(d-udev-dev, %s: client ptr %p\n, __func__, 
client);
+   }
break;
case TUNER_RTL2832_FC2580:
fe = dvb_attach(fc2580_attach, adap-fe[0], d-i2c_adap,
-- 
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

Re: cannot ret error from probe - switch tuner to I2C driver model

[Antti Palosaari]

On 14.10.2013 03:10, Antti Palosaari wrote:

kernel: usb 1-2: rtl2832u_tuner_attach:
kernel: e4000 5-0064: e4000_probe:
kernel: usb 1-2: rtl2832u_tuner_attach: client ptr 88030a849000

See attached patch.

Is there any way to return error to caller?

Abuse platform data ptr from struct i2c_board_info and call 
i2c_unregister_device() ?


Answer to myself: best option seems to be check i2c_get_clientdata() 
pointer after i2c_new_device().


client = i2c_new_device(d-i2c_adap, info);
if (client)
if (i2c_get_clientdata(client) == NULL)
// OOPS, I2C probe fails

That is because it is set NULL in error case by really_probe() in 
drivers/base/dd.c. Error status is also cleared there with comment:

/*
 * Ignore errors returned by -probe so that the next driver can try
 * its luck.
 */

That is told in I2C documentation too:
Note that starting with kernel 2.6.34, you don't have to set the `data' 
field

to NULL in remove() or if probe() failed anymore. The i2c-core does this
automatically on these occasions. Those are also the only times the core 
will

touch this field.



But maybe the comment for actual function, i2c_new_device, is still a 
bit misleading as it says NULL is returned for the error. All the other 
errors yes, but not for the I2C .probe() as it is reseted by device core.


* This returns the new i2c client, which may be saved for later use with
 * i2c_unregister_device(); or NULL to indicate an error.
 */
struct i2c_client *
i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)


regards
Antti




regards
Antti

---
  drivers/media/tuners/e4000.c| 31 +++
  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 18 --
  2 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index 54e2d8a..f4e0567 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -442,6 +442,37 @@ err:
  }
  EXPORT_SYMBOL(e4000_attach);

+static int e4000_probe(struct i2c_client *client, const struct i2c_device_id 
*did)
+{
+   dev_info(client-dev, %s:\n, __func__);
+   return -ENODEV;
+}
+
+static int e4000_remove(struct i2c_client *client)
+{
+   dev_info(client-dev, %s:\n, __func__);
+   return 0;
+}
+
+static const struct i2c_device_id e4000_id[] = {
+   {e4000, 0},
+   {}
+};
+
+MODULE_DEVICE_TABLE(i2c, e4000_id);
+
+static struct i2c_driver e4000_driver = {
+   .driver = {
+   .owner  = THIS_MODULE,
+   .name   = e4000,
+   },
+   .probe  = e4000_probe,
+   .remove = e4000_remove,
+   .id_table   = e4000_id,
+};
+
+module_i2c_driver(e4000_driver);
+
  MODULE_DESCRIPTION(Elonics E4000 silicon tuner driver);
  MODULE_AUTHOR(Antti Palosaari cr...@iki.fi);
  MODULE_LICENSE(GPL);
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index defc491..fbbe867 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -898,8 +898,22 @@ static int rtl2832u_tuner_attach(struct dvb_usb_adapter 
*adap)
adap-fe[0]-ops.tuner_ops.get_rf_strength;
return 0;
case TUNER_RTL2832_E4000:
-   fe = dvb_attach(e4000_attach, adap-fe[0], d-i2c_adap,
-   rtl2832u_e4000_config);
+// fe = dvb_attach(e4000_attach, adap-fe[0], d-i2c_adap,
+// rtl2832u_e4000_config);
+   {
+   static const struct i2c_board_info info = {
+   .type = e4000,
+   .addr = 0x64,
+   };
+   struct i2c_client *client;
+
+   fe = NULL;
+   client = i2c_new_device(d-i2c_adap, info);
+   if (IS_ERR_OR_NULL(client))
+   dev_err(d-udev-dev, e4000 probe failed\n);
+
+   dev_dbg(d-udev-dev, %s: client ptr %p\n, __func__, 
client);
+   }
break;
case TUNER_RTL2832_FC2580:
fe = dvb_attach(fc2580_attach, adap-fe[0], d-i2c_adap,




--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

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 Oct 14 04:00:14 CEST 2013
git branch: test
git hash:   d10e8280c4c2513d3e7350c27d8e6f0fa03a5f71
gcc version:i686-linux-gcc (GCC) 4.8.1
sparse version: 0.4.5-rc1
host hardware:  x86_64
host os:3.11-4.slh.2-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.31.14-i686: OK
linux-2.6.32.27-i686: OK
linux-2.6.33.7-i686: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12-rc1-i686: OK
linux-2.6.31.14-x86_64: OK
linux-2.6.32.27-x86_64: OK
linux-2.6.33.7-x86_64: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse version: 0.4.5-rc1
sparse: ERRORS

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/media.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] s5p-jpeg: fix uninitialized use in hdr parse

[Seung-Woo Kim]

Hi Sylwester,

Thanks for you comment.

On 2013년 10월 12일 18:39, Sylwester Nawrocki wrote:
 Hi Seung-Woo,
 
 On 10/10/2013 09:06 AM, Seung-Woo Kim wrote:
 For hdr parse error, it can return false without any assignments
 which cause build warning.

 Signed-off-by: Seung-Woo Kimsw0312@samsung.com
 ---
   drivers/media/platform/s5p-jpeg/jpeg-core.c |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
 b/drivers/media/platform/s5p-jpeg/jpeg-core.c
 index 15d2396..7db374e 100644
 --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
 +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
 @@ -442,14 +442,14 @@ static bool s5p_jpeg_parse_hdr(struct
 s5p_jpeg_q_data *result,
   while (notfound) {
   c = get_byte(jpeg_buffer);
   if (c == -1)
 -break;
 +return false;
 
 notfound is being assigned before entering the while loop, so I'm not sure
 what exactly is not correct here. Can you quote the original build
 warning ?

Here is the build warning.

drivers/media/platform/s5p-jpeg/jpeg-core.c: In function
's5p_jpeg_parse_hdr':
drivers/media/platform/s5p-jpeg/jpeg-core.c:432: warning: 'components'
may be used uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'height' may
be used uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'width' may be
used uninitialized in this function

 It's a good idea to always include compiler errors/warnings in the commit
 message.

Right, I'll repost with warning message.

 
 BTW, name of the variable is a bit confusing, I think naming it 'found' and
 using negation of it would be easier to follow; that's not something we'd
 be changing now though.
 
   if (c != 0xff)
   continue;
   do
   c = get_byte(jpeg_buffer);
   while (c == 0xff);
   if (c == -1)
 -break;
 +return false;
   if (c == 0)
   continue;
   length = 0;
 
 Thanks,
 Sylwester
 

-- 
Seung-Woo Kim
Samsung Software RD Center
--

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] s5p-jpeg: fix uninitialized use in hdr parse

[Seung-Woo Kim]

For hdr parse error, it can return false without any assignments
which cause following build warning.

drivers/media/platform/s5p-jpeg/jpeg-core.c: In function 's5p_jpeg_parse_hdr':
drivers/media/platform/s5p-jpeg/jpeg-core.c:432: warning: 'components' may be 
used uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'height' may be used 
uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'width' may be used 
uninitialized in this function

Signed-off-by: Seung-Woo Kim sw0312@samsung.com
---
change from v1
- add build warning to commit message
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 15d2396..7db374e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -442,14 +442,14 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data 
*result,
while (notfound) {
c = get_byte(jpeg_buffer);
if (c == -1)
-   break;
+   return false;
if (c != 0xff)
continue;
do
c = get_byte(jpeg_buffer);
while (c == 0xff);
if (c == -1)
-   break;
+   return false;
if (c == 0)
continue;
length = 0;
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html