cron job: media_tree daily build: ERRORS

2017-07-27 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:   Fri Jul 28 05:00:28 CEST 2017
media-tree git hash:da48c948c263c9d87dfc64566b3373a858cc8aa2
media_build git hash:   1abc6be7b313cb92ff9128cea3d69df7f63e725f
v4l-utils git hash: 06273a34de574ed2c89e9a655012ce4ee1136f9e
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.11.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
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: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: 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: ERRORS
linux-4.11-i686: OK
linux-4.12.1-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: ERRORS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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


Re: [PATCH v4] uvcvideo: add a metadata device node

2017-07-27 Thread Laurent Pinchart
Hi Guennadi,

On Tuesday 25 Jul 2017 15:27:24 Guennadi Liakhovetski wrote:
> On Fri, 21 Jul 2017, Laurent Pinchart wrote:
> > Hi Guennadi,
> > 
> > Thank you for the patch.
> > 
> >> Some UVC video cameras contain metadata in their payload headers. This
> >> patch extracts that data, adding more clock synchronisation information,
> >> on both bulk and isochronous endpoints and makes it available to the
> >> user space on a separate video node, using the V4L2_CAP_META_CAPTURE
> >> capability and the V4L2_BUF_TYPE_META_CAPTURE buffer queue type. Even
> >> though different cameras will have different metadata formats, we use
> >> the same V4L2_META_FMT_UVC pixel format for all of them. Users have to
> >> parse data, based on the specific camera model information.
> > 
> > The issue we still haven't addressed is how to ensure that vendors will
> > document their metadata format :-S
> 
> Uhm, add a black list of offending vendors and drop 60% of their frames?
> ;-)

This was actually a serious question :-)

How about white-listing cameras instead, and enabling extended metadata (after 
the standard header) support only for vendors who have documented their format 
?

Speaking of which, where's the documentation for the camera you're working on 
? :-)

> >> This version of the patch only creates such metadata nodes for cameras,
> >> specifying a UVC_QUIRK_METADATA_NODE quirk flag.
> >> 
> >> Signed-off-by: Guennadi Liakhovetski 
> >> ---
> >> 
> >> v4:
> >> - add support for isochronous cameras. Metadata is now collected from as
> >> many payloads as they fit in the buffer
> >> - add a USB Start Of Frame and a system timestamp to each metadata block
> >> for user-space clock synchronisation
> >> - use a default buffer size of 1024 bytes
> >> 
> >> Thanks to Laurent for patient long discussions and to everybody, who
> >> helped me conduct all the investigation into various past, present and
> >> future UVC cameras :-)
> >> 
> >>  drivers/media/usb/uvc/Makefile   |   2 +-
> >>  drivers/media/usb/uvc/uvc_driver.c   |   4 +
> >>  drivers/media/usb/uvc/uvc_isight.c   |   2 +-
> >>  drivers/media/usb/uvc/uvc_metadata.c | 158 
> >>  drivers/media/usb/uvc/uvc_queue.c|  68 ++-
> >>  drivers/media/usb/uvc/uvc_video.c| 101 +++---
> >>  drivers/media/usb/uvc/uvcvideo.h |  23 -
> >>  drivers/media/v4l2-core/v4l2-ioctl.c |   1 +
> >>  include/uapi/linux/uvcvideo.h|  19 +
> >>  include/uapi/linux/videodev2.h   |   3 +
> >>  10 files changed, 347 insertions(+), 34 deletions(-)
> >>  create mode 100644 drivers/media/usb/uvc/uvc_metadata.c
> > 
> > [snip]
> > 
> >> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> >> b/drivers/media/usb/uvc/uvc_driver.c
> >> index 70842c5..9f23dcf 100644
> >> --- a/drivers/media/usb/uvc/uvc_driver.c
> >> +++ b/drivers/media/usb/uvc/uvc_driver.c

[snip]

> >> @@ -1941,6 +1942,9 @@ static int uvc_register_video(struct uvc_device
> >> *dev,
> > >   return ret;
> > >   }
> > > 
> > > + /* Register a metadata node. */
> > > + uvc_meta_register(stream);
> > 
> > This can fail, you should handle errors.
> 
> Yes, this is in a way deliberate. If metadata node registration fails, the
> driver continues without one. Would you prefer to fail and unregister the
> main node in this case?

No, that's fine, but you should then add a comment to explain why the error 
isn't handled.

Please also make sure that no damage can occur at device removal time if the 
metadata node hasn't been registered.

> > >   if (stream->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> > >   stream->chain->caps |= V4L2_CAP_VIDEO_CAPTURE;
> > >   else
> > 
> > [snip]
> > 
> >> diff --git a/drivers/media/usb/uvc/uvc_metadata.c
> >> b/drivers/media/usb/uvc/uvc_metadata.c
> >> new file mode 100644
> >> index 000..876badd
> >> --- /dev/null
> >> +++ b/drivers/media/usb/uvc/uvc_metadata.c

[snip]

> >> +/* 
> >> + * videobuf2 Queue Operations
> >> + */
> >> +
> >> +static struct vb2_ops uvc_meta_queue_ops = {
> >> +  .queue_setup = uvc_queue_setup,
> >> +  .buf_prepare = uvc_buffer_prepare,
> >> +  .buf_queue = uvc_buffer_queue,
> >> +  .wait_prepare = vb2_ops_wait_prepare,
> >> +  .wait_finish = vb2_ops_wait_finish,
> >> +  .stop_streaming = uvc_stop_streaming,
> > 
> > This looks unbalanced without a start_streaming operation. I know that
> > you've modified the uvc_stop_streaming() function to not stop the video
> > stream for metadata video nodes, but I think the code would be clearer
> > if you implemented a uvc_meta_stop_streaming() function
> > for
> 
> Unfinished sentence?

Sorry, I meant to write for meta data nodes I think :-)

> Adding a uvc_meta_stop_streaming() wouldn't balance the .start_streaming()
> by itself. Do you want a dummy function, returning 0 there? Seems even
> uglier to me...

That doesn't sound better, you're 

Re: [PATCH RESEND 03/14] [media] ddbridge: bump ddbridge code to version 0.9.29

2017-07-27 Thread kbuild test robot
Hi Daniel,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on next-20170727]
[cannot apply to v4.13-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Scheller/ddbridge-bump-to-ddbridge-0-9-29/20170725-074332
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-b0-07280453 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/infiniband/hw/hfi1/qsfp.o: In function `i2c_write':
>> qsfp.c:(.text+0x780): multiple definition of `i2c_write'
   drivers/media/pci/ddbridge/ddbridge-i2c.o:ddbridge-i2c.c:(.text+0x7c0): 
first defined here
   drivers/infiniband/hw/hfi1/qsfp.o: In function `i2c_read':
   qsfp.c:(.text+0x1110): multiple definition of `i2c_read'
   drivers/media/pci/ddbridge/ddbridge-i2c.o:ddbridge-i2c.c:(.text+0x780): 
first defined here

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH RESEND 02/14] [media] ddbridge: split code into multiple files

2017-07-27 Thread kbuild test robot
Hi Daniel,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on next-20170727]
[cannot apply to v4.13-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Scheller/ddbridge-bump-to-ddbridge-0-9-29/20170725-074332
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-b0-07280453 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/infiniband/hw/hfi1/qsfp.o: In function `i2c_read':
>> qsfp.c:(.text+0x1110): multiple definition of `i2c_read'
   drivers/media/pci/ddbridge/ddbridge-i2c.o:ddbridge-i2c.c:(.text+0x620): 
first defined here

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


[PATCH] staging: media: davinci_vpfe: use __func__ for function names

2017-07-27 Thread Diwakar Sharma
Checkpatch reported warnings for use of embedded function names.
Use __func__ instead of embedded function names.

Signed-off-by: Diwakar Sharma 
---
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 10 +-
 drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c |  8 
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 6a3434c..a59ab6f 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -696,21 +696,21 @@ static int ipipe_get_gamma_params(struct 
vpfe_ipipe_device *ipipe, void *param)
 
if (!gamma->bypass_r && !gamma_param->table_r) {
dev_err(dev,
-   "ipipe_get_gamma_params: table ptr empty for R\n");
+   "%s: table ptr empty for R\n", __func__);
return -EINVAL;
}
memcpy(gamma_param->table_r, gamma->table_r,
   (table_size * sizeof(struct vpfe_ipipe_gamma_entry)));
 
if (!gamma->bypass_g && !gamma_param->table_g) {
-   dev_err(dev, "ipipe_get_gamma_params: table ptr empty for G\n");
+   dev_err(dev, "%s: table ptr empty for G\n", __func__);
return -EINVAL;
}
memcpy(gamma_param->table_g, gamma->table_g,
   (table_size * sizeof(struct vpfe_ipipe_gamma_entry)));
 
if (!gamma->bypass_b && !gamma_param->table_b) {
-   dev_err(dev, "ipipe_get_gamma_params: table ptr empty for B\n");
+   dev_err(dev, "%s: table ptr empty for B\n", __func__);
return -EINVAL;
}
memcpy(gamma_param->table_b, gamma->table_b,
@@ -743,7 +743,7 @@ static int ipipe_get_3d_lut_params(struct vpfe_ipipe_device 
*ipipe, void *param)
 
lut_param->en = lut->en;
if (!lut_param->table) {
-   dev_err(dev, "ipipe_get_3d_lut_params: Invalid table ptr\n");
+   dev_err(dev, "%s: Invalid table ptr\n", __func__);
return -EINVAL;
}
 
@@ -924,7 +924,7 @@ static int ipipe_get_gbce_params(struct vpfe_ipipe_device 
*ipipe, void *param)
gbce_param->en = gbce->en;
gbce_param->type = gbce->type;
if (!gbce_param->table) {
-   dev_err(dev, "ipipe_get_gbce_params: Invalid table ptr\n");
+   dev_err(dev, "%s: Invalid table ptr\n", __func__);
return -EINVAL;
}
 
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c 
b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
index bffe215..16e2e7e 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
@@ -161,7 +161,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
 {
struct vpfe_device *vpfe_dev = dev_id;
 
-   v4l2_dbg(1, debug, _dev->v4l2_dev, "vpfe_isr\n");
+   v4l2_dbg(1, debug, _dev->v4l2_dev, "%s\n", __func__);
vpfe_isif_buffer_isr(_dev->vpfe_isif);
vpfe_resizer_buffer_isr(_dev->vpfe_resizer);
return IRQ_HANDLED;
@@ -172,7 +172,7 @@ static irqreturn_t vpfe_vdint1_isr(int irq, void *dev_id)
 {
struct vpfe_device *vpfe_dev = dev_id;
 
-   v4l2_dbg(1, debug, _dev->v4l2_dev, "vpfe_vdint1_isr\n");
+   v4l2_dbg(1, debug, _dev->v4l2_dev, "%s\n", __func__);
vpfe_isif_vidint1_isr(_dev->vpfe_isif);
return IRQ_HANDLED;
 }
@@ -182,7 +182,7 @@ static irqreturn_t vpfe_imp_dma_isr(int irq, void *dev_id)
 {
struct vpfe_device *vpfe_dev = dev_id;
 
-   v4l2_dbg(1, debug, _dev->v4l2_dev, "vpfe_imp_dma_isr\n");
+   v4l2_dbg(1, debug, _dev->v4l2_dev, "%s\n", __func__);
vpfe_ipipeif_ss_buffer_isr(_dev->vpfe_ipipeif);
vpfe_resizer_dma_isr(_dev->vpfe_resizer);
return IRQ_HANDLED;
@@ -693,7 +693,7 @@ static int vpfe_remove(struct platform_device *pdev)
 {
struct vpfe_device *vpfe_dev = platform_get_drvdata(pdev);
 
-   v4l2_info(pdev->dev.driver, "vpfe_remove\n");
+   v4l2_info(pdev->dev.driver, "%s\n", __func__);
 
kzfree(vpfe_dev->sd);
vpfe_detach_irq(vpfe_dev);
-- 
1.9.1



Re: [PATCH v3 02/12] intel-ipu3: mmu: implement driver

2017-07-27 Thread Robin Murphy
On 20/07/17 22:49, Sakari Ailus wrote:
> Hi Robin,
> 
> On Wed, Jul 19, 2017 at 02:37:12PM +0100, Robin Murphy wrote:
> ...
>>> +static int ipu3_mmu_map(struct iommu_domain *domain, unsigned long iova,
>>> +   phys_addr_t paddr, size_t size, int prot)
>>> +{
>>> +   struct ipu3_mmu_domain *mmu_dom = to_ipu3_mmu_domain(domain);
>>> +   u32 l1pt_idx, l2pt_idx;
>>> +   unsigned long flags;
>>> +   u32 *l2pt;
>>> +
>>> +   /* We assume a page by page mapping. */
>>> +   if (WARN_ON(size != IPU3_PAGE_SIZE))
>>> +   return -EINVAL;
>>
>> The core API already enforces this, so drivers shouldn't need to be
>> paranoid.
>>
>>> +
>>> +   address_to_pte_idx(iova, _idx, _idx);
>>> +
>>> +   l2pt = ipu3_mmu_get_l2pt(mmu_dom, l1pt_idx, true);
>>> +   if (!l2pt)
>>> +   return -ENOMEM;
>>> +
>>> +   spin_lock_irqsave(_dom->lock, flags);
>>> +
>>> +   if (l2pt[l2pt_idx] != mmu_dom->dummy_page_pteval) {
>>> +   spin_unlock_irqrestore(_dom->lock, flags);
>>> +   return -EBUSY;
>>> +   }
>>> +
>>> +   l2pt[l2pt_idx] = IPU3_ADDR2PTE(paddr);
>>> +
>>> +   clflush_cache_range([l2pt_idx], sizeof(*l2pt));
>>> +
>>> +   if (mmu_dom->mmu)
>>
>> Yikes, are there actually users in the kernel which allocate domains and
>> try to create mappings in them before attaching any devices? In general,
>> that poses an ugly problem for certain IOMMU drivers :(
> 
> This case is a bit special. The MMU is part of a PCI device which is also
> behind the MMU itself.
> 
> Just the existence of mapped memory (or the mapping operation itself)
> shouldn't require powering on or keeping the device powered on. Hence this.

Oh, I understand not invalidating the TLBs if they're already powered
off, it's the "if (mmu_dom->mmu)" check itself that's worrying me, since
that is only NULL until the first device is attached to the domain. What
I'm asking is whether it's actually possible in practice to get here
before mmu_dom->mmu is set (I hope not).

>>> +   call_if_ipu3_is_powered(mmu_dom->mmu, ipu3_mmu_tlb_invalidate);
>>> +
>>> +   spin_unlock_irqrestore(_dom->lock, flags);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static size_t ipu3_mmu_unmap(struct iommu_domain *domain, unsigned long 
>>> iova,
>>> +size_t size)
>>> +{
>>> +   struct ipu3_mmu_domain *mmu_dom = to_ipu3_mmu_domain(domain);
>>> +   u32 l1pt_idx, l2pt_idx;
>>> +   unsigned long flags;
>>> +   u32 *l2pt;
>>> +
>>> +   /* We assume a page by page unmapping. */
>>> +   if (WARN_ON(size != IPU3_PAGE_SIZE))
>>> +   return 0;
>>
>> As above.
>>
>>> +
>>> +   address_to_pte_idx(iova, _idx, _idx);
>>> +
>>> +   l2pt = ipu3_mmu_get_l2pt(mmu_dom, l1pt_idx, false);
>>> +   if (!l2pt)
>>> +   return 0;
>>> +
>>> +   spin_lock_irqsave(_dom->lock, flags);
>>> +
>>> +   if (l2pt[l2pt_idx] == mmu_dom->dummy_page_pteval)
>>> +   size = 0;
>>> +   l2pt[l2pt_idx] = mmu_dom->dummy_page_pteval;
>>> +
>>> +   clflush_cache_range([l2pt_idx], sizeof(*l2pt));
>>> +
>>> +   if (mmu_dom->mmu)
>>> +   call_if_ipu3_is_powered(mmu_dom->mmu, ipu3_mmu_tlb_invalidate);
>>> +
>>> +   spin_unlock_irqrestore(_dom->lock, flags);
>>> +
>>> +   return size;
>>> +}
>>> +
>>> +static phys_addr_t ipu3_mmu_iova_to_phys(struct iommu_domain *domain,
>>> +dma_addr_t iova)
>>> +{
>>> +   struct ipu3_mmu_domain *d = to_ipu3_mmu_domain(domain);
>>> +   u32 l1pt_idx, l2pt_idx;
>>> +   u32 pteval;
>>> +   u32 *l2pt;
>>> +
>>> +   address_to_pte_idx(iova, _idx, _idx);
>>> +
>>> +   l2pt = ipu3_mmu_get_l2pt(d, l1pt_idx, false);
>>> +   if (!l2pt)
>>> +   return 0;
>>> +
>>> +   pteval = l2pt[l2pt_idx];
>>> +   if (pteval == d->dummy_page_pteval)
>>> +   return 0;
>>> +
>>> +   return IPU3_PTE2ADDR(pteval);
>>> +}
>>> +
>>> +static struct iommu_group *ipu3_mmu_device_group(struct device *dev)
>>> +{
>>> +   struct ipu3_mmu *mmu = to_ipu3_mmu(dev);
>>> +
>>> +   return mmu->group;
>>
>>  return iommu_group_ref_get(mmu->group);
>>
>> Otherwise, add 2 or more devices, remove 1 again, and watch the
>> still-live group disappear from under your feet.
>>
>>> +}
>>> +
>>> +static int ipu3_mmu_add_device(struct device *dev)
>>> +{
>>> +   struct iommu_group *group;
>>> +
>>> +   group = iommu_group_get_for_dev(dev);
>>> +   if (IS_ERR(group))
>>> +   return PTR_ERR(group);
>>> +
>>> +   iommu_group_put(group);
>>> +   return 0;
>>> +}
>>> +
>>> +static void ipu3_mmu_remove_device(struct device *dev)
>>> +{
>>> +   struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
>>> +
>>> +   if (!domain)
>>> +   return;
>>> +
>>> +   ipu3_mmu_detach_dev(domain, dev);
>>
>> Ah, so you avoid the refcount bug by forgetting to remove the device
>> from the group at all, but then go and implement the unpleasant
>> consequences of tearing down a potentially-live domain manually :)
>>
>> You should call iommu_group_remove_device() here (i.e. undoing what
>> iommu_group_get_for_dev() 

[PATCH] v4l2-tpg-core.c: fix typo in bt2020_full matrix

2017-07-27 Thread Hans Verkuil
My eye fell on this wrong coefficient in the bt2020_full matrix.
The bt2020 matrix (limited range) is OK.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 3dd22da7e17d..a772976cfe26 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -615,7 +615,7 @@ static void color_to_ycbcr(struct tpg_data *tpg, int r, int 
g, int b,
static const int bt2020_full[3][3] = {
{ COEFF(0.2627, 255),  COEFF(0.6780, 255),  COEFF(0.0593, 255)  
},
{ COEFF(-0.1396, 255), COEFF(-0.3604, 255), COEFF(0.5, 255) 
},
-   { COEFF(0.5, 255), COEFF(-0.4698, 255), COEFF(-0.0402, 255) 
},
+   { COEFF(0.5, 255), COEFF(-0.4598, 255), COEFF(-0.0402, 255) 
},
};
static const int bt2020c[4] = {
COEFF(1.0 / 1.9404, 224), COEFF(1.0 / 1.5816, 224),


[PATCH v3 2/2] dt-bindings: media: Add Amlogic Meson AO-CEC bindings

2017-07-27 Thread Neil Armstrong
The Amlogic SoCs embeds a standalone CEC Controller, this patch adds this
device bindings.

Acked-by: Rob Herring 
Signed-off-by: Neil Armstrong 
---
 .../devicetree/bindings/media/meson-ao-cec.txt | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/meson-ao-cec.txt

diff --git a/Documentation/devicetree/bindings/media/meson-ao-cec.txt 
b/Documentation/devicetree/bindings/media/meson-ao-cec.txt
new file mode 100644
index 000..8671bdb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/meson-ao-cec.txt
@@ -0,0 +1,28 @@
+* Amlogic Meson AO-CEC driver
+
+The Amlogic Meson AO-CEC module is present is Amlogic SoCs and its purpose is
+to handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be following
+   "amlogic,meson-gx-ao-cec"
+
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+  - interrupts : AO-CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to AO-CEC clock.
+  - clock-names : from common clock binding: must contain "core",
+ corresponding to entry in the clocks property.
+  - hdmi-phandle: phandle to the HDMI controller
+
+Example:
+
+cec_AO: cec@100 {
+   compatible = "amlogic,meson-gx-ao-cec";
+   reg = <0x0 0x00100 0x0 0x14>;
+   interrupts = ;
+   clocks = <_AO CLKID_AO_CEC_32K>;
+   clock-names = "core";
+   hdmi-phandle = <_tx>;
+};
-- 
1.9.1



[PATCH v3 0/2] media: Add Amlogic Meson AO CEC Controller support

2017-07-27 Thread Neil Armstrong
The Amlogic SoC embeds a standalone CEC controller, this patch adds a driver
for such controller.
The controller does not need HPD to be active, and could support up to max
5 logical addresses, but only 1 is handled since the Suspend firmware can
make use of this unique logical address to wake up the device.

The Suspend firmware configuration will be added in an other patchset.

Changes since v2 at [2] :
 - change meson_ao_cec_read/write prototype to simplify error handling

Changes since v1 at [1] :
 - add timeout to wait busy, with error return
 - handle busy error in all read/write operations
 - add CEC_CAP_PASSTHROUGH
 - add bindings ack

[1] 
https://lkml.kernel.org/r/1499336870-24118-1-git-send-email-narmstr...@baylibre.com
[2] 
https://lkml.kernel.org/r/1499673696-21372-1-git-send-email-narmstr...@baylibre.com

Neil Armstrong (2):
  platform: Add Amlogic Meson AO CEC Controller driver
  dt-bindings: media: Add Amlogic Meson AO-CEC bindings

 .../devicetree/bindings/media/meson-ao-cec.txt |  28 +
 drivers/media/platform/Kconfig |  11 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/meson/Makefile  |   1 +
 drivers/media/platform/meson/ao-cec.c  | 744 +
 5 files changed, 786 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/meson-ao-cec.txt
 create mode 100644 drivers/media/platform/meson/Makefile
 create mode 100644 drivers/media/platform/meson/ao-cec.c

-- 
1.9.1



[PATCH v3 1/2] platform: Add Amlogic Meson AO CEC Controller driver

2017-07-27 Thread Neil Armstrong
The Amlogic SoC embeds a standalone CEC controller, this patch adds a driver
for such controller.
The controller does not need HPD to be active, and could support up to max
5 logical addresses, but only 1 is handled since the Suspend firmware can
make use of this unique logical address to wake up the device.

The Suspend firmware configuration will be added in an other patchset.

Signed-off-by: Neil Armstrong 
---
 drivers/media/platform/Kconfig|  11 +
 drivers/media/platform/Makefile   |   2 +
 drivers/media/platform/meson/Makefile |   1 +
 drivers/media/platform/meson/ao-cec.c | 744 ++
 4 files changed, 758 insertions(+)
 create mode 100644 drivers/media/platform/meson/Makefile
 create mode 100644 drivers/media/platform/meson/ao-cec.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 1313cd5..1e67381 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -536,6 +536,17 @@ menuconfig CEC_PLATFORM_DRIVERS
 
 if CEC_PLATFORM_DRIVERS
 
+config VIDEO_MESON_AO_CEC
+   tristate "Amlogic Meson AO CEC driver"
+   depends on ARCH_MESON || COMPILE_TEST
+   select CEC_CORE
+   select CEC_NOTIFIER
+   ---help---
+ This is a driver for Amlogic Meson SoCs AO CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 config VIDEO_SAMSUNG_S5P_CEC
tristate "Samsung S5P CEC driver"
depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc7..a52d7b6 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP)  += mtk-mdp/
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
 
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
+
+obj-y  += meson/
diff --git a/drivers/media/platform/meson/Makefile 
b/drivers/media/platform/meson/Makefile
new file mode 100644
index 000..597beb8
--- /dev/null
+++ b/drivers/media/platform/meson/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_MESON_AO_CEC)   += ao-cec.o
diff --git a/drivers/media/platform/meson/ao-cec.c 
b/drivers/media/platform/meson/ao-cec.c
new file mode 100644
index 000..5c3607c
--- /dev/null
+++ b/drivers/media/platform/meson/ao-cec.c
@@ -0,0 +1,744 @@
+/*
+ * Driver for Amlogic Meson AO CEC Controller
+ *
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved
+ * Copyright (C) 2017 BayLibre, SAS
+ * Author: Neil Armstrong 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* CEC Registers */
+
+/*
+ * [2:1] cntl_clk
+ *  - 0 = Disable clk (Power-off mode)
+ *  - 1 = Enable gated clock (Normal mode)
+ *  - 2 = Enable free-run clk (Debug mode)
+ */
+#define CEC_GEN_CNTL_REG   0x00
+
+#define CEC_GEN_CNTL_RESET BIT(0)
+#define CEC_GEN_CNTL_CLK_DISABLE   0
+#define CEC_GEN_CNTL_CLK_ENABLE1
+#define CEC_GEN_CNTL_CLK_ENABLE_DBG2
+#define CEC_GEN_CNTL_CLK_CTRL_MASK GENMASK(2, 1)
+
+/*
+ * [7:0] cec_reg_addr
+ * [15:8] cec_reg_wrdata
+ * [16] cec_reg_wr
+ *  - 0 = Read
+ *  - 1 = Write
+ * [23] bus free
+ * [31:24] cec_reg_rddata
+ */
+#define CEC_RW_REG 0x04
+
+#define CEC_RW_ADDRGENMASK(7, 0)
+#define CEC_RW_WR_DATA GENMASK(15, 8)
+#define CEC_RW_WRITE_ENBIT(16)
+#define CEC_RW_BUS_BUSYBIT(23)
+#define CEC_RW_RD_DATA GENMASK(31, 24)
+
+/*
+ * [1] tx intr
+ * [2] rx intr
+ */
+#define CEC_INTR_MASKN_REG 0x08
+#define CEC_INTR_CLR_REG   0x0c
+#define CEC_INTR_STAT_REG  0x10
+
+#define CEC_INTR_TXBIT(1)
+#define CEC_INTR_RXBIT(2)
+
+/* CEC Commands */
+
+#define CEC_TX_MSG_0_HEADER0x00
+#define CEC_TX_MSG_1_OPCODE0x01
+#define CEC_TX_MSG_2_OP1   0x02
+#define CEC_TX_MSG_3_OP2   0x03
+#define CEC_TX_MSG_4_OP3   0x04
+#define CEC_TX_MSG_5_OP4   0x05
+#define CEC_TX_MSG_6_OP5   0x06
+#define CEC_TX_MSG_7_OP6   0x07
+#define CEC_TX_MSG_8_OP7   0x08
+#define CEC_TX_MSG_9_OP8   0x09
+#define CEC_TX_MSG_A_OP9   0x0A
+#define CEC_TX_MSG_B_OP10  0x0B
+#define CEC_TX_MSG_C_OP11  0x0C
+#define CEC_TX_MSG_D_OP12  0x0D
+#define CEC_TX_MSG_E_OP13  0x0E
+#define CEC_TX_MSG_F_OP14  0x0F
+#define CEC_TX_MSG_LENGTH  0x10
+#define CEC_TX_MSG_CMD 0x11

Re: [PATCH v2 1/2] platform: Add Amlogic Meson AO CEC Controller driver

2017-07-27 Thread Neil Armstrong
On 07/27/2017 04:43 PM, Neil Armstrong wrote:
> On 07/25/2017 03:45 PM, Hans Verkuil wrote:
>> On 07/25/17 14:34, Neil Armstrong wrote:
>>> Hi Hans,
>>
> +static int meson_ao_cec_probe(struct platform_device *pdev)
> +{
> + struct meson_ao_cec_device *ao_cec;
> + struct platform_device *hdmi_dev;
> + struct device_node *np;
> + struct resource *res;
> + int ret, irq;
> +
> + np = of_parse_phandle(pdev->dev.of_node, "hdmi-phandle", 0);
> + if (!np) {
> + dev_err(>dev, "Failed to find hdmi node\n");
> + return -ENODEV;
> + }
> +
> + hdmi_dev = of_find_device_by_node(np);
> + if (hdmi_dev == NULL)
> + return -EPROBE_DEFER;
> +
> + ao_cec = devm_kzalloc(>dev, sizeof(*ao_cec), GFP_KERNEL);
> + if (!ao_cec)
> + return -ENOMEM;
> +
> + spin_lock_init(_cec->cec_reg_lock);
> +
> + ao_cec->notify = cec_notifier_get(_dev->dev);
> + if (!ao_cec->notify)
> + return -ENOMEM;
> +
> + ao_cec->adap = cec_allocate_adapter(_ao_cec_ops, ao_cec,
> + "meson_ao_cec",
> + CEC_CAP_LOG_ADDRS |
> + CEC_CAP_TRANSMIT |
> + CEC_CAP_RC |
> + CEC_CAP_PASSTHROUGH,
> + 1); /* Use 1 for now */

 I recommend that you add support for 2 logical addresses. More isn't 
 allowed
 by the CEC 2.0 spec anyway (no such restriction for CEC 1.4, but more than
 two really isn't needed).
>>>
>>> I know, but in the "communication" register with the suspend/poweroff 
>>> firmware
>>> that  handles the wake up, only a single logical address is supported...
>>>
>>> What should I do in this case ? Which logical adress should I pass to the 
>>> firmware when implementing ir ?
>>
>> Ah, OK. Interesting.
>>
>> From cec-adap.c:
>>
>> if (log_addrs->num_log_addrs == 2) {
>> if (!(type_mask & ((1 << 
>> CEC_LOG_ADDR_TYPE_AUDIOSYSTEM) |
>>(1 << CEC_LOG_ADDR_TYPE_TV {
>> dprintk(1, "two LAs is only allowed for 
>> audiosystem and TV\n");
>> return -EINVAL;
>> }
>> if (!(type_mask & ((1 << CEC_LOG_ADDR_TYPE_PLAYBACK) 
>> |
>>(1 << 
>> CEC_LOG_ADDR_TYPE_RECORD {
>> dprintk(1, "an audiosystem/TV can only be 
>> combined with record or playback\n");
>> return -EINVAL;
>> }
>> }
>>
>> So you would store the TV or AUDIOSYSTEM logical address in the firmware, 
>> since those
>> describe the system best.
>>
>> I.e. it is a TV/Audiosystem with recording/playback capabilities.
>>
>> The problem is that for CEC 1.4 no such restriction is imposed (the test 
>> above is
>> specific to CEC 2.0). But I think it makes sense to just check if 
>> TV/Audiosystem
>> is selected and pick that as the LA to store in the firmware, and otherwise 
>> just
>> pick the first LA (log_addr[0]).
> 
> 
> Ok I'll add support for dual LA, and I'll do this LA selection when I'll add 
> firmware support.

Sorry, but having more than 1 LA makes the CEC controller very unstable, I'll 
need more info from amlogic to activate multiple LAs.

Neil

> 
> Thanks,
> Neil
> 
> 
>> Regards,
>>
>>  Hans
>>
> 



Re: [PATCH v2 1/2] platform: Add Amlogic Meson AO CEC Controller driver

2017-07-27 Thread Neil Armstrong
On 07/25/2017 03:45 PM, Hans Verkuil wrote:
> On 07/25/17 14:34, Neil Armstrong wrote:
>> Hi Hans,
> 
 +static int meson_ao_cec_probe(struct platform_device *pdev)
 +{
 +  struct meson_ao_cec_device *ao_cec;
 +  struct platform_device *hdmi_dev;
 +  struct device_node *np;
 +  struct resource *res;
 +  int ret, irq;
 +
 +  np = of_parse_phandle(pdev->dev.of_node, "hdmi-phandle", 0);
 +  if (!np) {
 +  dev_err(>dev, "Failed to find hdmi node\n");
 +  return -ENODEV;
 +  }
 +
 +  hdmi_dev = of_find_device_by_node(np);
 +  if (hdmi_dev == NULL)
 +  return -EPROBE_DEFER;
 +
 +  ao_cec = devm_kzalloc(>dev, sizeof(*ao_cec), GFP_KERNEL);
 +  if (!ao_cec)
 +  return -ENOMEM;
 +
 +  spin_lock_init(_cec->cec_reg_lock);
 +
 +  ao_cec->notify = cec_notifier_get(_dev->dev);
 +  if (!ao_cec->notify)
 +  return -ENOMEM;
 +
 +  ao_cec->adap = cec_allocate_adapter(_ao_cec_ops, ao_cec,
 +  "meson_ao_cec",
 +  CEC_CAP_LOG_ADDRS |
 +  CEC_CAP_TRANSMIT |
 +  CEC_CAP_RC |
 +  CEC_CAP_PASSTHROUGH,
 +  1); /* Use 1 for now */
>>>
>>> I recommend that you add support for 2 logical addresses. More isn't allowed
>>> by the CEC 2.0 spec anyway (no such restriction for CEC 1.4, but more than
>>> two really isn't needed).
>>
>> I know, but in the "communication" register with the suspend/poweroff 
>> firmware
>> that  handles the wake up, only a single logical address is supported...
>>
>> What should I do in this case ? Which logical adress should I pass to the 
>> firmware when implementing ir ?
> 
> Ah, OK. Interesting.
> 
> From cec-adap.c:
> 
> if (log_addrs->num_log_addrs == 2) {
> if (!(type_mask & ((1 << 
> CEC_LOG_ADDR_TYPE_AUDIOSYSTEM) |
>(1 << CEC_LOG_ADDR_TYPE_TV {
> dprintk(1, "two LAs is only allowed for 
> audiosystem and TV\n");
> return -EINVAL;
> }
> if (!(type_mask & ((1 << CEC_LOG_ADDR_TYPE_PLAYBACK) |
>(1 << CEC_LOG_ADDR_TYPE_RECORD 
> {
> dprintk(1, "an audiosystem/TV can only be 
> combined with record or playback\n");
> return -EINVAL;
> }
> }
> 
> So you would store the TV or AUDIOSYSTEM logical address in the firmware, 
> since those
> describe the system best.
> 
> I.e. it is a TV/Audiosystem with recording/playback capabilities.
> 
> The problem is that for CEC 1.4 no such restriction is imposed (the test 
> above is
> specific to CEC 2.0). But I think it makes sense to just check if 
> TV/Audiosystem
> is selected and pick that as the LA to store in the firmware, and otherwise 
> just
> pick the first LA (log_addr[0]).


Ok I'll add support for dual LA, and I'll do this LA selection when I'll add 
firmware support.

Thanks,
Neil


> Regards,
> 
>   Hans
> 



Re: [PATCHv3 6/6] media: drop use of MEDIA_API_VERSION

2017-07-27 Thread Laurent Pinchart
Hi Hans,

On Saturday 22 Jul 2017 13:30:57 Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Set media_version to LINUX_VERSION_CODE, just as we did for
> driver_version.
> 
> Nobody ever rememebers to update the version number, but
> LINUX_VERSION_CODE will always be updated.
> 
> Move the MEDIA_API_VERSION define to the ifndef __KERNEL__ section of the
> media.h header. That way kernelspace can't accidentally start to use
> it again.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/media-device.c | 3 +--
>  include/uapi/linux/media.h   | 5 +++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 979e4307d248..3c99294e3ebf 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -69,9 +69,8 @@ static int media_device_get_info(struct media_device *dev,
> strlcpy(info->serial, dev->serial, sizeof(info->serial));
>   strlcpy(info->bus_info, dev->bus_info, sizeof(info->bus_info));
> 
> - info->media_version = MEDIA_API_VERSION;
> + info->media_version = info->driver_version = LINUX_VERSION_CODE;

I'd split this on two lines, I believe it would be clearer. Apart from that,

Reviewed-by: Laurent Pinchart 

>   info->hw_revision = dev->hw_revision;
> - info->driver_version = LINUX_VERSION_CODE;
> 
>   return 0;
>  }
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index fac96c64fe51..4865f1e71339 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -30,8 +30,6 @@
>  #include 
>  #include 
> 
> -#define MEDIA_API_VERSIONKERNEL_VERSION(0, 1, 0)
> -
>  struct media_device_info {
>   char driver[16];
>   char model[32];
> @@ -187,6 +185,9 @@ struct media_device_info {
>  #define MEDIA_ENT_T_V4L2_SUBDEV_LENS MEDIA_ENT_F_LENS
>  #define MEDIA_ENT_T_V4L2_SUBDEV_DECODER  MEDIA_ENT_F_ATV_DECODER
>  #define MEDIA_ENT_T_V4L2_SUBDEV_TUNERMEDIA_ENT_F_TUNER
> +
> +/* Obsolete symbol for media_version, no longer used in the kernel */
> +#define MEDIA_API_VERSIONKERNEL_VERSION(0, 1, 0)
>  #endif
> 
>  /* Entity flags */

-- 
Regards,

Laurent Pinchart



Re: [PATCH 1/2] staging: greybus: light: Don't leak memory for no gain

2017-07-27 Thread Rui Miguel Silva
Hi,
On Wed, Jul 26, 2017 at 08:32:08PM +0200, Pavel Machek wrote:
> Hi!
> 
> > On Tue, Jul 25, 2017 at 02:30:31PM +0200, Johan Hovold wrote:
> > > [ +CC: Rui and Greg ]
> > 
> > Thanks Johan. I only got this because of you.
> 
> > > > return ret;
> > > >  }
> > > 
> > > And while it's fine to take this through linux-media, it would still be
> > > good to keep the maintainers on CC.
> > 
> > Sakari, if you could resend the all series to the right lists and
> > maintainers for proper review that would be great.
> > 
> > I did not get 0/2 and 2/2 patches.
> 
> 0/2 and 2/2 were unrelated to the memory leak, IIRC. Let me google it
> for you...
> 
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg115840.html
> 
> This is memory leak and the driver is in staging. Acked-by

Yeah, I will not Ack a patch that never hit my inbox, sorry.

>or fixing > it yourself would be appropriate response, asking
> for resending of the series... not quite so.

Sure, if Sakari do not send a new version already taking in
account Johan comments, which I agree. I will fix it myself when
possible.

---
Cheers,
Rui


[ragnatech:media-tree] BUILD SUCCESS da48c948c263c9d87dfc64566b3373a858cc8aa2

2017-07-27 Thread kbuild test robot
git://git.ragnatech.se/linux  media-tree
da48c948c263c9d87dfc64566b3373a858cc8aa2  media: fix warning on 
v4l2_subdev_call() result interpreted as bool

elapsed time: 1130m

configs tested: 153

The following configs have been built successfully.
More configs may be tested in the coming days.

x86_64   allmodconfig
sh   allmodconfig
shtitan_defconfig
sh  rsk7269_defconfig
sh  sh7785lcr_32bit_defconfig
shallnoconfig
x86_64 randconfig-a0-07271829
i386   tinyconfig
cris etrax-100lx_v2_defconfig
blackfin  TCM-BF537_defconfig
blackfinBF561-EZKIT-SMP_defconfig
blackfinBF533-EZKIT_defconfig
blackfinBF526-EZBRD_defconfig
ia64  allnoconfig
ia64defconfig
ia64 alldefconfig
i386   randconfig-x019-201730
i386   randconfig-x013-201730
i386   randconfig-x016-201730
i386   randconfig-x012-201730
i386   randconfig-x018-201730
i386   randconfig-x010-201730
i386   randconfig-x015-201730
i386   randconfig-x011-201730
i386   randconfig-x017-201730
i386   randconfig-x014-201730
microblaze  mmu_defconfig
microblazenommu_defconfig
i386   randconfig-n0-07241914
x86_64 randconfig-x007-201730
x86_64 randconfig-x001-201730
x86_64 randconfig-x000-201730
x86_64 randconfig-x006-201730
x86_64 randconfig-x003-201730
x86_64 randconfig-x004-201730
x86_64 randconfig-x009-201730
x86_64 randconfig-x005-201730
x86_64 randconfig-x008-201730
x86_64 randconfig-x002-201730
x86_64  kexec
x86_64   rhel
x86_64   rhel-7.2
c6xevmc6678_defconfig
xtensa   common_defconfig
m32r   m32104ut_defconfig
score  spct6600_defconfig
xtensa  iss_defconfig
m32r opsput_defconfig
m32r   usrv_defconfig
m32r mappi3.smp_defconfig
nios2 10m50_defconfig
h8300h8300h-sim_defconfig
powerpc defconfig
s390default_defconfig
powerpc   ppc64_defconfig
powerpc   allnoconfig
x86_64 randconfig-x016-201730
x86_64 randconfig-x011-201730
x86_64 randconfig-x019-201730
x86_64 randconfig-x014-201730
x86_64 randconfig-x012-201730
x86_64 randconfig-x013-201730
x86_64 randconfig-x018-201730
x86_64 randconfig-x015-201730
x86_64 randconfig-x010-201730
x86_64 randconfig-x017-201730
arm   omap2plus_defconfig
armsa1100
arm  allmodconfig
arm   samsung
armmvebu_v7_defconfig
arm  ixp4xx_defconfig
arm   imx_v6_v7_defconfig
arm64allmodconfig
arm   tegra_defconfig
arm  arm5
arm64alldefconfig
armsh
arm arm67
i386 randconfig-a0-201730
i386 randconfig-a1-201730
i386   randconfig-s0-07240817
i386   randconfig-s1-07240817
x86_64 randconfig-i0-07231502
i386   randconfig-i0-07240017
i386   randconfig-i1-07240017
sparc   defconfig
sparc64   allnoconfig
sparc64 defconfig
armkeystone_defconfig
blackfin   CM-BF561_defconfig
shecovec24-romimage_defconfig
blackfinBF538-EZKIT_defconfig
tiledefconfig
x86_64lkp
i386 allmodconfig
m68k   sun3_defconfig
m68k  multi_defconfig
m68k   m5475evb_defconfig
pariscc3000_defconfig
parisc b180_defconfig
parisc  defconfig
alpha   

[PATCH] media/extended-controls.rst: fix wrong enum names

2017-07-27 Thread Hans Verkuil
MPEG4 level and profile defines were wrong. Fix this.

Signed-off-by: Hans Verkuil 
Reported-by: Nicolas Dufresne 
---
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
b/Documentation/media/uapi/v4l/extended-controls.rst
index 9acc9cad49e2..667ba882c4cd 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -942,21 +942,21 @@ enum v4l2_mpeg_video_mpeg4_level -
 :header-rows:  0
 :stub-columns: 0

-* - ``V4L2_MPEG_VIDEO_LEVEL_0``
+* - ``V4L2_MPEG_VIDEO_MPEG4_LEVEL_0``
   - Level 0
-* - ``V4L2_MPEG_VIDEO_LEVEL_0B``
+* - ``V4L2_MPEG_VIDEO_MPEG4_LEVEL_0B``
   - Level 0b
-* - ``V4L2_MPEG_VIDEO_LEVEL_1``
+* - ``V4L2_MPEG_VIDEO_MPEG4_LEVEL_1``
   - Level 1
-* - ``V4L2_MPEG_VIDEO_LEVEL_2``
+* - ``V4L2_MPEG_VIDEO_MPEG4_LEVEL_2``
   - Level 2
-* - ``V4L2_MPEG_VIDEO_LEVEL_3``
+* - ``V4L2_MPEG_VIDEO_MPEG4_LEVEL_3``
   - Level 3
-* - ``V4L2_MPEG_VIDEO_LEVEL_3B``
+* - ``V4L2_MPEG_VIDEO_MPEG4_LEVEL_3B``
   - Level 3b
-* - ``V4L2_MPEG_VIDEO_LEVEL_4``
+* - ``V4L2_MPEG_VIDEO_MPEG4_LEVEL_4``
   - Level 4
-* - ``V4L2_MPEG_VIDEO_LEVEL_5``
+* - ``V4L2_MPEG_VIDEO_MPEG4_LEVEL_5``
   - Level 5


@@ -1028,15 +1028,15 @@ enum v4l2_mpeg_video_mpeg4_profile -
 :header-rows:  0
 :stub-columns: 0

-* - ``V4L2_MPEG_VIDEO_PROFILE_SIMPLE``
+* - ``V4L2_MPEG_VIDEO_MPEG4_PROFILE_SIMPLE``
   - Simple profile
-* - ``V4L2_MPEG_VIDEO_PROFILE_ADVANCED_SIMPLE``
+* - ``V4L2_MPEG_VIDEO_MPEG4_PROFILE_ADVANCED_SIMPLE``
   - Advanced Simple profile
-* - ``V4L2_MPEG_VIDEO_PROFILE_CORE``
+* - ``V4L2_MPEG_VIDEO_MPEG4_PROFILE_CORE``
   - Core profile
-* - ``V4L2_MPEG_VIDEO_PROFILE_SIMPLE_SCALABLE``
+* - ``V4L2_MPEG_VIDEO_MPEG4_PROFILE_SIMPLE_SCALABLE``
   - Simple Scalable profile
-* - ``V4L2_MPEG_VIDEO_PROFILE_ADVANCED_CODING_EFFICIENCY``
+* - ``V4L2_MPEG_VIDEO_MPEG4_PROFILE_ADVANCED_CODING_EFFICIENCY``
   -




Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

2017-07-27 Thread Maxime Ripard
On Thu, Jul 27, 2017 at 03:16:44PM +0300, Baruch Siach wrote:
> Hi Yong,
> 
> I managed to get the Frame Done interrupt with the previous version of this 
> driver on the A33 OLinuXino. No data yet (all zeros). I'm still working on it.
> 
> One comment below.
> 
> On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > and CSI1 is used for parallel interface. This is not documented in
> > datasheet but by testing and guess.
> > 
> > This patch implement a v4l2 framework driver for it.
> > 
> > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > ISP's support are not included in this patch.
> > 
> > Signed-off-by: Yong Deng 
> > ---
> 
> [...]
> 
> > +static int update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr)
> > +{
> > +   struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
> > +   /* transform physical address to bus address */
> > +   dma_addr_t bus_addr = addr - 0x4000;
> 
> What is the source of this magic number? Is it platform dependent? Are there 
> other devices doing DMA that need this adjustment?

This is the RAM base address in most (but not all) Allwinner
SoCs. You'll want to use PHYS_OFFSET instead.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature


Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

2017-07-27 Thread Baruch Siach
Hi Yong,

I managed to get the Frame Done interrupt with the previous version of this 
driver on the A33 OLinuXino. No data yet (all zeros). I'm still working on it.

One comment below.

On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> and CSI1 is used for parallel interface. This is not documented in
> datasheet but by testing and guess.
> 
> This patch implement a v4l2 framework driver for it.
> 
> Currently, the driver only support the parallel interface. MIPI-CSI2,
> ISP's support are not included in this patch.
> 
> Signed-off-by: Yong Deng 
> ---

[...]

> +static int update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr)
> +{
> + struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
> + /* transform physical address to bus address */
> + dma_addr_t bus_addr = addr - 0x4000;

What is the source of this magic number? Is it platform dependent? Are there 
other devices doing DMA that need this adjustment?

baruch

> +
> + regmap_write(sdev->regmap, CSI_CH_F0_BUFA_REG,
> +  (bus_addr + sdev->planar_offset[0]) >> 2);
> + if (sdev->planar_offset[1] != -1)
> + regmap_write(sdev->regmap, CSI_CH_F1_BUFA_REG,
> +  (bus_addr + sdev->planar_offset[1]) >> 2);
> + if (sdev->planar_offset[2] != -1)
> + regmap_write(sdev->regmap, CSI_CH_F2_BUFA_REG,
> +  (bus_addr + sdev->planar_offset[2]) >> 2);
> +
> + return 0;
> +}

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -


[PATCH 3/3] media/doc: improve the SMPTE 2084 documentation

2017-07-27 Thread Hans Verkuil
From: Hans Verkuil 

Make note of the different luminance ranges between HDR and SDR.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/colorspaces-details.rst | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/media/uapi/v4l/colorspaces-details.rst 
b/Documentation/media/uapi/v4l/colorspaces-details.rst
index 47d7d1915284..b5d551b9cc8f 100644
--- a/Documentation/media/uapi/v4l/colorspaces-details.rst
+++ b/Documentation/media/uapi/v4l/colorspaces-details.rst
@@ -793,3 +793,15 @@ Transfer function:
 Inverse Transfer function:
 L = (max(L':sup:`1/m2` - c1, 0) / (c2 - c3 *
 L'\ :sup:`1/m2`))\ :sup:`1/m1`
+
+Take care when converting between this transfer function and non-HDR transfer
+functions: the linear RGB values [0…1] of HDR content map to a luminance range
+of 0 to 1 cd/m\ :sup:`2` whereas the linear RGB values of non-HDR (aka
+Standard Dynamic Range or SDR) map to a luminance range of 0 to 100 cd/m\ 
:sup:`2`.
+
+To go from SDR to HDR you will have to divide L by 100 first. To go in the 
other
+direction you will have to multiply L by 100. Of course, this clamps all
+luminance values over 100 cd/m\ :sup:`2` to 100 cd/m\ :sup:`2`.
+
+There are better methods, see e.g. :ref:`colimg` for more in-depth information
+about this.
-- 
2.13.1



[PATCH 1/3] media/doc: rename and reorder pixfmt files

2017-07-27 Thread Hans Verkuil
From: Hans Verkuil 

After the DocBook conversion a number of pixfmt description files just had
a number in the filename (pix-fmt-004, 006, etc) which was not very descriptive.

Rename them.

Note that pixfmt-008.rst was folded into colorspaces-details.rst, so that
file is deleted. It's easier to maintain that way.

Also moved the colorspace sections to the end of the chapter. The old order
was weird: the "Standard Image Formats" section (an intro into pixel formats)
was followed by the colorspace sections instead of the pixel format 
descriptions.

Moving it to the end resolved that issue.

Signed-off-by: Hans Verkuil 
---
 .../v4l/{pixfmt-006.rst => colorspaces-defs.rst}   |  0
 .../{pixfmt-007.rst => colorspaces-details.rst}| 30 
 Documentation/media/uapi/v4l/pixfmt-008.rst| 32 --
 .../v4l/{pixfmt-013.rst => pixfmt-compressed.rst}  |  0
 .../uapi/v4l/{pixfmt-004.rst => pixfmt-intro.rst}  |  0
 .../v4l/{pixfmt-003.rst => pixfmt-v4l2-mplane.rst} |  0
 .../uapi/v4l/{pixfmt-002.rst => pixfmt-v4l2.rst}   |  0
 Documentation/media/uapi/v4l/pixfmt.rst| 15 +-
 8 files changed, 37 insertions(+), 40 deletions(-)
 rename Documentation/media/uapi/v4l/{pixfmt-006.rst => colorspaces-defs.rst} 
(100%)
 rename Documentation/media/uapi/v4l/{pixfmt-007.rst => 
colorspaces-details.rst} (96%)
 delete mode 100644 Documentation/media/uapi/v4l/pixfmt-008.rst
 rename Documentation/media/uapi/v4l/{pixfmt-013.rst => pixfmt-compressed.rst} 
(100%)
 rename Documentation/media/uapi/v4l/{pixfmt-004.rst => pixfmt-intro.rst} (100%)
 rename Documentation/media/uapi/v4l/{pixfmt-003.rst => pixfmt-v4l2-mplane.rst} 
(100%)
 rename Documentation/media/uapi/v4l/{pixfmt-002.rst => pixfmt-v4l2.rst} (100%)

diff --git a/Documentation/media/uapi/v4l/pixfmt-006.rst 
b/Documentation/media/uapi/v4l/colorspaces-defs.rst
similarity index 100%
rename from Documentation/media/uapi/v4l/pixfmt-006.rst
rename to Documentation/media/uapi/v4l/colorspaces-defs.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-007.rst 
b/Documentation/media/uapi/v4l/colorspaces-details.rst
similarity index 96%
rename from Documentation/media/uapi/v4l/pixfmt-007.rst
rename to Documentation/media/uapi/v4l/colorspaces-details.rst
index 0c30ee2577d3..128b2acbe824 100644
--- a/Documentation/media/uapi/v4l/pixfmt-007.rst
+++ b/Documentation/media/uapi/v4l/colorspaces-details.rst
@@ -758,3 +758,33 @@ scaled to [-128…128] and then clipped to [-128…127].
``V4L2_COLORSPACE_JPEG`` can be considered to be an abbreviation for
``V4L2_COLORSPACE_SRGB``, ``V4L2_YCBCR_ENC_601`` and
``V4L2_QUANTIZATION_FULL_RANGE``.
+
+***
+Detailed Transfer Function Descriptions
+***
+
+.. _xf-smpte-2084:
+
+Transfer Function SMPTE 2084 (V4L2_XFER_FUNC_SMPTE2084)
+===
+
+The :ref:`smpte2084` standard defines the transfer function used by
+High Dynamic Range content.
+
+Constants:
+m1 = (2610 / 4096) / 4
+
+m2 = (2523 / 4096) * 128
+
+c1 = 3424 / 4096
+
+c2 = (2413 / 4096) * 32
+
+c3 = (2392 / 4096) * 32
+
+Transfer function:
+L' = ((c1 + c2 * L\ :sup:`m1`) / (1 + c3 * L\ :sup:`m1`))\ :sup:`m2`
+
+Inverse Transfer function:
+L = (max(L':sup:`1/m2` - c1, 0) / (c2 - c3 *
+L'\ :sup:`1/m2`))\ :sup:`1/m1`
diff --git a/Documentation/media/uapi/v4l/pixfmt-008.rst 
b/Documentation/media/uapi/v4l/pixfmt-008.rst
deleted file mode 100644
index 4bec79784bdd..
--- a/Documentation/media/uapi/v4l/pixfmt-008.rst
+++ /dev/null
@@ -1,32 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-***
-Detailed Transfer Function Descriptions
-***
-
-
-.. _xf-smpte-2084:
-
-Transfer Function SMPTE 2084 (V4L2_XFER_FUNC_SMPTE2084)
-===
-
-The :ref:`smpte2084` standard defines the transfer function used by
-High Dynamic Range content.
-
-Constants:
-m1 = (2610 / 4096) / 4
-
-m2 = (2523 / 4096) * 128
-
-c1 = 3424 / 4096
-
-c2 = (2413 / 4096) * 32
-
-c3 = (2392 / 4096) * 32
-
-Transfer function:
-L' = ((c1 + c2 * L\ :sup:`m1`) / (1 + c3 * L\ :sup:`m1`))\ :sup:`m2`
-
-Inverse Transfer function:
-L = (max(L':sup:`1/m2` - c1, 0) / (c2 - c3 *
-L'\ :sup:`1/m2`))\ :sup:`1/m1`
diff --git a/Documentation/media/uapi/v4l/pixfmt-013.rst 
b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
similarity index 100%
rename from Documentation/media/uapi/v4l/pixfmt-013.rst
rename to Documentation/media/uapi/v4l/pixfmt-compressed.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-004.rst 
b/Documentation/media/uapi/v4l/pixfmt-intro.rst
similarity index 100%
rename from Documentation/media/uapi/v4l/pixfmt-004.rst
rename to Documentation/media/uapi/v4l/pixfmt-intro.rst
diff --git 

[PATCH 2/3] media/doc: improve bt.2020 documentation

2017-07-27 Thread Hans Verkuil
From: Hans Verkuil 

Add a note stating that bt.2020 is often used in combination with the
smpte 2084 transfer function.

Also use the right references to the documentation of that transfer
function.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/colorspaces-defs.rst| 2 +-
 Documentation/media/uapi/v4l/colorspaces-details.rst | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/v4l/colorspaces-defs.rst 
b/Documentation/media/uapi/v4l/colorspaces-defs.rst
index 7ae7dcf73f63..e67ed1e0b3fa 100644
--- a/Documentation/media/uapi/v4l/colorspaces-defs.rst
+++ b/Documentation/media/uapi/v4l/colorspaces-defs.rst
@@ -97,7 +97,7 @@ whole range, 0-255, dividing the angular value by 1.41. The 
enum
 * - ``V4L2_XFER_FUNC_DCI_P3``
   - Use the DCI-P3 transfer function.
 * - ``V4L2_XFER_FUNC_SMPTE2084``
-  - Use the SMPTE 2084 transfer function.
+  - Use the SMPTE 2084 transfer function. See :ref:`xf-smpte-2084`.
 
 
 
diff --git a/Documentation/media/uapi/v4l/colorspaces-details.rst 
b/Documentation/media/uapi/v4l/colorspaces-details.rst
index 128b2acbe824..47d7d1915284 100644
--- a/Documentation/media/uapi/v4l/colorspaces-details.rst
+++ b/Documentation/media/uapi/v4l/colorspaces-details.rst
@@ -418,6 +418,11 @@ Inverse Transfer function:
 
 L = \left( \frac{L' + 0.099}{1.099}\right) ^{\frac{1}{0.45} }\text{, for } 
L' \ge 0.081
 
+Please note that while Rec. 709 is defined as the default transfer function
+by the :ref:`itu2020` standard, in practice this colorspace is often used
+with the :ref:`xf-smpte-2084`. In particular Ultra HD Blu-ray discs use
+this combination.
+
 The luminance (Y') and color difference (Cb and Cr) are obtained with
 the following ``V4L2_YCBCR_ENC_BT2020`` encoding:
 
-- 
2.13.1



[PATCH 0/3] media/doc: rename pixfmt files, improve colorspace docs

2017-07-27 Thread Hans Verkuil
From: Hans Verkuil 

Rename the pixfmt-0XX.rst files left over from the DocBook conversion to 
something
that is more human readable.

Improve the bt.2020 and SMPTE 2084 documentation.

Regards,

Hans

Hans Verkuil (3):
  media/doc: rename and reorder pixfmt files
  media/doc: improve bt.2020 documentation
  media/doc: improve the SMPTE 2084 documentation

 .../v4l/{pixfmt-006.rst => colorspaces-defs.rst}   |  2 +-
 .../{pixfmt-007.rst => colorspaces-details.rst}| 47 ++
 Documentation/media/uapi/v4l/pixfmt-008.rst| 32 ---
 .../v4l/{pixfmt-013.rst => pixfmt-compressed.rst}  |  0
 .../uapi/v4l/{pixfmt-004.rst => pixfmt-intro.rst}  |  0
 .../v4l/{pixfmt-003.rst => pixfmt-v4l2-mplane.rst} |  0
 .../uapi/v4l/{pixfmt-002.rst => pixfmt-v4l2.rst}   |  0
 Documentation/media/uapi/v4l/pixfmt.rst| 15 ---
 8 files changed, 55 insertions(+), 41 deletions(-)
 rename Documentation/media/uapi/v4l/{pixfmt-006.rst => colorspaces-defs.rst} 
(98%)
 rename Documentation/media/uapi/v4l/{pixfmt-007.rst => 
colorspaces-details.rst} (92%)
 delete mode 100644 Documentation/media/uapi/v4l/pixfmt-008.rst
 rename Documentation/media/uapi/v4l/{pixfmt-013.rst => pixfmt-compressed.rst} 
(100%)
 rename Documentation/media/uapi/v4l/{pixfmt-004.rst => pixfmt-intro.rst} (100%)
 rename Documentation/media/uapi/v4l/{pixfmt-003.rst => pixfmt-v4l2-mplane.rst} 
(100%)
 rename Documentation/media/uapi/v4l/{pixfmt-002.rst => pixfmt-v4l2.rst} (100%)

-- 
2.13.1



[PATCH 1/4] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages

2017-07-27 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Scatterlist entries have an unsigned int for the offset so
correct the sg_alloc_table_from_pages function accordingly.

Since these are offsets withing a page, unsigned int is
wide enough.

Also converts callers which were using unsigned long locally
with the lower_32_bits annotation to make it explicitly
clear what is happening.

v2: Use offset_in_page. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Cc: Masahiro Yamada 
Cc: Pawel Osciak 
Cc: Marek Szyprowski 
Cc: Kyungmin Park 
Cc: Tomasz Stanislawski 
Cc: Matt Porter 
Cc: Alexandre Bounine 
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Marek Szyprowski  (v1)
Reviewed-by: Chris Wilson 
Reviewed-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++--
 drivers/rapidio/devices/rio_mport_cdev.c   | 4 ++--
 include/linux/scatterlist.h| 2 +-
 lib/scatterlist.c  | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 4f246d166111..2405077fdc71 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -479,7 +479,7 @@ static void *vb2_dc_get_userptr(struct device *dev, 
unsigned long vaddr,
 {
struct vb2_dc_buf *buf;
struct frame_vector *vec;
-   unsigned long offset;
+   unsigned int offset;
int n_pages, i;
int ret = 0;
struct sg_table *sgt;
@@ -507,7 +507,7 @@ static void *vb2_dc_get_userptr(struct device *dev, 
unsigned long vaddr,
buf->dev = dev;
buf->dma_dir = dma_dir;
 
-   offset = vaddr & ~PAGE_MASK;
+   offset = lower_32_bits(offset_in_page(vaddr));
vec = vb2_create_framevec(vaddr, size, dma_dir == DMA_FROM_DEVICE);
if (IS_ERR(vec)) {
ret = PTR_ERR(vec);
diff --git a/drivers/rapidio/devices/rio_mport_cdev.c 
b/drivers/rapidio/devices/rio_mport_cdev.c
index 5beb0c361076..5c1b6388122a 100644
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -876,10 +876,10 @@ rio_dma_transfer(struct file *filp, u32 transfer_mode,
 * offset within the internal buffer specified by handle parameter.
 */
if (xfer->loc_addr) {
-   unsigned long offset;
+   unsigned int offset;
long pinned;
 
-   offset = (unsigned long)(uintptr_t)xfer->loc_addr & ~PAGE_MASK;
+   offset = lower_32_bits(offset_in_page(xfer->loc_addr));
nr_pages = PAGE_ALIGN(xfer->length + offset) >> PAGE_SHIFT;
 
page_list = kmalloc_array(nr_pages,
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 4b3286ac60c8..205aefb4ed93 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -263,7 +263,7 @@ int __sg_alloc_table(struct sg_table *, unsigned int, 
unsigned int,
 int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
 int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
-   unsigned long offset, unsigned long size,
+   unsigned int offset, unsigned long size,
gfp_t gfp_mask);
 
 size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index be7b4dd6b68d..dee0c5004e2f 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -391,7 +391,7 @@ EXPORT_SYMBOL(sg_alloc_table);
  */
 int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
-   unsigned long offset, unsigned long size,
+   unsigned int offset, unsigned long size,
gfp_t gfp_mask)
 {
unsigned int chunks;
-- 
2.9.4



[PATCH v1] media: ov13858: Fix initial expsoure max

2017-07-27 Thread Chiranjeevi Rapolu
Previously, initial exposure max was set incorrectly to (0x7fff - 8).
Now, limit exposure max to current resolution (VTS - 8).

Signed-off-by: Chiranjeevi Rapolu 
---
 drivers/media/i2c/ov13858.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
index 86550d8..013c565 100644
--- a/drivers/media/i2c/ov13858.c
+++ b/drivers/media/i2c/ov13858.c
@@ -66,7 +66,6 @@
 /* Exposure control */
 #define OV13858_REG_EXPOSURE   0x3500
 #define OV13858_EXPOSURE_MIN   4
-#define OV13858_EXPOSURE_MAX   (OV13858_VTS_MAX - 8)
 #define OV13858_EXPOSURE_STEP  1
 #define OV13858_EXPOSURE_DEFAULT   0x640
 
@@ -1602,6 +1601,7 @@ static int ov13858_init_controls(struct ov13858 *ov13858)
 {
struct i2c_client *client = v4l2_get_subdevdata(>sd);
struct v4l2_ctrl_handler *ctrl_hdlr;
+   s64 exposure_max;
int ret;
 
ctrl_hdlr = >ctrl_handler;
@@ -1640,10 +1640,11 @@ static int ov13858_init_controls(struct ov13858 
*ov13858)
OV13858_PPL_1080MHZ - ov13858->cur_mode->width);
ov13858->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
 
+   exposure_max = ov13858->cur_mode->vts - 8;
ov13858->exposure = v4l2_ctrl_new_std(
ctrl_hdlr, _ctrl_ops,
V4L2_CID_EXPOSURE, OV13858_EXPOSURE_MIN,
-   OV13858_EXPOSURE_MAX, OV13858_EXPOSURE_STEP,
+   exposure_max, OV13858_EXPOSURE_STEP,
OV13858_EXPOSURE_DEFAULT);
 
v4l2_ctrl_new_std(ctrl_hdlr, _ctrl_ops, V4L2_CID_ANALOGUE_GAIN,
-- 
1.9.1



[PATCH v1] [media] ov13858 Set default fps as current fps

2017-07-27 Thread Chiranjeevi Rapolu
On format change, sometimes, sensor was streaming at a much higher
FPS than the default. This was resulting in various problems like
frame drops/corruption.

Upon format change, set default vblank as current vblank. This will
ensure that sensor will start streaming at default fps.

Signed-off-by: Chiranjeevi Rapolu 
---
 drivers/media/i2c/ov13858.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
index 86550d8..8e6c8f0 100644
--- a/drivers/media/i2c/ov13858.c
+++ b/drivers/media/i2c/ov13858.c
@@ -1377,6 +1377,7 @@ static int ov13858_get_pad_format(struct v4l2_subdev *sd,
struct ov13858 *ov13858 = to_ov13858(sd);
const struct ov13858_mode *mode;
struct v4l2_mbus_framefmt *framefmt;
+   s32 vblank_def;
s64 h_blank;
 
mutex_lock(>mutex);
@@ -1397,10 +1398,12 @@ static int ov13858_get_pad_format(struct v4l2_subdev 
*sd,
ov13858->pixel_rate,
link_freq_configs[mode->link_freq_index].pixel_rate);
/* Update limits and set FPS to default */
+   vblank_def = ov13858->cur_mode->vts - ov13858->cur_mode->height;
__v4l2_ctrl_modify_range(
ov13858->vblank, OV13858_VBLANK_MIN,
OV13858_VTS_MAX - ov13858->cur_mode->height, 1,
-   ov13858->cur_mode->vts - ov13858->cur_mode->height);
+   vblank_def);
+   __v4l2_ctrl_s_ctrl(ov13858->vblank, vblank_def);
h_blank =
link_freq_configs[mode->link_freq_index].pixels_per_line
 - ov13858->cur_mode->width;
-- 
1.9.1



Re: [PATCH v3] [media] v4l2: Add support for go2001 PCI codec driver

2017-07-27 Thread kbuild test robot
Hi Thierry,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thierry-Escande/v4l2-Add-support-for-go2001-PCI-codec-driver/20170727-033126
base:   git://linuxtv.org/media_tree.git master
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/media/pci/go2001/go2001_driver.c: In function 'go2001_buf_init':
>> drivers/media/pci/go2001/go2001_driver.c:274:32: warning: format '%zu' 
>> expects argument of type 'size_t', but argument 6 has type 'long unsigned 
>> int' [-Wformat=]
   go2001_err(gdev, "Plane address/size not aligned %d/%zu\n",
   ^~~~

vim +274 drivers/media/pci/go2001/go2001_driver.c

   240  
   241  static int go2001_buf_init(struct vb2_buffer *vb)
   242  {
   243  struct go2001_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
   244  struct go2001_dev *gdev = ctx->gdev;
   245  struct device *dev = >pdev->dev;
   246  struct go2001_buffer *gbuf = vb_to_go2001_buf(vb);
   247  struct go2001_dma_desc *dma_desc;
   248  struct go2001_mmap_list_entry *mmap_list;
   249  enum dma_data_direction dir;
   250  struct scatterlist *sg;
   251  struct sg_table *sgt;
   252  u64 dma_addr;
   253  u32 dma_len;
   254  int plane, sgi;
   255  int ret;
   256  
   257  go2001_trace(gdev);
   258  
   259  if (WARN_ON(gbuf->mapped))
   260  return -EINVAL;
   261  
   262  dir = V4L2_TYPE_IS_OUTPUT(vb->vb2_queue->type) ?
   263DMA_TO_DEVICE :
   264DMA_FROM_DEVICE;
   265  
   266  for (plane = 0; plane < vb->num_planes; ++plane) {
   267  dma_desc = >dma_desc[plane];
   268  WARN_ON(!IS_ALIGNED(dma_desc->map_addr, 16));
   269  
   270  sgt = vb2_dma_sg_plane_desc(vb, plane);
   271  
   272  if (!IS_ALIGNED(sgt->sgl->offset, 8) ||
   273  !IS_ALIGNED(vb2_plane_size(vb, plane), 8)) {
 > 274  go2001_err(gdev, "Plane address/size not 
 > aligned %d/%zu\n",
   275 sgt->sgl->offset, vb2_plane_size(vb, 
plane));
   276  
   277  ret = -EINVAL;
   278  goto err;
   279  }
   280  
   281  dma_desc->num_entries = sgt->nents;
   282  dma_desc->list_size = dma_desc->num_entries *
   283sizeof(struct 
go2001_mmap_list_entry);
   284  dma_desc->mmap_list = dma_alloc_coherent(dev,
   285   
dma_desc->list_size,
   286   
_desc->dma_addr,
   287   GFP_KERNEL);
   288  if (!dma_desc->mmap_list) {
   289  go2001_err(gdev, "Failed allocating HW memory 
map\n");
   290  
   291  ret = -ENOMEM;
   292  goto err;
   293  }
   294  
   295  go2001_dbg(gdev, 3, "Plane %d: mmap list size: %zu\n", 
plane,
   296 dma_desc->list_size);
   297  
   298  mmap_list = dma_desc->mmap_list;
   299  for_each_sg(sgt->sgl, sg, dma_desc->num_entries, sgi) {
   300  dma_addr = sg_dma_address(sg);
   301  dma_len = sg_dma_len(sg);
   302  
   303  mmap_list[sgi].dma_addr = cpu_to_le64(dma_addr);
   304  mmap_list[sgi].size = cpu_to_le32(dma_len);
   305  
   306  go2001_dbg(gdev, 4, "Chunk %d: 0x%08llx, size 
%d\n",
   307 sgi, dma_addr, dma_len);
   308  }
   309  }
   310  
   311  ret = go2001_map_buffer(ctx, gbuf);
   312  if (ret) {
   313  go2001_err(ctx->gdev, "Failed mapping buffer in HW\n");
   314  goto err;
   315  }
   316  
   317  return 0;
   318  
   319  err:
   320  for (; plane > 0; --plane) {
   321  dma_desc = >dma_desc[plane - 1];
   322  dma_free_coherent(dev, dma_desc->list_size, 
dma_desc->mmap_list,
   323