cron job: media_tree daily build: ERRORS

[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:   Sun Jul  9 05:00:16 CEST 2017
media-tree git hash:2748e76ddb2967c4030171342ebdd3faa6a5e8e8
media_build git hash:   bc1db0a204a87da86349ea5e64ae0d65e945609d
v4l-utils git hash: 8e68406dae2233e811032dc8e7714c09c818e893
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
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: 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: 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: ERRORS
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: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
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-rc1-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: ERRORS
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: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
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-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: [PATCH v6 1/3] [media] v4l: add parsed MPEG-2 support

[Nicolas Dufresne]

Le samedi 08 juillet 2017 à 13:16 +0800, ayaka a écrit :
> 
> On 07/08/2017 02:33 AM, Nicolas Dufresne wrote:
> > Le samedi 08 juillet 2017 à 01:29 +0800, ayaka a écrit :
> > > On 07/04/2017 05:29 PM, Hugues FRUCHET wrote:
> > > > Hi Randy,
> > > > Thanks for review, and sorry for late reply, answers inline.
> > > > BR,
> > > > Hugues.
> > > > 
> > > > On 06/11/2017 01:41 PM, ayaka wrote:
> > > > > On 04/28/2017 09:25 PM, Hugues Fruchet wrote:
> > > > > > Add "parsed MPEG-2" pixel format & related controls
> > > > > > needed by stateless video decoders.
> > > > > > In order to decode the video bitstream chunk provided
> > > > > > by user on output queue, stateless decoders require
> > > > > > also some extra data resulting from this video bitstream
> > > > > > chunk parsing.
> > > > > > Those parsed extra data have to be set by user through
> > > > > > control framework using the dedicated mpeg video extended
> > > > > > controls introduced in this patchset.
> > > > > 
> > > > > I have compared those v4l2 controls with the registers of the rockchip
> > > > > video IP.
> > > > > 
> > > > > Most of them are met, but only lacks of sw_init_qp.
> > > > 
> > > > In case of MPEG-1/2, this register seems forced to 1, please double
> > > > check the on2 headers parsing library related to MPEG2. Nevertheless, I
> > > > see this hardware register used with VP8/H264.
> > > 
> > > Yes, it is forced to be 1. We can skip this field for MPEG1/2
> > > > Hence, no need to put this field on MPEG-2 interface, but should come
> > > > with VP8/H264.
> > > > 
> > > > > Here is the full translation table of the registers of the rockchip
> > > > > video IP.
> > > > > 
> > > > > q_scale_type
> > > > > sw_qscale_type
> > > > > concealment_motion_vectorssw_con_mv_e
> > > > > intra_dc_precision  
> > > > > sw_intra_dc_prec
> > > > > intra_vlc_format
> > > > > sw_intra_vlc_tab
> > > > > frame_pred_frame_dct  
> > > > > sw_frame_pred_dct
> > > > > 
> > > > > alternate_scan
> > > > > sw_alt_scan_flag_e
> > > > > 
> > > > > f_code
> > > > > sw_fcode_bwd_ver
> > > > >   
> > > > > 
> > > > > sw_fcode_bwd_hor
> > > > >   
> > > > > 
> > > > > sw_fcode_fwd_ver
> > > > >   
> > > > > 
> > > > > sw_fcode_fwd_hor
> > > > > full_pel_forward_vector  
> > > > > sw_mv_accuracy_fwd
> > > > > full_pel_backward_vector   
> > > > > sw_mv_accuracy_bwd
> > > > > 
> > > > > 
> > > > > I also saw you add two format for parsed MPEG-2/MPEG-1 format, I would
> > > > > not recommand to do that.
> > > > 
> > > > We need to differentiate MPEG-1/MPEG-2, not all the fields are
> > > > applicable depending on version.
> > > 
> > > Usually the MPEG-2 decoder could support MPEG-1, as I know, the syntax
> > > of byte stream of them are the same.
> > > > > That is what google does, because for a few video format and some
> > > > > hardware, they just request a offsets from the original video byte 
> > > > > stream.
> > > > 
> > > > I don't understand your comment, perhaps have you some as a basis of
> > > > discussion ?
> > > 
> > > I mean
> > > 
> > > V4L2-PIX-FMT-MPEG2-PARSED V4L2-PIX-FMT-MPEG1-PARSED I wonder whether you
> > > want use the new format to inform the userspace that this device is for
> > > stateless video decoder, as google defined something like
> > > V4L2_PIX_FMT_H264_SLICE. I think the driver registers some controls is
> > > enough for the userspace to detect whether it is a stateless device. Or
> > > it will increase the work of the userspace(I mean Gstreamer).
> > 
> > Just a note that SLICE has nothing to do with PARSED here. You could
> > have an H264 decoder that is stateless and support handling slices
> > rather then full frames (e.g. V4L2_PIX_FMT_H264_SLICE_PARSED could be
> > valid).
> 
> Actually, they have the same meanings, the H264_SLICE is not a slice, it 
> is an access unit in the rockchip vpu driver for Google.

Let's make sure this never get into mainline unmodified. H264_SLICE
should indicate that encoded buffer need to contains at least one
slice. We already have a format that indicates that a complete AU must
be passed. I do have active project going on where we really want to
pass slice for low latency cases and I would really appreciate if that
name can be used.

> > 
> > I would not worry to much about Gst, as we will likely use this device
> > through the libv4l2 here, hence will only notice the "emulated"
> > V4L2_PIX_FMT_MPEG2 and ignore the _PARSED variant. And without libv4l2,
> > we'd just ignore this driver completely. I doubt we will implement per-
> > device parsing inside Gst itself if it's already done in an external
> > library for us. libv4l2 

Re: [PATCH v2 4/7] [media] ov9650: use write_array() for resolution sequences

[Sakari Ailus]

On Mon, Jul 03, 2017 at 11:16:05AM +0200, Hugues Fruchet wrote:
> Align resolution sequences on initialization sequence using
> i2c_rv structure NULL terminated .This add flexibility
> on resolution sequence size.
> Document resolution related registers by using corresponding
> define instead of hexa address/value.
> 
> Signed-off-by: Hugues Fruchet 
> ---
>  drivers/media/i2c/ov9650.c | 88 
> +++---
>  1 file changed, 59 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
> index 7e9a902..db96698 100644
> --- a/drivers/media/i2c/ov9650.c
> +++ b/drivers/media/i2c/ov9650.c
> @@ -227,11 +227,16 @@ struct ov965x_ctrls {
>   u8 update;
>  };
>  
> +struct i2c_rv {
> + u8 addr;
> + u8 value;
> +};
> +
>  struct ov965x_framesize {
>   u16 width;
>   u16 height;
>   u16 max_exp_lines;
> - const u8 *regs;
> + const struct i2c_rv *regs;
>  };
>  
>  struct ov965x_interval {
> @@ -280,11 +285,6 @@ struct ov965x {
>   u8 apply_frame_fmt;
>  };
>  
> -struct i2c_rv {
> - u8 addr;
> - u8 value;
> -};
> -
>  static const struct i2c_rv ov965x_init_regs[] = {
>   { REG_COM2, 0x10 }, /* Set soft sleep mode */
>   { REG_COM5, 0x00 }, /* System clock options */
> @@ -342,30 +342,59 @@ struct i2c_rv {
>   { REG_NULL, 0 }
>  };
>  
> -#define NUM_FMT_REGS 14
> -/*
> - * COM7,  COM3,  COM4, HSTART, HSTOP, HREF, VSTART, VSTOP, VREF,
> - * EXHCH, EXHCL, ADC,  OCOM,   OFON
> - */
> -static const u8 frame_size_reg_addr[NUM_FMT_REGS] = {
> - 0x12, 0x0c, 0x0d, 0x17, 0x18, 0x32, 0x19, 0x1a, 0x03,
> - 0x2a, 0x2b, 0x37, 0x38, 0x39,
> -};
> -
> -static const u8 ov965x_sxga_regs[NUM_FMT_REGS] = {
> - 0x00, 0x00, 0x00, 0x1e, 0xbe, 0xbf, 0x01, 0x81, 0x12,
> - 0x10, 0x34, 0x81, 0x93, 0x51,
> +static const struct i2c_rv ov965x_sxga_regs[] = {
> + { REG_COM7, 0x00 },
> + { REG_COM3, 0x00 },
> + { REG_COM4, 0x00 },
> + { REG_HSTART, 0x1e },
> + { REG_HSTOP, 0xbe },
> + { 0x32, 0xbf },
> + { REG_VSTART, 0x01 },
> + { REG_VSTOP, 0x81 },
> + { REG_VREF, 0x12 },
> + { REG_EXHCH, 0x10 },
> + { REG_EXHCL, 0x34 },
> + { REG_ADC, 0x81 },
> + { REG_ACOM, 0x93 },
> + { REG_OFON, 0x51 },
> + { REG_NULL, 0 },
>  };
>  
> -static const u8 ov965x_vga_regs[NUM_FMT_REGS] = {
> - 0x40, 0x04, 0x80, 0x26, 0xc6, 0xed, 0x01, 0x3d, 0x00,
> - 0x10, 0x40, 0x91, 0x12, 0x43,
> +static const struct i2c_rv ov965x_vga_regs[] = {
> + { REG_COM7, 0x40 },
> + { REG_COM3, 0x04 },
> + { REG_COM4, 0x80 },
> + { REG_HSTART, 0x26 },
> + { REG_HSTOP, 0xc6 },
> + { 0x32, 0xed },
> + { REG_VSTART, 0x01 },
> + { REG_VSTOP, 0x3d },
> + { REG_VREF, 0x00 },
> + { REG_EXHCH, 0x10 },
> + { REG_EXHCL, 0x40 },
> + { REG_ADC, 0x91 },
> + { REG_ACOM, 0x12 },
> + { REG_OFON, 0x43 },
> + { REG_NULL, 0 },
>  };
>  
>  /* Determined empirically. */
> -static const u8 ov965x_qvga_regs[NUM_FMT_REGS] = {
> - 0x10, 0x04, 0x80, 0x25, 0xc5, 0xbf, 0x00, 0x80, 0x12,
> - 0x10, 0x40, 0x91, 0x12, 0x43,
> +static const struct i2c_rv ov965x_qvga_regs[] = {
> + { REG_COM7, 0x10 },
> + { REG_COM3, 0x04 },
> + { REG_COM4, 0x80 },
> + { REG_HSTART, 0x25 },
> + { REG_HSTOP, 0xc5 },
> + { 0x32, 0xbf },
> + { REG_VSTART, 0x00 },
> + { REG_VSTOP, 0x80 },
> + { REG_VREF, 0x12 },
> + { REG_EXHCH, 0x10 },
> + { REG_EXHCL, 0x40 },
> + { REG_ADC, 0x91 },
> + { REG_ACOM, 0x12 },
> + { REG_OFON, 0x43 },
> + { REG_NULL, 0 },
>  };
>  
>  static const struct ov965x_framesize ov965x_framesizes[] = {
> @@ -1266,11 +1295,12 @@ static int ov965x_set_fmt(struct v4l2_subdev *sd, 
> struct v4l2_subdev_pad_config
>  
>  static int ov965x_set_frame_size(struct ov965x *ov965x)
>  {
> - int i, ret = 0;
> + int ret = 0;
> +
> + v4l2_dbg(1, debug, ov965x->client, "%s\n", __func__);
>  
> - for (i = 0; ret == 0 && i < NUM_FMT_REGS; i++)
> - ret = ov965x_write(ov965x->client, frame_size_reg_addr[i],
> -ov965x->frame_size->regs[i]);
> + ret = ov965x_write_array(ov965x->client,
> +  ov965x->frame_size->regs);
>   return ret;

return ov96...();

And you can remove ret, too.

>  }
>  

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v2 3/7] [media] ov9650: add device tree support

[Sakari Ailus]

Hi Hugues,

On Mon, Jul 03, 2017 at 11:16:04AM +0200, Hugues Fruchet wrote:
> Allows use of device tree configuration data.
> If no device tree data is there, configuration is taken from platform data.
> In order to keep GPIOs configuration compatible between both way of doing,
> GPIOs are switched to descriptor-based interface.
> 
> Signed-off-by: H. Nikolaus Schaller 
> Signed-off-by: Hugues Fruchet 
> ---
>  drivers/media/i2c/Kconfig  |  2 +-
>  drivers/media/i2c/ov9650.c | 77 
> ++
>  2 files changed, 59 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 121b3b5..168115c 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -615,7 +615,7 @@ config VIDEO_OV7670
>  
>  config VIDEO_OV9650
>   tristate "OmniVision OV9650/OV9652 sensor support"
> - depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on GPIOLIB && I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
>   ---help---
> This is a V4L2 sensor-level driver for the Omnivision
> OV9650 and OV9652 camera sensors.
> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
> index 1e4e99e..7e9a902 100644
> --- a/drivers/media/i2c/ov9650.c
> +++ b/drivers/media/i2c/ov9650.c
> @@ -11,12 +11,14 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>   */
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -249,9 +251,10 @@ struct ov965x {
>   struct v4l2_subdev sd;
>   struct media_pad pad;
>   enum v4l2_mbus_type bus_type;
> - int gpios[NUM_GPIOS];
> + struct gpio_desc *gpios[NUM_GPIOS];
>   /* External master clock frequency */
>   unsigned long mclk_frequency;
> + struct clk *clk;
>  
>   /* Protects the struct fields below */
>   struct mutex lock;
> @@ -511,10 +514,10 @@ static int ov965x_set_color_matrix(struct ov965x 
> *ov965x)
>   return 0;
>  }
>  
> -static void ov965x_gpio_set(int gpio, int val)
> +static void ov965x_gpio_set(struct gpio_desc *gpio, int val)
>  {
> - if (gpio_is_valid(gpio))
> - gpio_set_value(gpio, val);
> + if (gpio)
> + gpiod_set_value_cansleep(gpio, val);

gpiod_set_value_cansleep() can manage with NULL gpio parameter, no need to
check it.

>  }
>  
>  static void __ov965x_set_power(struct ov965x *ov965x, int on)
> @@ -1406,24 +1409,28 @@ static int ov965x_configure_gpios(struct ov965x 
> *ov965x,
> const struct ov9650_platform_data *pdata)
>  {
>   int ret, i;
> + int gpios[NUM_GPIOS];
>  
> - ov965x->gpios[GPIO_PWDN] = pdata->gpio_pwdn;
> - ov965x->gpios[GPIO_RST]  = pdata->gpio_reset;
> + gpios[GPIO_PWDN] = pdata->gpio_pwdn;
> + gpios[GPIO_RST]  = pdata->gpio_reset;
>  
> - for (i = 0; i < ARRAY_SIZE(ov965x->gpios); i++) {
> - int gpio = ov965x->gpios[i];
> + for (i = 0; i < ARRAY_SIZE(gpios); i++) {
> + int gpio = gpios[i];
>  
>   if (!gpio_is_valid(gpio))
>   continue;
>   ret = devm_gpio_request_one(>client->dev, gpio,
> - GPIOF_OUT_INIT_HIGH, "OV965X");
> - if (ret < 0)
> + GPIOF_OUT_INIT_HIGH, DRIVER_NAME);

DRIVER_NAME is different from "OV965X". Is this an intended change?

> + if (ret < 0) {
> + dev_err(>client->dev,
> + "Failed to request gpio%d (%d)\n", gpio, ret);
>   return ret;
> + }
>   v4l2_dbg(1, debug, >sd, "set gpio %d to 1\n", gpio);
>  
>   gpio_set_value(gpio, 1);
>   gpio_export(gpio, 0);
> - ov965x->gpios[i] = gpio;
> + ov965x->gpios[i] = gpio_to_desc(gpio);
>   }
>  
>   return 0;
> @@ -1469,14 +1476,10 @@ static int ov965x_probe(struct i2c_client *client,
>   struct v4l2_subdev *sd;
>   struct ov965x *ov965x;
>   int ret;
> + struct device_node *np = client->dev.of_node;

It'd be nice to declare this next to pdata, rather than after ret and other
short declarations.

>  
> - if (pdata == NULL) {
> - dev_err(>dev, "platform data not specified\n");
> - return -EINVAL;
> - }
> -
> - if (pdata->mclk_frequency == 0) {
> - dev_err(>dev, "MCLK frequency not specified\n");
> + if (!pdata && !np) {
> + dev_err(>dev, "Platform data or device tree data must 
> be provided\n");
>   return -EINVAL;
>   }
>  
> @@ -1486,7 +1489,35 @@ static int ov965x_probe(struct i2c_client *client,
>  
>   mutex_init(>lock);
>   ov965x->client = client;
> - ov965x->mclk_frequency = 

Re: [PATCH 2/2] staging: media: atomisp2: Replace kfree()/vfree() with kvfree()

[Amitoj Kaur Chawla]

On Sat, Jul 8, 2017 at 4:58 AM, Bernd Petrovitsch
 wrote:
> On Fri, 2017-07-07 at 20:41 -0400, Amitoj Kaur Chawla wrote:
> [...]
>> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
>> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
>> @@ -117,11 +117,7 @@ void *atomisp_kernel_zalloc(size_t bytes, bool
>> zero_mem)
>>   */
>>  void atomisp_kernel_free(void *ptr)
>>  {
>> - /* Verify if buffer was allocated by vmalloc() or kmalloc()
>> */
>> - if (is_vmalloc_addr(ptr))
>> - vfree(ptr);
>> - else
>> - kfree(ptr);
>> + kvfree(ptr);
>>  }
>>
>>  /*
>
> Why not get rid of the trivial wrapper function completely?
>

Oh yes, i'll send a v2.

Amitoj

Re: [PATCH] staging: atomisp: gc0310: constify acpi_device_id.

[Sakari Ailus]

On Fri, Jul 07, 2017 at 11:47:43AM +0100, Alan Cox wrote:
> On Thu, 2017-07-06 at 21:50 +0530, Arvind Yadav wrote:
> > acpi_device_id are not supposed to change at runtime. All functions
> > working with acpi_device_id provided by  work with
> > const acpi_device_id. So mark the non-const structs as const.
> > 
> > File size before:
> >    text    data bss dec hex 
> > filename
> >   10297    1888   0   12185    2f99
> > drivers/staging/media/atomisp/i2c/gc0310.o
> > 
> > File size After adding 'const':
> >    text    data bss dec hex 
> > filename
> >   10361    1824   0   12185    2f99
> > drivers/staging/media/atomisp/i2c/gc0310.o
> > 
> > Signed-off-by: Arvind Yadav 
> > ---
> >  drivers/staging/media/atomisp/i2c/gc0310.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c
> > b/drivers/staging/media/atomisp/i2c/gc0310.c
> > index 1ec616a..c8162bb 100644
> > --- a/drivers/staging/media/atomisp/i2c/gc0310.c
> > +++ b/drivers/staging/media/atomisp/i2c/gc0310.c
> > @@ -1453,7 +1453,7 @@ static int gc0310_probe(struct i2c_client
> > *client,
> >     return ret;
> >  }
> >  
> > -static struct acpi_device_id gc0310_acpi_match[] = {
> > +static const struct acpi_device_id gc0310_acpi_match[] = {
> >     {"XXGC0310"},
> >     {},
> >  };
> 
> (All four)
> 
> Acked-by: Alan Cox 

There's four more... I've applied all to my atomisp branch.

Arvind: please send the patches as a single set next time.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: media-build breaks for Kernel 3.13

[Jasmin J.]

Hello Hans!

> It suggests you are using an old media_build.
No I am not, but I found another problem.
We have changed a driver and the patches needs to be adapted for that.

Sorry to bother you.

BR,
   Jasmin

Re: media-build breaks for Kernel 3.13

[Hans Verkuil]

On 08/07/17 22:41, Jasmin J. wrote:
> Hello!
> 
> I tried to compile the last media master for Kernel 3.13 (Ubuntu 14.04) and 
> get
> errors during the patch step:
> tar xfj linux-media.tar.bz2
>  rm -f .patches_applied .linked_dir .git_log.md5
>  make -C /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l stagingconfig
>  make[1]: Entering directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l'
>  make[2]: Entering directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
>  Applying patches for kernel 3.13.0-117-generic
>  patch -s -f -N -p1 -i ../backports/api_version.patch
>  patch -s -f -N -p1 -i ../backports/pr_fmt.patch
>  1 out of 1 hunk FAILED

Hmm, works fine for me. It still failed to build for 3.13 for other reasons, 
which I've now
fixed, but the patch step is working fine for me.

It suggests you are using an old media_build. Make sure you do a git pull.

Regards,

Hans

>  Makefile:138: recipe for target 'apply_patches' failed
>  make[2]: Leaving directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
>  Makefile:388: recipe for target 'stagingconfig' failed
>  make[1]: Leaving directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l'
>  Makefile:26: recipe for target 'stagingconfig' failed
>  Disabling CONFIG_DVB_DEMUX_SECTION_LOSS_LOG
>  Disabling CONFIG_DVB_DDBRIDGE_MSIENABLE
>  Disabling CONFIG_VIDEOBUF2_MEMOPS
>  Disabling CONFIG_FRAME_VECTOR
>  Disabling CONFIG_DVB_AF9033
>  Disabling CONFIG_VIDEO_ET8EK8
>  Disabling CONFIG_VIDEO_DW9714
>  Disabling CONFIG_SDR_MAX2175
>  Disabling CONFIG_VIDEO_VIMC
>  Setting CONFIG_DVB_MAX_ADAPTERS to 32
>  make -C /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l
>  make[1]: Entering directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l'
>  scripts/make_makefile.pl
>  Updating/Creating .config
>  make[2]: Entering directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
>  make[2]: Entering directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
>  make[3]: Entering directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
>  make[3]: Entering directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
>  Unapplying patches
>  Unapplying patches
>  patch -s -f -R -p1 -i ../backports/api_version.patch
>  patch -s -f -R -p1 -i ../backports/api_version.patch
>  make[3]: Leaving directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
>  Applying patches for kernel 3.13.0-117-generic
>  make[3]: Leaving directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
>  Applying patches for kernel 3.13.0-117-generic
>  Applying patches for kernel 3.13.0-117-generic
>  make[3]: Leaving directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
>  Applying patches for kernel 3.13.0-117-generic
>  patch -s -f -N -p1 -i ../backports/api_version.patch
>  patch -s -f -N -p1 -i ../backports/api_version.patch
>  1 out of 1 hunk FAILED -- saving rejects to file 
> drivers/media/cec/cec-api.c.rej
>  2 out of 2 hunks FAILED -- saving rejects to file 
> drivers/media/media-device.c.rej
>  1 out of 1 hunk FAILED -- saving rejects to file 
> drivers/media/usb/uvc/uvc_driver.c.rej
>  1 out of 1 hunk FAILED -- saving rejects to file 
> drivers/media/v4l2-core/v4l2-ioctl.c.rej
>  patch -s -f -N -p1 -i ../backports/pr_fmt.patch
>  patch -s -f -N -p1 -i ../backports/pr_fmt.patch
>  1 out of 1 hunk FAILED
>  1 out of 1 hunk FAILED
>  Makefile:138: recipe for target 'apply_patches' failed
>  Makefile:138: recipe for target 'apply_patches' failed
>  make[2]: Leaving directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
>  make[2]: Leaving directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
>  Preparing to compile for kernel version 3.13.0
>  WARNING: This is the V4L/DVB backport tree, with experimental drivers
>   backported to run on legacy kernels from the development tree at:
>  http://git.linuxtv.org/media-tree.git.
>   It is generally safe to use it for testing a new driver or
>   feature, but its usage on production environments is risky.
>   Don't use it in production. You've been warned.
>  CEC_CORE: Requires at least kernel 3.19.0
>  MEDIA_CEC_SUPPORT: Requires at least kernel 3.19.0
>  V4L2_FLASH_LED_CLASS: Requires at least kernel 4.2.0
>  RC_ST: Requires at least kernel 3.15.0
> Created default (all yes) .config file
>  ./scripts/make_myconfig.pl
>  perl scripts/make_config_compat.pl /lib/modules/3.13.0-117-generic/build 
> ./.myconfig ./config-compat.h
>  make -C firmware prep
>  creating symbolic links...
>  make[2]: Entering directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/firmware'
>  make[2]: Leaving directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/firmware'
>  make -C firmware
>  make[2]: Entering directory 
> '/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/firmware'
>

media-build breaks for Kernel 3.13

[Jasmin J.]

Hello!

I tried to compile the last media master for Kernel 3.13 (Ubuntu 14.04) and get
errors during the patch step:
tar xfj linux-media.tar.bz2
 rm -f .patches_applied .linked_dir .git_log.md5
 make -C /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l stagingconfig
 make[1]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l'
 make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 Applying patches for kernel 3.13.0-117-generic
 patch -s -f -N -p1 -i ../backports/api_version.patch
 patch -s -f -N -p1 -i ../backports/pr_fmt.patch
 1 out of 1 hunk FAILED
 Makefile:138: recipe for target 'apply_patches' failed
 make[2]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 Makefile:388: recipe for target 'stagingconfig' failed
 make[1]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l'
 Makefile:26: recipe for target 'stagingconfig' failed
 Disabling CONFIG_DVB_DEMUX_SECTION_LOSS_LOG
 Disabling CONFIG_DVB_DDBRIDGE_MSIENABLE
 Disabling CONFIG_VIDEOBUF2_MEMOPS
 Disabling CONFIG_FRAME_VECTOR
 Disabling CONFIG_DVB_AF9033
 Disabling CONFIG_VIDEO_ET8EK8
 Disabling CONFIG_VIDEO_DW9714
 Disabling CONFIG_SDR_MAX2175
 Disabling CONFIG_VIDEO_VIMC
 Setting CONFIG_DVB_MAX_ADAPTERS to 32
 make -C /mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l
 make[1]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l'
 scripts/make_makefile.pl
 Updating/Creating .config
 make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 make[3]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 make[3]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 Unapplying patches
 Unapplying patches
 patch -s -f -R -p1 -i ../backports/api_version.patch
 patch -s -f -R -p1 -i ../backports/api_version.patch
 make[3]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 Applying patches for kernel 3.13.0-117-generic
 make[3]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 Applying patches for kernel 3.13.0-117-generic
 Applying patches for kernel 3.13.0-117-generic
 make[3]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 Applying patches for kernel 3.13.0-117-generic
 patch -s -f -N -p1 -i ../backports/api_version.patch
 patch -s -f -N -p1 -i ../backports/api_version.patch
 1 out of 1 hunk FAILED -- saving rejects to file 
drivers/media/cec/cec-api.c.rej
 2 out of 2 hunks FAILED -- saving rejects to file 
drivers/media/media-device.c.rej
 1 out of 1 hunk FAILED -- saving rejects to file 
drivers/media/usb/uvc/uvc_driver.c.rej
 1 out of 1 hunk FAILED -- saving rejects to file 
drivers/media/v4l2-core/v4l2-ioctl.c.rej
 patch -s -f -N -p1 -i ../backports/pr_fmt.patch
 patch -s -f -N -p1 -i ../backports/pr_fmt.patch
 1 out of 1 hunk FAILED
 1 out of 1 hunk FAILED
 Makefile:138: recipe for target 'apply_patches' failed
 Makefile:138: recipe for target 'apply_patches' failed
 make[2]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 make[2]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 Preparing to compile for kernel version 3.13.0
 WARNING: This is the V4L/DVB backport tree, with experimental drivers
  backported to run on legacy kernels from the development tree at:
 http://git.linuxtv.org/media-tree.git.
  It is generally safe to use it for testing a new driver or
  feature, but its usage on production environments is risky.
  Don't use it in production. You've been warned.
 CEC_CORE: Requires at least kernel 3.19.0
 MEDIA_CEC_SUPPORT: Requires at least kernel 3.19.0
 V4L2_FLASH_LED_CLASS: Requires at least kernel 4.2.0
 RC_ST: Requires at least kernel 3.15.0
Created default (all yes) .config file
 ./scripts/make_myconfig.pl
 perl scripts/make_config_compat.pl /lib/modules/3.13.0-117-generic/build 
./.myconfig ./config-compat.h
 make -C firmware prep
 creating symbolic links...
 make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/firmware'
 make[2]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/firmware'
 make -C firmware
 make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/firmware'
   CC  ihex2fw
 Generating ttusb-budget/dspbootcode.bin
 Generating vicam/firmware.fw
 Generating cpia2/stv0672_vp4.bin
 Generating av7110/bootcode.bin
 make[2]: Leaving directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/v4l/firmware'
 Kernel build directory is /lib/modules/3.13.0-117-generic/build
 make -C ../linux apply_patches
 make[2]: Entering directory 
'/mnt/home_hdd/jasmin/vdr/dd_driver/git/media_build/linux'
 make[3]: Entering directory 

Re: Kaffeine with VLC backend.

[Mauro Carvalho Chehab]

Em Sat, 8 Jul 2017 21:30:32 +0100
Malcolm Priestley  escreveu:

> On 08/07/17 20:09, Mauro Carvalho Chehab wrote:
> > Em Sat, 8 Jul 2017 18:13:14 +0100
> > Malcolm Priestley  escreveu:
> >   
> >> On 08/07/17 08:17, Malcolm Priestley wrote:  
> >>> Hi Mauro
> >>>
> >>> Have you encountered a strange bug with Kaffeine with VLC backend.
> >>>
> >>> Certain channels will not play correctly, the recordings will also not
> >>> play in VLC.
> >>>
> >>> However, they will play fine with xine player. Only some channels are
> >>> affected of those provided by SKY such as 12207 V on Astra 28.2.
> >>>
> >>> These channels will play fine with Kaffeine with xine backend they also
> >>> play with VLC's dvb-s interface.
> >>>
> >>> Any ideas what could be wrong with the TS format?
> >>>
> >>> I am wondering if SKY are inserting something into the format.  
> >>
> >> Just a follow up it appears that the PCR is missing from the stream
> >> which is transmitted on a different PID.
> >>
> >> In the case of the above channel manually adding PID 8190 the backend
> >> plays normally.  
> > 
> > You're likely using an old version of Kaffeine. See this BZ:  
> I was already using the latest git tree.

Ah, ok.

> 
> > 
> > https://bugs.kde.org/show_bug.cgi?id=376805
> > No it hasn't fixed it the PCR is still missing from the stream.  
> 
> Somehow, PCR PID needs to be added to the PID filter.
> 
> Unless there is a way VLC can ignore it like xine does?

I suspect that it is probably easier to patch Kaffeine for it to filter
the PCR PIDs and send to libVLC.

Part of the filtering logic is at:
src/dvb/dvbsi.cpp

Please notice, however, that part of the contents of this file is
auto-generated via tools/updatedvbsi.cpp from tools/dvbsi.xml.

Thanks,
Mauro

Re: Kaffeine with VLC backend.

[Malcolm Priestley]

On 08/07/17 20:09, Mauro Carvalho Chehab wrote:

Em Sat, 8 Jul 2017 18:13:14 +0100
Malcolm Priestley  escreveu:


On 08/07/17 08:17, Malcolm Priestley wrote:

Hi Mauro

Have you encountered a strange bug with Kaffeine with VLC backend.

Certain channels will not play correctly, the recordings will also not
play in VLC.

However, they will play fine with xine player. Only some channels are
affected of those provided by SKY such as 12207 V on Astra 28.2.

These channels will play fine with Kaffeine with xine backend they also
play with VLC's dvb-s interface.

Any ideas what could be wrong with the TS format?

I am wondering if SKY are inserting something into the format.


Just a follow up it appears that the PCR is missing from the stream
which is transmitted on a different PID.

In the case of the above channel manually adding PID 8190 the backend
plays normally.


You're likely using an old version of Kaffeine. See this BZ:

I was already using the latest git tree.



https://bugs.kde.org/show_bug.cgi?id=376805
No it hasn't fixed it the PCR is still missing from the stream.


Somehow, PCR PID needs to be added to the PID filter.

Unless there is a way VLC can ignore it like xine does?

Kworld 340U (1b80:a340) kernel 4.8.0 ERROR: i2c_transfer returned: -6

[Kumar Vivek]

New subscriber and first time poster. I have tried to read most of the
instructions and etiquettes regarding the mailing list but there might
still be some noob mistakes on my part.

I have had this tuner for a while and I used it successfully in 2009
(with help from Markus Rechberger - who provided me with the
appropriate patch). I saw that the patches were included in the kernel
drivers and this was fully supported. I tried to use it again recently
and ran into problems and hence this mail. I have spent days trying to
figure out the problem and have been unsuccessful.

I am using kernel 4.8.0

The variant of this USB ATSC device I have has vid:pid = 1b80:a340 ,
EM2870 USB bridge, lgdt3304 demodulator/Frontend, TDA18271HDC2 tuner.

I loaded the em28xx module with debugging on - including i2c bus scan
and i2c transfer.

[  320.139648] em2870 #0 at em28xx_i2c_xfer: read stop addr=1c len=0:
[  320.139652] (pipe 0x8280): IN:  c0 02 00 00 1c 00 01 00
[  320.140008] <<< cf
[  320.140038] (pipe 0x8280): IN:  c0 00 00 00 05 00 01 00 <<< 00

[  320.140732] em2870 #0: found i2c device @ 0x1c on bus 0 [lgdt330x]

.
[  320.177163] (pipe 0x8280): IN:  c0 02 00 00 a0 00 01 00
[  320.177541] <<< 1a
[  320.177547] (pipe 0x8280): IN:  c0 00 00 00 05 00 01 00 <<< 00

[  320.177663] em2870 #0: found i2c device @ 0xa0 on bus 0 [eeprom]
.

[  320.186289] (pipe 0x8280): IN:  c0 02 00 00 c4 00 01 00
[  320.186659] <<< 84
[  320.186665] (pipe 0x8280): IN:  c0 00 00 00 05 00 01 00 <<< 00

[  320.186945] em2870 #0: found i2c device @ 0xc4 on bus 0 [tuner (analog)]

This is a bit strange since the tuner TDA18271HDC2 is at 0x60 (7 bit)
or 0xC0 (8 bit) i2c address and usually - i2cbus scan doesn't reveal
the tuner's address.

And then this happens :
[  320.203404] em2870 #0: Identified as KWorld PlusTV 340U or UB435-Q
(ATSC) (card=76)
[  320.203406] em28xx: Currently, V4L2 is not supported on this model
[  320.203407] em2870 #0: dvb set to isoc mode.
[  320.260270] em2870 #0: Binding DVB extension
[  320.260274] em2870 #0 em28xx_alloc_urbs :em28xx: called
em28xx_alloc_isoc in mode 2
[  320.260276] em2870 #0 em28xx_uninit_usb_xfer :em28xx: called
em28xx_uninit_usb_xfer in mode 2
[  320.260279] (pipe 0x8280): IN:  c0 00 00 00 0c 00 01 00 <<< 00
[  320.260536] (pipe 0x8200): OUT: 40 00 00 00 0c 00 01 00 >>> 00
[  320.260631] (pipe 0x8200): OUT: 40 00 00 00 12 00 01 00 >>> 27
[  320.260833] (pipe 0x8200): OUT: 40 00 00 00 48 00 01 00 >>> 00
[  320.260987] (pipe 0x8200): OUT: 40 00 00 00 12 00 01 00 >>> 37
[  320.275990] (pipe 0x8280): IN:  c0 00 00 00 08 00 01 00 <<< ff
[  320.278154] (pipe 0x8200): OUT: 40 00 00 00 08 00 01 00 >>> 7d
[  320.337050] em2870 #0 at em28xx_i2c_xfer: write nonstop addr=1c len=2: 00 01
[  320.337056] (pipe 0x8200): OUT: 40 03 00 00 1c 00 02 00 >>>
[  320.337057]  00 01
[  320.337502] (pipe 0x8280): IN:  c0 00 00 00 05 00 01 00 <<< 00

[  320.337618] em2870 #0 at em28xx_i2c_xfer: read stop addr=1c len=1:
[  320.337620] (pipe 0x8280): IN:  c0 02 00 00 1c 00 01 00
[  320.337860] <<< 30
[  320.337867] (pipe 0x8280): IN:  c0 00 00 00 05 00 01 00 <<< 00
[  320.337979]  30
[  320.337984] em2870 #0 at em28xx_i2c_xfer: write stop addr=1c len=3: 08 08 80
[  320.337987] (pipe 0x8200): OUT: 40 02 00 00 1c 00 03 00 >>>
[  320.337988]  08 08 80
[  320.338518] (pipe 0x8280): IN:  c0 00 00 00 05 00 01 00 <<< 00

[  320.338618] em2870 #0 at em28xx_i2c_xfer: write nonstop addr=1c len=2: 08 08
[  320.338622] (pipe 0x8200): OUT: 40 03 00 00 1c 00 02 00 >>>
[  320.338623]  08 08
[  320.339018] (pipe 0x8280): IN:  c0 00 00 00 05 00 01 00 <<< 00

[  320.339110] em2870 #0 at em28xx_i2c_xfer: read stop addr=1c len=1:
[  320.339113] (pipe 0x8280): IN:  c0 02 00 00 1c 00 01 00
[  320.339391] <<< 80
[  320.339397] (pipe 0x8280): IN:  c0 00 00 00 05 00 01 00 <<< 00
[  320.339490]  80
[  320.339496] em2870 #0 at em28xx_i2c_xfer: write stop addr=1c len=3: 08 08 00
[  320.339499] (pipe 0x8200): OUT: 40 02 00 00 1c 00 03 00 >>>
[  320.339499]  08 08 00
[  320.340768] (pipe 0x8280): IN:  c0 00 00 00 05 00 01 00 <<< 00

[  320.341276] tda18271 12-0060: creating new instance
[  320.341279] em2870 #0 at em28xx_i2c_xfer: write nonstop addr=c0 len=1: 00
[  320.341283] (pipe 0x8200): OUT: 40 03 00 00 c0 00 01 00 >>>
[  320.341284]  00
[  320.341506] (pipe 0x8280): IN:  c0 00 00 00 05 00 01 00 <<< 10
[  320.341637]  ERROR: -6
[  320.341642] tda18271_read_regs: [12-0060|M] ERROR: i2c_transfer returned: -6
[  320.341647] tda18271_dump_regs: [12-0060|M] === TDA18271 REG DUMP ===
[  320.341648] tda18271_dump_regs: [12-0060|M] ID_BYTE= 0x00
[  320.341650] tda18271_dump_regs: [12-0060|M] THERMO_BYTE= 0x00
[  320.341651] tda18271_dump_regs: [12-0060|M] POWER_LEVEL_BYTE   = 0x00
[  320.341652] tda18271_dump_regs: [12-0060|M] EASY_PROG_BYTE_1   = 0x00
[  320.341653] tda18271_dump_regs: [12-0060|M] EASY_PROG_BYTE_2   = 0x00
[ 

Re: Kaffeine with VLC backend.

[Mauro Carvalho Chehab]

Em Sat, 8 Jul 2017 18:13:14 +0100
Malcolm Priestley  escreveu:

> On 08/07/17 08:17, Malcolm Priestley wrote:
> > Hi Mauro
> > 
> > Have you encountered a strange bug with Kaffeine with VLC backend.
> > 
> > Certain channels will not play correctly, the recordings will also not 
> > play in VLC.
> > 
> > However, they will play fine with xine player. Only some channels are 
> > affected of those provided by SKY such as 12207 V on Astra 28.2.
> > 
> > These channels will play fine with Kaffeine with xine backend they also 
> > play with VLC's dvb-s interface.
> > 
> > Any ideas what could be wrong with the TS format?
> > 
> > I am wondering if SKY are inserting something into the format.  
> 
> Just a follow up it appears that the PCR is missing from the stream 
> which is transmitted on a different PID.
> 
> In the case of the above channel manually adding PID 8190 the backend 
> plays normally.

You're likely using an old version of Kaffeine. See this BZ:

https://bugs.kde.org/show_bug.cgi?id=376805


Thanks,
Mauro

Re: Kaffeine with VLC backend.

[Malcolm Priestley]

On 08/07/17 08:17, Malcolm Priestley wrote:

Hi Mauro

Have you encountered a strange bug with Kaffeine with VLC backend.

Certain channels will not play correctly, the recordings will also not 
play in VLC.


However, they will play fine with xine player. Only some channels are 
affected of those provided by SKY such as 12207 V on Astra 28.2.


These channels will play fine with Kaffeine with xine backend they also 
play with VLC's dvb-s interface.


Any ideas what could be wrong with the TS format?

I am wondering if SKY are inserting something into the format.


Just a follow up it appears that the PCR is missing from the stream 
which is transmitted on a different PID.


In the case of the above channel manually adding PID 8190 the backend 
plays normally.

Re: [PATCH v6] media: platform: Renesas IMR driver

[Konstantin Kozhevnikov]

Hello all,

the sample is made publicly available, and can be taken from 
https://github.com/CogentEmbedded/imr-sv-utest/blob/master/utest/utest-imr.c.


It doesn't show how luminance/chrominance correction actually works, 
however. That feature has been tested once a while ago, and probably we 
are going to release that soon.


Regarding usage of "chromacity" word in the comments, I actually meant 
"chrominance" or "chroma". The difference for non-native speaker is 
probably a bit vague, just like one between "luminance" and 
"luminosity". In the R-Car manual it is referred to as "hue", but what 
is meant is the "luma" and "chroma". These short forms seem a bit weird 
to me, hence I was using the words "luminance" and "chromacity". If 
that's confusing, I don't mind them be replaced with just "luma"/"chroma".


For documentation part, I am not 100% sure Renesas is okay with 
disclosing each and every detail, it might be the case we should obtain 
a permit from their legals. Still, I believe the person who is about to 
use the driver is having an access to at least Technical Reference 
Manual of R-Car Gen2/3, so adding a reference to a chapter in TRM will 
most likely be sufficient.


The question about usage of "user-pointer" buffers (V4L2_MEMORY_USERPTR) 
is a bit confusing. Indeed, right now we are using that scheme, though I 
wouldn't say we are absolutely required to do that. Specifically, we are 
allocating the contiguous buffers using Renesas' proprietary "mmngr" 
driver (it's not a rocket science thing, but it's made proprietary for 
some reason). Then we are using the buffers for various persons, both in 
EGL and in IMR. I guess we are okay with moving completely to DMA-fd 
(given the fact we have an accompanying driver "mmngrbuf" which serves 
for translation of memory pointers to DMA-fds for further cross-process 
sharing and stuff). I mean, if USERPTR is tagged as an obsolete / 
deprecated function, we are fine with dropping it. However, there is one 
thing I'd like to understand from V4L2 experts. I do see sometimes 
(during application closing or shortly after it) the bunches of warnings 
from kernel regarding "corrupted" MMU state (don't recall exactly, but 
it sounds like page which is supposed to be free gets somehow 
corrupted). Is that something that is related to (mis)use of USERPTR? I 
was trying to find out if there is any memory corruption caused by 
application logic, came to conclusion it's not. To me it looks like a 
race condition between unmapping of VMAs and V4L2 buffers deallocation 
which yields sometimes unpredictable results. Can you please provide 
some details about possible issues with usage of USERPTR with 
DMA-contiguous buffer driver, it would be good to find a match.


(Sorry, it got pretty long)

Sincerely,
Kostya

On 06/07/17 21:16, Sergei Shtylyov wrote:

Hello!

On 07/03/2017 03:43 PM, Hans Verkuil wrote:


Index: media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
===
--- /dev/null
+++ media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
@@ -0,0 +1,86 @@
+Renesas R-Car Image Rendeder (IMR) Driver


Rendeder -> Renderer


   Oops, sorry. :-)


+=
+
+This file documents some driver-specific aspects of the IMR driver, 
such as

+driver-specific ioctls.
+
+The ioctl reference
+~~~
+
+VIDIOC_IMR_MESH - Set mapping data
+^^
+
+Argument: struct imr_map_desc
+
+**Description**:
+
+This ioctl sets up the mesh using which the input frames will be


s/using/through/

+transformed into the output frames. The mesh can be strictly 
rectangular
+(when IMR_MAP_MESH bit is set in imr_map_desc::type) or 
arbitrary (when

+that bit is not set).
+
+A rectangular mesh consists of the imr_mesh structure followed 
by M*N
+vertex objects (where M is imr_mesh::rows and N is 
imr_mesh::columns).

+In case either IMR_MAP_AUTOSG or IMR_MAP_AUTODG bits were set in
+imr_map_desc::type, imr_mesh::{x|y}0 specify the coordinates of 
the top
+left corner of the auto-generated mesh and imr_mesh::d{x|y} 
specify the

+mesh's X/Y steps.


What if any of the other types are used like IMR_MAP_LUCE?


   IMR_MAP_LUCE only affects the vertex object.


Is this documented in a Renesas datasheet?


   Yes.


If so, add a reference to that in this
documentation.


   Unfortunately it's not publicly available.


+
+An arbitrary mesh consists of the imr_vbo structure followed by N
+triangle objects (where N is imr_vbo::num), consisting of 3 vertex
+objects each.
+
+A vertex object has a complex structure:
+
+.. code-block:: none
+
+__u16vvertical   \ source coordinates (only present
+__u16uhorizontal / if IMR_MAP_AUTOSG isn't set)
+__u16Yvertical   \ destination coordinates (only here
+__u16Xhorizontal / if IMR_MAP_AUTODG isn't set)

Re: [PATCH v2] staging: atomisp: use kstrdup to replace kmalloc and memcpy

[Sakari Ailus]

Hi Hari,

On Fri, Jul 07, 2017 at 08:15:21PM +0530, Hari Prasath wrote:
> kstrdup kernel primitive can be used to replace kmalloc followed by
> string copy. This was reported by coccinelle tool
> 
> Signed-off-by: Hari Prasath 
> ---
>  .../media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c   | 10 
> +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git 
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c 
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> index 34cc56f..68db87b 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> @@ -144,14 +144,10 @@ sh_css_load_blob_info(const char *fw, const struct 
> ia_css_fw_info *bi, struct ia
>   )
>   {
>   char *namebuffer;
> - int namelength = (int)strlen(name);
> -
> - namebuffer = (char *) kmalloc(namelength + 1, GFP_KERNEL);
> - if (namebuffer == NULL)
> - return IA_CSS_ERR_CANNOT_ALLOCATE_MEMORY;
> -
> - memcpy(namebuffer, name, namelength + 1);
>  
> + namebuffer = kstrdup(name, GFP_KERNEL);
> + if (!namebuffer)
> + return -ENOMEM;

The patch also changes the return value in error cases. I believe the
caller(s) expect to get errors in the IA_CCS_ERR_* range.

>   bd->name = fw_minibuffer[index].name = namebuffer;
>   } else {
>   bd->name = name;

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 2/2] staging: media: atomisp2: Replace kfree()/vfree() with kvfree()

[Bernd Petrovitsch]

On Fri, 2017-07-07 at 20:41 -0400, Amitoj Kaur Chawla wrote:
[...]
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> @@ -117,11 +117,7 @@ void *atomisp_kernel_zalloc(size_t bytes, bool
> zero_mem)
>   */
>  void atomisp_kernel_free(void *ptr)
>  {
> - /* Verify if buffer was allocated by vmalloc() or kmalloc()
> */
> - if (is_vmalloc_addr(ptr))
> - vfree(ptr);
> - else
> - kfree(ptr);
> + kvfree(ptr);
>  }
>  
>  /*

Why not get rid of the trivial wrapper function completely?

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

Kaffeine with VLC backend.

[Malcolm Priestley]

Hi Mauro

Have you encountered a strange bug with Kaffeine with VLC backend.

Certain channels will not play correctly, the recordings will also not 
play in VLC.


However, they will play fine with xine player. Only some channels are 
affected of those provided by SKY such as 12207 V on Astra 28.2.


These channels will play fine with Kaffeine with xine backend they also 
play with VLC's dvb-s interface.


Any ideas what could be wrong with the TS format?

I am wondering if SKY are inserting something into the format.

Regards


Malcolm