cron job: media_tree daily build: OK

2018-10-28 Thread 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 29 05:00:09 CET 2018
media-tree git hash:3b796aa60af087f5fec75aee9b17f2130f2b9adc
media_build git hash:   0c8bb27f3aaa682b9548b656f77505c3d1f11e71
v4l-utils git hash: c36dbbdfa8b30b2badd4f893b59d0bd4f0bd12aa
edid-decode git hash:   5eeb151a748788666534d6ea3da07f90400d24c2
gcc version:i686-linux-gcc (GCC) 8.2.0
sparse version: 0.5.2
smatch version: 0.5.1
host hardware:  x86_64
host os:4.18.0-2-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: OK
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.57-i686: OK
linux-3.16.57-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.123-i686: OK
linux-3.18.123-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.159-i686: OK
linux-4.4.159-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.131-i686: OK
linux-4.9.131-x86_64: OK
linux-4.10.17-i686: OK
linux-4.10.17-x86_64: OK
linux-4.11.12-i686: OK
linux-4.11.12-x86_64: OK
linux-4.12.14-i686: OK
linux-4.12.14-x86_64: OK
linux-4.13.16-i686: OK
linux-4.13.16-x86_64: OK
linux-4.14.74-i686: OK
linux-4.14.74-x86_64: OK
linux-4.15.18-i686: OK
linux-4.15.18-x86_64: OK
linux-4.16.18-i686: OK
linux-4.16.18-x86_64: OK
linux-4.17.19-i686: OK
linux-4.17.19-x86_64: OK
linux-4.18.12-i686: OK
linux-4.18.12-x86_64: OK
linux-4.19-i686: OK
linux-4.19-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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


[PATCH] media: saa7134: hvr1110 can decode rc6

2018-10-28 Thread Sean Young
The function get_key_hvr1110 can only decode rc5, however this is a
standard hauppauge z8f0811 which can decode rc6 as well. Use
get_key_haup_xvr() instead.

Test on a HVR 1110.

Signed-off-by: Sean Young 
---
 drivers/media/pci/saa7134/saa7134-input.c | 43 +++
 1 file changed, 4 insertions(+), 39 deletions(-)

diff --git a/drivers/media/pci/saa7134/saa7134-input.c 
b/drivers/media/pci/saa7134/saa7134-input.c
index 6e6d68964017..bc1ed7798d21 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -299,43 +299,6 @@ static int get_key_purpletv(struct IR_i2c *ir, enum 
rc_proto *protocol,
return 1;
 }
 
-static int get_key_hvr1110(struct IR_i2c *ir, enum rc_proto *protocol,
-  u32 *scancode, u8 *toggle)
-{
-   int rc;
-   unsigned char buf[5];
-
-   /* poll IR chip */
-   rc = i2c_master_recv(ir->c, buf, 5);
-   if (rc != 5) {
-   ir_dbg(ir, "read error\n");
-   if (rc < 0)
-   return rc;
-   return -EIO;
-   }
-
-   /* Check if some key were pressed */
-   if (!(buf[0] & 0x80))
-   return 0;
-
-   /*
-* buf[3] & 0x80 is always high.
-* buf[3] & 0x40 is a parity bit. A repeat event is marked
-* by preserving it into two separate readings
-* buf[4] bits 0 and 1, and buf[1] and buf[2] are always
-* zero.
-*
-* Note that the keymap which the hvr1110 uses is RC5.
-*
-* FIXME: start bits could maybe be used...?
-*/
-   *protocol = RC_PROTO_RC5;
-   *scancode = RC_SCANCODE_RC5(buf[3] & 0x1f, buf[4] >> 2);
-   *toggle = !!(buf[3] & 0x40);
-   return 1;
-}
-
-
 static int get_key_beholdm6xx(struct IR_i2c *ir, enum rc_proto *protocol,
  u32 *scancode, u8 *toggle)
 {
@@ -1029,9 +992,11 @@ void saa7134_probe_i2c_ir(struct saa7134_dev *dev)
(1 == rc) ? "yes" : "no");
break;
case SAA7134_BOARD_HAUPPAUGE_HVR1110:
-   dev->init_data.name = "HVR 1110";
-   dev->init_data.get_key = get_key_hvr1110;
+   dev->init_data.name = saa7134_boards[dev->board].name;
dev->init_data.ir_codes = RC_MAP_HAUPPAUGE;
+   dev->init_data.type = RC_PROTO_BIT_RC5 |
+   RC_PROTO_BIT_RC6_MCE | RC_PROTO_BIT_RC6_6A_32;
+   dev->init_data.internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
info.addr = 0x71;
break;
case SAA7134_BOARD_BEHOLD_607FM_MK3:
-- 
2.17.2



Re: [PATCH v4 3/6] media: v4l2-common: add V4L2_FRACT_COMPARE

2018-10-28 Thread Matt Ranostay
On Sun, Oct 28, 2018 at 9:25 AM Akinobu Mita  wrote:
>
> 2018年10月28日(日) 12:49 Matt Ranostay :
> >
> > On Sat, Oct 20, 2018 at 7:26 AM Akinobu Mita  wrote:
> > >
> > > Add macro to compare two v4l2_fract values in v4l2 common internal API.
> > > The same macro FRACT_CMP() is used by vivid and bcm2835-camera.  This just
> > > renames it to V4L2_FRACT_COMPARE in order to avoid namespace collision.
> > >
> > > Cc: Matt Ranostay 
> > > Cc: Sakari Ailus 
> > > Cc: Hans Verkuil 
> > > Cc: Mauro Carvalho Chehab 
> > > Acked-by: Sakari Ailus 
> > > Signed-off-by: Akinobu Mita 
> > > ---
> > > * v4
> > > - No changes from v3
> > >
> > >  include/media/v4l2-common.h | 5 +
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
> > > index cdc87ec..eafb8a3 100644
> > > --- a/include/media/v4l2-common.h
> > > +++ b/include/media/v4l2-common.h
> > > @@ -384,4 +384,9 @@ int v4l2_g_parm_cap(struct video_device *vdev,
> > >  int v4l2_s_parm_cap(struct video_device *vdev,
> > > struct v4l2_subdev *sd, struct v4l2_streamparm *a);
> > >
> > > +/* Compare two v4l2_fract structs */
> > > +#define V4L2_FRACT_COMPARE(a, OP, b)   \
> > > +   ((u64)(a).numerator * (b).denominator OP\
> > > +   (u64)(b).numerator * (a).denominator)
> > > +
> >
> > Noticed a few issues today when testing another thermal camera that
> > can do 0.5 fps to 64 fps with this macro..
>
> I expect your new thermal camera's frame_intervals will be something
> like below.
>
> static const struct v4l2_fract frame_intervals[] = {
> { 1, 64 },  /* 64 fps */
> { 1, 4 },   /* 4 fps */
> { 1, 2 },   /* 2 fps */
> { 2, 1 },   /* 0.5 fps */
> };
>
> > 1) This can have collision easily when numerator and denominators
> > multiplied have the same product, example is 0.5hz and 2hz have the
> > same output as 2
>
> I think V4L2_FRACT_COMPARE() can correctly compare with 0.5hz and 2hz.
>
> V4L2_FRACT_COMPARE({ 1, 2 }, <=, { 2, 1 }); // -->  true
> V4L2_FRACT_COMPARE({ 2, 1 }, <=, { 1, 2 }); //-->  false
>
> > 2) Also this doesn't reduce fractions so I am seeing 400 compared
> > with 4 for instance with a 4hz frame interval.
>
> I think this works fine, too.
>
> V4L2_FRACT_COMPARE({ 1, 400 }, <=, { 1, 4 }); //-->  true
> V4L2_FRACT_COMPARE({ 1, 4 }, <=, { 1, 400 }); //-->  false
>
> Or, do I misunderstand your problem?

Probably not! I didn't think of them having to be sorted in a certain
way, but will test and probably will work.

Couldn't hurt to have that noted in a comment some where as well.

- Matt


Re: [PATCH v4 3/6] media: v4l2-common: add V4L2_FRACT_COMPARE

2018-10-28 Thread Akinobu Mita
2018年10月28日(日) 12:49 Matt Ranostay :
>
> On Sat, Oct 20, 2018 at 7:26 AM Akinobu Mita  wrote:
> >
> > Add macro to compare two v4l2_fract values in v4l2 common internal API.
> > The same macro FRACT_CMP() is used by vivid and bcm2835-camera.  This just
> > renames it to V4L2_FRACT_COMPARE in order to avoid namespace collision.
> >
> > Cc: Matt Ranostay 
> > Cc: Sakari Ailus 
> > Cc: Hans Verkuil 
> > Cc: Mauro Carvalho Chehab 
> > Acked-by: Sakari Ailus 
> > Signed-off-by: Akinobu Mita 
> > ---
> > * v4
> > - No changes from v3
> >
> >  include/media/v4l2-common.h | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
> > index cdc87ec..eafb8a3 100644
> > --- a/include/media/v4l2-common.h
> > +++ b/include/media/v4l2-common.h
> > @@ -384,4 +384,9 @@ int v4l2_g_parm_cap(struct video_device *vdev,
> >  int v4l2_s_parm_cap(struct video_device *vdev,
> > struct v4l2_subdev *sd, struct v4l2_streamparm *a);
> >
> > +/* Compare two v4l2_fract structs */
> > +#define V4L2_FRACT_COMPARE(a, OP, b)   \
> > +   ((u64)(a).numerator * (b).denominator OP\
> > +   (u64)(b).numerator * (a).denominator)
> > +
>
> Noticed a few issues today when testing another thermal camera that
> can do 0.5 fps to 64 fps with this macro..

I expect your new thermal camera's frame_intervals will be something
like below.

static const struct v4l2_fract frame_intervals[] = {
{ 1, 64 },  /* 64 fps */
{ 1, 4 },   /* 4 fps */
{ 1, 2 },   /* 2 fps */
{ 2, 1 },   /* 0.5 fps */
};

> 1) This can have collision easily when numerator and denominators
> multiplied have the same product, example is 0.5hz and 2hz have the
> same output as 2

I think V4L2_FRACT_COMPARE() can correctly compare with 0.5hz and 2hz.

V4L2_FRACT_COMPARE({ 1, 2 }, <=, { 2, 1 }); // -->  true
V4L2_FRACT_COMPARE({ 2, 1 }, <=, { 1, 2 }); //-->  false

> 2) Also this doesn't reduce fractions so I am seeing 400 compared
> with 4 for instance with a 4hz frame interval.

I think this works fine, too.

V4L2_FRACT_COMPARE({ 1, 400 }, <=, { 1, 4 }); //-->  true
V4L2_FRACT_COMPARE({ 1, 4 }, <=, { 1, 400 }); //-->  false

Or, do I misunderstand your problem?


Re: [PATCH v4 5/6] media: video-i2c: support changing frame interval

2018-10-28 Thread Akinobu Mita
2018年10月28日(日) 12:39 Matt Ranostay :
>
> On Sat, Oct 20, 2018 at 7:26 AM Akinobu Mita  wrote:
> >
> > AMG88xx has a register for setting frame rate 1 or 10 FPS.
> > This adds support changing frame interval.
> >
> > Reference specifications:
> > https://docid81hrs3j1.cloudfront.net/medialibrary/2017/11/PANA-S-A0002141979-1.pdf
> >
> > Cc: Matt Ranostay 
> > Cc: Sakari Ailus 
> > Cc: Hans Verkuil 
> > Cc: Mauro Carvalho Chehab 
> > Acked-by: Matt Ranostay 
> > Acked-by: Sakari Ailus 
> > Signed-off-by: Akinobu Mita 
> > ---
> > * v4
> > - No changes from v3
> >
> >  drivers/media/i2c/video-i2c.c | 78 
> > ---
> >  1 file changed, 66 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> > index f23cb91..3334fc2 100644
> > --- a/drivers/media/i2c/video-i2c.c
> > +++ b/drivers/media/i2c/video-i2c.c
> > @@ -52,6 +52,8 @@ struct video_i2c_data {
> >
> > struct task_struct *kthread_vid_cap;
> > struct list_head vid_cap_active;
> > +
> > +   struct v4l2_fract frame_interval;
> >  };
> >
> >  static const struct v4l2_fmtdesc amg88xx_format = {
> > @@ -74,8 +76,9 @@ struct video_i2c_chip {
> > const struct v4l2_fmtdesc *format;
> > const struct v4l2_frmsize_discrete *size;
> >
> > -   /* max frames per second */
> > -   unsigned int max_fps;
> > +   /* available frame intervals */
> > +   const struct v4l2_fract *frame_intervals;
> > +   unsigned int num_frame_intervals;
> >
> > /* pixel buffer size */
> > unsigned int buffer_size;
> > @@ -85,6 +88,9 @@ struct video_i2c_chip {
> >
> > const struct regmap_config *regmap_config;
> >
> > +   /* setup function */
> > +   int (*setup)(struct video_i2c_data *data);
> > +
> > /* xfer function */
> > int (*xfer)(struct video_i2c_data *data, char *buf);
> >
> > @@ -92,6 +98,10 @@ struct video_i2c_chip {
> > int (*hwmon_init)(struct video_i2c_data *data);
> >  };
> >
> > +/* Frame rate register */
> > +#define AMG88XX_REG_FPSC   0x02
> > +#define AMG88XX_FPSC_1FPS  BIT(0)
> > +
> >  /* Thermistor register */
> >  #define AMG88XX_REG_TTHL   0x0e
> >
> > @@ -104,6 +114,19 @@ static int amg88xx_xfer(struct video_i2c_data *data, 
> > char *buf)
> > data->chip->buffer_size);
> >  }
> >
> > +static int amg88xx_setup(struct video_i2c_data *data)
> > +{
> > +   unsigned int mask = AMG88XX_FPSC_1FPS;
> > +   unsigned int val;
> > +
> > +   if (data->frame_interval.numerator == 
> > data->frame_interval.denominator)
> > +   val = mask;
> > +   else
> > +   val = 0;
> > +
> > +   return regmap_update_bits(data->regmap, AMG88XX_REG_FPSC, mask, 
> > val);
> > +}
> > +
> >  #if IS_ENABLED(CONFIG_HWMON)
> >
> >  static const u32 amg88xx_temp_config[] = {
> > @@ -178,14 +201,21 @@ static int amg88xx_hwmon_init(struct video_i2c_data 
> > *data)
> >
> >  #define AMG88XX0
> >
> > +static const struct v4l2_fract amg88xx_frame_intervals[] = {
> > +   { 1, 10 },
> > +   { 1, 1 },
> > +};
> > +
> >  static const struct video_i2c_chip video_i2c_chip[] = {
> > [AMG88XX] = {
> > .size   = _size,
> > .format = _format,
> > -   .max_fps= 10,
> > +   .frame_intervals= amg88xx_frame_intervals,
> > +   .num_frame_intervals= 
> > ARRAY_SIZE(amg88xx_frame_intervals),
> > .buffer_size= 128,
> > .bpp= 16,
> > .regmap_config  = _regmap_config,
> > +   .setup  = _setup,
> > .xfer   = _xfer,
> > .hwmon_init = amg88xx_hwmon_init,
> > },
> > @@ -250,7 +280,8 @@ static void buffer_queue(struct vb2_buffer *vb)
> >  static int video_i2c_thread_vid_cap(void *priv)
> >  {
> > struct video_i2c_data *data = priv;
> > -   unsigned int delay = msecs_to_jiffies(1000 / data->chip->max_fps);
> > +   unsigned int delay = mult_frac(HZ, data->frame_interval.numerator,
> > +  data->frame_interval.denominator);
> >
> > set_freezable();
> >
> > @@ -312,19 +343,26 @@ static void video_i2c_del_list(struct vb2_queue *vq, 
> > enum vb2_buffer_state state
> >  static int start_streaming(struct vb2_queue *vq, unsigned int count)
> >  {
> > struct video_i2c_data *data = vb2_get_drv_priv(vq);
> > +   int ret;
> >
> > if (data->kthread_vid_cap)
> > return 0;
> >
> > +   ret = data->chip->setup(data);
> > +   if (ret)
> > +   goto error_del_list;
> > +
> > data->sequence = 0;
> > data->kthread_vid_cap = kthread_run(video_i2c_thread_vid_cap, data,
> > "%s-vid-cap", 
> > data->v4l2_dev.name);
> > -   

Re: Kaffeine: cool pull request in GitHub

2018-10-28 Thread Mauro Carvalho Chehab
Hi Antoni,

Em Sun, 28 Oct 2018 01:02:39 +0200
Antoni Bella Pérez  escreveu:

>   Hi
> 
>   I found three pull request in GitHub and this code has not been included in 
> the master branch.
> 
>   
> 
>   * Fix audio CD playing
> #3 by mrandybu was closed a day ago 
> 
>   * Add support for parallel instant records
> #2 by kochstefan was closed on 17 Feb 
> 
>   * Fix compile on FreeBSD
> uest in GitHu#1 by arvedarved was closed on 3 May 2016
> 
>   I think that would be interesting include it to https://cgit.kde.org/
> kaffeine.git for next release. After your review... ;-)

Thank you for pointing it to me. That audio CD was broken for a long
time. Good to have it fixed.

I applied all 3 series. Not sure if the FreeBSD is really useful, as
AFAIKT the Linux DVB API is specific to Linux, but maybe someone 
backported it.

Anyway, it doesn't hurt applying it. 

Thanks,
Mauro