Re: Backport a Security Fix for CVE-2015-7833 to v4.1

2016-04-18 Thread Greg KH 
On Mon, Apr 18, 2016 at 06:01:19PM +0900, Yuki Machida wrote:
> Hi Greg and Sasha,
> 
> Please do not accept patch of 588afcc to stable tree,
> because above patch has some problem.
> It reported by Vladis and Hans.
> https://patchwork.linuxtv.org/patch/32798/
> https://www.spinics.net/lists/linux-media/msg96936.html
> http://article.gmane.org/gmane.linux.kernel.stable/174202/match=cve+2015+7833

Ok, now dropped from the 3.14-stable and 4.4-stable queues, thanks.

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

cron job: media_tree daily build: OK

2016-04-18 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:   Tue Apr 19 04:00:17 CEST 2016
git branch: test
git hash:   ecb7b0183a89613c154d1bea48b494907efbf8f9
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3413-g618cd5c
host hardware:  x86_64
host os:4.4.0-164

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-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: 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.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-rc1-i686: 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.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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 1/2] [media] atmel-isc: add the Image Sensor Controller code

2016-04-18 Thread Wu, Songjun 



On 4/14/2016 22:14, Laurent Pinchart wrote:

Hello Songjun,

On Thursday 14 Apr 2016 13:44:27 Wu, Songjun wrote:

The option 'CONFIG_COMMON_CLK=y' is needed to add to '.config'.
But I do not validate, '.config' will be generated automatically and
overwritten when it is changed.


Your driver's Kconfig entry should then contain "depends on COMMON_CLK".


Accept.
Thank you.

On 4/14/2016 00:01, kbuild test robot wrote:

Hi Songjun,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.6-rc3 next-20160413]
[if your patch is applied to the wrong git tree, please drop us a note to
help improving the system]

url:
https://github.com/0day-ci/linux/commits/Songjun-Wu/atmel-isc-add-driver-> > 
for-Atmel-ISC/20160413-155337 base:   git://linuxtv.org/media_tree.git
master
config: powerpc-allyesconfig (attached as .config)

reproduce:
  wget
  https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/p
  lain/sbin/make.cross -O ~/bin/make.cross chmod +x
  ~/bin/make.cross
  # save the attached .config to linux build tree
  make.cross ARCH=powerpc

All errors (new ones prefixed by >>):
  from include/linux/of.h:21,

  from drivers/media/platform/atmel/atmel-isc.c:27:
 drivers/media/platform/atmel/atmel-isc.c: In function
 'isc_clk_enable':
 include/linux/kernel.h:824:48: error: initialization from incompatible
 pointer type [-Werror=incompatible-pointer-types]>
   const typeof( ((type *)0)->member ) *__mptr = (ptr); \

 ^

 drivers/media/platform/atmel/atmel-isc.c:55:24: note: in expansion of
 macro 'container_of'>
  #define to_isc_clk(hw) container_of(hw, struct isc_clk, hw)

 ^

 drivers/media/platform/atmel/atmel-isc.c:247:28: note: in expansion of
 macro 'to_isc_clk'>
   struct isc_clk *isc_clk = to_isc_clk(hw);

 ^

 include/linux/kernel.h:824:48: note: (near initialization for
 'isc_clk')

   const typeof( ((type *)0)->member ) *__mptr = (ptr); \

 ^

 drivers/media/platform/atmel/atmel-isc.c:55:24: note: in expansion of
 macro 'container_of'>
  #define to_isc_clk(hw) container_of(hw, struct isc_clk, hw)

 ^

 drivers/media/platform/atmel/atmel-isc.c:247:28: note: in expansion of
 macro 'to_isc_clk'>
   struct isc_clk *isc_clk = to_isc_clk(hw);

 ^

 drivers/media/platform/atmel/atmel-isc.c: In function
 'isc_clk_disable':
 include/linux/kernel.h:824:48: error: initialization from incompatible
 pointer type [-Werror=incompatible-pointer-types]>
   const typeof( ((type *)0)->member ) *__mptr = (ptr); \

 ^

 drivers/media/platform/atmel/atmel-isc.c:55:24: note: in expansion of
 macro 'container_of'>
  #define to_isc_clk(hw) container_of(hw, struct isc_clk, hw)

 ^

 drivers/media/platform/atmel/atmel-isc.c:280:28: note: in expansion of
 macro 'to_isc_clk'>
   struct isc_clk *isc_clk = to_isc_clk(hw);

 ^

 include/linux/kernel.h:824:48: note: (near initialization for
 'isc_clk')

   const typeof( ((type *)0)->member ) *__mptr = (ptr); \

 ^

 drivers/media/platform/atmel/atmel-isc.c:55:24: note: in expansion of
 macro 'container_of'>
  #define to_isc_clk(hw) container_of(hw, struct isc_clk, hw)

 ^

 drivers/media/platform/atmel/atmel-isc.c:280:28: note: in expansion of
 macro 'to_isc_clk'>
   struct isc_clk *isc_clk = to_isc_clk(hw);

 ^

 drivers/media/platform/atmel/atmel-isc.c: In function
 'isc_clk_is_enabled':
 include/linux/kernel.h:824:48: error: initialization from incompatible
 pointer type [-Werror=incompatible-pointer-types]>
   const typeof( ((type *)0)->member ) *__mptr = (ptr); \

 ^

 drivers/media/platform/atmel/atmel-isc.c:55:24: note: in expansion of
 macro 'container_of'>
  #define to_isc_clk(hw) container_of(hw, struct isc_clk, hw)

 ^

 drivers/media/platform/atmel/atmel-isc.c:295:28: note: in expansion of
 macro 'to_isc_clk'>
   struct isc_clk *isc_clk = to_isc_clk(hw);

 ^

 include/linux/kernel.h:824:48: note: (near initialization for
 'isc_clk')

   const typeof( ((type *)0)->member ) *__mptr = (ptr); \

 ^

 drivers/media/platform/atmel/atmel-isc.c:55:24: note: in expansion of
 macro 'container_of'>
  #define to_isc_clk(hw) container_of(hw,

Greetings!!!

2016-04-18 Thread andreas122 
Hi, how are you? My name is J Eric Denials, External Financial Auditor at 
Lloyds Banking Group plc., London. It is a pleasure to contact you at this time 
through this medium. I have a cool and legitimate deal to do with you as you're 
a foreigner, it will be mutually beneficial to both. If you’re interested, 
urgently, get back to me for more explanation about the deal.
Regards
Eric
--
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 4/7] tw686x: Add support for DMA scatter-gather mode

2016-04-18 Thread Tim Harvey 
On Fri, Apr 1, 2016 at 3:38 PM, Ezequiel Garcia
 wrote:
> Now that the driver has the infrastructure to support more
> DMA modes, let's add the DMA scatter-gather mode.
>
> In this mode, the device delivers sequential top-bottom
> frames.
>
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/media/pci/tw686x/Kconfig|   1 +
>  drivers/media/pci/tw686x/tw686x-core.c  |   4 +
>  drivers/media/pci/tw686x/tw686x-video.c | 188 
> 
>  drivers/media/pci/tw686x/tw686x.h   |  14 +++
>  4 files changed, 207 insertions(+)
>
> diff --git a/drivers/media/pci/tw686x/Kconfig 
> b/drivers/media/pci/tw686x/Kconfig
> index ef8ca85522f8..34ff37712313 100644
> --- a/drivers/media/pci/tw686x/Kconfig
> +++ b/drivers/media/pci/tw686x/Kconfig
> @@ -4,6 +4,7 @@ config VIDEO_TW686X
> depends on HAS_DMA
> select VIDEOBUF2_VMALLOC
> select VIDEOBUF2_DMA_CONTIG
> +   select VIDEOBUF2_DMA_SG
> select SND_PCM
> help
>   Support for Intersil/Techwell TW686x-based frame grabber cards.
> diff --git a/drivers/media/pci/tw686x/tw686x-core.c 
> b/drivers/media/pci/tw686x/tw686x-core.c
> index 9a7646c0f9f6..586bc6723c93 100644
> --- a/drivers/media/pci/tw686x/tw686x-core.c
> +++ b/drivers/media/pci/tw686x/tw686x-core.c
> @@ -65,6 +65,8 @@ static const char *dma_mode_name(unsigned int mode)
> return "memcpy";
> case TW686X_DMA_MODE_CONTIG:
> return "contig";
> +   case TW686X_DMA_MODE_SG:
> +   return "sg";
> default:
> return "unknown";
> }
> @@ -81,6 +83,8 @@ static int tw686x_dma_mode_set(const char *val, struct 
> kernel_param *kp)
> dma_mode = TW686X_DMA_MODE_MEMCPY;
> else if (!strcasecmp(val, dma_mode_name(TW686X_DMA_MODE_CONTIG)))
> dma_mode = TW686X_DMA_MODE_CONTIG;
> +   else if (!strcasecmp(val, dma_mode_name(TW686X_DMA_MODE_SG)))
> +   dma_mode = TW686X_DMA_MODE_SG;
> else
> return -EINVAL;
> return 0;
> diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
> b/drivers/media/pci/tw686x/tw686x-video.c
> index ed6abb4c41c2..16228c559f9a 100644
> --- a/drivers/media/pci/tw686x/tw686x-video.c
> +++ b/drivers/media/pci/tw686x/tw686x-video.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "tw686x.h"
>  #include "tw686x-regs.h"
> @@ -28,6 +29,10 @@
>  #define TW686X_VIDEO_WIDTH 720
>  #define TW686X_VIDEO_HEIGHT(id)((id & V4L2_STD_625_50) ? 576 
> : 480)
>
> +#define TW686X_MAX_SG_ENTRY_SIZE   4096
> +#define TW686X_MAX_SG_DESC_COUNT   256 /* PAL 720x576 needs 203 4-KB 
> pages */
> +#define TW686X_SG_TABLE_SIZE   (TW686X_MAX_SG_DESC_COUNT * 
> sizeof(struct tw686x_sg_desc))
> +
>  static const struct tw686x_format formats[] = {
> {
> .fourcc = V4L2_PIX_FMT_UYVY,
> @@ -196,6 +201,174 @@ const struct tw686x_dma_ops contig_dma_ops = {
> .field  = V4L2_FIELD_INTERLACED,
>  };
>
> +static int tw686x_sg_desc_fill(struct tw686x_sg_desc *descs,
> +  struct tw686x_v4l2_buf *buf,
> +  unsigned int buf_len)
> +{
> +   struct sg_table *vbuf = vb2_dma_sg_plane_desc(>vb.vb2_buf, 0);
> +   unsigned int len, entry_len;
> +   struct scatterlist *sg;
> +   int i, count;
> +
> +   /* Clear the scatter-gather table */
> +   memset(descs, 0, TW686X_SG_TABLE_SIZE);
> +
> +   count = 0;
> +   for_each_sg(vbuf->sgl, sg, vbuf->nents, i) {
> +   dma_addr_t phys = sg_dma_address(sg);
> +   len = sg_dma_len(sg);
> +
> +   while (len && buf_len) {
> +
> +   if (count == TW686X_MAX_SG_DESC_COUNT)
> +   return -ENOMEM;
> +
> +   entry_len = min_t(unsigned int, len,
> + TW686X_MAX_SG_ENTRY_SIZE);
> +   entry_len = min_t(unsigned int, entry_len, buf_len);
> +   descs[count].phys = cpu_to_le32(phys);
> +   descs[count++].flags_length =
> +   cpu_to_le32(BIT(30) | entry_len);
> +   phys += entry_len;
> +   len -= entry_len;
> +   buf_len -= entry_len;
> +   }
> +
> +   if (!buf_len)
> +   return 0;
> +   }
> +
> +   return -ENOMEM;
> +}
> +
> +static void tw686x_sg_buf_refill(struct tw686x_video_channel *vc,
> +unsigned int pb)
> +{
> +   struct tw686x_dev *dev = vc->dev;
> +   struct tw686x_v4l2_buf *buf;
> +
> +   while (!list_empty(>vidq_queued)) {
> +   unsigned int buf_len;
> +
> +   buf =

Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

2016-04-18 Thread Nicolas Dufresne 
Le lundi 18 avril 2016 à 16:22 +0800, tiffany lin a écrit :
> > > We are plaining to remove m2m framework in th feature, although
> we think
> > 
> > Remove it for just the decoder driver or both encoder and decoder?
> > 
> Remove it from decoder driver.

Did you look at how CODA handle it (drivers/media/platform/coda/coda-
common.c) ? I don't know any detail, but they do have the same issue
and use both v4l2_m2m_fop_poll and v4l2_m2m_fop_mmap.

cheers,
Nicolas
--
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

Greetings!!!

2016-04-18 Thread andreas11 
Hi, how are you? My name is J Eric Denials, External Financial Auditor at 
Lloyds Banking Group plc., London. It is a pleasure to contact you at this time 
through this medium. I have a cool and legitimate deal to do with you as you're 
a foreigner, it will be mutually beneficial to both. If you’re interested, 
urgently, get back to me for more explanation about the deal.
Regards
Eric
--
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 3/7] tw686x: Add support for DMA contiguous interlaced frame mode

2016-04-18 Thread Tim Harvey 
On Fri, Apr 1, 2016 at 3:38 PM, Ezequiel Garcia
 wrote:
> Now that the driver has the infrastructure to support more
> DMA modes, let's add the DMA contiguous interlaced frame mode.
>
> In this mode, the DMA P and B buffers are programmed with
> the user-provided buffers. When a P (or B) frame is ready,
> a new buffer is dequeued into P (or B).
>
> In addition to interlaced fields, the device can also be
> programmed to deliver alternate fields. Only interlaced
> mode is supported for now.
>
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/media/pci/tw686x/Kconfig|  1 +
>  drivers/media/pci/tw686x/tw686x-core.c  |  4 +++
>  drivers/media/pci/tw686x/tw686x-video.c | 50 
> +
>  drivers/media/pci/tw686x/tw686x.h   |  1 +
>  4 files changed, 56 insertions(+)
>
> diff --git a/drivers/media/pci/tw686x/Kconfig 
> b/drivers/media/pci/tw686x/Kconfig
> index fb8536974052..ef8ca85522f8 100644
> --- a/drivers/media/pci/tw686x/Kconfig
> +++ b/drivers/media/pci/tw686x/Kconfig
> @@ -3,6 +3,7 @@ config VIDEO_TW686X
> depends on PCI && VIDEO_DEV && VIDEO_V4L2 && SND
> depends on HAS_DMA
> select VIDEOBUF2_VMALLOC
> +   select VIDEOBUF2_DMA_CONTIG
> select SND_PCM
> help
>   Support for Intersil/Techwell TW686x-based frame grabber cards.
> diff --git a/drivers/media/pci/tw686x/tw686x-core.c 
> b/drivers/media/pci/tw686x/tw686x-core.c
> index 01c06bb59e78..9a7646c0f9f6 100644
> --- a/drivers/media/pci/tw686x/tw686x-core.c
> +++ b/drivers/media/pci/tw686x/tw686x-core.c
> @@ -63,6 +63,8 @@ static const char *dma_mode_name(unsigned int mode)
> switch (mode) {
> case TW686X_DMA_MODE_MEMCPY:
> return "memcpy";
> +   case TW686X_DMA_MODE_CONTIG:
> +   return "contig";
> default:
> return "unknown";
> }
> @@ -77,6 +79,8 @@ static int tw686x_dma_mode_set(const char *val, struct 
> kernel_param *kp)
>  {
> if (!strcasecmp(val, dma_mode_name(TW686X_DMA_MODE_MEMCPY)))
> dma_mode = TW686X_DMA_MODE_MEMCPY;
> +   else if (!strcasecmp(val, dma_mode_name(TW686X_DMA_MODE_CONTIG)))
> +   dma_mode = TW686X_DMA_MODE_CONTIG;
> else
> return -EINVAL;
> return 0;
> diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
> b/drivers/media/pci/tw686x/tw686x-video.c
> index 82ae607b1d01..ed6abb4c41c2 100644
> --- a/drivers/media/pci/tw686x/tw686x-video.c
> +++ b/drivers/media/pci/tw686x/tw686x-video.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "tw686x.h"
>  #include "tw686x-regs.h"
> @@ -148,6 +149,53 @@ const struct tw686x_dma_ops memcpy_dma_ops = {
> .field  = V4L2_FIELD_INTERLACED,
>  };
>
> +static void tw686x_contig_buf_refill(struct tw686x_video_channel *vc,
> +unsigned int pb)
> +{
> +   struct tw686x_v4l2_buf *buf;
> +
> +   while (!list_empty(>vidq_queued)) {
> +   u32 reg = pb ? VDMA_B_ADDR[vc->ch] : VDMA_P_ADDR[vc->ch];
> +   dma_addr_t phys;
> +
> +   buf = list_first_entry(>vidq_queued,
> +   struct tw686x_v4l2_buf, list);
> +   list_del(>list);
> +
> +   phys = vb2_dma_contig_plane_dma_addr(>vb.vb2_buf, 0);
> +   reg_write(vc->dev, reg, phys);
> +
> +   buf->vb.vb2_buf.state = VB2_BUF_STATE_ACTIVE;
> +   vc->curr_bufs[pb] = buf;
> +   return;
> +   }
> +   vc->curr_bufs[pb] = NULL;
> +}
> +
> +static void tw686x_contig_cleanup(struct tw686x_dev *dev)
> +{
> +   vb2_dma_contig_cleanup_ctx(dev->alloc_ctx);
> +}
> +
> +static int tw686x_contig_setup(struct tw686x_dev *dev)
> +{
> +   dev->alloc_ctx = vb2_dma_contig_init_ctx(>pci_dev->dev);
> +   if (IS_ERR(dev->alloc_ctx)) {
> +   dev_err(>pci_dev->dev, "unable to init DMA context\n");
> +   return PTR_ERR(dev->alloc_ctx);
> +   }
> +   return 0;
> +}
> +
> +const struct tw686x_dma_ops contig_dma_ops = {
> +   .setup  = tw686x_contig_setup,
> +   .cleanup= tw686x_contig_cleanup,
> +   .buf_refill = tw686x_contig_buf_refill,
> +   .mem_ops= _dma_contig_memops,
> +   .hw_dma_mode= TW686X_FRAME_MODE,
> +   .field  = V4L2_FIELD_INTERLACED,
> +};
> +
>  static unsigned int tw686x_fields_map(v4l2_std_id std, unsigned int fps)
>  {
> static const unsigned int map[15] = {
> @@ -832,6 +880,8 @@ int tw686x_video_init(struct tw686x_dev *dev)
>
> if (dev->dma_mode == TW686X_DMA_MODE_MEMCPY)
> dev->dma_ops = _dma_ops;
> +   else if (dev->dma_mode == TW686X_DMA_MODE_CONTIG)
> +   dev->dma_ops = _dma_ops;
> else
> return -EINVAL;
>
> diff --git

[PATCH] USB_PID_DIBCOM_STK8096GP also comes with USB_VID_DIBCOM vendor ID (FIXED PATCH)

2016-04-18 Thread Alejandro Torrado 
Signed-off-by: Alejandro Torrado 
---
 drivers/media/usb/dvb-usb/dib0700_devices.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c 
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index ea0391e..0857b56 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -3814,6 +3814,7 @@ struct usb_device_id dib0700_usb_id_table[] = {
{ USB_DEVICE(USB_VID_PCTV,  USB_PID_PCTV_2002E) },
{ USB_DEVICE(USB_VID_PCTV,  USB_PID_PCTV_2002E_SE) },
{ USB_DEVICE(USB_VID_PCTV,  USB_PID_DIBCOM_STK8096PVR) },
+   { USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK8096PVR) },
{ 0 }   /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -5017,7 +5018,8 @@ struct dvb_usb_device_properties dib0700_devices[] = {
.num_device_descs = 1,
.devices = {
{   "DiBcom STK8096-PVR reference design",
-   { _usb_id_table[83], NULL },
+   { _usb_id_table[83],
+   _usb_id_table[84], NULL},
{ NULL },
},
},
-- 
1.9.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: [PATCH] USB_PID_DIBCOM_STK8096GP also comes with USB_VID_DIBCOM vendor ID.

2016-04-18 Thread Alejandro Torrado 
This patch is incomplete. Sorry about that. New one coming soon.

2016-04-18 12:46 GMT-03:00 Alejandro Torrado :
> Signed-off-by: Alejandro Torrado 
> ---
>  drivers/media/usb/dvb-usb/dib0700_devices.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c 
> b/drivers/media/usb/dvb-usb/dib0700_devices.c
> index ea0391e..ee7bafc 100644
> --- a/drivers/media/usb/dvb-usb/dib0700_devices.c
> +++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
> @@ -3814,6 +3814,7 @@ struct usb_device_id dib0700_usb_id_table[] = {
> { USB_DEVICE(USB_VID_PCTV,  USB_PID_PCTV_2002E) },
> { USB_DEVICE(USB_VID_PCTV,  USB_PID_PCTV_2002E_SE) },
> { USB_DEVICE(USB_VID_PCTV,  USB_PID_DIBCOM_STK8096PVR) },
> +   { USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK8096PVR) },
> { 0 }   /* Terminating entry */
>  };
>  MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB_PID_DIBCOM_STK8096GP also comes with USB_VID_DIBCOM vendor ID.

2016-04-18 Thread Alejandro Torrado 
Signed-off-by: Alejandro Torrado 
---
 drivers/media/usb/dvb-usb/dib0700_devices.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c 
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index ea0391e..ee7bafc 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -3814,6 +3814,7 @@ struct usb_device_id dib0700_usb_id_table[] = {
{ USB_DEVICE(USB_VID_PCTV,  USB_PID_PCTV_2002E) },
{ USB_DEVICE(USB_VID_PCTV,  USB_PID_PCTV_2002E_SE) },
{ USB_DEVICE(USB_VID_PCTV,  USB_PID_DIBCOM_STK8096PVR) },
+   { USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK8096PVR) },
{ 0 }   /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
-- 
1.9.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

[GIT PULL FOR v4.6] Two revert patches

2016-04-18 Thread Hans Verkuil 
Hi Mauro,

These two patches should go to 4.6.

Note that the usbvision patch is also part of a 4.7 pull request of mine, but
I realized that it should go to 4.6, not 4.7.

Regards,

Hans

The following changes since commit ecb7b0183a89613c154d1bea48b494907efbf8f9:

  [media] m88ds3103: fix undefined division (2016-04-13 19:17:39 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.6a

for you to fetch changes up to 9990a56c2ed064abfd72e074182800c56a876ae9:

  davinci_vpfe: Revert "staging: media: davinci_vpfe: remove,unnecessary ret 
variable" (2016-04-18 16:17:31 +0200)


Hans Verkuil (1):
  davinci_vpfe: Revert "staging: media: davinci_vpfe: remove,unnecessary 
ret variable"

Vladis Dronov (1):
  usbvision: revert commit 588afcc1

 drivers/media/usb/usbvision/usbvision-video.c   |  7 ---
 drivers/staging/media/davinci_vpfe/vpfe_video.c | 54 
+
 2 files changed, 34 insertions(+), 27 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gstreamer: v4l2videodec plugin

2016-04-18 Thread Rob Clark 
On Fri, Apr 15, 2016 at 12:09 PM, Nicolas Dufresne  wrote:
> Le vendredi 15 avril 2016 à 11:58 -0400, Rob Clark a écrit :
>> The issue is probably the YUV format, which we cannot really deal
>> with
>> properly in gallium..  it's a similar issue to multi-planer even if
>> it
>> is in a single buffer.
>>
>> The best way to handle this would be to import the same dmabuf fd
>> twice, with appropriate offsets, to create one GL_RED eglimage for Y
>> and one GL_RG eglimage for UV, and then combine them in shader in a
>> similar way to how you'd handle separate Y and UV planes..
>
> That's the strategy we use in GStreamer, as very few GL stack support
> implicit color conversions. For that to work you need to implement the
> "offset" field in winsys_handle, that was added recently, and make sure
> you have R8 and RG88 support (usually this is just mapping).

oh, heh, looks like nobody bothered to add this yet:

-
diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c
b/src/gallium/drivers/freedreno/freedreno_resource.c
index 9aded3b..fab78ab 100644
--- a/src/gallium/drivers/freedreno/freedreno_resource.c
+++ b/src/gallium/drivers/freedreno/freedreno_resource.c
@@ -669,6 +669,7 @@ fd_resource_from_handle(struct pipe_screen *pscreen,
 rsc->base.vtbl = _resource_vtbl;
 rsc->cpp = util_format_get_blocksize(tmpl->format);
 slice->pitch /= rsc->cpp;
+slice->offset = handle->offset;

 assert(rsc->cpp);
-


> cheers,
> Nicolas
--
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: Kernel docs: muddying the waters a bit

2016-04-18 Thread Mauro Carvalho Chehab 
Em Mon, 18 Apr 2016 10:10:17 +0200
Markus Heiser  escreveu:

> Hi Mauro, hi kernel-doc authors, 
> 
> Am 12.04.2016 um 15:58 schrieb Mauro Carvalho Chehab 
> :
> 
> > Em Fri, 8 Apr 2016 17:12:27 +0200
> > Markus Heiser  escreveu:
> >   
> >> Hi kernel-doc authors,
> >> 
> >> motivated by this MT, I implemented a toolchain to migrate the kernel’s 
> >> DocBook XML documentation to reST markup. 
> >> 
> >> It converts 99% of the docs well ... to gain an impression how 
> >> kernel-docs could benefit from, visit my sphkerneldoc project page
> >> on github:
> >> 
> >> http://return42.github.io/sphkerneldoc/
> >> 
> >> The sources available at:
> >> 
> >> https://github.com/return42/sphkerneldoc
> >> 
> >> The work is underway, suggestions are welcome!
> >> 
> >> .. have a nice weekend ..  
> > 
> > Hi Markus,
> > 
> > Thanks for your work. I'm basically worried about the media docbook,
> > with has some complexities that I was not able to figure out a way to
> > convert it to reST.
> > 
> > So, let me pinpoint some issues that I noticed there, on a quick
> > look.
> > 
> > The first thing I noticed is that the index doesn't match what's
> > there, when generated from DocBook:
> > https://linuxtv.org/downloads/v4l-dvb-apis/v4l2spec.html
> > 
> > So, for instance, "Interfaces" is at the same level as "Input/Output".
> > 
> > This sounds like an something went wrong when dealing with the title
> > indentation levels during the conversion.
> >   
> 
> Yes, the hierarchical structure was broken by two causes. First was, that the
> *chunking* was wrong and the other was, that my DocBook-XML-filter (dbxml) 
> placed
> all sections and sub(-sub)-sections at the same level (direct under chapter). 
> This was
> not only broken in the linux_tv book, in the other books also.
> 
> Thanks for pointing and sorry that I have overlooked this (I was so much 
> focused on
> on converting single elements to reST, that I not see the wood for the trees).
> 
> It is now fixed, may you give it a new try.

Thanks! It looks good now.

> > I would also like to see the titles numbered in chapters (and, if
> > possible, in sections and items) and to be properly indented at the 
> > index.  
> 
> BTW a few words about differences between DockBook and reST (Sphinx).
> 
> With DocBook you write *books*, the protocol (the DocBook application) has
> no facility to *chunk* and interconnect several documents. The external 
> ENTITY 
> is a workaround on the SGML layer, not on XML nor on the DB-application layer.
> Thats the reason, why so many XML-tools don't handle this entities and
> many DocBook to (e.g.) reST tools are fail.
> 
> With **standard** reST it is nearly the same, except there is a "include"
> directive on the application layer. But this directive is very simple,
> comparable to the C preprocessor "#include" directive.
> 
> With the **superset** reST-markup of Sphinx-doc you get a the "toctree" 
> directive,
> which lets you control how a document-tree should be build.
> 
>  http://www.sphinx-doc.org/en/stable/markup/toctree.html
> 
> @Mauro: you mentioned a docutils (rst2*) experience in your mail 
>   http://marc.info/?l=linux-doc=145735316012094=2
> 
>   Because the "toctree" directive -- and other directives
>   we use -- are a part of a superset of the **standard** 
>   reST, the standard docutils (like rst2*) will not work.
> 
> OK, back to your requirements: within the toctree directive you can
> set options like "maxdepth" and "numbered". It is a decision, how
> deep TOCs should go and if they should be numbered. IMO, in a
> HTML rendered page, with a proper navigation bar on the side, deep 
> TOCs in the running text have no pros, they only blow up the running
> text and bring more scrolling with. In my sense numbering chapters
> make only sense in books, not in HTML pages, where you have hyperlinks.
> 
> Just for demonstration, I added numbering in the linux-tv book:
> 
> https://github.com/return42/sphkerneldoc/commit/468ded71f62d497ac71aead1a6d50de7ef77c3c3
> 
> May be, I will drop it later, because all reST sources are generated
> by a make target and I always commit the whole reST tree. As I said, 
> it is a decision which might be made later, when the migration takes 
> places.

This is the uAPI spec DocBook, that we modify frequently, as we add
more features to the Kernel, and as we make sure that all drivers will
behave the same. So, from time to time, we need to clarify some topics
at the documentation. By having a numeration, it is easier for us to
discuss things like:
"1.2.10.14. V4L2_PIX_FMT_VYUY (‘VYUY’)" is not properly
described and requires some sort of clarification.

Ok, one could also refer to it via a hyperlink, but several Kernel
media maintainers prefer to generate a single big html file, as it
makes easier to locate everything it is needed on it.

So, with the item number, they can just seek

IMPORTANT MAIL TO YOU

2016-04-18 Thread verifelaw 
I am Capt. Lawrence Tyman, an officer in US Army,and also a West Point
Graduate, serving in the Military with the 82nd Air Borne Division
Peace keeping force deployed from Afganistan to Syria.  
We were moved to Syria from Iraq as the last batch just left,and i
really need your help in assisting me with the safe keeping of 1 military
trunk box contain funds amount of $10.2M which i secured on a raiding we 
carried out in 
January in one of the chief Syrian IsIs base which i headed the squard as the 
Captain.  With every possible arrangement to lift this box out, is intended to 
arrive 
Belgium from there a diplomat will deliver it to your designated location
I hope you can be trusted? You will be rewarded handsomely if you could help
me secure the funds until I conclude my service here in 3 month to meet you 
while we can 
plan head to head on a good and profitable business or company i can invest my 
funds in your country.
If you can be trusted and willing to support me in securing this safely kindly 
indicate 
by Letting me know this (1) Your name (2) Your address (3) Age (4) Occupation 
and 
i will explain further when i get a response from you
kindly contact me in this my private email address below: lawrencety...@gmx.com

Regards,
Capt. Lawrence Tyman
--
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 v3 6/7] media: rcar-vin: initialize EDID data

2016-04-18 Thread Hans Verkuil 
On 04/14/2016 06:17 PM, Ulrich Hecht wrote:
> Initializes the decoder subdevice with a fixed EDID blob.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 46 
> +
>  1 file changed, 46 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index ba2ed4e..5b32105 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -720,6 +720,41 @@ void rvin_v4l2_remove(struct rvin_dev *vin)
>   video_unregister_device(>vdev);
>  }
>  
> +static u8 edid[256] = {
> + 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
> + 0x48, 0xAE, 0x9C, 0x27, 0x00, 0x00, 0x00, 0x00,
> + 0x19, 0x12, 0x01, 0x03, 0x80, 0x00, 0x00, 0x78,
> + 0x0E, 0x00, 0xB2, 0xA0, 0x57, 0x49, 0x9B, 0x26,
> + 0x10, 0x48, 0x4F, 0x2F, 0xCF, 0x00, 0x31, 0x59,
> + 0x45, 0x59, 0x61, 0x59, 0x81, 0x99, 0x01, 0x01,
> + 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3A,
> + 0x80, 0x18, 0x71, 0x38, 0x2D, 0x40, 0x58, 0x2C,
> + 0x46, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1E,
> + 0x00, 0x00, 0x00, 0xFD, 0x00, 0x31, 0x55, 0x18,
> + 0x5E, 0x11, 0x00, 0x0A, 0x20, 0x20, 0x20, 0x20,
> + 0x20, 0x20, 0x00, 0x00, 0x00, 0xFC, 0x00, 0x43,
> + 0x20, 0x39, 0x30, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A,
> + 0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0x10,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x68,
> + 0x02, 0x03, 0x1a, 0xc0, 0x48, 0xa2, 0x10, 0x04,
> + 0x02, 0x01, 0x21, 0x14, 0x13, 0x23, 0x09, 0x07,
> + 0x07, 0x65, 0x03, 0x0c, 0x00, 0x10, 0x00, 0xe2,
> + 0x00, 0x2a, 0x01, 0x1d, 0x00, 0x80, 0x51, 0xd0,
> + 0x1c, 0x20, 0x40, 0x80, 0x35, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x1e, 0x8c, 0x0a, 0xd0, 0x8a,
> + 0x20, 0xe0, 0x2d, 0x10, 0x10, 0x3e, 0x96, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x18, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xd7
> +};

Where does this EDID come from? I'm just wondering if it has been
adjusted for the capabilities of the adv.

BTW, it is useful if userspace can read the EDID via VIDIOC_G_EDID.

In general I am of two minds whether the EDID should be set in the driver
or whether it should be left to userspace. The EDID contains vendor IDs
and things like that, which are generally better left to userspace for
embedded systems.

Note that the v4l2-ctl utility has support to fill the edid to a standard HDMI
EDID. See v4l2-ctl --help-edid.

My feeling is that it is better to add G/S_EDID support to the r-car driver
and not initialize the EDID at all.

Regards,

Hans

> +
>  int rvin_v4l2_probe(struct rvin_dev *vin)
>  {
>   struct v4l2_subdev_format fmt = {
> @@ -821,5 +856,16 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
>   v4l2_info(>v4l2_dev, "Device registered as %s\n",
> video_device_node_name(>vdev));
>  
> + {
> + struct v4l2_subdev_edid rvin_edid = {
> + .pad = 0,
> + .start_block = 0,
> + .blocks = 2,
> + .edid = edid,
> + };
> + v4l2_subdev_call(sd, pad, set_edid,
> + _edid);
> + }
> +
>   return ret;
>  }
> 

--
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 v3 5/7] media: rcar-vin: add DV timings support

2016-04-18 Thread Hans Verkuil 
Hi Ulrich,

This isn't right: this just overwrites the adv7180 input with an HDMI input.

I assume the intention is to have support for both adv7180 and HDMI input and
to use VIDIOC_S_INPUT to select between the two.

This really needs some more work, I'm afraid.

Regards,

Hans

On 04/14/2016 06:17 PM, Ulrich Hecht wrote:
> Adds ioctls DV_TIMINGS_CAP, ENUM_DV_TIMINGS, G_DV_TIMINGS, S_DV_TIMINGS,
> and QUERY_DV_TIMINGS.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 69 
> +
>  1 file changed, 69 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index d8d5f3a..ba2ed4e 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -413,12 +413,17 @@ static int rvin_enum_input(struct file *file, void 
> *priv,
>  struct v4l2_input *i)
>  {
>   struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
>  
>   if (i->index != 0)
>   return -EINVAL;
>  
>   i->type = V4L2_INPUT_TYPE_CAMERA;
>   i->std = vin->vdev.tvnorms;
> +
> + if (v4l2_subdev_has_op(sd, pad, dv_timings_cap))
> + i->capabilities = V4L2_IN_CAP_DV_TIMINGS;
> +
>   strlcpy(i->name, "Camera", sizeof(i->name));
>  
>   return 0;
> @@ -461,6 +466,64 @@ static int rvin_g_std(struct file *file, void *priv, 
> v4l2_std_id *a)
>   return v4l2_subdev_call(sd, video, g_std, a);
>  }
>  
> +static int rvin_enum_dv_timings(struct file *file, void *priv_fh,
> + struct v4l2_enum_dv_timings *timings)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> +
> + timings->pad = 0;
> + return v4l2_subdev_call(sd,
> + pad, enum_dv_timings, timings);
> +}
> +
> +static int rvin_s_dv_timings(struct file *file, void *priv_fh,
> + struct v4l2_dv_timings *timings)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> + int err;
> +
> + err = v4l2_subdev_call(sd,
> + video, s_dv_timings, timings);
> + if (!err) {
> + vin->sensor.width = timings->bt.width;
> + vin->sensor.height = timings->bt.height;
> + }
> + return err;
> +}
> +
> +static int rvin_g_dv_timings(struct file *file, void *priv_fh,
> + struct v4l2_dv_timings *timings)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> +
> + return v4l2_subdev_call(sd,
> + video, g_dv_timings, timings);
> +}
> +
> +static int rvin_query_dv_timings(struct file *file, void *priv_fh,
> + struct v4l2_dv_timings *timings)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> +
> + return v4l2_subdev_call(sd,
> + video, query_dv_timings, timings);
> +}
> +
> +static int rvin_dv_timings_cap(struct file *file, void *priv_fh,
> + struct v4l2_dv_timings_cap *cap)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + struct v4l2_subdev *sd = vin_to_sd(vin);
> +
> + cap->pad = 0;
> + return v4l2_subdev_call(sd,
> + pad, dv_timings_cap, cap);
> +}
> +
>  static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>   .vidioc_querycap= rvin_querycap,
>   .vidioc_try_fmt_vid_cap = rvin_try_fmt_vid_cap,
> @@ -477,6 +540,12 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>   .vidioc_g_input = rvin_g_input,
>   .vidioc_s_input = rvin_s_input,
>  
> + .vidioc_dv_timings_cap  = rvin_dv_timings_cap,
> + .vidioc_enum_dv_timings = rvin_enum_dv_timings,
> + .vidioc_g_dv_timings= rvin_g_dv_timings,
> + .vidioc_s_dv_timings= rvin_s_dv_timings,
> + .vidioc_query_dv_timings= rvin_query_dv_timings,
> +
>   .vidioc_querystd= rvin_querystd,
>   .vidioc_g_std   = rvin_g_std,
>   .vidioc_s_std   = rvin_s_std,
> 

--
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: [PATCHv4] [media] rcar-vin: add Renesas R-Car VIN driver

2016-04-18 Thread Hans Verkuil 
Hi Niklas,

Thanks for the patch. I've been testing this a bit more and there are a
few things missing.

On 04/12/2016 04:33 PM, Niklas Söderlund wrote:
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> new file mode 100644
> index 000..a752171
> --- /dev/null
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -0,0 +1,732 @@
> +/*
> + * Driver for Renesas R-Car VIN
> + *
> + * Copyright (C) 2016 Renesas Electronics Corp.
> + * Copyright (C) 2011-2013 Renesas Solutions Corp.
> + * Copyright (C) 2013 Cogent Embedded, Inc., 
> + * Copyright (C) 2008 Magnus Damm
> + *
> + * Based on the soc-camera rcar_vin driver
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "rcar-vin.h"
> +
> +#define RVIN_DEFAULT_FORMAT  V4L2_PIX_FMT_YUYV
> +#define RVIN_MAX_WIDTH   2048
> +#define RVIN_MAX_HEIGHT  2048
> +
> +/* 
> -
> + * Format Conversions
> + */
> +
> +static const struct rvin_video_format rvin_formats[] = {
> + {
> + .fourcc = V4L2_PIX_FMT_NV16,
> + .bpp= 1,
> + },
> + {
> + .fourcc = V4L2_PIX_FMT_YUYV,
> + .bpp= 2,
> + },
> + {
> + .fourcc = V4L2_PIX_FMT_UYVY,
> + .bpp= 2,
> + },
> + {
> + .fourcc = V4L2_PIX_FMT_RGB565,
> + .bpp= 2,
> + },
> + {
> + .fourcc = V4L2_PIX_FMT_XRGB555,
> + .bpp= 2,
> + },
> + {
> + .fourcc = V4L2_PIX_FMT_XBGR32,
> + .bpp= 4,
> + },
> +};
> +
> +const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(rvin_formats); i++)
> + if (rvin_formats[i].fourcc == pixelformat)
> + return rvin_formats + i;
> +
> + return NULL;
> +}
> +
> +static u32 rvin_format_bytesperline(struct v4l2_pix_format *pix)
> +{
> + const struct rvin_video_format *fmt;
> +
> + fmt = rvin_format_from_pixel(pix->pixelformat);
> +
> + if (WARN_ON(!fmt))
> + return -EINVAL;
> +
> + return pix->width * fmt->bpp;
> +}
> +
> +static u32 rvin_format_sizeimage(struct v4l2_pix_format *pix)
> +{
> + if (pix->pixelformat == V4L2_PIX_FMT_NV16)
> + return pix->bytesperline * pix->height * 2;
> +
> + return pix->bytesperline * pix->height;
> +}
> +
> +/* 
> -
> + * V4L2
> + */
> +
> +static int __rvin_try_format_sensor(struct rvin_dev *vin,
> + u32 which,
> + struct v4l2_pix_format *pix,
> + struct rvin_sensor *sensor)
> +{
> + struct v4l2_subdev *sd;
> + struct v4l2_subdev_pad_config pad_cfg;
> + struct v4l2_subdev_format format = {
> + .which = which,
> + };
> + int ret;
> +
> + sd = vin_to_sd(vin);
> +
> + v4l2_fill_mbus_format(, pix, vin->sensor.code);
> +
> + ret = v4l2_device_call_until_err(sd->v4l2_dev, 0, pad, set_fmt,
> +  _cfg, );
> + if (ret < 0)
> + return ret;
> +
> + v4l2_fill_pix_format(pix, );
> +
> + sensor->width = pix->width;
> + sensor->height = pix->height;
> +
> + vin_dbg(vin, "Sensor format: %ux%u\n", sensor->width, sensor->height);
> +
> + return 0;
> +}
> +
> +static int __rvin_try_format(struct rvin_dev *vin,
> +  u32 which,
> +  struct v4l2_pix_format *pix,
> +  struct rvin_sensor *sensor)
> +{
> + const struct rvin_video_format *info;
> + u32 rwidth, rheight, walign;
> +
> + /* Requested */
> + rwidth = pix->width;
> + rheight = pix->height;
> +
> + /*
> +  * Retrieve format information and select the current format if the
> +  * requested format isn't supported.
> +  */
> + info = rvin_format_from_pixel(pix->pixelformat);
> + if (!info) {
> + vin_dbg(vin, "Format %x not found, keeping %x\n",
> + pix->pixelformat, vin->format.pixelformat);
> + *pix = vin->format;
> + pix->width = rwidth;
> + pix->height = rheight;
> + }
> +
> + /* Always recalculate */
> +

Re: Kernel docs: muddying the waters a bit

2016-04-18 Thread Markus Heiser 
Hi Jonahtan,

Am 12.04.2016 um 17:46 schrieb Jonathan Corbet :

> On Fri, 8 Apr 2016 17:12:27 +0200
> Markus Heiser  wrote:
> 
>> motivated by this MT, I implemented a toolchain to migrate the kernel’s 
>> DocBook XML documentation to reST markup. 
>> 
>> It converts 99% of the docs well ... to gain an impression how 
>> kernel-docs could benefit from, visit my sphkerneldoc project page
>> on github:
>> 
>>  http://return42.github.io/sphkerneldoc/
> 
> So I've obviously been pretty quiet on this recently.  Apologies...I've
> been dealing with an extended death-in-the-family experience, and there is
> still a fair amount of cleanup to be done.
> 
> Looking quickly at this work, it seems similar to the results I got.  But
> there's a lot of code there that came from somewhere?

>From me? ... except the kernel-doc script which is a fork from your 

  git://git.lwn.net/linux.git doc/sphinx


>  I'd put together a
> fairly simple conversion using pandoc and a couple of short sed scripts;
> is there a reason for a more complex solution?

It depends. If you have a simple DocBook with less various markup, maybe not.
May you want to read my remarks about migration tools and especially pandoc:

* 
https://return42.github.io/sphkerneldoc/articles/dbtools.html#remarks-on-pandoc

A few more words about, what I have done:

I wrote a lib of XML filters which might be also usefully in other
migration projects (dbxml). 

* https://github.com/return42/sphkerneldoc/blob/master/scripts/dbxml.py

It uses a xml-parser, pandoc, pandoc-filters and regular expressions. Because
I did not implemented a whole converter, I hacked around pandoc. Thats why
conversion is done in several steps:

1. copy xml file(s) to a cache space

2. substitude unsolved internal and external entities

3. filter all xml files

   * run custom hooks on every node 

   * apply filters on every node and inject reST into the XML-tree where pandoc 
fails.
 https://github.com/return42/sphkerneldoc/blob/master/scripts/dbxml.py#L515

4. convert intermediary XML result with pandoc to json (needed by pandoc 
filters)

5. apply pandoc-filter and clean up the injected reST markup from step3

6. convert filtered json to reST

7. fix the produce reST with regular expression

... the last step is similar to your sed scripts.


And I wrote a commandline Interface to use this lib (see func db2rst):

* https://github.com/return42/sphkerneldoc/blob/master/scripts/dbtools.py#L146
 
With this db2rst all kernel DB-XML books could be migrated, except the linux-tv
book, which has much more complexity. For this, there is a separated commandline
called media2rst

* https://github.com/return42/sphkerneldoc/blob/master/scripts/dbtools.py#L107

The media2rst needs several special handlings, which is implemented in 
hooks (the dbxml interface method)

* https://github.com/return42/sphkerneldoc/blob/master/scripts/media.py

Summarize, why should one prefer this tools over pandoc + sed?

* Pandoc coverage is less on reading and writing, this is where 
  dbxml comes into play

  - reading DocBook: 

https://github.com/jgm/pandoc/blob/master/src/Text/Pandoc/Readers/DocBook.hs#L23
  
  - writing reST has many bugs and leaks 
(you fixed some of them with sed)

* Pandoc does not support external entities (linux-tv), covered by dbxml

* dbxml brings the ability to chunk one large XML book into small 
  reST chunks e.g. kernel-hacking book:


https://github.com/return42/sphkerneldoc/tree/master/doc/books/kernel-hacking

* dbxml lets you manipulate the XML source before you convert it to reST

  this might helpfull e.g. if you have to convert single-column informal-tables 
  to lists or other things ... in short; dbxml and it's hooks are the key to 
hack
  everything you need in a full automated DocBook-->reST migration workflow.


--Markus--

> Thanks for looking into this, anyway; I hope to be able to focus more on
> it shortly.
> 
> jon
> --
> 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] r8a7791-koelsch.dts: add HDMI input

2016-04-18 Thread Hans Verkuil 
Add support in the dts for the HDMI input. Based on the Lager dts
patch from Ultich Hecht.

Signed-off-by: Hans Verkuil 
---
Ulrich, can you add this patch to your r-car HDMI patch series?

Thanks!

Hans
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 0ad71b8..e4c2ec83 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -394,6 +394,11 @@
renesas,function = "usb1";
};

+   vin0_pins: vin0 {
+   renesas,groups = "vin0_data24", "vin0_sync", "vin0_clkenb", 
"vin0_clk";
+   renesas,function = "vin0";
+   };
+
vin1_pins: vin1 {
renesas,groups = "vin1_data8", "vin1_clk";
renesas,function = "vin1";
@@ -552,6 +557,21 @@
reg = <0x12>;
};

+   hdmi-in@4c {
+   compatible = "adi,adv7612";
+   reg = <0x4c>;
+   interrupt-parent = <>;
+   interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+   remote = <>;
+   default-input = <0>;
+
+   port {
+   adv7612: endpoint {
+   remote-endpoint = <>;
+   };
+   };
+   };
+
composite-in@20 {
compatible = "adi,adv7180";
reg = <0x20>;
@@ -672,6 +692,27 @@
cpu0-supply = <_dvfs>;
 };

+/* HDMI video input */
+ {
+   status = "okay";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vin0ep: endpoint {
+   remote-endpoint = <>;
+   bus-width = <24>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   data-active = <1>;
+   };
+   };
+};
+
 /* composite video input */
  {
status = "okay";
-- 
2.8.0.rc3

--
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: Backport a Security Fix for CVE-2015-7833 to v4.1

2016-04-18 Thread Vladis Dronov 
Hello, Yuki, all,

> Why "usbvision: revert commit 588afcc1" is not accepted in linux-media ?

As mentioned in a message from Hans down this thread, it "fell through the 
cracks",
unfortunately. (http://www.spinics.net/lists/linux-media/msg99495.html)

Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer

- Original Message -
From: "Yuki Machida" 
To: "Vladis Dronov" 
Cc: "sasha levin" , linux-media@vger.kernel.org, 
sta...@vger.kernel.org, hverk...@xs4all.nl, oneu...@suse.com, 
mche...@osg.samsung.com, r...@spenneberg.net
Sent: Monday, April 18, 2016 10:32:12 AM
Subject: Re: Backport a Security Fix for CVE-2015-7833 to v4.1

Hi Vladis,

On 2016年04月15日 18:55, Vladis Dronov wrote:
> Hello, Yuki, all,
>
> My commit fa52bd506f resolves CVE-2015-7833, as mentioned in
> https://www.spinics.net/lists/linux-media/msg96936.html
I understand that commit fa52bd506f resolved security issue of CVE-2015-7833
and commit 588afcc1 is not needed for fixing of CVE-2015-7833.

> Please, note a message from Hans down this thread, who agrees
> with my point.
I understand the opinion of Vladis and Hans.
Why "usbvision: revert commit 588afcc1" is not accepted in linux-media ?

Regards,
Yuki Machida
--
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: Backport a Security Fix for CVE-2015-7833 to v4.1

2016-04-18 Thread Yuki Machida 

Hi Greg and Sasha,

Please do not accept patch of 588afcc to stable tree,
because above patch has some problem.
It reported by Vladis and Hans.
https://patchwork.linuxtv.org/patch/32798/
https://www.spinics.net/lists/linux-media/msg96936.html
http://article.gmane.org/gmane.linux.kernel.stable/174202/match=cve+2015+7833

Thank you for your help.

Regards,
Yuki Machida

On 2016年04月15日 18:55, Vladis Dronov wrote:

Hello, Yuki, all,

My commit fa52bd506f resolves CVE-2015-7833, as mentioned in
https://www.spinics.net/lists/linux-media/msg96936.html

Please, note a message from Hans down this thread, who agrees
with my point.

Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer

- Original Message -
From: "Yuki Machida" 
To: "Vladis Dronov" 
Cc: "sasha levin" , linux-media@vger.kernel.org, 
sta...@vger.kernel.org, hverk...@xs4all.nl, oneu...@suse.com, mche...@osg.samsung.com, 
r...@spenneberg.net
Sent: Friday, April 15, 2016 10:31:17 AM
Subject: Re: Backport a Security Fix for CVE-2015-7833 to v4.1

Hi Vladis,

  > I apologize for intercepting, but I believe commit 588afcc1 should
  > not be accepted and reverted in the trees where it was.
  >
  > Reasons:
  >
  > https://patchwork.linuxtv.org/patch/32798/
  > or
  > https://www.spinics.net/lists/linux-media/msg96936.html
Thank you for your reply.

If it revert commit 588afcc1 from the kernel,
It exists a Security Issue of CVE-2015-7833.
What do you think about it?

Best regards,
Yuki Machida

On 2016年04月11日 21:03, Vladis Dronov wrote:

Hello,

I apologize for intercepting, but I believe commit 588afcc1 should
not be accepted and reverted in the trees where it was.

Reasons:

https://patchwork.linuxtv.org/patch/32798/
or
https://www.spinics.net/lists/linux-media/msg96936.html


Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer

- Original Message -
From: "Yuki Machida" 
To: "sasha levin" 
Cc: linux-media@vger.kernel.org, sta...@vger.kernel.org, hverk...@xs4all.nl, 
oneu...@suse.com, vdro...@redhat.com, mche...@osg.samsung.com, 
r...@spenneberg.net
Sent: Monday, April 11, 2016 7:19:34 AM
Subject: Backport a Security Fix for CVE-2015-7833 to v4.1

Hi Sasha,

I conformed that these patches for CVE-2015-7833 not applied at v4.1.21.
588afcc1c0e45358159090d95bf7b246fb67565
fa52bd506f274b7619955917abfde355e3d19ff
Could you please apply this CVE-2015-7833 fix for 4.1-stable ?

References:
https://security-tracker.debian.org/tracker/CVE-2015-7833
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=588afcc1c0e45358159090d95bf7b246fb67565f
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fa52bd506f274b7619955917abfde355e3d19ffe

Regards,
Yuki Machida


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


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

Re: Backport a Security Fix for CVE-2015-7833 to v4.1

2016-04-18 Thread Yuki Machida 

Hi Vladis,

On 2016年04月15日 18:55, Vladis Dronov wrote:

Hello, Yuki, all,

My commit fa52bd506f resolves CVE-2015-7833, as mentioned in
https://www.spinics.net/lists/linux-media/msg96936.html

I understand that commit fa52bd506f resolved security issue of CVE-2015-7833
and commit 588afcc1 is not needed for fixing of CVE-2015-7833.


Please, note a message from Hans down this thread, who agrees
with my point.

I understand the opinion of Vladis and Hans.
Why "usbvision: revert commit 588afcc1" is not accepted in linux-media ?



Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer

- Original Message -
From: "Yuki Machida" 
To: "Vladis Dronov" 
Cc: "sasha levin" , linux-media@vger.kernel.org, 
sta...@vger.kernel.org, hverk...@xs4all.nl, oneu...@suse.com, mche...@osg.samsung.com, 
r...@spenneberg.net
Sent: Friday, April 15, 2016 10:31:17 AM
Subject: Re: Backport a Security Fix for CVE-2015-7833 to v4.1

Hi Vladis,

  > I apologize for intercepting, but I believe commit 588afcc1 should
  > not be accepted and reverted in the trees where it was.
  >
  > Reasons:
  >
  > https://patchwork.linuxtv.org/patch/32798/
  > or
  > https://www.spinics.net/lists/linux-media/msg96936.html
Thank you for your reply.

If it revert commit 588afcc1 from the kernel,
It exists a Security Issue of CVE-2015-7833.
What do you think about it?

Best regards,
Yuki Machida

On 2016年04月11日 21:03, Vladis Dronov wrote:

Hello,

I apologize for intercepting, but I believe commit 588afcc1 should
not be accepted and reverted in the trees where it was.

Reasons:

https://patchwork.linuxtv.org/patch/32798/
or
https://www.spinics.net/lists/linux-media/msg96936.html


Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer

- Original Message -
From: "Yuki Machida" 
To: "sasha levin" 
Cc: linux-media@vger.kernel.org, sta...@vger.kernel.org, hverk...@xs4all.nl, 
oneu...@suse.com, vdro...@redhat.com, mche...@osg.samsung.com, 
r...@spenneberg.net
Sent: Monday, April 11, 2016 7:19:34 AM
Subject: Backport a Security Fix for CVE-2015-7833 to v4.1

Hi Sasha,

I conformed that these patches for CVE-2015-7833 not applied at v4.1.21.
588afcc1c0e45358159090d95bf7b246fb67565
fa52bd506f274b7619955917abfde355e3d19ff
Could you please apply this CVE-2015-7833 fix for 4.1-stable ?

References:
https://security-tracker.debian.org/tracker/CVE-2015-7833
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=588afcc1c0e45358159090d95bf7b246fb67565f
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fa52bd506f274b7619955917abfde355e3d19ffe

Regards,
Yuki Machida


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



Regards,
Yuki Machida
--
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 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

2016-04-18 Thread tiffany lin 
Hi Hans,

On Mon, 2016-04-18 at 09:32 +0200, Hans Verkuil wrote:
> On 04/18/2016 07:40 AM, tiffany lin wrote:
> > 
> > snipped.
> > 
> >>> +
> >>> +void mtk_vcodec_dec_set_default_params(struct mtk_vcodec_ctx *ctx)
> >>> +{
> >>> + struct mtk_q_data *q_data;
> >>> +
> >>> + ctx->m2m_ctx->q_lock = >dev->dev_mutex;
> >>> + ctx->fh.m2m_ctx = ctx->m2m_ctx;
> >>> + ctx->fh.ctrl_handler = >ctrl_hdl;
> >>> + INIT_WORK(>decode_work, mtk_vdec_worker);
> >>> +
> >>> + q_data = >q_data[MTK_Q_DATA_SRC];
> >>> + memset(q_data, 0, sizeof(struct mtk_q_data));
> >>> + q_data->visible_width = DFT_CFG_WIDTH;
> >>> + q_data->visible_height = DFT_CFG_HEIGHT;
> >>> + q_data->fmt = _video_formats[OUT_FMT_IDX];
> >>> + q_data->colorspace = V4L2_COLORSPACE_REC709;
> >>> + q_data->field = V4L2_FIELD_NONE;
> >>> + ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
> >>> + DFT_CFG_WIDTH * DFT_CFG_HEIGHT;
> >>> + ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] = 0;
> >>> +
> >>> +
> >>> + q_data = >q_data[MTK_Q_DATA_DST];
> >>> + memset(q_data, 0, sizeof(struct mtk_q_data));
> >>> + q_data->visible_width = DFT_CFG_WIDTH;
> >>> + q_data->visible_height = DFT_CFG_HEIGHT;
> >>> + q_data->coded_width = DFT_CFG_WIDTH;
> >>> + q_data->coded_height = DFT_CFG_HEIGHT;
> >>> + q_data->colorspace = V4L2_COLORSPACE_REC709;
> >>> + q_data->field = V4L2_FIELD_NONE;
> >>> +
> >>> + q_data->fmt = _video_formats[CAP_FMT_IDX];
> >>> +
> >>> + v4l_bound_align_image(_data->coded_width,
> >>> + MTK_VDEC_MIN_W,
> >>> + MTK_VDEC_MAX_W, 4,
> >>> + _data->coded_height,
> >>> + MTK_VDEC_MIN_H,
> >>> + MTK_VDEC_MAX_H, 5, 6);
> >>> +
> >>> + q_data->sizeimage[0] = q_data->coded_width * q_data->coded_height;
> >>> + q_data->bytesperline[0] = q_data->coded_width;
> >>> + q_data->sizeimage[1] = q_data->sizeimage[0] / 2;
> >>> + q_data->bytesperline[1] = q_data->coded_width;
> >>> +
> >>> +}
> >>> +
> >>> +static int vidioc_vdec_streamon(struct file *file, void *priv,
> >>> + enum v4l2_buf_type type)
> >>> +{
> >>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +
> >>> + mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
> >>> +
> >>> + return v4l2_m2m_streamon(file, ctx->m2m_ctx, type);
> >>> +}
> >>> +
> >>> +static int vidioc_vdec_streamoff(struct file *file, void *priv,
> >>> +  enum v4l2_buf_type type)
> >>> +{
> >>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +
> >>> + mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
> >>> + return v4l2_m2m_streamoff(file, ctx->m2m_ctx, type);
> >>> +}
> >>> +
> >>> +static int vidioc_vdec_reqbufs(struct file *file, void *priv,
> >>> +struct v4l2_requestbuffers *reqbufs)
> >>> +{
> >>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> + int ret;
> >>> +
> >>> + mtk_v4l2_debug(3, "[%d] (%d) count=%d", ctx->idx,
> >>> +  reqbufs->type, reqbufs->count);
> >>> + ret = v4l2_m2m_reqbufs(file, ctx->m2m_ctx, reqbufs);
> >>> +
> >>> + return ret;
> >>> +}
> >>
> >> Please use the v4l2_m2m_ioctl_* helper functions were applicable.
> >>
> > 
> > 
> > 
> > snipped.
> >>> +static unsigned int fops_vcodec_poll(struct file *file,
> >>> +  struct poll_table_struct *wait)
> >>> +{
> >>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
> >>> + struct mtk_vcodec_dev *dev = ctx->dev;
> >>> + int ret;
> >>> +
> >>> + mutex_lock(>dev_mutex);
> >>> + ret = v4l2_m2m_poll(file, ctx->m2m_ctx, wait);
> >>> + mutex_unlock(>dev_mutex);
> >>> +
> >>> + return ret;
> >>> +}
> >>> +
> >>> +static int fops_vcodec_mmap(struct file *file, struct vm_area_struct 
> >>> *vma)
> >>> +{
> >>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
> >>> +
> >>> + return v4l2_m2m_mmap(file, ctx->m2m_ctx, vma);
> >>> +}
> >>> +
> >>> +static const struct v4l2_file_operations mtk_vcodec_fops = {
> >>> + .owner  = THIS_MODULE,
> >>> + .open   = fops_vcodec_open,
> >>> + .release= fops_vcodec_release,
> >>> + .poll   = fops_vcodec_poll,
> >>> + .unlocked_ioctl = video_ioctl2,
> >>> + .mmap   = fops_vcodec_mmap,
> >>
> >> You should be able to use the v4l2_m2m_fop helper functions for poll and 
> >> mmap.
> >>
> > 
> > Hi Hans,
> > 
> > We are plaining to remove m2m framework in th feature, although we think
> 
> Remove it for just the decoder driver or both encoder and decoder?
> 
Remove it from decoder driver.

> > it is easy to use and could save a lot of code similar to what m2m
> > framework implemented and reduce code size.
> > The main reason is that in v4l2_m2m_try_schedule, it required that at
> > least one output buffer and one capture buffer to run device_run.
> > We want to start device_run without capture buffer queued.
>

Re: [PATCH v6 20/24] iio: imu: inv_mpu6050: change the i2c gate to be mux-locked

2016-04-18 Thread Daniel Baluta 
On Sun, Apr 3, 2016 at 1:54 PM, Jonathan Cameron  wrote:
> On 03/04/16 09:52, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> The root i2c adapter lock is then no longer held by the i2c mux during
>> accesses behind the i2c gate, and such accesses need to take that lock
>> just like any other ordinary i2c accesses do.
>>
>> So, declare the i2c gate mux-locked, and zap the code that makes the
>> unlocked i2c accesses and just use ordinary regmap_write accesses.
>>
>> This also happens to fix the deadlock described in
>> http://patchwork.ozlabs.org/patch/584776/ authored by
>> Adriana Reus  and submitted by
>> Daniel Baluta 
>>
>> --8<--
>> iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock
>>
>> This deadlock occurs if the accel/gyro and the sensor on the auxiliary
>> I2C (in my setup it's an ak8975) are working at the same time.
>>
>> Scenario:
>>
>>   T1  T2
>>  
>> inv_mpu6050_read_fifo  aux sensor op (eg. ak8975_read_raw)
>> | |
>> mutex_lock(_dev->mlock)   i2c_transfer
>> | |
>> i2c transaction i2c adapter lock
>> | |
>> i2c adapter locki2c_mux_master_xfer
>>   |
>> inv_mpu6050_select_bypass
>>   |
>> mutex_lock(_dev->mlock)
>>
>> When we operate on an mpu sensor the order of locking is mpu lock
>> followed by the i2c adapter lock. However, when we operate the auxiliary
>> sensor the order of locking is the other way around.
>>
>> ...
>> --8<--
>>
>> The reason this patch fixes the deadlock is that T2 does not grab the
>> i2c adapter lock until the very end (and grabs the newfangled i2c mux
>> lock where it previously grabbed the i2c adapter lock).
>>
>> Signed-off-by: Peter Rosin 
> This one obviously wants a ack from Adriana or Daniel in addition to mine.
> I'm more than happy for these to go through the i2c tree btw.
>
> Acked-by: Jonathan Cameron 

Acked-by: Daniel Baluta 


>> ---
>>  Documentation/i2c/i2c-topology|  2 +-
>>  drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 56 
>> +++
>>  2 files changed, 13 insertions(+), 45 deletions(-)
>>
>> diff --git a/Documentation/i2c/i2c-topology b/Documentation/i2c/i2c-topology
>> index 7a10edd0874f..346623a80bd1 100644
>> --- a/Documentation/i2c/i2c-topology
>> +++ b/Documentation/i2c/i2c-topology
>> @@ -50,7 +50,7 @@ i2c-mux-pinctrl   Normally parent-locked, 
>> mux-locked iff
>>  i2c-mux-reg   Parent-locked
>>
>>  In drivers/iio/
>> -imu/inv_mpu6050/  Parent-locked
>> +imu/inv_mpu6050/  Mux-locked
>>
>>  In drivers/media/
>>  dvb-frontends/m88ds3103   Parent-locked
>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c 
>> b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>> index 0d429d788106..71ad31a275c9 100644
>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>> @@ -24,45 +24,16 @@ static const struct regmap_config inv_mpu_regmap_config 
>> = {
>>   .val_bits = 8,
>>  };
>>
>> -/*
>> - * The i2c read/write needs to happen in unlocked mode. As the parent
>> - * adapter is common. If we use locked versions, it will fail as
>> - * the mux adapter will lock the parent i2c adapter, while calling
>> - * select/deselect functions.
>> - */
>> -static int inv_mpu6050_write_reg_unlocked(struct i2c_client *client,
>> -   u8 reg, u8 d)
>> -{
>> - int ret;
>> - u8 buf[2] = {reg, d};
>> - struct i2c_msg msg[1] = {
>> - {
>> - .addr = client->addr,
>> - .flags = 0,
>> - .len = sizeof(buf),
>> - .buf = buf,
>> - }
>> - };
>> -
>> - ret = __i2c_transfer(client->adapter, msg, 1);
>> - if (ret != 1)
>> - return ret;
>> -
>> - return 0;
>> -}
>> -
>>  static int inv_mpu6050_select_bypass(struct i2c_mux_core *muxc, u32 chan_id)
>>  {
>> - struct i2c_client *client = i2c_mux_priv(muxc);
>> - struct iio_dev *indio_dev = dev_get_drvdata(>dev);
>> + struct iio_dev *indio_dev = i2c_mux_priv(muxc);
>>   struct inv_mpu6050_state *st = iio_priv(indio_dev);
>>   int ret = 0;
>>
>>   /* Use the same mutex which was used everywhere to protect power-op */
>>   mutex_lock(_dev->mlock);
>>   if (!st->powerup_count) {
>> - ret = inv_mpu6050_write_reg_unlocked(client,
>> -

Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver

2016-04-18 Thread Hans Verkuil 
On 04/18/2016 07:40 AM, tiffany lin wrote:
> 
> snipped.
> 
>>> +
>>> +void mtk_vcodec_dec_set_default_params(struct mtk_vcodec_ctx *ctx)
>>> +{
>>> +   struct mtk_q_data *q_data;
>>> +
>>> +   ctx->m2m_ctx->q_lock = >dev->dev_mutex;
>>> +   ctx->fh.m2m_ctx = ctx->m2m_ctx;
>>> +   ctx->fh.ctrl_handler = >ctrl_hdl;
>>> +   INIT_WORK(>decode_work, mtk_vdec_worker);
>>> +
>>> +   q_data = >q_data[MTK_Q_DATA_SRC];
>>> +   memset(q_data, 0, sizeof(struct mtk_q_data));
>>> +   q_data->visible_width = DFT_CFG_WIDTH;
>>> +   q_data->visible_height = DFT_CFG_HEIGHT;
>>> +   q_data->fmt = _video_formats[OUT_FMT_IDX];
>>> +   q_data->colorspace = V4L2_COLORSPACE_REC709;
>>> +   q_data->field = V4L2_FIELD_NONE;
>>> +   ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
>>> +   DFT_CFG_WIDTH * DFT_CFG_HEIGHT;
>>> +   ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] = 0;
>>> +
>>> +
>>> +   q_data = >q_data[MTK_Q_DATA_DST];
>>> +   memset(q_data, 0, sizeof(struct mtk_q_data));
>>> +   q_data->visible_width = DFT_CFG_WIDTH;
>>> +   q_data->visible_height = DFT_CFG_HEIGHT;
>>> +   q_data->coded_width = DFT_CFG_WIDTH;
>>> +   q_data->coded_height = DFT_CFG_HEIGHT;
>>> +   q_data->colorspace = V4L2_COLORSPACE_REC709;
>>> +   q_data->field = V4L2_FIELD_NONE;
>>> +
>>> +   q_data->fmt = _video_formats[CAP_FMT_IDX];
>>> +
>>> +   v4l_bound_align_image(_data->coded_width,
>>> +   MTK_VDEC_MIN_W,
>>> +   MTK_VDEC_MAX_W, 4,
>>> +   _data->coded_height,
>>> +   MTK_VDEC_MIN_H,
>>> +   MTK_VDEC_MAX_H, 5, 6);
>>> +
>>> +   q_data->sizeimage[0] = q_data->coded_width * q_data->coded_height;
>>> +   q_data->bytesperline[0] = q_data->coded_width;
>>> +   q_data->sizeimage[1] = q_data->sizeimage[0] / 2;
>>> +   q_data->bytesperline[1] = q_data->coded_width;
>>> +
>>> +}
>>> +
>>> +static int vidioc_vdec_streamon(struct file *file, void *priv,
>>> +   enum v4l2_buf_type type)
>>> +{
>>> +   struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +
>>> +   mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
>>> +
>>> +   return v4l2_m2m_streamon(file, ctx->m2m_ctx, type);
>>> +}
>>> +
>>> +static int vidioc_vdec_streamoff(struct file *file, void *priv,
>>> +enum v4l2_buf_type type)
>>> +{
>>> +   struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +
>>> +   mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
>>> +   return v4l2_m2m_streamoff(file, ctx->m2m_ctx, type);
>>> +}
>>> +
>>> +static int vidioc_vdec_reqbufs(struct file *file, void *priv,
>>> +  struct v4l2_requestbuffers *reqbufs)
>>> +{
>>> +   struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +   int ret;
>>> +
>>> +   mtk_v4l2_debug(3, "[%d] (%d) count=%d", ctx->idx,
>>> +reqbufs->type, reqbufs->count);
>>> +   ret = v4l2_m2m_reqbufs(file, ctx->m2m_ctx, reqbufs);
>>> +
>>> +   return ret;
>>> +}
>>
>> Please use the v4l2_m2m_ioctl_* helper functions were applicable.
>>
> 
> 
> 
> snipped.
>>> +static unsigned int fops_vcodec_poll(struct file *file,
>>> +struct poll_table_struct *wait)
>>> +{
>>> +   struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
>>> +   struct mtk_vcodec_dev *dev = ctx->dev;
>>> +   int ret;
>>> +
>>> +   mutex_lock(>dev_mutex);
>>> +   ret = v4l2_m2m_poll(file, ctx->m2m_ctx, wait);
>>> +   mutex_unlock(>dev_mutex);
>>> +
>>> +   return ret;
>>> +}
>>> +
>>> +static int fops_vcodec_mmap(struct file *file, struct vm_area_struct *vma)
>>> +{
>>> +   struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
>>> +
>>> +   return v4l2_m2m_mmap(file, ctx->m2m_ctx, vma);
>>> +}
>>> +
>>> +static const struct v4l2_file_operations mtk_vcodec_fops = {
>>> +   .owner  = THIS_MODULE,
>>> +   .open   = fops_vcodec_open,
>>> +   .release= fops_vcodec_release,
>>> +   .poll   = fops_vcodec_poll,
>>> +   .unlocked_ioctl = video_ioctl2,
>>> +   .mmap   = fops_vcodec_mmap,
>>
>> You should be able to use the v4l2_m2m_fop helper functions for poll and 
>> mmap.
>>
> 
> Hi Hans,
> 
> We are plaining to remove m2m framework in th feature, although we think

Remove it for just the decoder driver or both encoder and decoder?

> it is easy to use and could save a lot of code similar to what m2m
> framework implemented and reduce code size.
> The main reason is that in v4l2_m2m_try_schedule, it required that at
> least one output buffer and one capture buffer to run device_run.
> We want to start device_run without capture buffer queued.

I assume the reason is that you need to get the resolution etc. information
from the encoded stream? Without a capture buffer you can't actually decode
a frame, but that's probably not what this is about.

> Is there any suggestion that we

Re: [PATCH 1/2] [media] atmel-isc: add the Image Sensor Controller code

2016-04-18 Thread Hans Verkuil 
On 04/13/2016 09:44 AM, Songjun Wu wrote:
> Add driver for the Image Sensor Controller. It manages
> incoming data from a parallel based CMOS/CCD sensor.
> It has an internal image processor, also integrates a
> triple channel direct memory access controller master
> interface.
> 
> Signed-off-by: Songjun Wu 

Hi Songjun,

Before this driver can be accepted it has to pass the v4l2-compliance test.
The v4l2-compliance utility is here:

git://linuxtv.org/v4l-utils.git

Compile the utility straight from this repository so you're up to date.

First fix any failures you get when running 'v4l2-compliance', then do the
same when running 'v4l2-compliance -s' (now it is streaming as well) and
finally when running 'v4l2-compliance -f' (streaming and testing all available
formats).

I would like to see the output of 'v4l2-compliance -f' as part of the cover
letter of the next patch series.

Looking at the code I see that it will definitely fail a few tests :-)

Certainly the VIDIOC_CREATE_BUFS support in the queue_setup function is missing.
Read the comments for queue_setup in videobuf2-core.h for more information.

Regards,

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

Re: [PATCH] [media] smiapp: provide g_skip_top_lines method in sensor ops

2016-04-18 Thread Ivaylo Dimitrov 

Hi,

On 18.04.2016 00:44, Sakari Ailus wrote:

Hi Ivaylo,

On Sat, Apr 16, 2016 at 11:12:20AM +0300, Ivaylo Dimitrov wrote:

Some sensors (like the one in Nokia N900) provide metadata in the first
couple of lines. Make that information information available to the
pipeline.

Signed-off-by: Ivaylo Dimitrov 
---
  drivers/media/i2c/smiapp/smiapp-core.c | 12 
  drivers/media/i2c/smiapp/smiapp.h  |  1 +
  2 files changed, 13 insertions(+)


...


I'm afraid I think this is not exactly the best way to approach the issue.
It'd work, somehow, yes, but ---

1. A compliant sensor (at least in theory) is able to tell this information
itself. The number of metadata lines is present in the sensor frame format
descriptors.



Right. And this is where that number is taken from in the patch and made 
available to whoever wants to use it. See 
http://lxr.free-electrons.com/source/drivers/media/i2c/smiapp/smiapp-core.c#L177 
. I don't really understand your point here. Maybe the patch description 
is fuzzy? Could you elaborate?



2. The more generic problem of describing the frame layout should be solved.
Sensor metadata is just a special case of this. I've proposed frame
descriptors (see an old RFC
), but this is
just a partial solution as well; the APIs would need to be extended to
support metadata capture (I think Laurent has been working on that).



Could be, however what we have right now is 
http://lxr.free-electrons.com/source/drivers/media/platform/omap3isp/ispccp2.c#L369. 
Also, the patch is not trying to solve the problem with frame format 
description(or anything in general), but a mere way to pass an already 
available information in the sensor which is needed by omap3isp, by 
using an already existing API. I don't see how's that related to the way 
v4l API going to evolve in some (distant?) future. Not to say that once 
those frame format descriptors are available, it should be relatively 
easy to simply remove g_skip_top_lines form v4l2_subdev_sensor_ops and 
fix the drivers to use the new API.


BTW if you have any idea on how to pass (or set) the number of lines to 
be skipped at the start of the frame to omap3isp driver in some other 
way, I am fine with dropping the $subject patch and sending another one 
implementing your proposal.


Regards,
Ivo
--
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