Re: [PATCHv3 13/22] staging: android: ion: Use CMA APIs directly
Hi Laura, Thank you for the patch. On Monday 03 Apr 2017 11:57:55 Laura Abbott wrote: > When CMA was first introduced, its primary use was for DMA allocation > and the only way to get CMA memory was to call dma_alloc_coherent. This > put Ion in an awkward position since there was no device structure > readily available and setting one up messed up the coherency model. > These days, CMA can be allocated directly from the APIs. Switch to using > this model to avoid needing a dummy device. This also mitigates some of > the caching problems (e.g. dma_alloc_coherent only returning uncached > memory). Do we have a guarantee that the DMA mapping API, which we have to use for cache handling, will always support memory we allocate directly from CMA behind its back ? > Signed-off-by: Laura Abbott > --- > drivers/staging/android/ion/Kconfig| 7 +++ > drivers/staging/android/ion/Makefile | 3 +- > drivers/staging/android/ion/ion_cma_heap.c | 97 +++ > 3 files changed, 35 insertions(+), 72 deletions(-) > > diff --git a/drivers/staging/android/ion/Kconfig > b/drivers/staging/android/ion/Kconfig index 206c4de..15108c4 100644 > --- a/drivers/staging/android/ion/Kconfig > +++ b/drivers/staging/android/ion/Kconfig > @@ -10,3 +10,10 @@ menuconfig ION > If you're not using Android its probably safe to > say N here. > > +config ION_CMA_HEAP > + bool "Ion CMA heap support" > + depends on ION && CMA > + help > + Choose this option to enable CMA heaps with Ion. This heap is backed > + by the Contiguous Memory Allocator (CMA). If your system has these > + regions, you should say Y here. > diff --git a/drivers/staging/android/ion/Makefile > b/drivers/staging/android/ion/Makefile index 26672a0..66d0c4a 100644 > --- a/drivers/staging/android/ion/Makefile > +++ b/drivers/staging/android/ion/Makefile > @@ -1,6 +1,7 @@ > obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \ > ion_page_pool.o ion_system_heap.o \ > - ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o > + ion_carveout_heap.o ion_chunk_heap.o > +obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o > ifdef CONFIG_COMPAT > obj-$(CONFIG_ION) += compat_ion.o > endif > diff --git a/drivers/staging/android/ion/ion_cma_heap.c > b/drivers/staging/android/ion/ion_cma_heap.c index d562fd7..f3e0f59 100644 > --- a/drivers/staging/android/ion/ion_cma_heap.c > +++ b/drivers/staging/android/ion/ion_cma_heap.c > @@ -19,24 +19,19 @@ > #include > #include > #include > -#include > +#include > +#include > > #include "ion.h" > #include "ion_priv.h" > > struct ion_cma_heap { > struct ion_heap heap; > - struct device *dev; > + struct cma *cma; > }; > > #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap) > > -struct ion_cma_buffer_info { > - void *cpu_addr; > - dma_addr_t handle; > - struct sg_table *table; > -}; > - > > /* ION CMA heap operations functions */ > static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer > *buffer, @@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap > *heap, struct ion_buffer *buffer, unsigned long flags) > { > struct ion_cma_heap *cma_heap = to_cma_heap(heap); > - struct device *dev = cma_heap->dev; > - struct ion_cma_buffer_info *info; > - > - dev_dbg(dev, "Request buffer allocation len %ld\n", len); > - > - if (buffer->flags & ION_FLAG_CACHED) > - return -EINVAL; > + struct sg_table *table; > + struct page *pages; > + int ret; > > - info = kzalloc(sizeof(*info), GFP_KERNEL); > - if (!info) > + pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL); > + if (!pages) > return -ENOMEM; > > - info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle), > - GFP_HIGHUSER | __GFP_ZERO); > - > - if (!info->cpu_addr) { > - dev_err(dev, "Fail to allocate buffer\n"); > + table = kmalloc(sizeof(struct sg_table), GFP_KERNEL); > + if (!table) > goto err; > - } > > - info->table = kmalloc(sizeof(*info->table), GFP_KERNEL); > - if (!info->table) > + ret = sg_alloc_table(table, 1, GFP_KERNEL); > + if (ret) > goto free_mem; > > - if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle, > - len)) > - goto free_table; > - /* keep this for memory release */ > - buffer->priv_virt = info; > - buffer->sg_table = info->table; > - dev_dbg(dev, "Allocate buffer %p\n", buffer); > + sg_set_page(table->sgl, pages, len, 0); > + > + buffer->priv_virt = pages; > + buffer->sg_table = table; > return 0; > > -free_table: > - kfree(info->table); > free_mem: > - dma_free_coherent(dev, len, info->cpu_addr, info->handle); > + kfree(table); > err: > - kfree(info); > +
[PATCH 5/5] media: rc: meson-ir: change irq name to to of node name
Switch the interrupt description to the default which is the of node name. This is more in line with the interrupt descriptions in other meson drivers. Signed-off-by: Heiner Kallweit --- drivers/media/rc/meson-ir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c index 246da2db..471251b3 100644 --- a/drivers/media/rc/meson-ir.c +++ b/drivers/media/rc/meson-ir.c @@ -155,7 +155,7 @@ static int meson_ir_probe(struct platform_device *pdev) return ret; } - ret = devm_request_irq(dev, irq, meson_ir_irq, 0, "ir-meson", ir); + ret = devm_request_irq(dev, irq, meson_ir_irq, 0, NULL, ir); if (ret) { dev_err(dev, "failed to request irq\n"); return ret; -- 2.12.2
[PATCH 3/5] media: rc: meson-ir: switch to managed rc device allocation / registration
Switch to the managed versions of rc_allocate_device/rc_register_device, thus simplifying the code. Signed-off-by: Heiner Kallweit --- drivers/media/rc/meson-ir.c | 18 -- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c index a52036c5..d56ef27e 100644 --- a/drivers/media/rc/meson-ir.c +++ b/drivers/media/rc/meson-ir.c @@ -128,7 +128,7 @@ static int meson_ir_probe(struct platform_device *pdev) return irq; } - ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW); + ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW); if (!ir->rc) { dev_err(dev, "failed to allocate rc device\n"); return -ENOMEM; @@ -140,7 +140,6 @@ static int meson_ir_probe(struct platform_device *pdev) ir->rc->input_id.bustype = BUS_HOST; map_name = of_get_property(node, "linux,rc-map-name", NULL); ir->rc->map_name = map_name ? map_name : RC_MAP_EMPTY; - ir->rc->dev.parent = dev; ir->rc->allowed_protocols = RC_BIT_ALL_IR_DECODER; ir->rc->rx_resolution = US_TO_NS(MESON_TRATE); ir->rc->timeout = MS_TO_NS(200); @@ -149,16 +148,16 @@ static int meson_ir_probe(struct platform_device *pdev) spin_lock_init(&ir->lock); platform_set_drvdata(pdev, ir); - ret = rc_register_device(ir->rc); + ret = devm_rc_register_device(dev, ir->rc); if (ret) { dev_err(dev, "failed to register rc device\n"); - goto out_free; + return ret; } ret = devm_request_irq(dev, irq, meson_ir_irq, 0, "ir-meson", ir); if (ret) { dev_err(dev, "failed to request irq\n"); - goto out_unreg; + return ret; } /* Reset the decoder */ @@ -184,13 +183,6 @@ static int meson_ir_probe(struct platform_device *pdev) dev_info(dev, "receiver initialized\n"); return 0; -out_unreg: - rc_unregister_device(ir->rc); - ir->rc = NULL; -out_free: - rc_free_device(ir->rc); - - return ret; } static int meson_ir_remove(struct platform_device *pdev) @@ -203,8 +195,6 @@ static int meson_ir_remove(struct platform_device *pdev) meson_ir_set_mask(ir, IR_DEC_REG1, REG1_ENABLE, 0); spin_unlock_irqrestore(&ir->lock, flags); - rc_unregister_device(ir->rc); - return 0; } -- 2.12.2
[PATCH 2/5] media: rc: meson-ir: make use of the bitfield macros
Make use of the bitfield macros thus partially hiding the complexity of dealing with bitfields. The patch also includes a minor fix to REG0_RATE_MASK, so far it was set to bit 0..10, but according to the spec it's bit 0..11. Signed-off-by: Heiner Kallweit --- drivers/media/rc/meson-ir.c | 28 +--- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c index a4128d7c..a52036c5 100644 --- a/drivers/media/rc/meson-ir.c +++ b/drivers/media/rc/meson-ir.c @@ -19,6 +19,7 @@ #include #include #include +#include #include @@ -36,27 +37,24 @@ /* only available on Meson 8b and newer */ #define IR_DEC_REG20x20 -#define REG0_RATE_MASK (BIT(11) - 1) +#define REG0_RATE_MASK GENMASK(11, 0) #define DECODE_MODE_NEC0x0 #define DECODE_MODE_RAW0x2 /* Meson 6b uses REG1 to configure the mode */ #define REG1_MODE_MASK GENMASK(8, 7) -#define REG1_MODE_SHIFT7 /* Meson 8b / GXBB use REG2 to configure the mode */ #define REG2_MODE_MASK GENMASK(3, 0) -#define REG2_MODE_SHIFT0 -#define REG1_TIME_IV_SHIFT 16 -#define REG1_TIME_IV_MASK ((BIT(13) - 1) << REG1_TIME_IV_SHIFT) +#define REG1_TIME_IV_MASK GENMASK(28, 16) -#define REG1_IRQSEL_MASK (BIT(2) | BIT(3)) -#define REG1_IRQSEL_NEC_MODE (0 << 2) -#define REG1_IRQSEL_RISE_FALL (1 << 2) -#define REG1_IRQSEL_FALL (2 << 2) -#define REG1_IRQSEL_RISE (3 << 2) +#define REG1_IRQSEL_MASK GENMASK(3, 2) +#define REG1_IRQSEL_NEC_MODE 0 +#define REG1_IRQSEL_RISE_FALL 1 +#define REG1_IRQSEL_FALL 2 +#define REG1_IRQSEL_RISE 3 #define REG1_RESET BIT(0) #define REG1_ENABLEBIT(15) @@ -78,7 +76,7 @@ static void meson_ir_set_mask(struct meson_ir *ir, unsigned int reg, data = readl(ir->reg + reg); data &= ~mask; - data |= (value & mask); + data |= value; writel(data, ir->reg + reg); } @@ -91,7 +89,7 @@ static irqreturn_t meson_ir_irq(int irqno, void *dev_id) spin_lock(&ir->lock); duration = readl(ir->reg + IR_DEC_REG1); - duration = (duration & REG1_TIME_IV_MASK) >> REG1_TIME_IV_SHIFT; + duration = FIELD_GET(REG1_TIME_IV_MASK, duration); rawir.duration = US_TO_NS(duration * MESON_TRATE); rawir.pulse = !!(readl(ir->reg + IR_DEC_STATUS) & STATUS_IR_DEC_IN); @@ -170,16 +168,16 @@ static int meson_ir_probe(struct platform_device *pdev) /* Set general operation mode (= raw/software decoding) */ if (of_device_is_compatible(node, "amlogic,meson6-ir")) meson_ir_set_mask(ir, IR_DEC_REG1, REG1_MODE_MASK, - DECODE_MODE_RAW << REG1_MODE_SHIFT); + FIELD_PREP(REG1_MODE_MASK, DECODE_MODE_RAW)); else meson_ir_set_mask(ir, IR_DEC_REG2, REG2_MODE_MASK, - DECODE_MODE_RAW << REG2_MODE_SHIFT); + FIELD_PREP(REG2_MODE_MASK, DECODE_MODE_RAW)); /* Set rate */ meson_ir_set_mask(ir, IR_DEC_REG0, REG0_RATE_MASK, MESON_TRATE - 1); /* IRQ on rising and falling edges */ meson_ir_set_mask(ir, IR_DEC_REG1, REG1_IRQSEL_MASK, - REG1_IRQSEL_RISE_FALL); + FIELD_PREP(REG1_IRQSEL_MASK, REG1_IRQSEL_RISE_FALL)); /* Enable the decoder */ meson_ir_set_mask(ir, IR_DEC_REG1, REG1_ENABLE, REG1_ENABLE); -- 2.12.2
[PATCH 1/5] media: rc: meson-ir: remove irq from struct meson_ir
The irq number is used in the probe function only, therefore just use a local variable. Signed-off-by: Heiner Kallweit --- drivers/media/rc/meson-ir.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c index 5576dbd6..a4128d7c 100644 --- a/drivers/media/rc/meson-ir.c +++ b/drivers/media/rc/meson-ir.c @@ -68,7 +68,6 @@ struct meson_ir { void __iomem*reg; struct rc_dev *rc; - int irq; spinlock_t lock; }; @@ -112,7 +111,7 @@ static int meson_ir_probe(struct platform_device *pdev) struct resource *res; const char *map_name; struct meson_ir *ir; - int ret; + int irq, ret; ir = devm_kzalloc(dev, sizeof(struct meson_ir), GFP_KERNEL); if (!ir) @@ -125,10 +124,10 @@ static int meson_ir_probe(struct platform_device *pdev) return PTR_ERR(ir->reg); } - ir->irq = platform_get_irq(pdev, 0); - if (ir->irq < 0) { + irq = platform_get_irq(pdev, 0); + if (irq < 0) { dev_err(dev, "no irq resource\n"); - return ir->irq; + return irq; } ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW); @@ -158,7 +157,7 @@ static int meson_ir_probe(struct platform_device *pdev) goto out_free; } - ret = devm_request_irq(dev, ir->irq, meson_ir_irq, 0, "ir-meson", ir); + ret = devm_request_irq(dev, irq, meson_ir_irq, 0, "ir-meson", ir); if (ret) { dev_err(dev, "failed to request irq\n"); goto out_unreg; -- 2.12.2
[PATCH 4/5] media: rc: meson-ir: use readl_relaxed in the interrupt handler
We don't need the memory barriers here and an interrupt handler should be as fast as possible. Therefore switch to readl_relaxed. Signed-off-by: Heiner Kallweit --- drivers/media/rc/meson-ir.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c index d56ef27e..246da2db 100644 --- a/drivers/media/rc/meson-ir.c +++ b/drivers/media/rc/meson-ir.c @@ -83,16 +83,17 @@ static void meson_ir_set_mask(struct meson_ir *ir, unsigned int reg, static irqreturn_t meson_ir_irq(int irqno, void *dev_id) { struct meson_ir *ir = dev_id; - u32 duration; + u32 duration, status; DEFINE_IR_RAW_EVENT(rawir); spin_lock(&ir->lock); - duration = readl(ir->reg + IR_DEC_REG1); + duration = readl_relaxed(ir->reg + IR_DEC_REG1); duration = FIELD_GET(REG1_TIME_IV_MASK, duration); rawir.duration = US_TO_NS(duration * MESON_TRATE); - rawir.pulse = !!(readl(ir->reg + IR_DEC_STATUS) & STATUS_IR_DEC_IN); + status = readl_relaxed(ir->reg + IR_DEC_STATUS); + rawir.pulse = !!(status & STATUS_IR_DEC_IN); ir_raw_event_store_with_filter(ir->rc, &rawir); ir_raw_event_handle(ir->rc); -- 2.12.2
Re: [PATCHv3 07/22] staging: android: ion: Remove page faulting support
Hi, On 04/04/2017 12:27 AM, Laura Abbott wrote: The new method of syncing with dma_map means that the page faulting sync implementation is no longer applicable. Remove it. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 117 -- 1 file changed, 117 deletions(-) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 6aac935..226ea1f 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -42,37 +42,11 @@ #include "ion_priv.h" #include "compat_ion.h" -bool ion_buffer_fault_user_mappings(struct ion_buffer *buffer) -{ - return (buffer->flags & ION_FLAG_CACHED) && - !(buffer->flags & ION_FLAG_CACHED_NEEDS_SYNC); -} - bool ion_buffer_cached(struct ion_buffer *buffer) { return !!(buffer->flags & ION_FLAG_CACHED); } -static inline struct page *ion_buffer_page(struct page *page) -{ - return (struct page *)((unsigned long)page & ~(1UL)); -} - -static inline bool ion_buffer_page_is_dirty(struct page *page) -{ - return !!((unsigned long)page & 1UL); -} - -static inline void ion_buffer_page_dirty(struct page **page) -{ - *page = (struct page *)((unsigned long)(*page) | 1UL); -} - -static inline void ion_buffer_page_clean(struct page **page) -{ - *page = (struct page *)((unsigned long)(*page) & ~(1UL)); -} - /* this function should only be called while dev->lock is held */ static void ion_buffer_add(struct ion_device *dev, struct ion_buffer *buffer) @@ -140,25 +114,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap *heap, buffer->dev = dev; buffer->size = len; - if (ion_buffer_fault_user_mappings(buffer)) { - int num_pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE; - struct scatterlist *sg; - int i, j, k = 0; - - buffer->pages = vmalloc(sizeof(struct page *) * num_pages); We should also remove the vfree(buffer->pages) call in ion_buffer_destroy. In fact, we could removes 'pages' member from ion_buffer altogether. Thanks, Archit - if (!buffer->pages) { - ret = -ENOMEM; - goto err1; - } - - for_each_sg(table->sgl, sg, table->nents, i) { - struct page *page = sg_page(sg); - - for (j = 0; j < sg->length / PAGE_SIZE; j++) - buffer->pages[k++] = page++; - } - } - buffer->dev = dev; buffer->size = len; INIT_LIST_HEAD(&buffer->vmas); @@ -924,69 +879,6 @@ void ion_pages_sync_for_device(struct device *dev, struct page *page, dma_sync_sg_for_device(dev, &sg, 1, dir); } -struct ion_vma_list { - struct list_head list; - struct vm_area_struct *vma; -}; - -static int ion_vm_fault(struct vm_fault *vmf) -{ - struct ion_buffer *buffer = vmf->vma->vm_private_data; - unsigned long pfn; - int ret; - - mutex_lock(&buffer->lock); - ion_buffer_page_dirty(buffer->pages + vmf->pgoff); - BUG_ON(!buffer->pages || !buffer->pages[vmf->pgoff]); - - pfn = page_to_pfn(ion_buffer_page(buffer->pages[vmf->pgoff])); - ret = vm_insert_pfn(vmf->vma, vmf->address, pfn); - mutex_unlock(&buffer->lock); - if (ret) - return VM_FAULT_ERROR; - - return VM_FAULT_NOPAGE; -} - -static void ion_vm_open(struct vm_area_struct *vma) -{ - struct ion_buffer *buffer = vma->vm_private_data; - struct ion_vma_list *vma_list; - - vma_list = kmalloc(sizeof(*vma_list), GFP_KERNEL); - if (!vma_list) - return; - vma_list->vma = vma; - mutex_lock(&buffer->lock); - list_add(&vma_list->list, &buffer->vmas); - mutex_unlock(&buffer->lock); - pr_debug("%s: adding %p\n", __func__, vma); -} - -static void ion_vm_close(struct vm_area_struct *vma) -{ - struct ion_buffer *buffer = vma->vm_private_data; - struct ion_vma_list *vma_list, *tmp; - - pr_debug("%s\n", __func__); - mutex_lock(&buffer->lock); - list_for_each_entry_safe(vma_list, tmp, &buffer->vmas, list) { - if (vma_list->vma != vma) - continue; - list_del(&vma_list->list); - kfree(vma_list); - pr_debug("%s: deleting %p\n", __func__, vma); - break; - } - mutex_unlock(&buffer->lock); -} - -static const struct vm_operations_struct ion_vma_ops = { - .open = ion_vm_open, - .close = ion_vm_close, - .fault = ion_vm_fault, -}; - static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) { struct ion_buffer *buffer = dmabuf->priv; @@ -998,15 +890,6 @@ static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) return -EINVAL; } - if (ion_buffer_fault_
[PATCH 0/5] media: rc: meson-ir: series with smaller improvements
This series includes smaller improvements for the meson-ir driver. Tested on a Odroid C2. Heiner Kallweit (5): media: rc: meson-ir: remove irq from struct meson_ir media: rc: meson-ir: make use of the bitfield macros media: rc: meson-ir: switch to managed rc device allocation / registration media: rc: meson-ir: use readl_relaxed in the interrupt handler media: rc: meson-ir: change irq name to to of node name drivers/media/rc/meson-ir.c | 64 ++--- 1 file changed, 26 insertions(+), 38 deletions(-) -- 2.12.2
Re: [PATCHv3 08/22] staging: android: ion: Remove crufty cache support
Hi, On 04/04/2017 12:27 AM, Laura Abbott wrote: Now that we call dma_map in the dma_buf API callbacks there is no need to use the existing cache APIs. Remove the sync ioctl and the existing bad dma_sync calls. Explicit caching can be handled with the dma_buf sync API. We could get rid of the ION_FLAG_CACHED_NEEDS_SYNC flag in this patch too. Thanks, Archit Signed-off-by: Laura Abbott --- drivers/staging/android/ion/compat_ion.c| 1 - drivers/staging/android/ion/ion-ioctl.c | 6 drivers/staging/android/ion/ion.c | 40 - drivers/staging/android/ion/ion_carveout_heap.c | 6 drivers/staging/android/ion/ion_chunk_heap.c| 6 drivers/staging/android/ion/ion_page_pool.c | 3 -- drivers/staging/android/ion/ion_priv.h | 13 drivers/staging/android/ion/ion_system_heap.c | 5 drivers/staging/android/uapi/ion.h | 10 --- 9 files changed, 90 deletions(-) diff --git a/drivers/staging/android/ion/compat_ion.c b/drivers/staging/android/ion/compat_ion.c index 9a978d2..b892d3a 100644 --- a/drivers/staging/android/ion/compat_ion.c +++ b/drivers/staging/android/ion/compat_ion.c @@ -186,7 +186,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) case ION_IOC_SHARE: case ION_IOC_MAP: case ION_IOC_IMPORT: - case ION_IOC_SYNC: return filp->f_op->unlocked_ioctl(filp, cmd, (unsigned long)compat_ptr(arg)); default: diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..e096bcd 100644 --- a/drivers/staging/android/ion/ion-ioctl.c +++ b/drivers/staging/android/ion/ion-ioctl.c @@ -51,7 +51,6 @@ static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg) static unsigned int ion_ioctl_dir(unsigned int cmd) { switch (cmd) { - case ION_IOC_SYNC: case ION_IOC_FREE: case ION_IOC_CUSTOM: return _IOC_WRITE; @@ -146,11 +145,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) data.handle.handle = handle->id; break; } - case ION_IOC_SYNC: - { - ret = ion_sync_for_device(client, data.fd.fd); - break; - } case ION_IOC_CUSTOM: { if (!dev->custom_ioctl) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 226ea1f..8757164 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -863,22 +863,6 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment, dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction); } -void ion_pages_sync_for_device(struct device *dev, struct page *page, - size_t size, enum dma_data_direction dir) -{ - struct scatterlist sg; - - sg_init_table(&sg, 1); - sg_set_page(&sg, page, size, 0); - /* -* This is not correct - sg_dma_address needs a dma_addr_t that is valid -* for the targeted device, but this works on the currently targeted -* hardware. -*/ - sg_dma_address(&sg) = page_to_phys(page); - dma_sync_sg_for_device(dev, &sg, 1, dir); -} - static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) { struct ion_buffer *buffer = dmabuf->priv; @@ -1097,30 +1081,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd) } EXPORT_SYMBOL(ion_import_dma_buf_fd); -int ion_sync_for_device(struct ion_client *client, int fd) -{ - struct dma_buf *dmabuf; - struct ion_buffer *buffer; - - dmabuf = dma_buf_get(fd); - if (IS_ERR(dmabuf)) - return PTR_ERR(dmabuf); - - /* if this memory came from ion */ - if (dmabuf->ops != &dma_buf_ops) { - pr_err("%s: can not sync dmabuf from another exporter\n", - __func__); - dma_buf_put(dmabuf); - return -EINVAL; - } - buffer = dmabuf->priv; - - dma_sync_sg_for_device(NULL, buffer->sg_table->sgl, - buffer->sg_table->nents, DMA_BIDIRECTIONAL); - dma_buf_put(dmabuf); - return 0; -} - int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query) { struct ion_device *dev = client->dev; diff --git a/drivers/staging/android/ion/ion_carveout_heap.c b/drivers/staging/android/ion/ion_carveout_heap.c index 9bf8e98..e0e360f 100644 --- a/drivers/staging/android/ion/ion_carveout_heap.c +++ b/drivers/staging/android/ion/ion_carveout_heap.c @@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer *buffer) ion_heap_buffer_zero(buffer); - if (ion_buffer_cached(buffer)) - dma_sync_sg_for_device(NULL, table->s
Re: [PATCH] Quirk for webcam in MacBook Pro 2016
Hi Daniel, On Monday 10 Apr 2017 20:01:18 Daniel Roschka wrote: > Hi Laurent, > > I'm really sorry for all the wrong formatting. I already took measures so it > won't happen again. Don't worry, I've seen worse :-) > > Your patch is now in my git tree, and I will push it upstream for v4.13 > > (v4.11 will be released very soon, and given the pending pull requests for > > v4.12 in the Linux media tree I don't think I can add another one). > > Thanks a lot. Highly appreciated. > > > I collect USB descriptors for UVC devices. Could you please send me the > > output of > > > > lsusb -d 05ac:8600 > > I guess you want the verbose output of lsusb. You'll find it in the attached > file. It might contain more than than you expect as the iBridge device is a > custom ARM processor (probably very similar to the one in the Apple Watch), > not just connecting the webcam to the rest of the system, but also the > Touch Bar and the Touch ID sensor. Thank you very much for the information. -- Regards, Laurent Pinchart
cron job: media_tree daily build: ERRORS
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 11 05:00:21 CEST 2017 media-tree git hash:4aed35ca73f6d9cfd5f7089ba5d04f5fb8623080 media_build git hash: d49f7b2d9934c96a3d2c04021e4da1e12ec97995 v4l-utils git hash: 8356ccd427061e09e49d24bdcf74fa9c9b43080c gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: ERRORS linux-git-arm-davinci: OK linux-git-arm-multi: ERRORS linux-git-arm-pxa: OK linux-git-blackfin-bf561: ERRORS 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: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS 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: WARNINGS linux-3.11.1-i686: ERRORS linux-3.12.67-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: ERRORS linux-4.0.9-i686: ERRORS linux-4.1.33-i686: ERRORS linux-4.2.8-i686: ERRORS linux-4.3.6-i686: ERRORS linux-4.4.22-i686: ERRORS linux-4.5.7-i686: ERRORS linux-4.6.7-i686: ERRORS linux-4.7.5-i686: ERRORS linux-4.8-i686: ERRORS linux-4.9-i686: ERRORS linux-4.10.1-i686: ERRORS linux-4.11-rc1-i686: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS 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: WARNINGS linux-3.11.1-x86_64: ERRORS linux-3.12.67-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS 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: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.33-x86_64: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.22-x86_64: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.5-x86_64: ERRORS linux-4.8-x86_64: ERRORS linux-4.9-x86_64: ERRORS linux-4.10.1-x86_64: ERRORS linux-4.11-rc1-x86_64: ERRORS apps: WARNINGS spec-git: OK sparse: WARNINGS 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/index.html
[linux-stable-rc:linux-4.9.y 1742/1772] arch/arm/mach-omap2/pdata-quirks.c:537:49: error: 'rx51_ir_data' undeclared here (not in a function)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y head: 7ee2dbbb610d590fcc19cd507e70fc17c0eb542c commit: f2ea7a5c37300861913e0884fc846ade633b06f0 [1742/1772] rx51: broken build config: arm-multi_v7_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout f2ea7a5c37300861913e0884fc846ade633b06f0 # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): In file included from arch/arm/mach-omap2/pdata-quirks.c:15:0: >> arch/arm/mach-omap2/pdata-quirks.c:537:49: error: 'rx51_ir_data' undeclared >> here (not in a function) OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", &rx51_ir_data), ^ include/linux/of_platform.h:52:21: note: in definition of macro 'OF_DEV_AUXDATA' .platform_data = _pdata } ^~ vim +/rx51_ir_data +537 arch/arm/mach-omap2/pdata-quirks.c 531 #endif 532 #ifdef CONFIG_ARCH_OMAP3 533 OF_DEV_AUXDATA("ti,omap2-iommu", 0x5d00, "5d00.mmu", 534 &omap3_iommu_pdata), 535 OF_DEV_AUXDATA("ti,omap3-hsmmc", 0x4809c000, "4809c000.mmc", &mmc_pdata[0]), 536 OF_DEV_AUXDATA("ti,omap3-hsmmc", 0x480b4000, "480b4000.mmc", &mmc_pdata[1]), > 537 OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", &rx51_ir_data), 538 /* Only on am3517 */ 539 OF_DEV_AUXDATA("ti,davinci_mdio", 0x5c03, "davinci_mdio.0", NULL), 540 OF_DEV_AUXDATA("ti,am3517-emac", 0x5c00, "davinci_emac.0", --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[media] vimc: API proposal, configuring the topology from user space
Hi, Continuing the discussion about the API of the vimc driver, I made some changes based on the previous comments, please see below and let me know your opinion about it. Helen /*** Configfs considerations: / Informal definitions: subsystem: the root driver folder in user space (/configfs/vimc) item: aka a folder in user space attributes: aka files in the folder group: aka a folder that can contain subfolders (parent and child relation) default group: aka a subfolder that is created automatically when the "parent" folder is created it is not considered a child in terms of rmdir * Performing rmdir in a group will fail if it contain children that are not default groups, i.e, if the folder contain subfolders that are default group, then it can be removed with rmdir, if the subfolders were created with mkdir, then rmdir in the parent will fail. * Configfs has the notion of committable item but it is not implemented yet. A committable item is an item that can be in one of two parent folders called: live and pending. The idea is to create and modify the item in the pending directory and then to move the item through a rename to the live directory where it can't be modified. This seems to be a nice feature for vimc, but as it is not available yet the proposal below won't be based on this. * Groups can be dynamically created/destroyed by the driver whenever it wants. Afaik attributes can only be created when the group or item is created and symlinks can only be create from user space, i.e, the driver don't know how to create/destroy attributes or symlinks in anytime. /*** The API: / In short, a topology like this one: http://goo.gl/Y7eUfu Would look like this filesystem tree: https://goo.gl/mEOmOf v3 core changes: - I removed the use of symlinks as I wans't able to see how to do it nicely. - I use the names of the folders created by user space to retrieve information at mkdir time - hotplug file in each entity - hotplug file in each device - reset file in each device * The /configfs/vimc subsystem empty when the driver is loaded * Create a device Userspace can create a new vimc device with: $ mkdir /configfs/vimc/any_name Example: $ mkdir /configfs/vimc/vimc0 $ ls -l /configfs/vimc/vimc0 hotplug reset entities/ links/ entities/ and links/ folder are default groups, thus they don't prevent rmdir vimc0/, but rmdir will fail if it has any child inside entities/ or links/. hotplug is used to plug and unplug the device, it can read "plugged" or "unplugged" and user can write "plug" or "unplug" to change its state. Changing hotplug state will never fail as the configfs tree will always be in a valid state. reset is used to easily destroy all the topology without the need to walk through all the children to perform rmdir, writing 1 to reset file will set hotplug to "unplugged" and erase all folders under entities/ and links/. * Create an entity Userspace can create a new entity with: $ mkdir /configfs/vimc/vimc0/entities/: Example: $ mkdir /configfs/vimc/vimc0/entities/sensor:SensorA $ ls -l /configfs/vimc/vimc0/entities/sensor:SensorA hotplug pad:source:0/ The name of the folder needs to be in the format : or it will be rejected, this allows the creation of the right pads according to its role at mkdir time, eliminating the previously proposed role and name files. hotplug is used to plug and unplug the hw block, it can read "plugged" or "unplugged" and user can write "plug" or "unplug" to change its state. As we don't support this yet in the media core, changing it will only be allowed if /configfs/vimc/vimc0/hotplug is "unplugged". hotplug file is "unplugged" by default. Pads will be created as default groups with the name in the format pad:: and it will be an empty folder. If the hw block supports different number of pads, we could expose two files: sinks sources where the user space can write the desired number of sink and source pads and the driver will dynamically create the folders pad:: * Create a link User space can create a link between two entities with: $ mkdir /configfs/vimc/vimc0/links/:->: Example: $ mkdir /configfs/vimc/vimc0/links/DebayerA:1->Scaler:0 $ ls -l /configfs/vimc/vimc0/links/DebayerA:1->Scaler:0 flags mkdir will be rejected if folder is not on the format :->:. mkdir will be rejected if either or are not found in /configfs/vimc/vimc0/entities/ The link will only be created if both entities are in "plugged" state. When an entity is removed from /configfs/vimc/vimc0/entities/ with rmdir, its corresponding link folders at /configfs/vimc/vimc0/links will be automatically removed. If one of the entities changes from "plugged" to "unplugged", the link is
Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page
On 04/06/2017 06:01 AM, Marek Szyprowski wrote: > Hi Shuah, > > On 2017-04-05 18:02, Shuah Khan wrote: >> When coherent DMA memory without struct page is shared, importer >> fails to find the page and runs into kernel page fault when it >> tries to dmabuf_ops_attach/map_sg/map_page the invalid page found >> in the sg_table. Please see www.spinics.net/lists/stable/msg164204.html >> for more information on this problem. >> >> This solution allows coherent DMA memory without struct page to be >> shared by providing a way for the exporter to tag the DMA buffer as >> a special buffer without struct page association and passing the >> information in sg_table to the importer. This information is used >> in attach/map_sg to avoid cleaning D-cache and mapping. >> >> The details of the change are: >> >> Framework: >> - Add a new dma_attrs field to struct scatterlist. >> - Add a new DMA_ATTR_DEV_COHERENT_NOPAGE attribute to clearly identify >>Coherent memory without struct page. >> - Add a new dma_check_dev_coherent() interface to check if memory is >>the device coherent area. There is no way to tell where the memory >>returned by dma_alloc_attrs() came from. >> >> Exporter logic: >> - Add logic to vb2_dc_alloc() to call dma_check_dev_coherent() and set >>DMA_ATTR_DEV_COHERENT_NOPAGE based the results of the check. This is >>done in the exporter context. >> - Add logic to arm_dma_get_sgtable() to identify memory without struct >>page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute. If this attr is >>set, arm_dma_get_sgtable() will set page as the cpu_addr and update >>dma_address and dma_attrs fields in struct scatterlist for this sgl. >>This is done in exporter context when buffer is exported. With this >>Note: This change is made on top of Russell King's patch that added >>!pfn_valid(pfn) check to arm_dma_get_sgtable() to error out on invalid >>pages. Coherent memory without struct page will trigger this error. >> >> Importer logic: >> - Add logic to vb2_dc_dmabuf_ops_attach() to identify memory without >>struct page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute when it copies >>the sg_table from the exporter. It will copy dma_attrs and dma_address >>fields. With this logic, dmabuf_ops_attach will no longer trip on an >>invalid page. >> - Add logic to arm_dma_map_sg() to avoid mapping the page when sg_table >>has DMA_ATTR_DEV_COHERENT_NOPAGE buffer. >> - Add logic to arm_dma_unmap_sg() to do nothing for sg entries with >>DMA_ATTR_DEV_COHERENT_NOPAGE attribute. >> >> Without this change the following use-case that runs into kernel >> pagefault when importer tries to attach the exported buffer. >> >> With this change it works: (what a relief after watching pagefaults for >> weeks!!) >> >> gst-launch-1.0 filesrc location=~/GH3_MOV_HD.mp4 ! qtdemux ! h264parse ! >> v4l2video4dec capture-io-mode=dmabuf ! v4l2video7convert >> output-io-mode=dmabuf-import ! kmssink force-modesetting=true >> >> I am sending RFC patch to get feedback on the approach and see if I missed >> anything. > > Frankly, once You decided to hack around dma-buf and issues with coherent, > carved out memory, it might be a bit better to find the ultimate solution > instead of the another hack. Please note that it will still not allow to > share a buffer allocated from carved-out memory and a device, which is > behind IOMMU. With your patch s5p-mfc patch series does address the problem for this use-case for 4.12 onwards. However I am still concerned about prior release and this pagefault is bad. Invalid page test partially solves the problem. Would it helpful to at least prevent the pagfault with a definitive test. Please see my response to Russell. Let me know your thoughts on that. > > I thought a bit about this and the current shape of dma-buf code. > > IMHO the proper way of solving all those issues would be to replace > dma-buf internal representation of the memory from struct scatter_list > to pfn array. This would really solve the problem of buffers which > cannot be properly represented by scatter lists/struct pages and would > even allow sharing buffers between all kinds of devices. Scatter-lists > are also quite over-engineered structures to represent a single buffer > (pfn array is a bit more compact representation). Also there is a lots > of buggy code which use scatter-list in a bit creative way (like > assuming that each page maps to a single scatter list entry for > example). The only missing piece, required for such change would be > extending DMA-mapping with dma_map_pfn() interface. I agree with you on scatterlists being clumsy. Changing over to pfn array could simplify things. I am exploring a slightly different option that might not require too many changes. I will respond with concrete ideas later on this week. > > This would be however quite large task, especially taking into account > all current users of DMA-buf framework... Yeah it will be a large ta
Looking for device driver advice
I am looking for advice regarding the construction of a device driver for a MIPI CSI2 imager (a Sony IMX241) that is connected to a MIPI<->Parallel converter (Toshiba TC358748) wired into a parallel interface on a Soc (a Microchip/Atmel SAMAD2x device.) The Sony imager is controlled and configured via I2C, as is the Toshiba converter. I could write a single driver that configures both devices and treats them as a single device that just happens to use 2 i2c addresses. I could use the i2c_new_dummy() API to construct the device abstraction for the second physical device at probe time for the first physical device. Or I could do something smarter (or at least different), specifying the two devices independently via my device tree file, perhaps linking them together via "port" nodes. Currently, I use the "port" node concept to link an i2c imager to the Image System Controller (isc) node in the SAMA5 device. Perhaps that generalizes to a chain of nodes linked together... I don't know. I'm also not sure how these two devices might play into V4L2's "subdev" concept. Are they separate, independent sub devices of the ISC, or are they a single sub device. Any thoughts, intuition, pointers to existing code that addresses questions such as these, would be welcome. Thanks. --wpd
Re: [PATCH 0/3] support for Logilink VG0022a DVB-T2 stick
ping On Wed, 15 Mar 2017 23:22:07 +0100 Andreas Kemnade wrote: > Hi all, > here are some patches needed for supporting the > Logilink VG0022A DVB-T2 stick. > As the combination of chips in that stick is not > uncommon, the first two patches might also fix problems > for similar hardware. > > Andreas Kemnade (3): > [media] si2157: get chip id during probing > [media] af9035: init i2c already in it930x_frontend_attach > [media] af9035: add Logilink vg0022a to device id table > > drivers/media/tuners/si2157.c | 54 > +-- > drivers/media/tuners/si2157_priv.h| 7 + > drivers/media/usb/dvb-usb-v2/af9035.c | 45 - > 3 files changed, 83 insertions(+), 23 deletions(-) > pgpWXfZ3ZwVSm.pgp Description: OpenPGP digital signature
[PATCHv4 11/15] vidioc-queryctrl.rst: document V4L2_CTRL_FLAG_MODIFY_LAYOUT
From: Hans Verkuil Document this new control flag. Signed-off-by: Hans Verkuil --- Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 13 + Documentation/media/videodev2.h.rst.exceptions| 1 + 2 files changed, 14 insertions(+) diff --git a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst index 82769de801b1..1ffdc3f3c614 100644 --- a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst +++ b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst @@ -507,6 +507,19 @@ See also the examples in :ref:`control`. represents an action on the hardware. For example: clearing an error flag or triggering the flash. All the controls of the type ``V4L2_CTRL_TYPE_BUTTON`` have this flag set. +* .. _FLAG_MODIFY_LAYOUT: + + - ``V4L2_CTRL_FLAG_MODIFY_LAYOUT`` + - 0x0400 + - Changing this control value may modify the layout of the +buffer (for video devices) or the media bus format (for sub-devices). + + A typical example would be the ``V4L2_CID_ROTATE`` control. + + Note that typically controls with this flag will also set the + ``V4L2_CTRL_FLAG_GRABBED`` flag when buffers are allocated or + streaming is in progress since most drivers do not support changing + the format in that case. Return Value diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions index c9c611b18ba1..a5cb0a8686ac 100644 --- a/Documentation/media/videodev2.h.rst.exceptions +++ b/Documentation/media/videodev2.h.rst.exceptions @@ -341,6 +341,7 @@ replace define V4L2_CTRL_FLAG_WRITE_ONLY control-flags replace define V4L2_CTRL_FLAG_VOLATILE control-flags replace define V4L2_CTRL_FLAG_HAS_PAYLOAD control-flags replace define V4L2_CTRL_FLAG_EXECUTE_ON_WRITE control-flags +replace define V4L2_CTRL_FLAG_MODIFY_LAYOUT control-flags replace define V4L2_CTRL_FLAG_NEXT_CTRL control replace define V4L2_CTRL_FLAG_NEXT_COMPOUND control -- 2.11.0
[PATCHv4 09/15] v4l: Define a pixel format for the R-Car VSP1 2-D histogram engine
From: Niklas Söderlund The format is used on the R-Car VSP1 video queues that carry 2-D histogram statistics data. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart --- Documentation/media/uapi/v4l/meta-formats.rst | 1 + .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst| 120 + drivers/media/v4l2-core/v4l2-ioctl.c | 1 + include/uapi/linux/videodev2.h | 3 +- 4 files changed, 124 insertions(+), 1 deletion(-) create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst diff --git a/Documentation/media/uapi/v4l/meta-formats.rst b/Documentation/media/uapi/v4l/meta-formats.rst index 05ab91e12f10..01e24e3df571 100644 --- a/Documentation/media/uapi/v4l/meta-formats.rst +++ b/Documentation/media/uapi/v4l/meta-formats.rst @@ -13,3 +13,4 @@ These formats are used for the :ref:`metadata` interface only. :maxdepth: 1 pixfmt-meta-vsp1-hgo +pixfmt-meta-vsp1-hgt diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst new file mode 100644 index ..fb9f79466319 --- /dev/null +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst @@ -0,0 +1,120 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _v4l2-meta-fmt-vsp1-hgt: + +*** +V4L2_META_FMT_VSP1_HGT ('VSPT') +*** + +Renesas R-Car VSP1 2-D Histogram Data + + +Description +=== + +This format describes histogram data generated by the Renesas R-Car VSP1 +2-D Histogram (HGT) engine. + +The VSP1 HGT is a histogram computation engine that operates on HSV +data. It operates on a possibly cropped and subsampled input image and +computes the sum, maximum and minimum of the S component as well as a +weighted frequency histogram based on the H and S components. + +The histogram is a matrix of 6 Hue and 32 Saturation buckets, 192 in +total. Each HSV value is added to one or more buckets with a weight +between 1 and 16 depending on the Hue areas configuration. Finding the +corresponding buckets is done by inspecting the H and S value independently. + +The Saturation position **n** (0 - 31) of the bucket in the matrix is +found by the expression: + +n = S / 8 + +The Hue position **m** (0 - 5) of the bucket in the matrix depends on +how the HGT Hue areas are configured. There are 6 user configurable Hue +Areas which can be configured to cover overlapping Hue values: + +:: + + Area 0 Area 1 Area 2 Area 3 Area 4 Area 5 + + \ /| |\ /| |\ /| |\ /| |\ /| |\ /| |\ / +\ / | | \ / | | \ / | | \ / | | \ / | | \ / | | \ / + X | | X | | X | | X | | X | | X | | X +/ \ | | / \ | | / \ | | / \ | | / \ | | / \ | | / \ + / \| |/ \| |/ \| |/ \| |/ \| |/ \| |/ \ + 5U 0L 0U 1L 1U 2L 2U 3L 3U 4L 4U 5L 5U 0L +<0..Hue Value255> + +When two consecutive areas don't overlap (n+1L is equal to nU) the boundary +value is considered as part of the lower area. + +Pixels with a hue value included in the centre of an area (between nL and nU +included) are attributed to that single area and given a weight of 16. Pixels +with a hue value included in the overlapping region between two areas (between +n+1L and nU excluded) are attributed to both areas and given a weight for each +of these areas proportional to their position along the diagonal lines +(rounded down). + +The Hue area setup must match one of the following constrains: + +:: + +0L <= 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U + +:: + +0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U <= 0L + +**Byte Order.** +All data is stored in memory in little endian format. Each cell in the tables +contains one byte. + +.. flat-table:: VSP1 HGT Data - (776 bytes) +:header-rows: 2 +:stub-columns: 0 + +* - Offset + - :cspan:`4` Memory +* - + - [31:24] + - [23:16] + - [15:8] + - [7:0] +* - 0 + - - + - S max [7:0] + - - + - S min [7:0] +* - 4 + - :cspan:`4` S sum [31:0] +* - 8 + - :cspan:`4` Histogram bucket (m=0, n=0) [31:0] +* - 12 + - :cspan:`4` Histogram bucket (m=0, n=1) [31:0] +* - + - :cspan:`4` ... +* - 132 + - :cspan:`4` Histogram bucket (m=0, n=31) [31:0] +* - 136 + - :cspan:`4` Histogram bucket (m=1, n=0) [31:0] +* - + - :cspan:`4` ... +* - 264 + - :cspan:`4` Histogram bucket (m=2, n=0) [31:0] +* - + - :cspan:`4` ... +* - 392 + - :cspan:`4` Histogr
[PATCHv4 10/15] v4l: vsp1: Add HGT support
From: Niklas Söderlund The HGT is a Histogram Generator Two-Dimensions. It computes a weighted frequency histograms for hue and saturation areas over a configurable region of the image with optional subsampling. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/Makefile | 2 +- drivers/media/platform/vsp1/vsp1.h| 3 + drivers/media/platform/vsp1/vsp1_drv.c| 32 - drivers/media/platform/vsp1/vsp1_entity.c | 14 ++ drivers/media/platform/vsp1/vsp1_hgt.c| 222 ++ drivers/media/platform/vsp1/vsp1_hgt.h| 42 ++ drivers/media/platform/vsp1/vsp1_pipe.c | 16 +++ drivers/media/platform/vsp1/vsp1_pipe.h | 2 + drivers/media/platform/vsp1/vsp1_regs.h | 9 ++ drivers/media/platform/vsp1/vsp1_video.c | 6 + 10 files changed, 343 insertions(+), 5 deletions(-) create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.c create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.h diff --git a/drivers/media/platform/vsp1/Makefile b/drivers/media/platform/vsp1/Makefile index 8ab6a063569e..a33afc385a48 100644 --- a/drivers/media/platform/vsp1/Makefile +++ b/drivers/media/platform/vsp1/Makefile @@ -3,7 +3,7 @@ vsp1-y += vsp1_dl.o vsp1_drm.o vsp1_video.o vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o -vsp1-y += vsp1_hgo.o vsp1_histo.o +vsp1-y += vsp1_hgo.o vsp1_hgt.o vsp1_histo.o vsp1-y += vsp1_lif.o obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1.o diff --git a/drivers/media/platform/vsp1/vsp1.h b/drivers/media/platform/vsp1/vsp1.h index 0ba7521c01b4..85387a64179a 100644 --- a/drivers/media/platform/vsp1/vsp1.h +++ b/drivers/media/platform/vsp1/vsp1.h @@ -33,6 +33,7 @@ struct vsp1_platform_data; struct vsp1_bru; struct vsp1_clu; struct vsp1_hgo; +struct vsp1_hgt; struct vsp1_hsit; struct vsp1_lif; struct vsp1_lut; @@ -52,6 +53,7 @@ struct vsp1_uds; #define VSP1_HAS_WPF_VFLIP (1 << 5) #define VSP1_HAS_WPF_HFLIP (1 << 6) #define VSP1_HAS_HGO (1 << 7) +#define VSP1_HAS_HGT (1 << 8) struct vsp1_device_info { u32 version; @@ -76,6 +78,7 @@ struct vsp1_device { struct vsp1_bru *bru; struct vsp1_clu *clu; struct vsp1_hgo *hgo; + struct vsp1_hgt *hgt; struct vsp1_hsit *hsi; struct vsp1_hsit *hst; struct vsp1_lif *lif; diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c index 0acc8ed6ac59..048446af5ae7 100644 --- a/drivers/media/platform/vsp1/vsp1_drv.c +++ b/drivers/media/platform/vsp1/vsp1_drv.c @@ -31,6 +31,7 @@ #include "vsp1_dl.h" #include "vsp1_drm.h" #include "vsp1_hgo.h" +#include "vsp1_hgt.h" #include "vsp1_hsit.h" #include "vsp1_lif.h" #include "vsp1_lut.h" @@ -161,6 +162,16 @@ static int vsp1_uapi_create_links(struct vsp1_device *vsp1) return ret; } + if (vsp1->hgt) { + ret = media_create_pad_link(&vsp1->hgt->histo.entity.subdev.entity, + HISTO_PAD_SOURCE, + &vsp1->hgt->histo.video.entity, 0, + MEDIA_LNK_FL_ENABLED | + MEDIA_LNK_FL_IMMUTABLE); + if (ret < 0) + return ret; + } + if (vsp1->lif) { ret = media_create_pad_link(&vsp1->wpf[0]->entity.subdev.entity, RWPF_PAD_SOURCE, @@ -305,6 +316,17 @@ static int vsp1_create_entities(struct vsp1_device *vsp1) &vsp1->entities); } + if (vsp1->info->features & VSP1_HAS_HGT && vsp1->info->uapi) { + vsp1->hgt = vsp1_hgt_create(vsp1); + if (IS_ERR(vsp1->hgt)) { + ret = PTR_ERR(vsp1->hgt); + goto done; + } + + list_add_tail(&vsp1->hgt->histo.entity.list_dev, + &vsp1->entities); + } + /* * The LIF is only supported when used in conjunction with the DU, in * which case the userspace API is disabled. If the userspace API is @@ -591,7 +613,8 @@ static const struct vsp1_device_info vsp1_device_infos[] = { .model = "VSP1-S", .gen = 2, .features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO - | VSP1_HAS_LUT | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP, + | VSP1_HAS_HGT | VSP1_HAS_LUT | VSP1_HAS_SRU + | VSP1_HAS_WPF_VFLIP,
[PATCHv4 14/15] buffer.rst: clarify how V4L2_CTRL_FLAG_MODIFY_LAYOUT/GRABBER are used
From: Hans Verkuil Explain when the V4L2_CTRL_FLAG_MODIFY_LAYOUT and V4L2_CTRL_FLAG_MODIFY_GRABBER flags should be used. Signed-off-by: Hans Verkuil --- Documentation/media/uapi/v4l/buffer.rst | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst index 64613d935edd..ae6ee73f151c 100644 --- a/Documentation/media/uapi/v4l/buffer.rst +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -48,10 +48,16 @@ The set of information needed to interpret the content of a buffer (e.g. the pixel format, the line stride, the tiling orientation or the rotation) is collectively referred to in the rest of this section as the buffer layout. +Controls that can modify the buffer layout shall set the +``V4L2_CTRL_FLAG_MODIFY_LAYOUT`` flag. + Modifying formats or controls that influence the buffer size or layout require the stream to be stopped. Any attempt at such a modification while the stream is active shall cause the ioctl setting the format or the control to return -the ``EBUSY`` error code. +the ``EBUSY`` error code. In that case drivers shall also set the +``V4L2_CTRL_FLAG_GRABBED`` flag when calling +:c:func:`VIDIOC_QUERYCTRL` or :c:func:`VIDIOC_QUERY_EXT_CTRL` for such a +control while the stream is active. .. note:: @@ -67,7 +73,8 @@ the ``EBUSY`` error code. Controls that only influence the buffer layout can be modified at any time when the stream is stopped. As they don't influence the buffer size, no special handling is needed to synchronize those controls with buffer -allocation. +allocation and the ``V4L2_CTRL_FLAG_GRABBED`` flag is cleared once the +stream is stopped. Formats and controls that influence the buffer size interact with buffer allocation. The simplest way to handle this is for drivers to always require @@ -75,8 +82,10 @@ buffers to be reallocated in order to change those formats or controls. In that case, to perform such changes, userspace applications shall first stop the video stream with the :c:func:`VIDIOC_STREAMOFF` ioctl if it is running and free all buffers with the :c:func:`VIDIOC_REQBUFS` ioctl if they are -allocated. The format or controls can then be modified, and buffers shall then -be reallocated and the stream restarted. A typical ioctl sequence is +allocated. After freeing all buffers the ``V4L2_CTRL_FLAG_GRABBED`` flag +for controls is cleared. The format or controls can then be modified, and +buffers shall then be reallocated and the stream restarted. A typical ioctl +sequence is #. VIDIOC_STREAMOFF #. VIDIOC_REQBUFS(0) -- 2.11.0
[PATCHv4 15/15] vsp1: set V4L2_CTRL_FLAG_MODIFY_LAYOUT for histogram controls
From: Hans Verkuil The two histogram controls will modify the layout of the metadata, so this flag should be set. Signed-off-by: Hans Verkuil --- drivers/media/platform/vsp1/vsp1_hgo.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/vsp1/vsp1_hgo.c b/drivers/media/platform/vsp1/vsp1_hgo.c index a138c6b7fb05..50309c053b78 100644 --- a/drivers/media/platform/vsp1/vsp1_hgo.c +++ b/drivers/media/platform/vsp1/vsp1_hgo.c @@ -111,6 +111,7 @@ static const struct v4l2_ctrl_config hgo_max_rgb_control = { .max = 1, .def = 0, .step = 1, + .flags = V4L2_CTRL_FLAG_MODIFY_LAYOUT, }; static const s64 hgo_num_bins[] = { @@ -125,6 +126,7 @@ static const struct v4l2_ctrl_config hgo_num_bins_control = { .max = 1, .def = 0, .qmenu_int = hgo_num_bins, + .flags = V4L2_CTRL_FLAG_MODIFY_LAYOUT, }; /* - -- 2.11.0
[PATCHv4 01/15] v4l: Clearly document interactions between formats, controls and buffers
From: Laurent Pinchart V4L2 exposes parameters that influence buffers sizes through the format ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT, VIDIOC_S_FMT, and possibly VIDIOC_G_SELECTION and VIDIOC_S_SELECTION). Other parameters not part of the format structure may also influence buffer sizes or buffer layout in general. One existing such parameter is rotation, which is implemented by the V4L2_CID_ROTATE control and thus exposed through the V4L2 control ioctls. The interaction between those parameters and buffers is currently only partially specified by the V4L2 API. In particular interactions between controls and buffers isn't specified at all. The behaviour of the VIDIOC_S_FMT and VIDIOC_S_SELECTION ioctls when buffers are allocated is also not fully specified. This patch clearly defines and documents the interactions between formats, selections, controls and buffers. The preparatory discussions for the documentation change considered completely disallowing controls that change the buffer size or layout, in favour of extending the format API with a new ioctl that would bundle those controls with format information. The idea has been rejected, as this would essentially be a restricted version of the upcoming request API that wouldn't bring any additional value. Another option we have considered was to mandate the use of the request API to modify controls that influence buffer size or layout. This has also been rejected on the grounds that requiring the request API to change rotation even when streaming is stopped would significantly complicate implementation of drivers and usage of the V4L2 API for applications. Applications will however be required to use the upcoming request API to change at runtime formats or controls that influence the buffer size or layout, because of the need to synchronize buffers with the formats and controls. Otherwise there would be no way to interpret the content of a buffer correctly. Signed-off-by: Laurent Pinchart Acked-by: Sakari Ailus Acked-by: Hans Verkuil --- Documentation/media/uapi/v4l/buffer.rst | 110 1 file changed, 110 insertions(+) diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst index ac58966ccb9b..d1e0d55dc219 100644 --- a/Documentation/media/uapi/v4l/buffer.rst +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -34,6 +34,116 @@ flags are copied from the OUTPUT video buffer to the CAPTURE video buffer. +Interactions between formats, controls and buffers +== + +V4L2 exposes parameters that influence the buffer size, or the way data is +laid out in the buffer. Those parameters are exposed through both formats and +controls. One example of such a control is the ``V4L2_CID_ROTATE`` control +that modifies the direction in which pixels are stored in the buffer, as well +as the buffer size when the selected format includes padding at the end of +lines. + +The set of information needed to interpret the content of a buffer (e.g. the +pixel format, the line stride, the tiling orientation or the rotation) is +collectively referred to in the rest of this section as the buffer layout. + +Modifying formats or controls that influence the buffer size or layout require +the stream to be stopped. Any attempt at such a modification while the stream +is active shall cause the ioctl setting the format or the control to return +the ``EBUSY`` error code. + +.. note:: + + The :c:func:`VIDIOC_S_SELECTION` ioctl can, depending on the hardware (for + instance if the device doesn't include a scaler), modify the format in + addition to the selection rectangle. Similarly, the + :c:func:`VIDIOC_S_INPUT`, :c:func:`VIDIOC_S_OUTPUT`, :c:func:`VIDIOC_S_STD` + and :c:func:`VIDIOC_S_DV_TIMINGS` ioctls can also modify the format and + selection rectangles. When those ioctls result in a buffer size or layout + change, drivers shall handle that condition as they would handle it in the + :c:func:`VIDIOC_S_FMT` ioctl in all cases described in this section. + +Controls that only influence the buffer layout can be modified at any time +when the stream is stopped. As they don't influence the buffer size, no +special handling is needed to synchronize those controls with buffer +allocation. + +Formats and controls that influence the buffer size interact with buffer +allocation. The simplest way to handle this is for drivers to always require +buffers to be reallocated in order to change those formats or controls. In +that case, to perform such changes, userspace applications shall first stop +the video stream with the :c:func:`VIDIOC_STREAMOFF` ioctl if it is running +and free all buffers with the :c:func:`VIDIOC_REQBUFS` ioctl if they are +allocated. The format or controls can then be modified, and buffers shall then +be reallocated and the stream restarted. A typical ioctl sequence is + + #. VIDIOC_STREAMOFF + #. VIDIOC_REQBUFS(0) + #. VIDIOC_S_EXT_CTRLS +
[PATCHv4 05/15] v4l: vsp1: Support histogram generators in pipeline configuration
From: Laurent Pinchart Histogram generators are single-pad entities that branch as leaf nodes at any point in the pipeline. Make sure that pipeline traversal and routing configuration support them correctly. Support for the actual HGO and HGT operation will come later. Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_drm.c| 2 +- drivers/media/platform/vsp1/vsp1_drv.c| 4 +- drivers/media/platform/vsp1/vsp1_entity.c | 124 ++ drivers/media/platform/vsp1/vsp1_entity.h | 8 +- drivers/media/platform/vsp1/vsp1_pipe.c | 6 +- drivers/media/platform/vsp1/vsp1_video.c | 18 ++--- 6 files changed, 134 insertions(+), 28 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_drm.c b/drivers/media/platform/vsp1/vsp1_drm.c index 1f88d8473b71..9d235e830f5a 100644 --- a/drivers/media/platform/vsp1/vsp1_drm.c +++ b/drivers/media/platform/vsp1/vsp1_drm.c @@ -496,7 +496,7 @@ void vsp1_du_atomic_flush(struct device *dev) } } - vsp1_entity_route_setup(entity, dl); + vsp1_entity_route_setup(entity, pipe, dl); if (entity->ops->configure) { entity->ops->configure(entity, pipe, dl, diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c index 8d1e61b353bb..83a6669a6328 100644 --- a/drivers/media/platform/vsp1/vsp1_drv.c +++ b/drivers/media/platform/vsp1/vsp1_drv.c @@ -105,7 +105,9 @@ static int vsp1_create_sink_links(struct vsp1_device *vsp1, if (source->type == sink->type) continue; - if (source->type == VSP1_ENTITY_LIF || + if (source->type == VSP1_ENTITY_HGO || + source->type == VSP1_ENTITY_HGT || + source->type == VSP1_ENTITY_LIF || source->type == VSP1_ENTITY_WPF) continue; diff --git a/drivers/media/platform/vsp1/vsp1_entity.c b/drivers/media/platform/vsp1/vsp1_entity.c index 12eca5660d6e..88a2aae182ba 100644 --- a/drivers/media/platform/vsp1/vsp1_entity.c +++ b/drivers/media/platform/vsp1/vsp1_entity.c @@ -21,6 +21,8 @@ #include "vsp1.h" #include "vsp1_dl.h" #include "vsp1_entity.h" +#include "vsp1_pipe.h" +#include "vsp1_rwpf.h" static inline struct vsp1_entity * media_entity_to_vsp1_entity(struct media_entity *entity) @@ -28,11 +30,14 @@ media_entity_to_vsp1_entity(struct media_entity *entity) return container_of(entity, struct vsp1_entity, subdev.entity); } -void vsp1_entity_route_setup(struct vsp1_entity *source, +void vsp1_entity_route_setup(struct vsp1_entity *entity, +struct vsp1_pipeline *pipe, struct vsp1_dl_list *dl) { + struct vsp1_entity *source; struct vsp1_entity *sink; + source = entity; if (source->route->reg == 0) return; @@ -283,25 +288,32 @@ int vsp1_subdev_enum_frame_size(struct v4l2_subdev *subdev, * Media Operations */ -int vsp1_entity_link_setup(struct media_entity *entity, - const struct media_pad *local, - const struct media_pad *remote, u32 flags) +static int vsp1_entity_link_setup_source(const struct media_pad *source_pad, +const struct media_pad *sink_pad, +u32 flags) { struct vsp1_entity *source; - if (!(local->flags & MEDIA_PAD_FL_SOURCE)) - return 0; - - source = media_entity_to_vsp1_entity(local->entity); + source = media_entity_to_vsp1_entity(source_pad->entity); if (!source->route) return 0; if (flags & MEDIA_LNK_FL_ENABLED) { - if (source->sink) - return -EBUSY; - source->sink = remote->entity; - source->sink_pad = remote->index; + struct vsp1_entity *sink + = media_entity_to_vsp1_entity(sink_pad->entity); + + /* +* Fan-out is limited to one for the normal data path plus +* optional HGO and HGT. We ignore the HGO and HGT here. +*/ + if (sink->type != VSP1_ENTITY_HGO && + sink->type != VSP1_ENTITY_HGT) { + if (source->sink) + return -EBUSY; + source->sink = sink_pad->entity; + source->sink_pad = sink_pad->index; + } } else { source->sink = NULL; source->sink_pad = 0; @@ -310,6 +322,85 @@ int vsp1_entity_link_setup(struct media_entity *entity, return 0; } +static int vsp1_entity_link_setup_sink(const struct media_pad *source_pad, + const struct media_pad *sink_pad, +
[PATCHv4 13/15] v4l2-ctrls.c: set V4L2_CTRL_FLAG_MODIFY_LAYOUT for ROTATE
From: Hans Verkuil The rotate control will modify the layout by definition. Always set this flag. Signed-off-by: Hans Verkuil --- drivers/media/v4l2-core/v4l2-ctrls.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c index b4b364f68695..ec42872d11cf 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -997,6 +997,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type, *min = 0; *max = *step = 1; break; + case V4L2_CID_ROTATE: + *type = V4L2_CTRL_TYPE_INTEGER; + *flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT; + break; case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE: case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: *type = V4L2_CTRL_TYPE_INTEGER; -- 2.11.0
[PATCHv4 08/15] v4l: vsp1: Add HGO support
From: Laurent Pinchart The HGO is a Histogram Generator One-Dimension. It computes per-channel histograms over a configurable region of the image with optional subsampling. Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/Makefile | 2 +- drivers/media/platform/vsp1/vsp1.h| 3 + drivers/media/platform/vsp1/vsp1_drv.c| 42 -- drivers/media/platform/vsp1/vsp1_entity.c | 16 +++ drivers/media/platform/vsp1/vsp1_hgo.c| 228 ++ drivers/media/platform/vsp1/vsp1_hgo.h| 45 ++ drivers/media/platform/vsp1/vsp1_pipe.c | 16 +++ drivers/media/platform/vsp1/vsp1_pipe.h | 2 + drivers/media/platform/vsp1/vsp1_regs.h | 20 ++- drivers/media/platform/vsp1/vsp1_video.c | 6 + 10 files changed, 367 insertions(+), 13 deletions(-) create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.c create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.h diff --git a/drivers/media/platform/vsp1/Makefile b/drivers/media/platform/vsp1/Makefile index c559536f7867..8ab6a063569e 100644 --- a/drivers/media/platform/vsp1/Makefile +++ b/drivers/media/platform/vsp1/Makefile @@ -3,7 +3,7 @@ vsp1-y += vsp1_dl.o vsp1_drm.o vsp1_video.o vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o -vsp1-y += vsp1_histo.o +vsp1-y += vsp1_hgo.o vsp1_histo.o vsp1-y += vsp1_lif.o obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1.o diff --git a/drivers/media/platform/vsp1/vsp1.h b/drivers/media/platform/vsp1/vsp1.h index b23fa879a9aa..0ba7521c01b4 100644 --- a/drivers/media/platform/vsp1/vsp1.h +++ b/drivers/media/platform/vsp1/vsp1.h @@ -32,6 +32,7 @@ struct vsp1_entity; struct vsp1_platform_data; struct vsp1_bru; struct vsp1_clu; +struct vsp1_hgo; struct vsp1_hsit; struct vsp1_lif; struct vsp1_lut; @@ -50,6 +51,7 @@ struct vsp1_uds; #define VSP1_HAS_CLU (1 << 4) #define VSP1_HAS_WPF_VFLIP (1 << 5) #define VSP1_HAS_WPF_HFLIP (1 << 6) +#define VSP1_HAS_HGO (1 << 7) struct vsp1_device_info { u32 version; @@ -73,6 +75,7 @@ struct vsp1_device { struct vsp1_bru *bru; struct vsp1_clu *clu; + struct vsp1_hgo *hgo; struct vsp1_hsit *hsi; struct vsp1_hsit *hst; struct vsp1_lif *lif; diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c index 83a6669a6328..0acc8ed6ac59 100644 --- a/drivers/media/platform/vsp1/vsp1_drv.c +++ b/drivers/media/platform/vsp1/vsp1_drv.c @@ -30,6 +30,7 @@ #include "vsp1_clu.h" #include "vsp1_dl.h" #include "vsp1_drm.h" +#include "vsp1_hgo.h" #include "vsp1_hsit.h" #include "vsp1_lif.h" #include "vsp1_lut.h" @@ -150,6 +151,16 @@ static int vsp1_uapi_create_links(struct vsp1_device *vsp1) return ret; } + if (vsp1->hgo) { + ret = media_create_pad_link(&vsp1->hgo->histo.entity.subdev.entity, + HISTO_PAD_SOURCE, + &vsp1->hgo->histo.video.entity, 0, + MEDIA_LNK_FL_ENABLED | + MEDIA_LNK_FL_IMMUTABLE); + if (ret < 0) + return ret; + } + if (vsp1->lif) { ret = media_create_pad_link(&vsp1->wpf[0]->entity.subdev.entity, RWPF_PAD_SOURCE, @@ -283,6 +294,17 @@ static int vsp1_create_entities(struct vsp1_device *vsp1) list_add_tail(&vsp1->hst->entity.list_dev, &vsp1->entities); + if (vsp1->info->features & VSP1_HAS_HGO && vsp1->info->uapi) { + vsp1->hgo = vsp1_hgo_create(vsp1); + if (IS_ERR(vsp1->hgo)) { + ret = PTR_ERR(vsp1->hgo); + goto done; + } + + list_add_tail(&vsp1->hgo->histo.entity.list_dev, + &vsp1->entities); + } + /* * The LIF is only supported when used in conjunction with the DU, in * which case the userspace API is disabled. If the userspace API is @@ -568,8 +590,8 @@ static const struct vsp1_device_info vsp1_device_infos[] = { .version = VI6_IP_VERSION_MODEL_VSPS_H2, .model = "VSP1-S", .gen = 2, - .features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_LUT - | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP, + .features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_HGO + | VSP1_HAS_LUT | VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP, .rpf_count = 5, .uds_count = 3,
[PATCHv4 12/15] videodev.h: add V4L2_CTRL_FLAG_MODIFY_LAYOUT
From: Hans Verkuil Add new flag to indicate that changing this control will change the buffer/mediabus layout as well. Signed-off-by: Hans Verkuil --- include/uapi/linux/videodev2.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 75f032448ae5..2b8feb86d09e 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -1659,6 +1659,7 @@ struct v4l2_querymenu { #define V4L2_CTRL_FLAG_VOLATILE0x0080 #define V4L2_CTRL_FLAG_HAS_PAYLOAD 0x0100 #define V4L2_CTRL_FLAG_EXECUTE_ON_WRITE0x0200 +#define V4L2_CTRL_FLAG_MODIFY_LAYOUT 0x0400 /* Query flags, to be ORed with the control ID */ #define V4L2_CTRL_FLAG_NEXT_CTRL 0x8000 -- 2.11.0
[PATCHv4 00/15] R-Car VSP1 Histogram Support
From: Hans Verkuil This patch series is the rebased version of this pull request: https://www.mail-archive.com/linux-media@vger.kernel.org/msg111025.html It slightly modifies 'Add metadata buffer type and format' (remove experimental note and add newline after label) and it adds support for V4L2_CTRL_FLAG_MODIFY_LAYOUT, as requested by Mauro. No other changes were made. Regards, Hans Hans Verkuil (5): vidioc-queryctrl.rst: document V4L2_CTRL_FLAG_MODIFY_LAYOUT videodev.h: add V4L2_CTRL_FLAG_MODIFY_LAYOUT v4l2-ctrls.c: set V4L2_CTRL_FLAG_MODIFY_LAYOUT for ROTATE buffer.rst: clarify how V4L2_CTRL_FLAG_MODIFY_LAYOUT/GRABBER are used vsp1: set V4L2_CTRL_FLAG_MODIFY_LAYOUT for histogram controls Laurent Pinchart (8): v4l: Clearly document interactions between formats, controls and buffers v4l: vsp1: wpf: Implement rotation support v4l: Add metadata buffer type and format v4l: vsp1: Add histogram support v4l: vsp1: Support histogram generators in pipeline configuration v4l: vsp1: Fix HGO and HGT routing register addresses v4l: Define a pixel format for the R-Car VSP1 1-D histogram engine v4l: vsp1: Add HGO support Niklas Söderlund (2): v4l: Define a pixel format for the R-Car VSP1 2-D histogram engine v4l: vsp1: Add HGT support Documentation/media/uapi/v4l/buffer.rst| 122 Documentation/media/uapi/v4l/dev-meta.rst | 58 ++ Documentation/media/uapi/v4l/devices.rst | 1 + Documentation/media/uapi/v4l/meta-formats.rst | 16 + .../media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst| 168 ++ .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst| 120 Documentation/media/uapi/v4l/pixfmt.rst| 1 + Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 + Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 13 + Documentation/media/videodev2.h.rst.exceptions | 3 + drivers/media/platform/Kconfig | 1 + drivers/media/platform/vsp1/Makefile | 1 + drivers/media/platform/vsp1/vsp1.h | 6 + drivers/media/platform/vsp1/vsp1_drm.c | 2 +- drivers/media/platform/vsp1/vsp1_drv.c | 70 ++- drivers/media/platform/vsp1/vsp1_entity.c | 154 - drivers/media/platform/vsp1/vsp1_entity.h | 8 +- drivers/media/platform/vsp1/vsp1_hgo.c | 230 drivers/media/platform/vsp1/vsp1_hgo.h | 45 ++ drivers/media/platform/vsp1/vsp1_hgt.c | 222 +++ drivers/media/platform/vsp1/vsp1_hgt.h | 42 ++ drivers/media/platform/vsp1/vsp1_histo.c | 646 + drivers/media/platform/vsp1/vsp1_histo.h | 84 +++ drivers/media/platform/vsp1/vsp1_pipe.c| 38 +- drivers/media/platform/vsp1/vsp1_pipe.h| 4 + drivers/media/platform/vsp1/vsp1_regs.h| 33 +- drivers/media/platform/vsp1/vsp1_rpf.c | 2 +- drivers/media/platform/vsp1/vsp1_rwpf.c| 5 + drivers/media/platform/vsp1/vsp1_rwpf.h| 7 +- drivers/media/platform/vsp1/vsp1_video.c | 42 +- drivers/media/platform/vsp1/vsp1_wpf.c | 205 +-- drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 19 + drivers/media/v4l2-core/v4l2-ctrls.c | 4 + drivers/media/v4l2-core/v4l2-dev.c | 16 +- drivers/media/v4l2-core/v4l2-ioctl.c | 36 ++ drivers/media/v4l2-core/videobuf2-v4l2.c | 3 + include/media/v4l2-ioctl.h | 17 + include/trace/events/v4l2.h| 1 + include/uapi/linux/videodev2.h | 18 + 39 files changed, 2364 insertions(+), 102 deletions(-) create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst create mode 100644 Documentation/media/uapi/v4l/meta-formats.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.c create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.h create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.c create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.h create mode 100644 drivers/media/platform/vsp1/vsp1_histo.c create mode 100644 drivers/media/platform/vsp1/vsp1_histo.h -- 2.11.0
[PATCHv4 07/15] v4l: Define a pixel format for the R-Car VSP1 1-D histogram engine
From: Laurent Pinchart The format is used on the R-Car VSP1 video queues that carry 1-D histogram statistics data. Signed-off-by: Laurent Pinchart Acked-by: Sakari Ailus --- Documentation/media/uapi/v4l/meta-formats.rst | 15 ++ .../media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst| 168 + Documentation/media/uapi/v4l/pixfmt.rst| 1 + drivers/media/v4l2-core/v4l2-ioctl.c | 1 + include/uapi/linux/videodev2.h | 3 + 5 files changed, 188 insertions(+) create mode 100644 Documentation/media/uapi/v4l/meta-formats.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst diff --git a/Documentation/media/uapi/v4l/meta-formats.rst b/Documentation/media/uapi/v4l/meta-formats.rst new file mode 100644 index ..05ab91e12f10 --- /dev/null +++ b/Documentation/media/uapi/v4l/meta-formats.rst @@ -0,0 +1,15 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _meta-formats: + + +Metadata Formats + + +These formats are used for the :ref:`metadata` interface only. + + +.. toctree:: +:maxdepth: 1 + +pixfmt-meta-vsp1-hgo diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst new file mode 100644 index ..8d37bb313493 --- /dev/null +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst @@ -0,0 +1,168 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _v4l2-meta-fmt-vsp1-hgo: + +*** +V4L2_META_FMT_VSP1_HGO ('VSPH') +*** + +Renesas R-Car VSP1 1-D Histogram Data + + +Description +=== + +This format describes histogram data generated by the Renesas R-Car VSP1 1-D +Histogram (HGO) engine. + +The VSP1 HGO is a histogram computation engine that can operate on RGB, YCrCb +or HSV data. It operates on a possibly cropped and subsampled input image and +computes the minimum, maximum and sum of all pixels as well as per-channel +histograms. + +The HGO can compute histograms independently per channel, on the maximum of the +three channels (RGB data only) or on the Y channel only (YCbCr only). It can +additionally output the histogram with 64 or 256 bins, resulting in four +possible modes of operation. + +- In *64 bins normal mode*, the HGO operates on the three channels independently + to compute three 64-bins histograms. RGB, YCbCr and HSV image formats are + supported. +- In *64 bins maximum mode*, the HGO operates on the maximum of the (R, G, B) + channels to compute a single 64-bins histogram. Only the RGB image format is + supported. +- In *256 bins normal mode*, the HGO operates on the Y channel to compute a + single 256-bins histogram. Only the YCbCr image format is supported. +- In *256 bins maximum mode*, the HGO operates on the maximum of the (R, G, B) + channels to compute a single 256-bins histogram. Only the RGB image format is + supported. + +**Byte Order.** +All data is stored in memory in little endian format. Each cell in the tables +contains one byte. + +.. flat-table:: VSP1 HGO Data - 64 Bins, Normal Mode (792 bytes) +:header-rows: 2 +:stub-columns: 0 + +* - Offset + - :cspan:`4` Memory +* - + - [31:24] + - [23:16] + - [15:8] + - [7:0] +* - 0 + - - + - R/Cr/H max [7:0] + - - + - R/Cr/H min [7:0] +* - 4 + - - + - G/Y/S max [7:0] + - - + - G/Y/S min [7:0] +* - 8 + - - + - B/Cb/V max [7:0] + - - + - B/Cb/V min [7:0] +* - 12 + - :cspan:`4` R/Cr/H sum [31:0] +* - 16 + - :cspan:`4` G/Y/S sum [31:0] +* - 20 + - :cspan:`4` B/Cb/V sum [31:0] +* - 24 + - :cspan:`4` R/Cr/H bin 0 [31:0] +* - + - :cspan:`4` ... +* - 276 + - :cspan:`4` R/Cr/H bin 63 [31:0] +* - 280 + - :cspan:`4` G/Y/S bin 0 [31:0] +* - + - :cspan:`4` ... +* - 532 + - :cspan:`4` G/Y/S bin 63 [31:0] +* - 536 + - :cspan:`4` B/Cb/V bin 0 [31:0] +* - + - :cspan:`4` ... +* - 788 + - :cspan:`4` B/Cb/V bin 63 [31:0] + +.. flat-table:: VSP1 HGO Data - 64 Bins, Max Mode (264 bytes) +:header-rows: 2 +:stub-columns: 0 + +* - Offset + - :cspan:`4` Memory +* - + - [31:24] + - [23:16] + - [15:8] + - [7:0] +* - 0 + - - + - max(R,G,B) max [7:0] + - - + - max(R,G,B) min [7:0] +* - 4 + - :cspan:`4` max(R,G,B) sum [31:0] +* - 8 + - :cspan:`4` max(R,G,B) bin 0 [31:0] +* - + - :cspan:`4` ... +* - 260 + - :cspan:`4` max(R,G,B) bin 63 [31:0] + +.. flat-table:: VSP1 HGO Data - 256 Bins, Normal Mode (1032 bytes) +:header-rows: 2 +:stub-columns: 0 + +* - Offset + - :cspan:`4` Memory +* - + - [31:24] + - [23:16] + - [15:8] + - [7:0] +* - 0 + - - + - Y max [7:0] + - - + - Y min [7:0] +* - 4 + - :cspan:`4` Y su
[PATCHv4 06/15] v4l: vsp1: Fix HGO and HGT routing register addresses
From: Laurent Pinchart The addresses are incorrect, fix them. Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_regs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_regs.h b/drivers/media/platform/vsp1/vsp1_regs.h index 47b1dee044fb..61369e267667 100644 --- a/drivers/media/platform/vsp1/vsp1_regs.h +++ b/drivers/media/platform/vsp1/vsp1_regs.h @@ -328,8 +328,8 @@ #define VI6_DPR_ROUTE_RT_MASK (0x3f << 0) #define VI6_DPR_ROUTE_RT_SHIFT 0 -#define VI6_DPR_HGO_SMPPT 0x2050 -#define VI6_DPR_HGT_SMPPT 0x2054 +#define VI6_DPR_HGO_SMPPT 0x2054 +#define VI6_DPR_HGT_SMPPT 0x2058 #define VI6_DPR_SMPPT_TGW_MASK (7 << 8) #define VI6_DPR_SMPPT_TGW_SHIFT8 #define VI6_DPR_SMPPT_PT_MASK (0x3f << 0) -- 2.11.0
[PATCHv4 03/15] v4l: Add metadata buffer type and format
From: Laurent Pinchart The metadata buffer type is used to transfer metadata between userspace and kernelspace through a V4L2 buffers queue. It comes with a new metadata capture capability and format description. Signed-off-by: Laurent Pinchart Tested-by: Guennadi Liakhovetski Acked-by: Sakari Ailus Acked-by: Hans Verkuil [hans.verk...@cisco.com: removed left-over 'experimental' note] [hans.verk...@cisco.com: add newline after _v4l2-meta-format label] --- Documentation/media/uapi/v4l/buffer.rst | 3 ++ Documentation/media/uapi/v4l/dev-meta.rst| 58 Documentation/media/uapi/v4l/devices.rst | 1 + Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 ++ Documentation/media/videodev2.h.rst.exceptions | 2 + drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 19 drivers/media/v4l2-core/v4l2-dev.c | 16 --- drivers/media/v4l2-core/v4l2-ioctl.c | 34 ++ drivers/media/v4l2-core/videobuf2-v4l2.c | 3 ++ include/media/v4l2-ioctl.h | 17 +++ include/trace/events/v4l2.h | 1 + include/uapi/linux/videodev2.h | 13 ++ 12 files changed, 164 insertions(+), 6 deletions(-) create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst index d1e0d55dc219..64613d935edd 100644 --- a/Documentation/media/uapi/v4l/buffer.rst +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -440,6 +440,9 @@ enum v4l2_buf_type - 12 - Buffer for Software Defined Radio (SDR) output stream, see :ref:`sdr`. +* - ``V4L2_BUF_TYPE_META_CAPTURE`` + - 13 + - Buffer for metadata capture, see :ref:`metadata`. diff --git a/Documentation/media/uapi/v4l/dev-meta.rst b/Documentation/media/uapi/v4l/dev-meta.rst new file mode 100644 index ..62518adfe37b --- /dev/null +++ b/Documentation/media/uapi/v4l/dev-meta.rst @@ -0,0 +1,58 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _metadata: + +** +Metadata Interface +** + +Metadata refers to any non-image data that supplements video frames with +additional information. This may include statistics computed over the image +or frame capture parameters supplied by the image source. This interface is +intended for transfer of metadata to userspace and control of that operation. + +The metadata interface is implemented on video capture device nodes. The device +can be dedicated to metadata or can implement both video and metadata capture +as specified in its reported capabilities. + +Querying Capabilities += + +Device nodes supporting the metadata interface set the ``V4L2_CAP_META_CAPTURE`` +flag in the ``device_caps`` field of the +:c:type:`v4l2_capability` structure returned by the :c:func:`VIDIOC_QUERYCAP` +ioctl. That flag means the device can capture metadata to memory. + +At least one of the read/write or streaming I/O methods must be supported. + + +Data Format Negotiation +=== + +The metadata device uses the :ref:`format` ioctls to select the capture format. +The metadata buffer content format is bound to that selected format. In addition +to the basic :ref:`format` ioctls, the :c:func:`VIDIOC_ENUM_FMT` ioctl must be +supported as well. + +To use the :ref:`format` ioctls applications set the ``type`` field of the +:c:type:`v4l2_format` structure to ``V4L2_BUF_TYPE_META_CAPTURE`` and use the +:c:type:`v4l2_meta_format` ``meta`` member of the ``fmt`` union as needed per +the desired operation. Both drivers and applications must set the remainder of +the :c:type:`v4l2_format` structure to 0. + +.. _v4l2-meta-format: + +.. flat-table:: struct v4l2_meta_format +:header-rows: 0 +:stub-columns: 0 +:widths: 1 1 2 + +* - __u32 + - ``dataformat`` + - The data format, set by the application. This is a little endian +:ref:`four character code `. V4L2 defines metadata formats +in :ref:`meta-formats`. +* - __u32 + - ``buffersize`` + - Maximum buffer size in bytes required for data. The value is set by the +driver. diff --git a/Documentation/media/uapi/v4l/devices.rst b/Documentation/media/uapi/v4l/devices.rst index 5c3d6c29e12c..fb7f8c26cf09 100644 --- a/Documentation/media/uapi/v4l/devices.rst +++ b/Documentation/media/uapi/v4l/devices.rst @@ -25,3 +25,4 @@ Interfaces dev-touch dev-event dev-subdev +dev-meta diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst b/Documentation/media/uapi/v4l/vidioc-querycap.rst index 165d8314327e..12e0d9a63cd8 100644 --- a/Documentation/media/uapi/v4l/vidioc-querycap.rst +++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst @@ -236,6 +236,9 @@ specification the ioctl returns an ``EINVAL`` error code. * - ``V4L2_CAP_SDR_OUTPUT`` - 0x0040 - The device supports the :re
[PATCHv4 02/15] v4l: vsp1: wpf: Implement rotation support
From: Laurent Pinchart Some WPF instances, on Gen3 devices, can perform 90° rotation when writing frames to memory. Implement support for this using the V4L2_CID_ROTATE control. Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_rpf.c | 2 +- drivers/media/platform/vsp1/vsp1_rwpf.c | 5 + drivers/media/platform/vsp1/vsp1_rwpf.h | 7 +- drivers/media/platform/vsp1/vsp1_video.c | 12 +- drivers/media/platform/vsp1/vsp1_wpf.c | 205 +++ 5 files changed, 177 insertions(+), 54 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c b/drivers/media/platform/vsp1/vsp1_rpf.c index f5a9a4c8c74d..8feddd59cf8d 100644 --- a/drivers/media/platform/vsp1/vsp1_rpf.c +++ b/drivers/media/platform/vsp1/vsp1_rpf.c @@ -106,7 +106,7 @@ static void rpf_configure(struct vsp1_entity *entity, * of the pipeline. */ output = vsp1_entity_get_pad_format(wpf, wpf->config, - RWPF_PAD_SOURCE); + RWPF_PAD_SINK); crop.width = pipe->partition.width * input_width / output->width; diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.c b/drivers/media/platform/vsp1/vsp1_rwpf.c index 7d52c88a583e..cfd8f1904fa6 100644 --- a/drivers/media/platform/vsp1/vsp1_rwpf.c +++ b/drivers/media/platform/vsp1/vsp1_rwpf.c @@ -121,6 +121,11 @@ static int vsp1_rwpf_set_format(struct v4l2_subdev *subdev, RWPF_PAD_SOURCE); *format = fmt->format; + if (rwpf->flip.rotate) { + format->width = fmt->format.height; + format->height = fmt->format.width; + } + done: mutex_unlock(&rwpf->entity.lock); return ret; diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h b/drivers/media/platform/vsp1/vsp1_rwpf.h index 1c98aff3da5d..58215a7ab631 100644 --- a/drivers/media/platform/vsp1/vsp1_rwpf.h +++ b/drivers/media/platform/vsp1/vsp1_rwpf.h @@ -56,9 +56,14 @@ struct vsp1_rwpf { struct { spinlock_t lock; - struct v4l2_ctrl *ctrls[2]; + struct { + struct v4l2_ctrl *vflip; + struct v4l2_ctrl *hflip; + struct v4l2_ctrl *rotate; + } ctrls; unsigned int pending; unsigned int active; + bool rotate; } flip; struct vsp1_rwpf_memory mem; diff --git a/drivers/media/platform/vsp1/vsp1_video.c b/drivers/media/platform/vsp1/vsp1_video.c index 5239e08fabc3..795a3ca9ca03 100644 --- a/drivers/media/platform/vsp1/vsp1_video.c +++ b/drivers/media/platform/vsp1/vsp1_video.c @@ -187,9 +187,13 @@ static void vsp1_video_pipeline_setup_partitions(struct vsp1_pipeline *pipe) struct vsp1_entity *entity; unsigned int div_size; + /* +* Partitions are computed on the size before rotation, use the format +* at the WPF sink. +*/ format = vsp1_entity_get_pad_format(&pipe->output->entity, pipe->output->entity.config, - RWPF_PAD_SOURCE); + RWPF_PAD_SINK); div_size = format->width; /* Gen2 hardware doesn't require image partitioning. */ @@ -229,9 +233,13 @@ static struct v4l2_rect vsp1_video_partition(struct vsp1_pipeline *pipe, struct v4l2_rect partition; unsigned int modulus; + /* +* Partitions are computed on the size before rotation, use the format +* at the WPF sink. +*/ format = vsp1_entity_get_pad_format(&pipe->output->entity, pipe->output->entity.config, - RWPF_PAD_SOURCE); + RWPF_PAD_SINK); /* A single partition simply processes the output size in full. */ if (pipe->partitions <= 1) { diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c b/drivers/media/platform/vsp1/vsp1_wpf.c index 25a2ed6e2e18..32df109b119f 100644 --- a/drivers/media/platform/vsp1/vsp1_wpf.c +++ b/drivers/media/platform/vsp1/vsp1_wpf.c @@ -43,32 +43,90 @@ static inline void vsp1_wpf_write(struct vsp1_rwpf *wpf, enum wpf_flip_ctrl { WPF_CTRL_VFLIP = 0, WPF_CTRL_HFLIP = 1, - WPF_CTRL_MAX, }; +static int vsp1_wpf_set_rotation(struct vsp1_rwpf *wpf, unsigned int rotation) +{ + struct vsp1_video *video = wpf->video; + struct v4l2_mbus_framefmt *sink_format; + struct v4l2_mbus_framefmt *source_format; + bool rotate; + int ret = 0; + + /* +* Only consider the 0°/180° from/to 90°/270° modifications, the rest +* is taken care of by the flipping c
[PATCHv4 04/15] v4l: vsp1: Add histogram support
From: Laurent Pinchart The histogram common code will be used to implement support for both the HGO and HGT histogram computation engines. Signed-off-by: Laurent Pinchart --- drivers/media/platform/Kconfig | 1 + drivers/media/platform/vsp1/Makefile | 1 + drivers/media/platform/vsp1/vsp1_histo.c | 646 +++ drivers/media/platform/vsp1/vsp1_histo.h | 84 4 files changed, 732 insertions(+) create mode 100644 drivers/media/platform/vsp1/vsp1_histo.c create mode 100644 drivers/media/platform/vsp1/vsp1_histo.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 7321f6123659..552e7f2df6fd 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -420,6 +420,7 @@ config VIDEO_RENESAS_VSP1 depends on (ARCH_RENESAS && OF) || COMPILE_TEST depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP select VIDEOBUF2_DMA_CONTIG + select VIDEOBUF2_VMALLOC ---help--- This is a V4L2 driver for the Renesas VSP1 video processing engine. diff --git a/drivers/media/platform/vsp1/Makefile b/drivers/media/platform/vsp1/Makefile index 1328e1bd2143..c559536f7867 100644 --- a/drivers/media/platform/vsp1/Makefile +++ b/drivers/media/platform/vsp1/Makefile @@ -3,6 +3,7 @@ vsp1-y += vsp1_dl.o vsp1_drm.o vsp1_video.o vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o +vsp1-y += vsp1_histo.o vsp1-y += vsp1_lif.o obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1.o diff --git a/drivers/media/platform/vsp1/vsp1_histo.c b/drivers/media/platform/vsp1/vsp1_histo.c new file mode 100644 index ..afab77cf4fa5 --- /dev/null +++ b/drivers/media/platform/vsp1/vsp1_histo.c @@ -0,0 +1,646 @@ +/* + * vsp1_histo.c -- R-Car VSP1 Histogram API + * + * Copyright (C) 2016 Renesas Electronics Corporation + * Copyright (C) 2016 Laurent Pinchart + * + * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com) + * + * 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 +#include + +#include "vsp1.h" +#include "vsp1_histo.h" +#include "vsp1_pipe.h" + +#define HISTO_MIN_SIZE 4U +#define HISTO_MAX_SIZE 8192U + +/* - + * Buffer Operations + */ + +static inline struct vsp1_histogram_buffer * +to_vsp1_histogram_buffer(struct vb2_v4l2_buffer *vbuf) +{ + return container_of(vbuf, struct vsp1_histogram_buffer, buf); +} + +struct vsp1_histogram_buffer * +vsp1_histogram_buffer_get(struct vsp1_histogram *histo) +{ + struct vsp1_histogram_buffer *buf = NULL; + unsigned long flags; + + spin_lock_irqsave(&histo->irqlock, flags); + + if (list_empty(&histo->irqqueue)) + goto done; + + buf = list_first_entry(&histo->irqqueue, struct vsp1_histogram_buffer, + queue); + list_del(&buf->queue); + histo->readout = true; + +done: + spin_unlock_irqrestore(&histo->irqlock, flags); + return buf; +} + +void vsp1_histogram_buffer_complete(struct vsp1_histogram *histo, + struct vsp1_histogram_buffer *buf, + size_t size) +{ + struct vsp1_pipeline *pipe = histo->pipe; + unsigned long flags; + + /* +* The pipeline pointer is guaranteed to be valid as this function is +* called from the frame completion interrupt handler, which can only +* occur when video streaming is active. +*/ + buf->buf.sequence = pipe->sequence; + buf->buf.vb2_buf.timestamp = ktime_get_ns(); + vb2_set_plane_payload(&buf->buf.vb2_buf, 0, size); + vb2_buffer_done(&buf->buf.vb2_buf, VB2_BUF_STATE_DONE); + + spin_lock_irqsave(&histo->irqlock, flags); + histo->readout = false; + wake_up(&histo->wait_queue); + spin_unlock_irqrestore(&histo->irqlock, flags); +} + +/* - + * videobuf2 Queue Operations + */ + +static int histo_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers, +unsigned int *nplanes, unsigned int sizes[], +struct device *alloc_devs[]) +{ + struct vsp1_histogram *histo = vb2_get_drv_priv(vq); + + if (*nplanes) { + if (*nplanes != 1) + r
Re: [PATCH 1/5] dt-bindings: media: Add document file for CXD2880 SPI I/F
On Thu, Apr 06, 2017 at 04:54:33PM +0900, yasunari.takigu...@sony.com wrote: > From: Yasunari Takiguchi > > This is the document file for Sony CXD2880 DVB-T2/T tuner + demodulator. > It contains the description of the SPI adapter binding. > > Signed-off-by: Yasunari Takiguchi > Signed-off-by: Masayuki Yamamoto > Signed-off-by: Hideki Nozawa > Signed-off-by: Kota Yonezawa > Signed-off-by: Toshihiko Matsumoto > Signed-off-by: Satoshi Watanabe > --- > .../devicetree/bindings/media/spi/sony-cxd2880.txt | 14 ++ > 1 file changed, 14 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/spi/sony-cxd2880.txt Acked-by: Rob Herring
Re: [PATCH v3 1/8] v4l: Add metadata buffer type and format
Em Mon, 10 Apr 2017 19:58:46 +0200 Hans Verkuil escreveu: > On 04/10/2017 07:23 PM, Mauro Carvalho Chehab wrote: > > Em Tue, 28 Feb 2017 17:56:41 +0200 > > Laurent Pinchart escreveu: > > > >> The metadata buffer type is used to transfer metadata between userspace > >> and kernelspace through a V4L2 buffers queue. It comes with a new > >> metadata capture capability and format description. > >> > >> Signed-off-by: Laurent Pinchart > >> Tested-by: Guennadi Liakhovetski > >> Acked-by: Sakari Ailus > >> Acked-by: Hans Verkuil > >> --- > >> Documentation/media/uapi/v4l/buffer.rst | 3 ++ > >> Documentation/media/uapi/v4l/dev-meta.rst| 62 > >> > >> Documentation/media/uapi/v4l/devices.rst | 1 + > >> Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 ++ > >> Documentation/media/videodev2.h.rst.exceptions | 2 + > >> drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 19 > >> drivers/media/v4l2-core/v4l2-dev.c | 16 +++--- > >> drivers/media/v4l2-core/v4l2-ioctl.c | 34 + > >> drivers/media/v4l2-core/videobuf2-v4l2.c | 3 ++ > >> include/media/v4l2-ioctl.h | 17 +++ > >> include/trace/events/v4l2.h | 1 + > >> include/uapi/linux/videodev2.h | 13 + > >> 12 files changed, 168 insertions(+), 6 deletions(-) > >> create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst > >> > >> diff --git a/Documentation/media/uapi/v4l/buffer.rst > >> b/Documentation/media/uapi/v4l/buffer.rst > >> index 5c58db98ab7a..02834ce7fa4d 100644 > >> --- a/Documentation/media/uapi/v4l/buffer.rst > >> +++ b/Documentation/media/uapi/v4l/buffer.rst > >> @@ -418,6 +418,9 @@ enum v4l2_buf_type > >>- 12 > >>- Buffer for Software Defined Radio (SDR) output stream, see > >>:ref:`sdr`. > >> +* - ``V4L2_BUF_TYPE_META_CAPTURE`` > >> + - 13 > >> + - Buffer for metadata capture, see :ref:`metadata`. > >> > >> > >> > >> diff --git a/Documentation/media/uapi/v4l/dev-meta.rst > >> b/Documentation/media/uapi/v4l/dev-meta.rst > >> new file mode 100644 > >> index ..b6044c54082a > >> --- /dev/null > >> +++ b/Documentation/media/uapi/v4l/dev-meta.rst > >> @@ -0,0 +1,62 @@ > >> +.. -*- coding: utf-8; mode: rst -*- > >> + > >> +.. _metadata: > >> + > >> +** > >> +Metadata Interface > >> +** > >> + > >> +Metadata refers to any non-image data that supplements video frames with > >> +additional information. This may include statistics computed over the > >> image > >> +or frame capture parameters supplied by the image source. This interface > >> is > >> +intended for transfer of metadata to userspace and control of that > >> operation. > >> + > >> +The metadata interface is implemented on video capture device nodes. The > >> device > >> +can be dedicated to metadata or can implement both video and metadata > >> capture > >> +as specified in its reported capabilities. > >> + > >> +.. note:: > >> + > >> +This is an :ref:`experimental` interface and may > >> +change in the future. > > > > While I'm ok with this comment, in practice, this comment is bogus. Once we > > merge it, it is unlikely that we'll be able to change it. > > > > That would just add a task on our TODO list that we'll need to remove this > > comment some day. > > I'll remove this. These notes were all removed some time ago. This patch was > most > likely made when these notes were still in use. > > > > >> + > >> +Querying Capabilities > >> += > >> + > >> +Device nodes supporting the metadata interface set the > >> ``V4L2_CAP_META_CAPTURE`` > >> +flag in the ``device_caps`` field of the > >> +:c:type:`v4l2_capability` structure returned by the > >> :c:func:`VIDIOC_QUERYCAP` > >> +ioctl. That flag means the device can capture metadata to memory. > >> + > >> +At least one of the read/write or streaming I/O methods must be supported. > >> + > >> + > >> +Data Format Negotiation > >> +=== > >> + > >> +The metadata device uses the :ref:`format` ioctls to select the capture > >> format. > >> +The metadata buffer content format is bound to that selected format. In > >> addition > >> +to the basic :ref:`format` ioctls, the :c:func:`VIDIOC_ENUM_FMT` ioctl > >> must be > >> +supported as well. > >> + > >> +To use the :ref:`format` ioctls applications set the ``type`` field of the > >> +:c:type:`v4l2_format` structure to ``V4L2_BUF_TYPE_META_CAPTURE`` and use > >> the > >> +:c:type:`v4l2_meta_format` ``meta`` member of the ``fmt`` union as needed > >> per > >> +the desired operation. Both drivers and applications must set the > >> remainder of > >> +the :c:type:`v4l2_format` structure to 0. > >> + > >> +.. _v4l2-meta-format: > > > > Better to add an space after the label. My experience with random versions > > of Sphinx is that it doesn't like to have diffe
[GIT PULL FOR v4.12] ov2640 & soc_camera sensor cleanups
These are old patches (2015!) that have been lying around in my todo list ever since. Since I plan to work a bit on soc-camera sensors (at least those that I have) and since ov2640 was just moved out of soc-camera, it is time I kick these out. Regards, Hans The following changes since commit a9b99bbedae6f861de3be635bdc9382e1e29a4f9: [media] em28xx: drop last soc_camera link (2017-04-10 14:28:39 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.12g for you to fetch changes up to 738777dd732e97ac664fe5152660d6e9ce6c033c: ov2640: avoid calling ov2640_select_win() twice (2017-04-10 20:02:17 +0200) Hans Verkuil (8): imx074: avoid calling imx074_find_datafmt() twice mt9m001: avoid calling mt9m001_find_datafmt() twice mt9v022: avoid calling mt9v022_find_datafmt() twice ov5642: avoid calling ov5642_find_datafmt() twice ov772x: avoid calling ov772x_select_params() twice ov9640: avoid calling ov9640_res_roundup() twice ov9740: avoid calling ov9740_res_roundup() twice ov2640: avoid calling ov2640_select_win() twice drivers/media/i2c/ov2640.c | 18 +++--- drivers/media/i2c/soc_camera/imx074.c | 2 +- drivers/media/i2c/soc_camera/mt9m001.c | 8 drivers/media/i2c/soc_camera/mt9v022.c | 8 drivers/media/i2c/soc_camera/ov5642.c | 2 +- drivers/media/i2c/soc_camera/ov772x.c | 41 + drivers/media/i2c/soc_camera/ov9640.c | 24 +++- drivers/media/i2c/soc_camera/ov9740.c | 18 +- 8 files changed, 34 insertions(+), 87 deletions(-)
Re: [PATCH 2/2] em28xx: simplify ID-reading from Micron sensors
Am 26.03.2017 um 16:24 schrieb Frank Schäfer: > > > Am 24.03.2017 um 20:16 schrieb Mauro Carvalho Chehab: >> Em Thu, 23 Mar 2017 19:03:20 +0100 >> Frank Schäfer escreveu: >> >>> Am 23.03.2017 um 13:56 schrieb Mauro Carvalho Chehab: Em Thu, 23 Mar 2017 13:01:32 +0100 Frank Schäfer escreveu: > Am 22.03.2017 um 15:46 schrieb Mauro Carvalho Chehab: >> Em Sun, 19 Feb 2017 19:29:18 +0100 >> Frank Schäfer escreveu: >> >>> Use i2c_smbus_read_word_data() instead of i2c_master_send() and >>> i2c_master_recv() for reading the ID of Micorn sensors. >>> Bytes need to be swapped afterwards, because >>> i2c_smbus_read_word_data() >>> assumes that the received bytes are little-endian byte order (as >>> specified >>> by smbus), while Micron sensors with 16 bit register width use >>> big endian >>> byte order. >>> >>> Signed-off-by: Frank Schäfer >>> --- >>> drivers/media/usb/em28xx/em28xx-camera.c | 28 >>> >>> 1 file changed, 4 insertions(+), 24 deletions(-) >>> >>> diff --git a/drivers/media/usb/em28xx/em28xx-camera.c >>> b/drivers/media/usb/em28xx/em28xx-camera.c >>> index 7b4129ab1cf9..4839479624e7 100644 >>> --- a/drivers/media/usb/em28xx/em28xx-camera.c >>> +++ b/drivers/media/usb/em28xx/em28xx-camera.c >>> @@ -106,8 +106,6 @@ static int em28xx_probe_sensor_micron(struct >>> em28xx *dev) >>> { >>> int ret, i; >>> char *name; >>> -u8 reg; >>> -__be16 id_be; >>> u16 id; >>> struct i2c_client *client = >>> &dev->i2c_client[dev->def_i2c_bus]; >>> @@ -115,10 +113,8 @@ static int >>> em28xx_probe_sensor_micron(struct em28xx *dev) >>> dev->em28xx_sensor = EM28XX_NOSENSOR; >>> for (i = 0; micron_sensor_addrs[i] != I2C_CLIENT_END; >>> i++) { >>> client->addr = micron_sensor_addrs[i]; >>> -/* NOTE: i2c_smbus_read_word_data() doesn't work with >>> BE data */ >>> /* Read chip ID from register 0x00 */ >>> -reg = 0x00; >>> -ret = i2c_master_send(client, ®, 1); >>> +ret = i2c_smbus_read_word_data(client, 0x00); /* >>> assumes LE */ >>> if (ret < 0) { >>> if (ret != -ENXIO) >>> dev_err(&dev->intf->dev, >>> @@ -126,24 +122,9 @@ static int >>> em28xx_probe_sensor_micron(struct em28xx *dev) >>>client->addr << 1, ret); >>> continue; >>> } >>> -ret = i2c_master_recv(client, (u8 *)&id_be, 2); >>> -if (ret < 0) { >>> -dev_err(&dev->intf->dev, >>> -"couldn't read from i2c device 0x%02x: error >>> %i\n", >>> -client->addr << 1, ret); >>> -continue; >>> -} >>> -id = be16_to_cpu(id_be); >>> +id = swab16(ret); /* LE -> BE */ >> That's wrong! You can't assume that CPU is BE, as some archs use LE. >> >> You should, instead, call le16_to_cpu(), to be sure that it will be >> doing the right thing. >> >> Something like: >> >> id = le16_to_cpu((__le16)ret); > SMBus read/write word transfers are always LE (see SMBus spec section > 6.5.5), > which is also what i2c_smbus_xfer_emulated() assumes: > http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L3485 I got that part, but, if the CPU is also LE, doing swab16() is wrong. It should swap it *only* if the CPU is BE. >>> No, it should always be swapped, because the bytes are always >>> transfered >>> in the wrong order. >>> The cpu endianess doesn't matter, (0x12 << 8) | 0x34 is always 0x1234. >> You still didn't get it. >> >> Let's assume that the ID is 0x148c (MT9M112). >> >> This value, represented in low endian, is stored in memory as: >> >> unsigned char __id[2] = { 0x8c, 0x14 }; >> >> If we do: >> u16 ret = *(u16 *)__id; >> >> What's stored at "ret" will depend if the sistem is LE or BE: >> >> on LE, ret == 0x148c >> on BE, ret == 0x8c14 >> >> If you do: >> u16 id = swapb16(val) >> >> you'll get: >> >> on LE, id == 0x8c14 >> on BE, id == 0x148c >> >> So, the value will be *wrong* at LE. >> >> However, if you do: >> id = le16_to_cpu((__le16)ret); >> >> On LE, this will evaluate to id = ret, and on BE, to id = swab16(ret). >> So, on both, you'll have: >> id = 0x148c. > > Can you please show me the code line(s) that make the value of the > word returned by i2c_smbus_read_word_data() cpu endianess dependent ? :) > Ping !? Cheers, Frank
Re: [PATCH] Quirk for webcam in MacBook Pro 2016
Hi Laurent, I'm really sorry for all the wrong formatting. I already took measures so it won't happen again. > Your patch is now in my git tree, and I will push it upstream for v4.13 > (v4.11 will be released very soon, and given the pending pull requests for > v4.12 in the Linux media tree I don't think I can add another one). Thanks a lot. Highly appreciated. > I collect USB descriptors for UVC devices. Could you please send me the > output of > > lsusb -d 05ac:8600 I guess you want the verbose output of lsusb. You'll find it in the attached file. It might contain more than than you expect as the iBridge device is a custom ARM processor (probably very similar to the one in the Apple Watch), not just connecting the webcam to the rest of the system, but also the Touch Bar and the Touch ID sensor. Regards, DanielBus 001 Device 002: ID 05ac:8600 Apple, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x05ac Apple, Inc. idProduct 0x8600 bcdDevice1.01 iManufacturer 1 Apple Inc. iProduct2 iBridge iSerial 3 nomac?123456 bNumConfigurations 3 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 469 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 5 Default iBridge Interfaces bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 14 Video bFunctionSubClass 1 Video Control bFunctionProtocol 0 iFunction 6 FaceTime HD Camera (Build-in) Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass14 Video bInterfaceSubClass 1 Video Control bInterfaceProtocol 0 iInterface 15 FaceTime HD Camera (Build-in, SN:CC264856L1KGJJM11) VideoControl Interface Descriptor: bLength13 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdUVC 1.50 wTotalLength 54 dwClockFrequency1.00MHz bInCollection 1 baInterfaceNr( 0) 1 VideoControl Interface Descriptor: bLength18 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Camera Sensor bAssocTerminal 0 iTerminal 0 wObjectiveFocalLengthMin 0 wObjectiveFocalLengthMax 0 wOcularFocalLength0 bControlSize 3 bmControls 0x VideoControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 2 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 1 iTerminal 0 VideoControl Interface Descriptor: bLength14 bDescriptorType36 bDescriptorSubtype 5 (PROCESSING_UNIT) bUnitID 3 bSourceID 1 wMaxMultiplier 0 bControlSize4 bmControls 0x iProcessing 0 bmVideoStandards 0x 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass14 Video bInterfaceSubClass 2 Video Streaming bInterfaceProtocol 0 iInterface 0 VideoStreaming Interface Descriptor: bLength14 bDescriptorType36 bDescriptorSubtype 1 (INPUT_HEADER) bNumFormats 1 wTotalLength 323 bEndPointAddress 129 bmInfo 0 bTerminalLink 2 bStillCaptureMethod 0 bTriggerSupport 0 bTriggerUsage 0 bControlSize1 bmaControls( 0
Re: [PATCH v3 1/8] v4l: Add metadata buffer type and format
On 04/10/2017 07:23 PM, Mauro Carvalho Chehab wrote: > Em Tue, 28 Feb 2017 17:56:41 +0200 > Laurent Pinchart escreveu: > >> The metadata buffer type is used to transfer metadata between userspace >> and kernelspace through a V4L2 buffers queue. It comes with a new >> metadata capture capability and format description. >> >> Signed-off-by: Laurent Pinchart >> Tested-by: Guennadi Liakhovetski >> Acked-by: Sakari Ailus >> Acked-by: Hans Verkuil >> --- >> Documentation/media/uapi/v4l/buffer.rst | 3 ++ >> Documentation/media/uapi/v4l/dev-meta.rst| 62 >> >> Documentation/media/uapi/v4l/devices.rst | 1 + >> Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 ++ >> Documentation/media/videodev2.h.rst.exceptions | 2 + >> drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 19 >> drivers/media/v4l2-core/v4l2-dev.c | 16 +++--- >> drivers/media/v4l2-core/v4l2-ioctl.c | 34 + >> drivers/media/v4l2-core/videobuf2-v4l2.c | 3 ++ >> include/media/v4l2-ioctl.h | 17 +++ >> include/trace/events/v4l2.h | 1 + >> include/uapi/linux/videodev2.h | 13 + >> 12 files changed, 168 insertions(+), 6 deletions(-) >> create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst >> >> diff --git a/Documentation/media/uapi/v4l/buffer.rst >> b/Documentation/media/uapi/v4l/buffer.rst >> index 5c58db98ab7a..02834ce7fa4d 100644 >> --- a/Documentation/media/uapi/v4l/buffer.rst >> +++ b/Documentation/media/uapi/v4l/buffer.rst >> @@ -418,6 +418,9 @@ enum v4l2_buf_type >>- 12 >>- Buffer for Software Defined Radio (SDR) output stream, see >> :ref:`sdr`. >> +* - ``V4L2_BUF_TYPE_META_CAPTURE`` >> + - 13 >> + - Buffer for metadata capture, see :ref:`metadata`. >> >> >> >> diff --git a/Documentation/media/uapi/v4l/dev-meta.rst >> b/Documentation/media/uapi/v4l/dev-meta.rst >> new file mode 100644 >> index ..b6044c54082a >> --- /dev/null >> +++ b/Documentation/media/uapi/v4l/dev-meta.rst >> @@ -0,0 +1,62 @@ >> +.. -*- coding: utf-8; mode: rst -*- >> + >> +.. _metadata: >> + >> +** >> +Metadata Interface >> +** >> + >> +Metadata refers to any non-image data that supplements video frames with >> +additional information. This may include statistics computed over the image >> +or frame capture parameters supplied by the image source. This interface is >> +intended for transfer of metadata to userspace and control of that >> operation. >> + >> +The metadata interface is implemented on video capture device nodes. The >> device >> +can be dedicated to metadata or can implement both video and metadata >> capture >> +as specified in its reported capabilities. >> + >> +.. note:: >> + >> +This is an :ref:`experimental` interface and may >> +change in the future. > > While I'm ok with this comment, in practice, this comment is bogus. Once we > merge it, it is unlikely that we'll be able to change it. > > That would just add a task on our TODO list that we'll need to remove this > comment some day. I'll remove this. These notes were all removed some time ago. This patch was most likely made when these notes were still in use. > >> + >> +Querying Capabilities >> += >> + >> +Device nodes supporting the metadata interface set the >> ``V4L2_CAP_META_CAPTURE`` >> +flag in the ``device_caps`` field of the >> +:c:type:`v4l2_capability` structure returned by the >> :c:func:`VIDIOC_QUERYCAP` >> +ioctl. That flag means the device can capture metadata to memory. >> + >> +At least one of the read/write or streaming I/O methods must be supported. >> + >> + >> +Data Format Negotiation >> +=== >> + >> +The metadata device uses the :ref:`format` ioctls to select the capture >> format. >> +The metadata buffer content format is bound to that selected format. In >> addition >> +to the basic :ref:`format` ioctls, the :c:func:`VIDIOC_ENUM_FMT` ioctl must >> be >> +supported as well. >> + >> +To use the :ref:`format` ioctls applications set the ``type`` field of the >> +:c:type:`v4l2_format` structure to ``V4L2_BUF_TYPE_META_CAPTURE`` and use >> the >> +:c:type:`v4l2_meta_format` ``meta`` member of the ``fmt`` union as needed >> per >> +the desired operation. Both drivers and applications must set the remainder >> of >> +the :c:type:`v4l2_format` structure to 0. >> + >> +.. _v4l2-meta-format: > > Better to add an space after the label. My experience with random versions > of Sphinx is that it doesn't like to have different types of paragraph > without at least one blank line between them. You mean 'Better to add a newline after the label'? It's a bit confusing. Regards, Hans
Re: [PATCH v3 1/8] v4l: Add metadata buffer type and format
Em Tue, 28 Feb 2017 17:56:41 +0200 Laurent Pinchart escreveu: > The metadata buffer type is used to transfer metadata between userspace > and kernelspace through a V4L2 buffers queue. It comes with a new > metadata capture capability and format description. > > Signed-off-by: Laurent Pinchart > Tested-by: Guennadi Liakhovetski > Acked-by: Sakari Ailus > Acked-by: Hans Verkuil > --- > Documentation/media/uapi/v4l/buffer.rst | 3 ++ > Documentation/media/uapi/v4l/dev-meta.rst| 62 > > Documentation/media/uapi/v4l/devices.rst | 1 + > Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 ++ > Documentation/media/videodev2.h.rst.exceptions | 2 + > drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 19 > drivers/media/v4l2-core/v4l2-dev.c | 16 +++--- > drivers/media/v4l2-core/v4l2-ioctl.c | 34 + > drivers/media/v4l2-core/videobuf2-v4l2.c | 3 ++ > include/media/v4l2-ioctl.h | 17 +++ > include/trace/events/v4l2.h | 1 + > include/uapi/linux/videodev2.h | 13 + > 12 files changed, 168 insertions(+), 6 deletions(-) > create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst > > diff --git a/Documentation/media/uapi/v4l/buffer.rst > b/Documentation/media/uapi/v4l/buffer.rst > index 5c58db98ab7a..02834ce7fa4d 100644 > --- a/Documentation/media/uapi/v4l/buffer.rst > +++ b/Documentation/media/uapi/v4l/buffer.rst > @@ -418,6 +418,9 @@ enum v4l2_buf_type >- 12 >- Buffer for Software Defined Radio (SDR) output stream, see > :ref:`sdr`. > +* - ``V4L2_BUF_TYPE_META_CAPTURE`` > + - 13 > + - Buffer for metadata capture, see :ref:`metadata`. > > > > diff --git a/Documentation/media/uapi/v4l/dev-meta.rst > b/Documentation/media/uapi/v4l/dev-meta.rst > new file mode 100644 > index ..b6044c54082a > --- /dev/null > +++ b/Documentation/media/uapi/v4l/dev-meta.rst > @@ -0,0 +1,62 @@ > +.. -*- coding: utf-8; mode: rst -*- > + > +.. _metadata: > + > +** > +Metadata Interface > +** > + > +Metadata refers to any non-image data that supplements video frames with > +additional information. This may include statistics computed over the image > +or frame capture parameters supplied by the image source. This interface is > +intended for transfer of metadata to userspace and control of that operation. > + > +The metadata interface is implemented on video capture device nodes. The > device > +can be dedicated to metadata or can implement both video and metadata capture > +as specified in its reported capabilities. > + > +.. note:: > + > +This is an :ref:`experimental` interface and may > +change in the future. While I'm ok with this comment, in practice, this comment is bogus. Once we merge it, it is unlikely that we'll be able to change it. That would just add a task on our TODO list that we'll need to remove this comment some day. > + > +Querying Capabilities > += > + > +Device nodes supporting the metadata interface set the > ``V4L2_CAP_META_CAPTURE`` > +flag in the ``device_caps`` field of the > +:c:type:`v4l2_capability` structure returned by the :c:func:`VIDIOC_QUERYCAP` > +ioctl. That flag means the device can capture metadata to memory. > + > +At least one of the read/write or streaming I/O methods must be supported. > + > + > +Data Format Negotiation > +=== > + > +The metadata device uses the :ref:`format` ioctls to select the capture > format. > +The metadata buffer content format is bound to that selected format. In > addition > +to the basic :ref:`format` ioctls, the :c:func:`VIDIOC_ENUM_FMT` ioctl must > be > +supported as well. > + > +To use the :ref:`format` ioctls applications set the ``type`` field of the > +:c:type:`v4l2_format` structure to ``V4L2_BUF_TYPE_META_CAPTURE`` and use the > +:c:type:`v4l2_meta_format` ``meta`` member of the ``fmt`` union as needed per > +the desired operation. Both drivers and applications must set the remainder > of > +the :c:type:`v4l2_format` structure to 0. > + > +.. _v4l2-meta-format: Better to add an space after the label. My experience with random versions of Sphinx is that it doesn't like to have different types of paragraph without at least one blank line between them. > +.. flat-table:: struct v4l2_meta_format > +:header-rows: 0 > +:stub-columns: 0 > +:widths: 1 1 2 > + > +* - __u32 > + - ``dataformat`` > + - The data format, set by the application. This is a little endian > +:ref:`four character code `. V4L2 defines metadata > formats > +in :ref:`meta-formats`. > +* - __u32 > + - ``buffersize`` > + - Maximum buffer size in bytes required for data. The value is set by > the > +driver. > diff --git a/Documentation/media/uapi/v4l/devices.rst > b/Documentation/media/uapi/v4l/d
Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging
On 04/10/2017 09:25 AM, Greg Kroah-Hartman wrote: > On Mon, Apr 10, 2017 at 09:20:27AM -0700, Laura Abbott wrote: >> On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote: >>> On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote: Hi, This is v3 of the series to do some serious Ion cleanup in preparation for moving out of staging. I didn't hear much on v2 so I'm going to assume people are okay with the series as is. I know there were still some open questions about moving away from /dev/ion but in the interest of small steps I'd like to go ahead and merge this series assuming there are no more major objections. More work can happen on top of this. >>> >>> I've applied patches 3-11 as those were independant of the CMA changes. >>> I'd like to take the rest, including the CMA changes, but I need an ack >>> from someone dealing with the -mm tree before I can do that. >>> >>> Or, if they just keep ignoring it, I guess I can take them :) >>> >>> thanks, >>> >>> greg k-h >>> >> >> Thanks. I'll send out some nag e-mails asking for Acks. If I don't get >> any, I'll resend the rest of the series after the 4.12 merge window. > > Why so long? This series has been sent a bunch, if no one responds in a > week, I'll be glad to take them all in my tree :) > > thanks, > > greg k-h > Ideally I'd like some confirmation that at least someone other than myself thinks it's a good idea but I know mm review bandwidth has been a topic of discussion so maybe silence is the best I can get. If you pick it up and nobody objects, I guess I won't object either :) Thanks, Laura
[GIT PULL 4.12] si2157: Si2141 tuner support
That patch set replaces existing si2146 support with new one, that looks more correct for my eyes. Antti The following changes since commit 7ca0ef3da09888b303991edb80cd0283ee641c9e: Merge tag 'v4.11-rc5' into patchwork (2017-04-04 11:11:43 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git si2168 for you to fetch changes up to c9110a61811b9349ac64c3e50fd927c580e2eacd: si2157: Add support for Si2141-A10 (2017-04-06 16:48:52 +0300) Antti Palosaari (1): si2157: revert si2157: Si2141/2151 tuner support Stefan Brüns (1): si2157: Add support for Si2141-A10 drivers/media/tuners/si2157.c | 85 +++-- 1 file changed, 23 insertions(+), 62 deletions(-) -- http://palosaari.fi/
[RFC PATCH] Document new V4L2_CTRL_FLAG_MODIFY_LAYOUT flag
This RFC patch adds documentation for the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag and how this and the GRABBED flag should be used. When approved I'll post a proper patch series introducing this flag. This patch sits on top of Laurent's vsp1/next branch. Also available here: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=vsp1 Regards, Hans Signed-off-by: Hans Verkuil --- diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst index 64613d935edd..ae6ee73f151c 100644 --- a/Documentation/media/uapi/v4l/buffer.rst +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -48,10 +48,16 @@ The set of information needed to interpret the content of a buffer (e.g. the pixel format, the line stride, the tiling orientation or the rotation) is collectively referred to in the rest of this section as the buffer layout. +Controls that can modify the buffer layout shall set the +``V4L2_CTRL_FLAG_MODIFY_LAYOUT`` flag. + Modifying formats or controls that influence the buffer size or layout require the stream to be stopped. Any attempt at such a modification while the stream is active shall cause the ioctl setting the format or the control to return -the ``EBUSY`` error code. +the ``EBUSY`` error code. In that case drivers shall also set the +``V4L2_CTRL_FLAG_GRABBED`` flag when calling +:c:func:`VIDIOC_QUERYCTRL` or :c:func:`VIDIOC_QUERY_EXT_CTRL` for such a +control while the stream is active. .. note:: @@ -67,7 +73,8 @@ the ``EBUSY`` error code. Controls that only influence the buffer layout can be modified at any time when the stream is stopped. As they don't influence the buffer size, no special handling is needed to synchronize those controls with buffer -allocation. +allocation and the ``V4L2_CTRL_FLAG_GRABBED`` flag is cleared once the +stream is stopped. Formats and controls that influence the buffer size interact with buffer allocation. The simplest way to handle this is for drivers to always require @@ -75,8 +82,10 @@ buffers to be reallocated in order to change those formats or controls. In that case, to perform such changes, userspace applications shall first stop the video stream with the :c:func:`VIDIOC_STREAMOFF` ioctl if it is running and free all buffers with the :c:func:`VIDIOC_REQBUFS` ioctl if they are -allocated. The format or controls can then be modified, and buffers shall then -be reallocated and the stream restarted. A typical ioctl sequence is +allocated. After freeing all buffers the ``V4L2_CTRL_FLAG_GRABBED`` flag +for controls is cleared. The format or controls can then be modified, and +buffers shall then be reallocated and the stream restarted. A typical ioctl +sequence is #. VIDIOC_STREAMOFF #. VIDIOC_REQBUFS(0) diff --git a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst index 82769de801b1..1ffdc3f3c614 100644 --- a/Documentation/media/uapi/v4l/vidioc-queryctrl.rst +++ b/Documentation/media/uapi/v4l/vidioc-queryctrl.rst @@ -507,6 +507,19 @@ See also the examples in :ref:`control`. represents an action on the hardware. For example: clearing an error flag or triggering the flash. All the controls of the type ``V4L2_CTRL_TYPE_BUTTON`` have this flag set. +* .. _FLAG_MODIFY_LAYOUT: + + - ``V4L2_CTRL_FLAG_MODIFY_LAYOUT`` + - 0x0400 + - Changing this control value may modify the layout of the +buffer (for video devices) or the media bus format (for sub-devices). + + A typical example would be the ``V4L2_CID_ROTATE`` control. + + Note that typically controls with this flag will also set the + ``V4L2_CTRL_FLAG_GRABBED`` flag when buffers are allocated or + streaming is in progress since most drivers do not support changing + the format in that case. Return Value diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions index c9c611b18ba1..a5cb0a8686ac 100644 --- a/Documentation/media/videodev2.h.rst.exceptions +++ b/Documentation/media/videodev2.h.rst.exceptions @@ -341,6 +341,7 @@ replace define V4L2_CTRL_FLAG_WRITE_ONLY control-flags replace define V4L2_CTRL_FLAG_VOLATILE control-flags replace define V4L2_CTRL_FLAG_HAS_PAYLOAD control-flags replace define V4L2_CTRL_FLAG_EXECUTE_ON_WRITE control-flags +replace define V4L2_CTRL_FLAG_MODIFY_LAYOUT control-flags replace define V4L2_CTRL_FLAG_NEXT_CTRL control replace define V4L2_CTRL_FLAG_NEXT_COMPOUND control
Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging
On Mon, Apr 10, 2017 at 09:20:27AM -0700, Laura Abbott wrote: > On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote: > > On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote: > >> Hi, > >> > >> This is v3 of the series to do some serious Ion cleanup in preparation for > >> moving out of staging. I didn't hear much on v2 so I'm going to assume > >> people are okay with the series as is. I know there were still some open > >> questions about moving away from /dev/ion but in the interest of small > >> steps I'd like to go ahead and merge this series assuming there are no more > >> major objections. More work can happen on top of this. > > > > I've applied patches 3-11 as those were independant of the CMA changes. > > I'd like to take the rest, including the CMA changes, but I need an ack > > from someone dealing with the -mm tree before I can do that. > > > > Or, if they just keep ignoring it, I guess I can take them :) > > > > thanks, > > > > greg k-h > > > > Thanks. I'll send out some nag e-mails asking for Acks. If I don't get > any, I'll resend the rest of the series after the 4.12 merge window. Why so long? This series has been sent a bunch, if no one responds in a week, I'll be glad to take them all in my tree :) thanks, greg k-h
Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging
On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote: > On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote: >> Hi, >> >> This is v3 of the series to do some serious Ion cleanup in preparation for >> moving out of staging. I didn't hear much on v2 so I'm going to assume >> people are okay with the series as is. I know there were still some open >> questions about moving away from /dev/ion but in the interest of small >> steps I'd like to go ahead and merge this series assuming there are no more >> major objections. More work can happen on top of this. > > I've applied patches 3-11 as those were independant of the CMA changes. > I'd like to take the rest, including the CMA changes, but I need an ack > from someone dealing with the -mm tree before I can do that. > > Or, if they just keep ignoring it, I guess I can take them :) > > thanks, > > greg k-h > Thanks. I'll send out some nag e-mails asking for Acks. If I don't get any, I'll resend the rest of the series after the 4.12 merge window. Thanks, Laura
Re: [PATCH v3 1/8] dt-bindings: Document STM32 DCMI bindings
On Tue, Apr 04, 2017 at 05:44:31PM +0200, Hugues Fruchet wrote: > This adds documentation of device tree bindings for the STM32 DCMI > (Digital Camera Memory Interface). > > Signed-off-by: Hugues Fruchet > --- > .../devicetree/bindings/media/st,stm32-dcmi.txt| 46 > ++ > 1 file changed, 46 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt One nit below, otherwise: Acked-by: Rob Herring > > diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt > b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt > new file mode 100644 > index 000..c0f6f4b > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt > @@ -0,0 +1,46 @@ > +STMicroelectronics STM32 Digital Camera Memory Interface (DCMI) > + > +Required properties: > +- compatible: "st,stm32-dcmi" > +- reg: physical base address and length of the registers set for the device > +- interrupts: should contain IRQ line for the DCMI > +- resets: reference to a reset controller, > + see Documentation/devicetree/bindings/reset/st,stm32-rcc.txt > +- clocks: list of clock specifiers, corresponding to entries in > + the clock-names property > +- clock-names: must contain "mclk", which is the DCMI peripherial clock > +- pinctrl: the pincontrol settings to configure muxing properly > + for pins that connect to DCMI device. > + See > Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt. > +- dmas: phandle to DMA controller node, > +see Documentation/devicetree/bindings/dma/stm32-dma.txt > +- dma-names: must contain "tx", which is the transmit channel from DCMI to > DMA > + > +DCMI supports a single port node with parallel bus. It should contain one > +'port' child node with child 'endpoint' node. Please refer to the bindings > +defined in Documentation/devicetree/bindings/media/video-interfaces.txt. > + > +Example: > + > + dcmi: dcmi@5005 { > + compatible = "st,stm32-dcmi"; > + reg = <0x5005 0x400>; > + interrupts = <78>; > + resets = <&rcc STM32F4_AHB2_RESET(DCMI)>; > + clocks = <&rcc 0 STM32F4_AHB2_CLOCK(DCMI)>; > + clock-names = "mclk"; > + pinctrl-names = "default"; > + pinctrl-0 = <&dcmi_pins>; > + dmas = <&dma2 1 1 0x414 0x3>; > + dma-names = "tx"; > + port { > + dcmi_0: endpoint@0 { Unit address in not valid without a reg prop, so drop it. > + remote-endpoint = <...>; > + bus-width = <8>; > + hsync-active = <0>; > + vsync-active = <0>; > + pclk-sample = <1>; > + }; > + }; > + }; > + > -- > 1.9.1 >
Re: [PATCHv3 17/22] staging: android: ion: Collapse internal header files
On 04/08/2017 11:12 AM, Emil Velikov wrote: > Hi Laura, > > Couple of trivial nitpicks below. > > On 3 April 2017 at 19:57, Laura Abbott wrote: > >> --- a/drivers/staging/android/ion/ion.h >> +++ b/drivers/staging/android/ion/ion.h >> @@ -1,5 +1,5 @@ >> /* >> - * drivers/staging/android/ion/ion.h >> + * drivers/staging/android/ion/ion_priv.h > Does not match the actual filename. > >> * >> * Copyright (C) 2011 Google, Inc. >> * >> @@ -14,24 +14,26 @@ >> * >> */ >> >> -#ifndef _LINUX_ION_H >> -#define _LINUX_ION_H >> +#ifndef _ION_PRIV_H >> +#define _ION_PRIV_H >> > Ditto. > >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> #include >> +#include >> >> #include "../uapi/ion.h" >> > You don't want to use "../" in includes. Perhaps address with another > patch, if you haven't already ? > There isn't a better option until this driver moves out of staging. Once it moves out it can be fixed up. Thanks, Laura > Regards, > Emil >
Re: [PATCH v8 1/2] media: i2c/ov5645: add the device tree binding document
On Mon, Apr 03, 2017 at 05:02:28PM +0300, Todor Tomov wrote: > Add the document for ov5645 device tree binding. > > Signed-off-by: Todor Tomov > Reviewed-by: Laurent Pinchart > --- > .../devicetree/bindings/media/i2c/ov5645.txt | 54 > ++ > 1 file changed, 54 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt Acked-by: Rob Herring
Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page
On 04/05/2017 05:14 PM, Russell King - ARM Linux wrote: > On Wed, Apr 05, 2017 at 10:02:42AM -0600, Shuah Khan wrote: >> When coherent DMA memory without struct page is shared, importer >> fails to find the page and runs into kernel page fault when it >> tries to dmabuf_ops_attach/map_sg/map_page the invalid page found >> in the sg_table. Please see www.spinics.net/lists/stable/msg164204.html >> for more information on this problem. >> >> This solution allows coherent DMA memory without struct page to be >> shared by providing a way for the exporter to tag the DMA buffer as >> a special buffer without struct page association and passing the >> information in sg_table to the importer. This information is used >> in attach/map_sg to avoid cleaning D-cache and mapping. >> >> The details of the change are: >> >> Framework: >> - Add a new dma_attrs field to struct scatterlist. >> - Add a new DMA_ATTR_DEV_COHERENT_NOPAGE attribute to clearly identify >> Coherent memory without struct page. >> - Add a new dma_check_dev_coherent() interface to check if memory is >> the device coherent area. There is no way to tell where the memory >> returned by dma_alloc_attrs() came from. >> >> Exporter logic: >> - Add logic to vb2_dc_alloc() to call dma_check_dev_coherent() and set >> DMA_ATTR_DEV_COHERENT_NOPAGE based the results of the check. This is >> done in the exporter context. >> - Add logic to arm_dma_get_sgtable() to identify memory without struct >> page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute. If this attr is >> set, arm_dma_get_sgtable() will set page as the cpu_addr and update >> dma_address and dma_attrs fields in struct scatterlist for this sgl. >> This is done in exporter context when buffer is exported. With this > > This sentence appears to just end... > > I'm not convinced that coherent allocations should be setting the "page" > of a scatterlist to anything that isn't a real struct page or NULL. It > is, after all, an error to look up the virtual address etc of the > scatterlist entry or kmap it when it isn't backed by a struct page. > > I'm actually already passing non-page backed memory through the DMA API > in armada-drm, although not entirely correctly, and etnaviv handles it > fine: > > } else if (dobj->linear) { > /* Single contiguous physical region - no struct page */ > if (sg_alloc_table(sgt, 1, GFP_KERNEL)) > goto free_sgt; > sg_dma_address(sgt->sgl) = dobj->dev_addr; > sg_dma_len(sgt->sgl) = dobj->obj.size; > > This is not quite correct, as it assumes (which is safe for it currently) > that the DMA address is the same on all devices. On Dove, which is where > this is used, that is the case, but it's not true elsewhere. Also note > that I'm avoid calling dma_map_sg() and dma_unmap_sg() - there's no iommus > to be considered. I see. That is not the case for the drivers involved in my use-case. exynos has iommu and this s5p-mfc exporting buffers to exynos-gsc use-case does work when iommu is enabled. > > I'd suggest that this follows the same pattern - setting the DMA address > (more appropriately for generic code) and the DMA length, while leaving > the virtual address members NULL/0. However, there's also the > complication of setting up any IOMMUs that would be necessary. I haven't > looked at that, or how it could work. > > I also think this should be documented in the dmabuf API that it can > pass such scatterlists that are DMA-parameter only. > > Lastly, I'd recommend that anything using this does _not_ provide > functional kmap/kmap_atomic support for these - kmap and kmap_atomic > are both out because there's no struct page anyway (and their use would > probably oops the kernel in this scenario.) I avoided mmap support in > armada drm, but if there's a pressing reason and real use case for the > importer to mmap() the buffers in userspace, it's something I could be > convinced of. > > What I'm quite certain of is that we do _not_ want to be passing > coherent memory allocations into the streaming DMA API, not even with > a special attribute. The DMA API is about gaining coherent memory > (shared ownership of the buffer), or mapping system memory to a > specified device (which can imply unique ownership.) Trying to mix > the two together muddies the separation that we have there, and makes > it harder to explain. As can be seen from this patch, we'd end up > needing to add this special DMA_ATTR_DEV_COHERENT_NOPAGE everywhere, > which is added complexity on top of stuff that is not required for > this circumstance. The ownership can be tricky as you mentioned. In this particular use-case, there is a clear ownership definition because of the way v4l2 export/import works and also the qbuf/dqbuf rules. However, there might be other use-cases ownership isn't clearly established. > > I can see why you're doing it, to avoid having to duplicate more of > the gen
[PATCH v3 2/7] v4l: async: Add fwnode match support
Add fwnode matching to complement OF node matching. And fwnode may also be an OF node. Do not enable fwnode matching yet. It will replace OF matching soon. Signed-off-by: Sakari Ailus --- drivers/media/v4l2-core/v4l2-async.c | 15 +++ include/media/v4l2-async.h | 5 + include/media/v4l2-subdev.h | 3 +++ 3 files changed, 23 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c index 96cc733..ff32f95 100644 --- a/drivers/media/v4l2-core/v4l2-async.c +++ b/drivers/media/v4l2-core/v4l2-async.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -46,6 +47,16 @@ static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd) of_node_full_name(asd->match.of.node)); } +static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd) +{ + if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode)) + return sd->fwnode == asd->match.fwnode.fwnode; + + return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)), + of_node_full_name( + to_of_node(asd->match.fwnode.fwnode))); +} + static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd) { if (!asd->match.custom.match) @@ -80,6 +91,9 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct v4l2_async_notifier * case V4L2_ASYNC_MATCH_OF: match = match_of; break; + case V4L2_ASYNC_MATCH_FWNODE: + match = match_fwnode; + break; default: /* Cannot happen, unless someone breaks us */ WARN_ON(true); @@ -158,6 +172,7 @@ int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev, case V4L2_ASYNC_MATCH_DEVNAME: case V4L2_ASYNC_MATCH_I2C: case V4L2_ASYNC_MATCH_OF: + case V4L2_ASYNC_MATCH_FWNODE: break; default: dev_err(notifier->v4l2_dev ? notifier->v4l2_dev->dev : NULL, diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h index 8e2a236..c3695fa 100644 --- a/include/media/v4l2-async.h +++ b/include/media/v4l2-async.h @@ -32,6 +32,7 @@ struct v4l2_async_notifier; * @V4L2_ASYNC_MATCH_DEVNAME: Match will use the device name * @V4L2_ASYNC_MATCH_I2C: Match will check for I2C adapter ID and address * @V4L2_ASYNC_MATCH_OF: Match will use OF node + * @V4L2_ASYNC_MATCH_FWNODE: Match will use firmware node * * This enum is used by the asyncrhronous sub-device logic to define the * algorithm that will be used to match an asynchronous device. @@ -41,6 +42,7 @@ enum v4l2_async_match_type { V4L2_ASYNC_MATCH_DEVNAME, V4L2_ASYNC_MATCH_I2C, V4L2_ASYNC_MATCH_OF, + V4L2_ASYNC_MATCH_FWNODE, }; /** @@ -58,6 +60,9 @@ struct v4l2_async_subdev { const struct device_node *node; } of; struct { + struct fwnode_handle *fwnode; + } fwnode; + struct { const char *name; } device_name; struct { diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index 0ab1c5d..5f1669c 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -788,6 +788,8 @@ struct v4l2_subdev_platform_data { * @devnode: subdev device node * @dev: pointer to the physical device, if any * @of_node: The device_node of the subdev, usually the same as dev->of_node. + * @fwnode: The fwnode_handle of the subdev, usually the same as + * either dev->of_node->fwnode or dev->fwnode (whichever is non-NULL). * @async_list: Links this subdev to a global subdev_list or @notifier->done * list. * @asd: Pointer to respective &struct v4l2_async_subdev. @@ -819,6 +821,7 @@ struct v4l2_subdev { struct video_device *devnode; struct device *dev; struct device_node *of_node; + struct fwnode_handle *fwnode; struct list_head async_list; struct v4l2_async_subdev *asd; struct v4l2_async_notifier *notifier; -- 2.7.4
[PATCH v3 6/7] docs-rst: media: Switch documentation to V4L2 fwnode API
Instead of including the V4L2 OF header in ReST documentation, use the V4L2 fwnode header instead. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart --- Documentation/media/kapi/v4l2-core.rst | 2 +- Documentation/media/kapi/v4l2-fwnode.rst | 3 +++ Documentation/media/kapi/v4l2-of.rst | 3 --- 3 files changed, 4 insertions(+), 4 deletions(-) create mode 100644 Documentation/media/kapi/v4l2-fwnode.rst delete mode 100644 Documentation/media/kapi/v4l2-of.rst diff --git a/Documentation/media/kapi/v4l2-core.rst b/Documentation/media/kapi/v4l2-core.rst index 2fbf532..11c3eca 100644 --- a/Documentation/media/kapi/v4l2-core.rst +++ b/Documentation/media/kapi/v4l2-core.rst @@ -13,11 +13,11 @@ Video4Linux devices v4l2-event v4l2-fh v4l2-flash-led-class +v4l2-fwnode v4l2-intro v4l2-mc v4l2-mediabus v4l2-mem2mem -v4l2-of v4l2-rect v4l2-subdev v4l2-tuner diff --git a/Documentation/media/kapi/v4l2-fwnode.rst b/Documentation/media/kapi/v4l2-fwnode.rst new file mode 100644 index 000..6c8bccd --- /dev/null +++ b/Documentation/media/kapi/v4l2-fwnode.rst @@ -0,0 +1,3 @@ +V4L2 fwnode kAPI + +.. kernel-doc:: include/media/v4l2-fwnode.h diff --git a/Documentation/media/kapi/v4l2-of.rst b/Documentation/media/kapi/v4l2-of.rst deleted file mode 100644 index 1ddf76b..000 --- a/Documentation/media/kapi/v4l2-of.rst +++ /dev/null @@ -1,3 +0,0 @@ -V4L2 Open Firmware kAPI -^^^ -.. kernel-doc:: include/media/v4l2-of.h -- 2.7.4
[PATCH v3 0/7] V4L2 fwnode support
Hello everyone, This patchset adds support for fwnode to V4L2. Besides OF, also ACPI based systems can be supported this way. By using V4L2 fwnode, the individual drivers do not need to be aware of the underlying firmware implementation. The patchset also removes specific V4L2 OF support and converts the affected drivers to use V4L2 fwnode. The patchset depends on another patchset here: http://www.spinics.net/lists/linux-acpi/msg72973.html> A git tree with the dependencies can be found here: https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi-merge> v1 of the set can be found here: http://www.spinics.net/lists/linux-media/msg111073.html> and v2 here: http://www.spinics.net/lists/linux-media/msg114110.html> changes since v2: - Use EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL(). - Alphabetically order the topics under V4L2 core kAPI documentation. - Prefer "fwnode" variable name for struct fwnode_handle pointers instead of "fwn". Similarly, use "vep" for struct v4l2_fwnode_endpoint instead of "vfwn". - Convert existing users of OF matching to fwnode matching. - Remove OF matching support as well as compatibility between OF and fwnode matching. - Use of_node_cmp() to determine whether two nodes match in case both of them are OF nodes. There is thus no functional difference between existing OF matching in v1. - Continue to use struct device_node.full_name on fwnodes that are known to be OF nodes instead of omitting such debug information. Drivers that can actually use fwnode need a new interface to provide this in fwnode framework. This is out of scope of the patchset. - Remove linux/of.h header inclusion in drivers/media/v4l2-core/v4l2-flash-led-class.c. - Improved line wrapping primarily in drivers/media/v4l2-core/v4l2-fwnode.c. - Rewrap KernelDoc documentation for V4L2 fwnode API up to 80 characters per line (new patch). - Fix KernelDoc documentation, there were a few locations where the argument had been changed but the documentation was not updated accordingly. - Fix punctuation and wording in V4L2 fwnode documentation. - Drop patch "v4l: media/drv-intf/soc_mediabus.h: include dependent header file". It is no longer needed. - Fix obtaining port parent in v4l2_fwnode_parse_link() on ACPI. - Include newly OF-supported atmel-isi to V4L2 OF -> fwnode conversion. - Add that the v4l2-fwnode.c has origins in v4l2-of.c to the commit message and the file header. changes since v1: - Use existing dev_fwnode() instead of device_fwnode_handle() added by the ACPI graph patchset, - Fix too long line of ^'s in ReST documentation and - Drop the patch rearranging the header files. It'd better go in separately, if at all. Sakari Ailus (7): v4l: fwnode: Support generic fwnode for parsing standardised properties v4l: async: Add fwnode match support v4l: flash led class: Use fwnode_handle instead of device_node in init v4l: Switch from V4L2 OF not V4L2 fwnode API docs-rst: media: Sort topic list alphabetically docs-rst: media: Switch documentation to V4L2 fwnode API v4l: Remove V4L2 OF framework in favour of V4L2 fwnode framework Documentation/media/kapi/v4l2-core.rst | 20 +- Documentation/media/kapi/v4l2-fwnode.rst | 3 + Documentation/media/kapi/v4l2-of.rst | 3 - drivers/leds/leds-aat1290.c| 5 +- drivers/leds/leds-max77693.c | 5 +- drivers/media/i2c/Kconfig | 9 + drivers/media/i2c/adv7604.c| 7 +- drivers/media/i2c/mt9v032.c| 7 +- drivers/media/i2c/ov2659.c | 8 +- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 7 +- drivers/media/i2c/s5k5baf.c| 6 +- drivers/media/i2c/smiapp/Kconfig | 1 + drivers/media/i2c/smiapp/smiapp-core.c | 29 ++- drivers/media/i2c/tc358743.c | 11 +- drivers/media/i2c/tvp514x.c| 6 +- drivers/media/i2c/tvp5150.c| 7 +- drivers/media/i2c/tvp7002.c| 6 +- drivers/media/platform/Kconfig | 3 + drivers/media/platform/am437x/Kconfig | 1 + drivers/media/platform/am437x/am437x-vpfe.c| 15 +- drivers/media/platform/atmel/Kconfig | 1 + drivers/media/platform/atmel/atmel-isc.c | 13 +- drivers/media/platform/exynos4-is/Kconfig | 2 + drivers/media/platform/exynos4-is/media-dev.c | 13 +- drivers/media/platform/exynos4-is/mipi-csis.c | 6 +- drivers/media/platform/omap3isp/isp.c | 49 ++-- drivers/media/platform/pxa_camera.c| 11 +- drivers/media/platform/rcar-vin/Kconfig| 1 + drivers/media/platform/rcar-vin/rcar-core.c| 23 +- drivers/media/platform/soc_camera/Kconfig | 1 + drivers/media/platform/soc_camera/atmel-isi.c | 7 +- drivers/media/platform/soc_camera/soc_camera.c | 7 +- drivers/media/plat
[PATCH v3 4/7] v4l: Switch from V4L2 OF not V4L2 fwnode API
Switch users of the v4l2_of_ APIs to the more generic v4l2_fwnode_ APIs. Async OF matching is replaced by fwnode matching and OF matching support is removed. Signed-off-by: Sakari Ailus Acked-by: Benoit Parrot # i2c/ov2569.c, am437x/am437x-vpfe.c and ti-vpe/cal.c --- drivers/media/i2c/Kconfig | 9 drivers/media/i2c/adv7604.c| 7 +-- drivers/media/i2c/mt9v032.c| 7 +-- drivers/media/i2c/ov2659.c | 8 ++-- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 7 +-- drivers/media/i2c/s5k5baf.c| 6 +-- drivers/media/i2c/smiapp/Kconfig | 1 + drivers/media/i2c/smiapp/smiapp-core.c | 29 ++-- drivers/media/i2c/tc358743.c | 11 +++-- drivers/media/i2c/tvp514x.c| 6 +-- drivers/media/i2c/tvp5150.c| 7 +-- drivers/media/i2c/tvp7002.c| 6 +-- drivers/media/platform/Kconfig | 3 ++ drivers/media/platform/am437x/Kconfig | 1 + drivers/media/platform/am437x/am437x-vpfe.c| 15 +++--- drivers/media/platform/atmel/Kconfig | 2 + drivers/media/platform/atmel/atmel-isc.c | 13 -- drivers/media/platform/atmel/atmel-isi.c | 11 +++-- drivers/media/platform/exynos4-is/Kconfig | 2 + drivers/media/platform/exynos4-is/media-dev.c | 13 +++--- drivers/media/platform/exynos4-is/mipi-csis.c | 6 +-- drivers/media/platform/omap3isp/isp.c | 49 ++-- drivers/media/platform/pxa_camera.c| 11 +++-- drivers/media/platform/rcar-vin/Kconfig| 1 + drivers/media/platform/rcar-vin/rcar-core.c| 19 drivers/media/platform/soc_camera/soc_camera.c | 7 +-- drivers/media/platform/ti-vpe/cal.c| 15 +++--- drivers/media/platform/xilinx/Kconfig | 1 + drivers/media/platform/xilinx/xilinx-vipp.c| 63 ++ drivers/media/v4l2-core/v4l2-async.c | 14 +- include/media/v4l2-async.h | 5 -- 31 files changed, 194 insertions(+), 161 deletions(-) diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index cee1dae..6b2423a 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -210,6 +210,7 @@ config VIDEO_ADV7604 depends on GPIOLIB || COMPILE_TEST select HDMI select MEDIA_CEC_EDID + select V4L2_FWNODE ---help--- Support for the Analog Devices ADV7604 video decoder. @@ -324,6 +325,7 @@ config VIDEO_TC358743 tristate "Toshiba TC358743 decoder" depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API select HDMI + select V4L2_FWNODE ---help--- Support for the Toshiba TC358743 HDMI to MIPI CSI-2 bridge. @@ -333,6 +335,7 @@ config VIDEO_TC358743 config VIDEO_TVP514X tristate "Texas Instruments TVP514x video decoder" depends on VIDEO_V4L2 && I2C + select V4L2_FWNODE ---help--- This is a Video4Linux2 sensor-level driver for the TI TVP5146/47 decoder. It is currently working with the TI OMAP3 camera @@ -344,6 +347,7 @@ config VIDEO_TVP514X config VIDEO_TVP5150 tristate "Texas Instruments TVP5150 video decoder" depends on VIDEO_V4L2 && I2C + select V4L2_FWNODE ---help--- Support for the Texas Instruments TVP5150 video decoder. @@ -353,6 +357,7 @@ config VIDEO_TVP5150 config VIDEO_TVP7002 tristate "Texas Instruments TVP7002 video decoder" depends on VIDEO_V4L2 && I2C + select V4L2_FWNODE ---help--- Support for the Texas Instruments TVP7002 video decoder. @@ -524,6 +529,7 @@ config VIDEO_OV2659 tristate "OmniVision OV2659 sensor support" depends on VIDEO_V4L2 && I2C depends on MEDIA_CAMERA_SUPPORT + select V4L2_FWNODE ---help--- This is a Video4Linux2 sensor-level driver for the OmniVision OV2659 camera. @@ -616,6 +622,7 @@ config VIDEO_MT9V032 depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API depends on MEDIA_CAMERA_SUPPORT select REGMAP_I2C + select V4L2_FWNODE ---help--- This is a Video4Linux2 sensor-level driver for the Micron MT9V032 752x480 CMOS sensor. @@ -663,6 +670,7 @@ config VIDEO_S5K4ECGX config VIDEO_S5K5BAF tristate "Samsung S5K5BAF sensor support" depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + select V4L2_FWNODE ---help--- This is a V4L2 sensor-level driver for Samsung S5K5BAF 2M camera sensor with an embedded SoC image signal processor. @@ -673,6 +681,7 @@ source "drivers/media/i2c/et8ek8/Kconfig" config VIDEO_S5C73M3 tristate "Samsung S5C73M3 sensor support" depends on I2C && SPI && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + select V4L2_FWNODE ---help---
[PATCH v3 5/7] docs-rst: media: Sort topic list alphabetically
Bring some order by alphabetically ordering the list of topics. Signed-off-by: Sakari Ailus --- Documentation/media/kapi/v4l2-core.rst | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/media/kapi/v4l2-core.rst b/Documentation/media/kapi/v4l2-core.rst index d8f6c46..2fbf532 100644 --- a/Documentation/media/kapi/v4l2-core.rst +++ b/Documentation/media/kapi/v4l2-core.rst @@ -4,23 +4,23 @@ Video4Linux devices .. toctree:: :maxdepth: 1 -v4l2-intro +v4l2-clocks +v4l2-common +v4l2-controls v4l2-dev v4l2-device -v4l2-fh -v4l2-subdev -v4l2-event -v4l2-controls -v4l2-videobuf -v4l2-videobuf2 -v4l2-clocks v4l2-dv-timings +v4l2-event +v4l2-fh v4l2-flash-led-class +v4l2-intro v4l2-mc v4l2-mediabus v4l2-mem2mem v4l2-of v4l2-rect +v4l2-subdev v4l2-tuner -v4l2-common v4l2-tveeprom +v4l2-videobuf +v4l2-videobuf2 -- 2.7.4
[PATCH v3 1/7] v4l: fwnode: Support generic fwnode for parsing standardised properties
The fwnode_handle is a more generic way than OF device_node to describe firmware nodes. Instead of the OF API, use more generic fwnode API to obtain the same information. As the V4L2 fwnode support will be required by a small minority of e.g. ACPI based systems (the same might actually go for OF), make this a module instead of embedding it in the videodev module. The origins of the V4L2 fwnode framework is in the V4L2 OF framework. Signed-off-by: Sakari Ailus --- drivers/media/v4l2-core/Kconfig | 3 + drivers/media/v4l2-core/Makefile | 1 + drivers/media/v4l2-core/v4l2-fwnode.c | 345 ++ include/media/v4l2-fwnode.h | 104 ++ 4 files changed, 453 insertions(+) create mode 100644 drivers/media/v4l2-core/v4l2-fwnode.c create mode 100644 include/media/v4l2-fwnode.h diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig index 6b1b78f..a35c336 100644 --- a/drivers/media/v4l2-core/Kconfig +++ b/drivers/media/v4l2-core/Kconfig @@ -55,6 +55,9 @@ config V4L2_FLASH_LED_CLASS When in doubt, say N. +config V4L2_FWNODE + tristate + # Used by drivers that need Videobuf modules config VIDEOBUF_GEN tristate diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile index 795a535..cf77a63 100644 --- a/drivers/media/v4l2-core/Makefile +++ b/drivers/media/v4l2-core/Makefile @@ -13,6 +13,7 @@ endif ifeq ($(CONFIG_OF),y) videodev-objs += v4l2-of.o endif +obj-$(CONFIG_V4L2_FWNODE) += v4l2-fwnode.o ifeq ($(CONFIG_TRACEPOINTS),y) videodev-objs += vb2-trace.o v4l2-trace.o endif diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c new file mode 100644 index 000..153c53c --- /dev/null +++ b/drivers/media/v4l2-core/v4l2-fwnode.c @@ -0,0 +1,345 @@ +/* + * V4L2 fwnode binding parsing library + * + * The origins of the V4L2 fwnode library are in V4L2 OF library that + * formerly was located in v4l2-of.c. + * + * Copyright (c) 2016 Intel Corporation. + * Author: Sakari Ailus + * + * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd. + * Author: Sylwester Nawrocki + * + * Copyright (C) 2012 Renesas Electronics Corp. + * Author: Guennadi Liakhovetski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +static int v4l2_fwnode_endpoint_parse_csi_bus(struct fwnode_handle *fwnode, + struct v4l2_fwnode_endpoint *vep) +{ + struct v4l2_fwnode_bus_mipi_csi2 *bus = &vep->bus.mipi_csi2; + bool have_clk_lane = false; + unsigned int flags = 0, lanes_used = 0; + unsigned int i; + u32 v; + int rval; + + rval = fwnode_property_read_u32_array(fwnode, "data-lanes", NULL, 0); + if (rval > 0) { + u32 array[ARRAY_SIZE(bus->data_lanes)]; + + bus->num_data_lanes = + min_t(int, ARRAY_SIZE(bus->data_lanes), rval); + + fwnode_property_read_u32_array(fwnode, "data-lanes", array, + bus->num_data_lanes); + + for (i = 0; i < bus->num_data_lanes; i++) { + if (lanes_used & BIT(array[i])) + pr_warn("duplicated lane %u in data-lanes\n", + array[i]); + lanes_used |= BIT(array[i]); + + bus->data_lanes[i] = array[i]; + } + } + + rval = fwnode_property_read_u32_array(fwnode, "lane-polarities", NULL, + 0); + if (rval > 0) { + u32 array[ARRAY_SIZE(bus->lane_polarities)]; + + if (rval < 1 + bus->num_data_lanes /* clock + data */) { + pr_warn("too few lane-polarities entries (need %u, got %u)\n", + 1 + bus->num_data_lanes, rval); + return -EINVAL; + } + + fwnode_property_read_u32_array(fwnode, "lane-polarities", array, + 1 + bus->num_data_lanes); + + for (i = 0; i < 1 + bus->num_data_lanes; i++) + bus->lane_polarities[i] = array[i]; + } + + if (!fwnode_property_read_u32(fwnode, "clock-lanes", &v)) { + if (lanes_used & BIT(v)) + pr_warn("duplicated lane %u in clock-lanes\n", v); + lanes_used |= BIT(v); + + bus->clock_lane = v; + have_clk_lane = true; + } + + if (fwnode_property_present(fwnode, "clock-noncontinuous")) + flags |= V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK; + else if (have_clk_
[PATCH v3 3/7] v4l: flash led class: Use fwnode_handle instead of device_node in init
Pass the more generic fwnode_handle to the init function than the device_node. Signed-off-by: Sakari Ailus --- drivers/leds/leds-aat1290.c| 5 +++-- drivers/leds/leds-max77693.c | 5 +++-- drivers/media/v4l2-core/v4l2-flash-led-class.c | 12 ++-- include/media/v4l2-flash-led-class.h | 4 ++-- 4 files changed, 14 insertions(+), 12 deletions(-) diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c index def3cf9..a21e192 100644 --- a/drivers/leds/leds-aat1290.c +++ b/drivers/leds/leds-aat1290.c @@ -503,8 +503,9 @@ static int aat1290_led_probe(struct platform_device *pdev) aat1290_init_v4l2_flash_config(led, &led_cfg, &v4l2_sd_cfg); /* Create V4L2 Flash subdev. */ - led->v4l2_flash = v4l2_flash_init(dev, sub_node, fled_cdev, NULL, - &v4l2_flash_ops, &v4l2_sd_cfg); + led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node), + fled_cdev, NULL, &v4l2_flash_ops, + &v4l2_sd_cfg); if (IS_ERR(led->v4l2_flash)) { ret = PTR_ERR(led->v4l2_flash); goto error_v4l2_flash_init; diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c index 1eb58ef..2d3062d 100644 --- a/drivers/leds/leds-max77693.c +++ b/drivers/leds/leds-max77693.c @@ -930,8 +930,9 @@ static int max77693_register_led(struct max77693_sub_led *sub_led, max77693_init_v4l2_flash_config(sub_led, led_cfg, &v4l2_sd_cfg); /* Register in the V4L2 subsystem. */ - sub_led->v4l2_flash = v4l2_flash_init(dev, sub_node, fled_cdev, NULL, - &v4l2_flash_ops, &v4l2_sd_cfg); + sub_led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node), + fled_cdev, NULL, &v4l2_flash_ops, + &v4l2_sd_cfg); if (IS_ERR(sub_led->v4l2_flash)) { ret = PTR_ERR(sub_led->v4l2_flash); goto err_v4l2_flash_init; diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c b/drivers/media/v4l2-core/v4l2-flash-led-class.c index 794e563..7b82881 100644 --- a/drivers/media/v4l2-core/v4l2-flash-led-class.c +++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c @@ -12,7 +12,7 @@ #include #include #include -#include +#include #include #include #include @@ -612,7 +612,7 @@ static const struct v4l2_subdev_internal_ops v4l2_flash_subdev_internal_ops = { static const struct v4l2_subdev_ops v4l2_flash_subdev_ops; struct v4l2_flash *v4l2_flash_init( - struct device *dev, struct device_node *of_node, + struct device *dev, struct fwnode_handle *fwn, struct led_classdev_flash *fled_cdev, struct led_classdev_flash *iled_cdev, const struct v4l2_flash_ops *ops, @@ -638,7 +638,7 @@ struct v4l2_flash *v4l2_flash_init( v4l2_flash->iled_cdev = iled_cdev; v4l2_flash->ops = ops; sd->dev = dev; - sd->of_node = of_node ? of_node : led_cdev->dev->of_node; + sd->fwnode = fwn ? fwn : dev_fwnode(led_cdev->dev); v4l2_subdev_init(sd, &v4l2_flash_subdev_ops); sd->internal_ops = &v4l2_flash_subdev_internal_ops; sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; @@ -654,7 +654,7 @@ struct v4l2_flash *v4l2_flash_init( if (ret < 0) goto err_init_controls; - of_node_get(sd->of_node); + fwnode_handle_get(sd->fwnode); ret = v4l2_async_register_subdev(sd); if (ret < 0) @@ -663,7 +663,7 @@ struct v4l2_flash *v4l2_flash_init( return v4l2_flash; err_async_register_sd: - of_node_put(sd->of_node); + fwnode_handle_put(sd->fwnode); v4l2_ctrl_handler_free(sd->ctrl_handler); err_init_controls: media_entity_cleanup(&sd->entity); @@ -683,7 +683,7 @@ void v4l2_flash_release(struct v4l2_flash *v4l2_flash) v4l2_async_unregister_subdev(sd); - of_node_put(sd->of_node); + fwnode_handle_put(sd->fwnode); v4l2_ctrl_handler_free(sd->ctrl_handler); media_entity_cleanup(&sd->entity); diff --git a/include/media/v4l2-flash-led-class.h b/include/media/v4l2-flash-led-class.h index b0fe4d6..5695853 100644 --- a/include/media/v4l2-flash-led-class.h +++ b/include/media/v4l2-flash-led-class.h @@ -108,7 +108,7 @@ static inline struct v4l2_flash *v4l2_ctrl_to_v4l2_flash(struct v4l2_ctrl *c) /** * v4l2_flash_init - initialize V4L2 flash led sub-device * @dev: flash device, e.g. an I2C device - * @of_node: of_node of the LED, may be NULL if the same as device's + * @fwn: fwnode_handle of the LED, may be NULL if the same as device's * @fled_cdev: LED flash class device to wrap * @iled_cdev: LED flash class device representing indicator LED associated * with fled_cdev, may be NULL @@ -122,7 +122,7 @@ static in
[PATCH v3 7/7] v4l: Remove V4L2 OF framework in favour of V4L2 fwnode framework
All drivers have been converted from V4L2 OF to V4L2 fwnode. The V4L2 OF framework is now unused. Remove it. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart --- drivers/media/v4l2-core/Makefile | 3 - drivers/media/v4l2-core/v4l2-of.c | 327 -- include/media/v4l2-of.h | 128 --- 3 files changed, 458 deletions(-) delete mode 100644 drivers/media/v4l2-core/v4l2-of.c delete mode 100644 include/media/v4l2-of.h diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile index cf77a63..098ad5f 100644 --- a/drivers/media/v4l2-core/Makefile +++ b/drivers/media/v4l2-core/Makefile @@ -10,9 +10,6 @@ videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \ ifeq ($(CONFIG_COMPAT),y) videodev-objs += v4l2-compat-ioctl32.o endif -ifeq ($(CONFIG_OF),y) - videodev-objs += v4l2-of.o -endif obj-$(CONFIG_V4L2_FWNODE) += v4l2-fwnode.o ifeq ($(CONFIG_TRACEPOINTS),y) videodev-objs += vb2-trace.o v4l2-trace.o diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c deleted file mode 100644 index 4f59f44..000 --- a/drivers/media/v4l2-core/v4l2-of.c +++ /dev/null @@ -1,327 +0,0 @@ -/* - * V4L2 OF binding parsing library - * - * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd. - * Author: Sylwester Nawrocki - * - * Copyright (C) 2012 Renesas Electronics Corp. - * Author: Guennadi Liakhovetski - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of version 2 of the GNU General Public License as - * published by the Free Software Foundation. - */ -#include -#include -#include -#include -#include -#include - -#include - -static int v4l2_of_parse_csi_bus(const struct device_node *node, -struct v4l2_of_endpoint *endpoint) -{ - struct v4l2_of_bus_mipi_csi2 *bus = &endpoint->bus.mipi_csi2; - struct property *prop; - bool have_clk_lane = false; - unsigned int flags = 0, lanes_used = 0; - u32 v; - - prop = of_find_property(node, "data-lanes", NULL); - if (prop) { - const __be32 *lane = NULL; - unsigned int i; - - for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) { - lane = of_prop_next_u32(prop, lane, &v); - if (!lane) - break; - - if (lanes_used & BIT(v)) - pr_warn("%s: duplicated lane %u in data-lanes\n", - node->full_name, v); - lanes_used |= BIT(v); - - bus->data_lanes[i] = v; - } - bus->num_data_lanes = i; - } - - prop = of_find_property(node, "lane-polarities", NULL); - if (prop) { - const __be32 *polarity = NULL; - unsigned int i; - - for (i = 0; i < ARRAY_SIZE(bus->lane_polarities); i++) { - polarity = of_prop_next_u32(prop, polarity, &v); - if (!polarity) - break; - bus->lane_polarities[i] = v; - } - - if (i < 1 + bus->num_data_lanes /* clock + data */) { - pr_warn("%s: too few lane-polarities entries (need %u, got %u)\n", - node->full_name, 1 + bus->num_data_lanes, i); - return -EINVAL; - } - } - - if (!of_property_read_u32(node, "clock-lanes", &v)) { - if (lanes_used & BIT(v)) - pr_warn("%s: duplicated lane %u in clock-lanes\n", - node->full_name, v); - lanes_used |= BIT(v); - - bus->clock_lane = v; - have_clk_lane = true; - } - - if (of_get_property(node, "clock-noncontinuous", &v)) - flags |= V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK; - else if (have_clk_lane || bus->num_data_lanes > 0) - flags |= V4L2_MBUS_CSI2_CONTINUOUS_CLOCK; - - bus->flags = flags; - endpoint->bus_type = V4L2_MBUS_CSI2; - - return 0; -} - -static void v4l2_of_parse_parallel_bus(const struct device_node *node, - struct v4l2_of_endpoint *endpoint) -{ - struct v4l2_of_bus_parallel *bus = &endpoint->bus.parallel; - unsigned int flags = 0; - u32 v; - - if (!of_property_read_u32(node, "hsync-active", &v)) - flags |= v ? V4L2_MBUS_HSYNC_ACTIVE_HIGH : - V4L2_MBUS_HSYNC_ACTIVE_LOW; - - if (!of_property_read_u32(node, "vsync-active", &v)) - flags |= v ? V4L2_MBUS_VSYNC_ACTIVE_HIGH : - V4L2_MBUS_VSYNC_ACTIVE_LOW; - - if (!of_property_read_u32(node, "field-even-active", &v)) - flags |= v ? V4L2_MBUS_FIELD_EVEN
Re: [PATCH v2.3] v4l: Clearly document interactions between formats, controls and buffers
Em Mon, 6 Mar 2017 16:14:41 +0200 Laurent Pinchart escreveu: > V4L2 exposes parameters that influence buffers sizes through the format > ioctls (VIDIOC_G_FMT, VIDIOC_TRY_FMT, VIDIOC_S_FMT, and possibly > VIDIOC_G_SELECTION and VIDIOC_S_SELECTION). Other parameters not part of > the format structure may also influence buffer sizes or buffer layout in > general. One existing such parameter is rotation, which is implemented > by the V4L2_CID_ROTATE control and thus exposed through the V4L2 control > ioctls. > > The interaction between those parameters and buffers is currently only > partially specified by the V4L2 API. In particular interactions between > controls and buffers isn't specified at all. The behaviour of the > VIDIOC_S_FMT and VIDIOC_S_SELECTION ioctls when buffers are allocated is > also not fully specified. > > This patch clearly defines and documents the interactions between > formats, selections, controls and buffers. > > The preparatory discussions for the documentation change considered > completely disallowing controls that change the buffer size or layout, > in favour of extending the format API with a new ioctl that would bundle > those controls with format information. The idea has been rejected, as > this would essentially be a restricted version of the upcoming request > API that wouldn't bring any additional value. > > Another option we have considered was to mandate the use of the request > API to modify controls that influence buffer size or layout. This has > also been rejected on the grounds that requiring the request API to > change rotation even when streaming is stopped would significantly > complicate implementation of drivers and usage of the V4L2 API for > applications. > > Applications will however be required to use the upcoming request API to > change at runtime formats or controls that influence the buffer size or > layout, because of the need to synchronize buffers with the formats and > controls. Otherwise there would be no way to interpret the content of a > buffer correctly. > > Signed-off-by: Laurent Pinchart > Acked-by: Sakari Ailus > --- > Changes since v2.2: > > - Describe the simple option first > - Fix error codes > > Changes since v2.1: > > - Fixed small issues in commit message > - Simplified wording of one sentence in the documentation > > Changes since v2: > > - Document the interaction with ioctls that can affect formats > (VIDIOC_S_SELECTION, VIDIOC_S_INPUT, VIDIOC_S_OUTPUT, VIDIOC_S_STD and > VIDIOC_S_DV_TIMINGS) > - Clarify the format/control change order > --- > Documentation/media/uapi/v4l/buffer.rst | 110 > > 1 file changed, 110 insertions(+) > > diff --git a/Documentation/media/uapi/v4l/buffer.rst > b/Documentation/media/uapi/v4l/buffer.rst > index ac58966ccb9b..d1e0d55dc219 100644 > --- a/Documentation/media/uapi/v4l/buffer.rst > +++ b/Documentation/media/uapi/v4l/buffer.rst ... > +.. note:: > + > + The API doesn't mandate the above order for control (3.) and format (4.) > + changes. Format and controls can be set in a different order, or even > + interleaved, depending on the device and use case. For instance some > + controls might behave differently for different pixel formats, in which > + case the format might need to be set first. > + > +When reallocation is required, any attempt to modify format or controls that > +influences the buffer size while buffers are allocated shall cause the format > +or control set ioctl to return the ``EBUSY`` error. Any attempt to queue a > +buffer too small for the current format or controls shall cause the > +:c:func:`VIDIOC_QBUF` ioctl to return a ``EINVAL`` error. This can be problematic. As I just implemented support for controls this weekend at Zbar, I'm now talking as an userspace app developer's hat. The real problem here is that applications must be aware of what controls change the buffer layout. Blindly changing controls without such check would cause the stream to fail with -EINVAL errors at QBUF. So, applications will need to to have a "black list" of controls that may influence the buffer size (like V4L2_CID_ROTATE), in order to know if, for such particular control, the stream should be stopped, in order to reallocate buffers. If such "black list" is not updated as newer controls are added, the final result is that, if the user changes such control, the application will receive EINVAL, causing it to fail streaming. Instead of that, the best is to add control flag to be returned via VIDIOC_QUERY_CTRL/VIDIOC_QUERY_EXT_CTRL indicating when a control modifies the buffer layout, e. g., something like: #define V4L2_CTRL_FLAG_MODIFY_BUF_LAYOUT0x0400 Such flag shall be set for V4L2_CID_ROTATE (and other controls) if, for a particular driver, the buffer layout is modified. This way, userspace can recognize such controls in runtime and reallocate the buffers if required by such controls. Regards Thanks, Mauro
Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid
On 08/04/17 13:11, Hans Verkuil wrote: > So, this is a bit of a blast from the past since the omap4 CEC development > has been on hold for almost a year. But I am about to resume my work on this > now that the CEC framework was merged. > > The latest code is here, if you are interested: > > https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=panda-cec > > It's pretty much unchanged from the version I posted a year ago, just rebased. > > But before I continue with this I have one question for you. First some > background: > > There is a special corner case (and I wasn't aware of that a year ago!) where > it is allowed to send a CEC message when there is *no HPD*. > > The reason is that some displays turn off the hotplug detect pin when they go > into standby or when another input is active. The only way to communicate with > such displays is via CEC. > > The problem is that without a HPD there is no EDID and basically no way for an > HDMI transmitter to detect that something is connected at all, unless you are > using CEC. > > What this means is that if we want to implement this on the omap4 the CEC > support > has to be on all the time. > > We have seen modern displays that behave like this, so this is a real issue. > And > this corner case is specifically allowed by the CEC specification: the Poll, > Image/Text View On and the Active Source messages can be sent to a TV even > when > there is no HPD in order to turn on the display if it was in standby and to > make > us the active input. > > The CEC framework in the kernel supports this starting with 4.12 (this code is > in the panda-cec branch above). > > If this *can't* be supported by the omap4, then I will likely have to add a > CEC > capability to signal to the application that this specific corner case is not > supported. > > I just did some tests with omap4 and I my impression is that this can't be > supported: when the HPD goes away it seems like most/all of the HDMI blocks > are > all powered off and any attempt to even access the CEC registers will fail. > > Changing this looks to be non-trivial if not impossible. > > Can you confirm that that isn't possible? If you think this can be done, then > I'd appreciate if you can give me a few pointers. HPD doesn't control the HW, it's all in the SW. So while I don't know much at all about CEC and haven't looked at this particular use case, I believe it's doable. HPD going off will make the DRM connector to be in "disconnected" state, which on omapdrm will cause everything about HDMI to be turned off. Does it work on some other DRM driver? I'm wondering if there's something in the DRM framework side that also has to be changed, in addition to omapdrm changes. It could require larger SW redesigns, though... Which makes me think that the work shouldn't be done until we have changed the omapdrm's driver model to DRM's common bridge driver model, and then all this could possibly be done in a more generic manner. Well, then again, I think the hdmi driver's internal power state handling could be improved even before that. Currently it's not very versatile. We should have ways to partially enable the IP for just the required parts. Tomi signature.asc Description: OpenPGP digital signature
[GIT PULL FOR v4.12] Various fixes
Various fixes for 4.12. Regards, Hans The following changes since commit 0538bee6fdec9b79910c1c9835e79be75d0e1bdf: [media] MAINTAINERS: update atmel-isi.c path (2017-04-10 08:13:08 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.12f for you to fetch changes up to 2c3d089c30302bf17953176e37ccfb344b53186e: v4l2-tpg: don't clamp XV601/709 to lim range (2017-04-10 13:32:32 +0200) Alexey Khoroshilov (1): m2m-deinterlace: don't return zero on failure paths in deinterlace_probe() Colin Ian King (1): coda: remove redundant call to v4l2_m2m_get_vq Geliang Tang (11): saa7134: use setup_timer saa7146: use setup_timer bt8xx: use setup_timer cx18: use setup_timer ivtv: use setup_timer netup_unidvb: use setup_timer av7110: use setup_timer fsl-viu: use setup_timer c8sectpfe: use setup_timer wl128x: use setup_timer imon: use setup_timer Hans Verkuil (2): videodev2.h: fix outdated comment v4l2-tpg: don't clamp XV601/709 to lim range Nikola Jelic (1): media: bcm2048: fix several macros Philipp Zabel (3): tvp5150: allow get/set_fmt on the video source pad tvp5150: fix pad format frame height coda: do not enumerate YUYV if VDOA is not available drivers/media/common/saa7146/saa7146_vbi.c| 5 ++--- drivers/media/common/saa7146/saa7146_video.c | 5 ++--- drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 9 - drivers/media/i2c/tvp5150.c | 4 ++-- drivers/media/pci/bt8xx/bttv-driver.c | 4 +--- drivers/media/pci/cx18/cx18-streams.c | 4 +--- drivers/media/pci/ivtv/ivtv-driver.c | 5 ++--- drivers/media/pci/netup_unidvb/netup_unidvb_core.c| 5 ++--- drivers/media/pci/saa7134/saa7134-ts.c| 5 ++--- drivers/media/pci/saa7134/saa7134-vbi.c | 5 ++--- drivers/media/pci/saa7134/saa7134-video.c | 5 ++--- drivers/media/pci/ttpci/av7110_ir.c | 5 ++--- drivers/media/platform/coda/coda-common.c | 8 ++-- drivers/media/platform/fsl-viu.c | 5 ++--- drivers/media/platform/m2m-deinterlace.c | 1 + drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 5 ++--- drivers/media/radio/wl128x/fmdrv_common.c | 5 ++--- drivers/media/rc/imon.c | 5 ++--- drivers/staging/media/bcm2048/radio-bcm2048.c | 12 ++-- include/uapi/linux/videodev2.h| 3 +-- 20 files changed, 50 insertions(+), 55 deletions(-)
Re: [PATCH v2 4/8] v4l: async: Provide interoperability between OF and fwnode matching
Hi Laurent, On Sat, Apr 08, 2017 at 01:10:47AM +0300, Sakari Ailus wrote: > Hi Laurent, > > On Fri, Apr 07, 2017 at 01:07:48PM +0300, Laurent Pinchart wrote: > > Hi Sakari, > > > > Thank you for the patch. > > > > On Thursday 06 Apr 2017 16:12:06 Sakari Ailus wrote: > > > OF and fwnode support are separated in V4L2 and individual drivers may > > > implement one of them. Sub-devices do not match with a notifier > > > expecting sub-devices with fwnodes, nor the other way around. > > > > Shouldn't we instead convert all drivers to fwnode matching ? What's > > missing > > after the mass conversion in patch 5/8 ? > > A lot of drivers use the OF frame work and thus do not deal with fwnodes > directly. I haven't entirely converted them to use the fwnode API since > making additional, unnecessary changes increases the likelihood of errors. Doing the rest of the conversion was less work than I originally had anticipated. The changes are obvious and very similar from driver to driver, perhaps unsurprisingly. Nevertheless, additional testing coverage certainly wouldn't hurt. -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
[GIT PULL FOR v4.12] ov2640: move out of soc-camera (rebased)
Hi Mauro, Here is the remainder of my "atmel-isi/ov7670/ov2640: convert to standalone drivers" pull request, rebased to the latest master. This should now merge fine. Regards, Hans The following changes since commit 0538bee6fdec9b79910c1c9835e79be75d0e1bdf: [media] MAINTAINERS: update atmel-isi.c path (2017-04-10 08:13:08 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git sama5d3 for you to fetch changes up to 9ef9f8fec3c8283f2186d4dd609e31914202809a: em28xx: drop last soc_camera link (2017-04-10 13:23:28 +0200) Hans Verkuil (4): ov2640: convert from soc-camera to a standard subdev sensor driver. ov2640: use standard clk and enable it. ov2640: add MC support em28xx: drop last soc_camera link drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile | 1 + drivers/media/i2c/{soc_camera => }/ov2640.c | 130 +++- drivers/media/i2c/soc_camera/Kconfig| 6 --- drivers/media/i2c/soc_camera/Makefile | 1 - drivers/media/usb/em28xx/em28xx-camera.c| 9 6 files changed, 55 insertions(+), 103 deletions(-) rename drivers/media/i2c/{soc_camera => }/ov2640.c (93%)
Re: [GIT PULL FOR v4.12] atmel-isi/ov7670/ov2640: convert to standalone drivers
Em Tue, 4 Apr 2017 14:46:25 +0200 Hans Verkuil escreveu: > Converts atmel-isi to a regular v4l2 driver instead of relying on soc-camera. > > The ov2640 and ov7670 drivers are also converted to normal i2c drivers. > > Tested with my sama5d3-Xplained board, the ov2640 sensor and two ov7670 > sensors: one with and one without reset/pwdn pins. Also tested with my > em28xx-based webcam. > > See here for the patch series' cover letter: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg110532.html > > The only change since this patch series was posted is that last patch updating > the atmel-isi path in MAINTAINERS. I applied this patch too. Next time, please change MAINTAINERS on the same patch you're moving the file, as it avoid the risk of forgetting to apply, if something fails in de middle of a patch series. > After this patch series the only platform driver still using soc-camera is the > sh_mobile_ceu_camera driver. > > The (tentative) plan is to merge soc-camera into that sh driver, ensuring it > is no longer available as a stand-alone framework. > > Regarding the other soc-camera i2c drivers: the following drivers are used > by sh board files: ov772x, tw9910, mt9t112, rj54n1cb0c. > > All others are never used by a soc-camera in-tree device. > > I am considering to make those four drivers depend on the sh_mobile_ceu_camera > driver. Sounds like a plan. > The other soc_camera i2c drivers can be moved to staging/media and > marked as BROKEN. If they aren't used, I guess we could just drop them. If anyone needs in the future, it should be easy to revert the change and add a patch converting them. > Are there any i2c soc_camera drivers that are also used by non-soc-camera > drivers? I'm not aware of that. > > I have some of the i2c soc_camera sensors, so when time permits I'll try to > convert them over as standalone sensor drivers. > > Regards, > > Hans > > The following changes since commit 700ea5e0e0dd70420a04e703ff264cc133834cba: > > Merge tag 'v4.11-rc1' into patchwork (2017-03-06 06:49:34 -0300) > > are available in the git repository at: > > git://linuxtv.org/hverkuil/media_tree.git sama5d3 > > for you to fetch changes up to 11498c0d43013f51e1041a6dcf8934d62df6f41b: > > MAINTAINERS: update atmel-isi.c path (2017-04-03 16:50:53 +0200) > > > Hans Verkuil (15): > ov7670: document device tree bindings > ov7670: call v4l2_async_register_subdev > ov7670: fix g/s_parm > ov7670: get xclk > ov7670: add devicetree support > atmel-isi: update device tree bindings documentation > atmel-isi: remove dependency of the soc-camera framework > atmel-isi: move out of soc_camera to atmel > ov2640: fix colorspace handling > ov2640: update bindings > ov2640: convert from soc-camera to a standard subdev sensor driver. > ov2640: use standard clk and enable it. > ov2640: add MC support > em28xx: drop last soc_camera link > MAINTAINERS: update atmel-isi.c path > > Documentation/devicetree/bindings/media/atmel-isi.txt| 91 --- > Documentation/devicetree/bindings/media/i2c/ov2640.txt | 23 +- > Documentation/devicetree/bindings/media/i2c/ov7670.txt | 43 +++ > MAINTAINERS |3 +- > drivers/media/i2c/Kconfig| 11 + > drivers/media/i2c/Makefile |1 + > drivers/media/i2c/{soc_camera => }/ov2640.c | 153 --- > drivers/media/i2c/ov7670.c | 75 +- > drivers/media/i2c/soc_camera/Kconfig |6 - > drivers/media/i2c/soc_camera/Makefile|1 - > drivers/media/platform/Makefile |1 + > drivers/media/platform/atmel/Kconfig | 11 +- > drivers/media/platform/atmel/Makefile|1 + > drivers/media/platform/atmel/atmel-isi.c | 1368 > ++ > drivers/media/platform/{soc_camera => atmel}/atmel-isi.h |0 > drivers/media/platform/soc_camera/Kconfig| 11 - > drivers/media/platform/soc_camera/Makefile |1 - > drivers/media/platform/soc_camera/atmel-isi.c| 1167 > > drivers/media/usb/em28xx/em28xx-camera.c |9 - > 19 files changed, 1615 insertions(+), 1361 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7670.txt > rename drivers/media/i2c/{soc_camera => }/ov2640.c (92%) > create mode 100644 drivers/media/platform/atmel/atmel-isi.c > rename drivers/media/platform/{soc_camera => atmel}/atmel-isi.h (100%) > delete mode 100644 drivers/media/platform/soc_camera
Re: [GIT PULL FOR v4.12] atmel-isi/ov7670/ov2640: convert to standalone drivers
Em Tue, 4 Apr 2017 14:46:25 +0200 Hans Verkuil escreveu: > Converts atmel-isi to a regular v4l2 driver instead of relying on soc-camera. > > The ov2640 and ov7670 drivers are also converted to normal i2c drivers. > > Tested with my sama5d3-Xplained board, the ov2640 sensor and two ov7670 > sensors: one with and one without reset/pwdn pins. Also tested with my > em28xx-based webcam. > > See here for the patch series' cover letter: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg110532.html > > The only change since this patch series was posted is that last patch updating > the atmel-isi path in MAINTAINERS. > > After this patch series the only platform driver still using soc-camera is the > sh_mobile_ceu_camera driver. > > The (tentative) plan is to merge soc-camera into that sh driver, ensuring it > is no longer available as a stand-alone framework. > > Regarding the other soc-camera i2c drivers: the following drivers are used > by sh board files: ov772x, tw9910, mt9t112, rj54n1cb0c. > > All others are never used by a soc-camera in-tree device. > > I am considering to make those four drivers depend on the sh_mobile_ceu_camera > driver. The other soc_camera i2c drivers can be moved to staging/media and > marked as BROKEN. > > Are there any i2c soc_camera drivers that are also used by non-soc-camera > drivers? I'm not aware of that. > > I have some of the i2c soc_camera sensors, so when time permits I'll try to > convert them over as standalone sensor drivers. > > Regards, > > Hans > > The following changes since commit 700ea5e0e0dd70420a04e703ff264cc133834cba: > > Merge tag 'v4.11-rc1' into patchwork (2017-03-06 06:49:34 -0300) > > are available in the git repository at: > > git://linuxtv.org/hverkuil/media_tree.git sama5d3 > > for you to fetch changes up to 11498c0d43013f51e1041a6dcf8934d62df6f41b: > > MAINTAINERS: update atmel-isi.c path (2017-04-03 16:50:53 +0200) > > > Hans Verkuil (15): > ov7670: document device tree bindings > ov7670: call v4l2_async_register_subdev > ov7670: fix g/s_parm > ov7670: get xclk > ov7670: add devicetree support > atmel-isi: update device tree bindings documentation > atmel-isi: remove dependency of the soc-camera framework > atmel-isi: move out of soc_camera to atmel > ov2640: fix colorspace handling > ov2640: update bindings > ov2640: convert from soc-camera to a standard subdev sensor driver. This patch has a non-trivial conflict with upstream. I tried to solve it, but it caused a compilation breakage: drivers/media/i2c/ov2640.c: In function 'ov2640_g_mbus_config': drivers/media/i2c/ov2640.c:1001:40: error: implicit declaration of function 'soc_camera_i2c_to_desc' [-Werror=implicit-function-declaration] struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client); ^~ drivers/media/i2c/ov2640.c:1001:40: warning: initialization makes pointer from integer without a cast [-Wint-conversion] drivers/media/i2c/ov2640.c:1007:15: error: implicit declaration of function 'soc_camera_apply_board_flags' [-Werror=implicit-function-declaration] cfg->flags = soc_camera_apply_board_flags(ssdd, cfg); ^~~~ drivers/media/i2c/ov2640.c: At top level: drivers/media/i2c/ov2640.c:1013:14: error: 'ov2640_s_stream' undeclared here (not in a function) .s_stream = ov2640_s_stream, ^~~ drivers/media/i2c/ov2640.c:1012:43: warning: 'ov2640_subdev_video_ops' defined but not used [-Wunused-const-variable=] static const struct v4l2_subdev_video_ops ov2640_subdev_video_ops = { ^~~ Please rebase. I applied already the patches 1 to 10 from this pull request. Regards, Mauro Thanks, Mauro
Re: [PATCH] Quirk for webcam in MacBook Pro 2016
Hi Daniel, On Sunday 09 Apr 2017 19:43:22 Daniel Roschka wrote: > Hi Laurent, > > I don't want to sound impatient, but I as I don't know what your usual > reaction times to patches are and already waited three weeks without any > reaction, I kindly want to ask, if you already had a chance to look into > this patch and consider it for inclusion into your tree? Thank you for pinging me, the patch was indeed buried under a pile of other e- mails :-) Your mail client (or server, I don't know) mangled the patch by replacing tabs with spaces. As the patch is short I've fixed this manually, but next time please try to fix the issue on your side. Another small issue is that the commit message should be wrapped at 72 columns. Depending on the text editor you use, git commit usually does that automatically for you. I've also added a "uvcvideo: " prefix to the subject line, otherwise short git logs wouldn't be very clear. As a rule of thumb, your subject line should contain enough information to understand which driver the patch relates to, and what it does. Your patch is now in my git tree, and I will push it upstream for v4.13 (v4.11 will be released very soon, and given the pending pull requests for v4.12 in the Linux media tree I don't think I can add another one). I collect USB descriptors for UVC devices. Could you please send me the output of lsusb -d 05ac:8600 if possible running as root ? Thank you for your contribution ! -- Regards, Laurent Pinchart
Re: [PATCH] dev-capture.rst/dev-output.rst: video standards ioctls are optional
On 04/10/2017 12:36 PM, Hans Verkuil wrote: > On 04/10/2017 12:21 PM, Mauro Carvalho Chehab wrote: >> Em Wed, 29 Mar 2017 09:56:47 +0200 >> Hans Verkuil escreveu: >> >>> The documentation for video capture and output devices claims that the >>> video standard >>> ioctls are required. This is not the case, they are only required for >>> PAL/NTSC/SECAM >>> type inputs and outputs. Sensors do not implement this at all and e.g. HDMI >>> inputs >>> implement the DV Timings ioctls. >>> >>> Just drop the mention of 'video standard' ioctls. >>> >>> Signed-off-by: Hans Verkuil >> >> This is an API change that has the potential of breaking userspace. >> >> In the past, several applications were failing if VIDIOC_ENUMSTD ioctl is >> not implemented. So, I remember we had this discussion before, but I don't >> remember the dirty details anymore. >> >> Yet, looking at the code, it seems that we ended by making VIDIOC_ENUMSTD >> mandatory and implemented at the core. So, V4L2 core will make this >> ioctl available for all drivers. The core implementattion will, however, >> return -ENODATA if the driver doesn't set video_device.tvnorms, indicating >> that standard video timings are not supported. >> >> So, instead of the enclosed patch, the documentation should mention the >> standard ioctls, saying that G_STD/S_STD are optional, and ENUMSTD is >> mandatory. > > I don't think so. In v4l2-dev.c ENUMSTD is only enabled if the driver supports > the s_std ioctl: > > if (is_vid || is_vbi || is_tch) { > /* ioctls valid for video or vbi */ > if (ops->vidioc_s_std) > set_bit(_IOC_NR(VIDIOC_ENUMSTD), valid_ioctls); > > And in case you are wondering: if you have two inputs, one SDTV and one HDTV, > then > you have both s_std and s_dv_timings ioctls and if you switch to the HDTV > input, > then tvnorms is set to 0, causing ENUMSTD to return -ENODATA. If you switch > back, > then the driver will fill in tvnorms to something non-0. Note that v4l2-compliance will verify that you can't enumerate standards if the input/output doesn't indicate STD support. So this patch is really correct. Regards, Hans > > Regards, > > Hans > >> >> We could include a note about it may return -ENODATA, although the ENUMSTD >> documentation already states that it returns -ENODATA: >> >> https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-enumstd.html >> >> Regards, >> Mauro >> >>> --- >>> diff --git a/Documentation/media/uapi/v4l/dev-capture.rst >>> b/Documentation/media/uapi/v4l/dev-capture.rst >>> index 32b32055d070..4218742ab5d9 100644 >>> --- a/Documentation/media/uapi/v4l/dev-capture.rst >>> +++ b/Documentation/media/uapi/v4l/dev-capture.rst >>> @@ -42,8 +42,8 @@ Video capture devices shall support :ref:`audio input >>> `, >>> :ref:`tuner`, :ref:`controls `, >>> :ref:`cropping and scaling ` and >>> :ref:`streaming parameter ` ioctls as needed. The >>> -:ref:`video input ` and :ref:`video standard ` >>> -ioctls must be supported by all video capture devices. >>> +:ref:`video input ` ioctls must be supported by all video >>> +capture devices. >>> >>> >>> Image Format Negotiation >>> diff --git a/Documentation/media/uapi/v4l/dev-output.rst >>> b/Documentation/media/uapi/v4l/dev-output.rst >>> index 25ae8ec96fdf..342eb4931f5c 100644 >>> --- a/Documentation/media/uapi/v4l/dev-output.rst >>> +++ b/Documentation/media/uapi/v4l/dev-output.rst >>> @@ -40,8 +40,8 @@ Video output devices shall support :ref:`audio output >>> `, >>> :ref:`modulator `, :ref:`controls `, >>> :ref:`cropping and scaling ` and >>> :ref:`streaming parameter ` ioctls as needed. The >>> -:ref:`video output ` and :ref:`video standard ` >>> -ioctls must be supported by all video output devices. >>> +:ref:`video output ` ioctls must be supported by all video >>> +output devices. >>> >>> >>> Image Format Negotiation >> >> >> >> Thanks, >> Mauro >> >
Re: [PATCH] dev-capture.rst/dev-output.rst: video standards ioctls are optional
On 04/10/2017 12:21 PM, Mauro Carvalho Chehab wrote: > Em Wed, 29 Mar 2017 09:56:47 +0200 > Hans Verkuil escreveu: > >> The documentation for video capture and output devices claims that the video >> standard >> ioctls are required. This is not the case, they are only required for >> PAL/NTSC/SECAM >> type inputs and outputs. Sensors do not implement this at all and e.g. HDMI >> inputs >> implement the DV Timings ioctls. >> >> Just drop the mention of 'video standard' ioctls. >> >> Signed-off-by: Hans Verkuil > > This is an API change that has the potential of breaking userspace. > > In the past, several applications were failing if VIDIOC_ENUMSTD ioctl is > not implemented. So, I remember we had this discussion before, but I don't > remember the dirty details anymore. > > Yet, looking at the code, it seems that we ended by making VIDIOC_ENUMSTD > mandatory and implemented at the core. So, V4L2 core will make this > ioctl available for all drivers. The core implementattion will, however, > return -ENODATA if the driver doesn't set video_device.tvnorms, indicating > that standard video timings are not supported. > > So, instead of the enclosed patch, the documentation should mention the > standard ioctls, saying that G_STD/S_STD are optional, and ENUMSTD is > mandatory. I don't think so. In v4l2-dev.c ENUMSTD is only enabled if the driver supports the s_std ioctl: if (is_vid || is_vbi || is_tch) { /* ioctls valid for video or vbi */ if (ops->vidioc_s_std) set_bit(_IOC_NR(VIDIOC_ENUMSTD), valid_ioctls); And in case you are wondering: if you have two inputs, one SDTV and one HDTV, then you have both s_std and s_dv_timings ioctls and if you switch to the HDTV input, then tvnorms is set to 0, causing ENUMSTD to return -ENODATA. If you switch back, then the driver will fill in tvnorms to something non-0. Regards, Hans > > We could include a note about it may return -ENODATA, although the ENUMSTD > documentation already states that it returns -ENODATA: > > https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-enumstd.html > > Regards, > Mauro > >> --- >> diff --git a/Documentation/media/uapi/v4l/dev-capture.rst >> b/Documentation/media/uapi/v4l/dev-capture.rst >> index 32b32055d070..4218742ab5d9 100644 >> --- a/Documentation/media/uapi/v4l/dev-capture.rst >> +++ b/Documentation/media/uapi/v4l/dev-capture.rst >> @@ -42,8 +42,8 @@ Video capture devices shall support :ref:`audio input >> `, >> :ref:`tuner`, :ref:`controls `, >> :ref:`cropping and scaling ` and >> :ref:`streaming parameter ` ioctls as needed. The >> -:ref:`video input ` and :ref:`video standard ` >> -ioctls must be supported by all video capture devices. >> +:ref:`video input ` ioctls must be supported by all video >> +capture devices. >> >> >> Image Format Negotiation >> diff --git a/Documentation/media/uapi/v4l/dev-output.rst >> b/Documentation/media/uapi/v4l/dev-output.rst >> index 25ae8ec96fdf..342eb4931f5c 100644 >> --- a/Documentation/media/uapi/v4l/dev-output.rst >> +++ b/Documentation/media/uapi/v4l/dev-output.rst >> @@ -40,8 +40,8 @@ Video output devices shall support :ref:`audio output >> `, >> :ref:`modulator `, :ref:`controls `, >> :ref:`cropping and scaling ` and >> :ref:`streaming parameter ` ioctls as needed. The >> -:ref:`video output ` and :ref:`video standard ` >> -ioctls must be supported by all video output devices. >> +:ref:`video output ` ioctls must be supported by all video >> +output devices. >> >> >> Image Format Negotiation > > > > Thanks, > Mauro >
Re: [PATCH] dev-capture.rst/dev-output.rst: video standards ioctls are optional
Em Wed, 29 Mar 2017 09:56:47 +0200 Hans Verkuil escreveu: > The documentation for video capture and output devices claims that the video > standard > ioctls are required. This is not the case, they are only required for > PAL/NTSC/SECAM > type inputs and outputs. Sensors do not implement this at all and e.g. HDMI > inputs > implement the DV Timings ioctls. > > Just drop the mention of 'video standard' ioctls. > > Signed-off-by: Hans Verkuil This is an API change that has the potential of breaking userspace. In the past, several applications were failing if VIDIOC_ENUMSTD ioctl is not implemented. So, I remember we had this discussion before, but I don't remember the dirty details anymore. Yet, looking at the code, it seems that we ended by making VIDIOC_ENUMSTD mandatory and implemented at the core. So, V4L2 core will make this ioctl available for all drivers. The core implementattion will, however, return -ENODATA if the driver doesn't set video_device.tvnorms, indicating that standard video timings are not supported. So, instead of the enclosed patch, the documentation should mention the standard ioctls, saying that G_STD/S_STD are optional, and ENUMSTD is mandatory. We could include a note about it may return -ENODATA, although the ENUMSTD documentation already states that it returns -ENODATA: https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-enumstd.html Regards, Mauro > --- > diff --git a/Documentation/media/uapi/v4l/dev-capture.rst > b/Documentation/media/uapi/v4l/dev-capture.rst > index 32b32055d070..4218742ab5d9 100644 > --- a/Documentation/media/uapi/v4l/dev-capture.rst > +++ b/Documentation/media/uapi/v4l/dev-capture.rst > @@ -42,8 +42,8 @@ Video capture devices shall support :ref:`audio input > `, > :ref:`tuner`, :ref:`controls `, > :ref:`cropping and scaling ` and > :ref:`streaming parameter ` ioctls as needed. The > -:ref:`video input ` and :ref:`video standard ` > -ioctls must be supported by all video capture devices. > +:ref:`video input ` ioctls must be supported by all video > +capture devices. > > > Image Format Negotiation > diff --git a/Documentation/media/uapi/v4l/dev-output.rst > b/Documentation/media/uapi/v4l/dev-output.rst > index 25ae8ec96fdf..342eb4931f5c 100644 > --- a/Documentation/media/uapi/v4l/dev-output.rst > +++ b/Documentation/media/uapi/v4l/dev-output.rst > @@ -40,8 +40,8 @@ Video output devices shall support :ref:`audio output > `, > :ref:`modulator `, :ref:`controls `, > :ref:`cropping and scaling ` and > :ref:`streaming parameter ` ioctls as needed. The > -:ref:`video output ` and :ref:`video standard ` > -ioctls must be supported by all video output devices. > +:ref:`video output ` ioctls must be supported by all video > +output devices. > > > Image Format Negotiation Thanks, Mauro
Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API
Moi, On 04/10/17 13:11, Mika Westerberg wrote: > On Mon, Apr 10, 2017 at 12:59:36PM +0300, Sakari Ailus wrote: >> Hi Mika and Laurent, >> >> On 04/10/17 12:21, Mika Westerberg wrote: >>> On Sat, Apr 08, 2017 at 01:55:15AM +0300, Sakari Ailus wrote: > My ACPI knowledge is limited, but don't ACPI nodes have 4 character names > that > can be combined in a string to create a full path ? There is something, yes, but the ACPI framework currently has no such functionality. I believe it could be implemented though. Cc Mika. >>> >>> All ACPI node names are 32-bit integers and those are combined to form a >>> path, like \_SB.PCI0.I2C0 and so on. A single ACPI node name cannot be >>> larger than 4 chars, though. >> >> On OF, each node has a full_node string attached to it. You could >> produce a similar string on ACPI, it is not currently done. Adding such >> a string to each fwnode would require some extra memory as well. I >> wonder if that could be a Kconfig option. >> >> It would help debugging though. >> >> Providing this information to the user space has been proposed as well: >> Devicetree spec defines the syntax for such strings. The user can use >> that information for recognising a particular device in the system. >> >> The ACPI spec does, too, but it is limited to ACPI nodes and does not >> address hierarchical data extensions. We'd define the syntax for those >> ourselves. >> >> Mika: what do you think? > > There is a function acpi_get_name() which you can use to extract the > full name of the node. Why not investigate how to use that instead of > duplicating the name in an ACPI node. > acpi_get_name() would obviously be needed to produce such a string in the first place. acpi_get_name() puts the string to an existing buffer so it cannot be used as such to return a pointer to a string (e.g. to be used for snprintf()). Also, it only contains the device path of the device. The data extension path matters here, too. -- Regards, Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API
On Mon, Apr 10, 2017 at 12:59:36PM +0300, Sakari Ailus wrote: > Hi Mika and Laurent, > > On 04/10/17 12:21, Mika Westerberg wrote: > > On Sat, Apr 08, 2017 at 01:55:15AM +0300, Sakari Ailus wrote: > >>> My ACPI knowledge is limited, but don't ACPI nodes have 4 character names > >>> that > >>> can be combined in a string to create a full path ? > >> > >> There is something, yes, but the ACPI framework currently has no such > >> functionality. I believe it could be implemented though. Cc Mika. > > > > All ACPI node names are 32-bit integers and those are combined to form a > > path, like \_SB.PCI0.I2C0 and so on. A single ACPI node name cannot be > > larger than 4 chars, though. > > On OF, each node has a full_node string attached to it. You could > produce a similar string on ACPI, it is not currently done. Adding such > a string to each fwnode would require some extra memory as well. I > wonder if that could be a Kconfig option. > > It would help debugging though. > > Providing this information to the user space has been proposed as well: > Devicetree spec defines the syntax for such strings. The user can use > that information for recognising a particular device in the system. > > The ACPI spec does, too, but it is limited to ACPI nodes and does not > address hierarchical data extensions. We'd define the syntax for those > ourselves. > > Mika: what do you think? There is a function acpi_get_name() which you can use to extract the full name of the node. Why not investigate how to use that instead of duplicating the name in an ACPI node.
Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API
Hi Mika and Laurent, On 04/10/17 12:21, Mika Westerberg wrote: > On Sat, Apr 08, 2017 at 01:55:15AM +0300, Sakari Ailus wrote: >>> My ACPI knowledge is limited, but don't ACPI nodes have 4 character names >>> that >>> can be combined in a string to create a full path ? >> >> There is something, yes, but the ACPI framework currently has no such >> functionality. I believe it could be implemented though. Cc Mika. > > All ACPI node names are 32-bit integers and those are combined to form a > path, like \_SB.PCI0.I2C0 and so on. A single ACPI node name cannot be > larger than 4 chars, though. On OF, each node has a full_node string attached to it. You could produce a similar string on ACPI, it is not currently done. Adding such a string to each fwnode would require some extra memory as well. I wonder if that could be a Kconfig option. It would help debugging though. Providing this information to the user space has been proposed as well: Devicetree spec defines the syntax for such strings. The user can use that information for recognising a particular device in the system. The ACPI spec does, too, but it is limited to ACPI nodes and does not address hierarchical data extensions. We'd define the syntax for those ourselves. Mika: what do you think? On omap3isp and other drivers --- I think the solution for now should be to assume OF instead. These drivers will be used on OF platforms only anyway. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API
On Sat, Apr 08, 2017 at 01:55:15AM +0300, Sakari Ailus wrote: > > My ACPI knowledge is limited, but don't ACPI nodes have 4 character names > > that > > can be combined in a string to create a full path ? > > There is something, yes, but the ACPI framework currently has no such > functionality. I believe it could be implemented though. Cc Mika. All ACPI node names are 32-bit integers and those are combined to form a path, like \_SB.PCI0.I2C0 and so on. A single ACPI node name cannot be larger than 4 chars, though.
Re: [PATCH v3 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series
On 04/04/2017 05:44 PM, Hugues Fruchet wrote: > This patchset introduces a basic support for Digital Camera Memory Interface > (DCMI) of STMicroelectronics STM32 SoC series. > > This first basic support implements RGB565 & YUV frame grabbing. > Cropping and JPEG support will be added later on. > > This has been tested on STM324x9I-EVAL evaluation board embedding > an OV2640 camera sensor. > > This driver depends on: > - [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers > http://www.spinics.net/lists/linux-media/msg113480.html > > === > = history = > === > version 3: > - stm32-dcmi: Add "Reviewed-by: Hans Verkuil " > - dt-bindings: Fix remarks from Rob Herring: > http://www.mail-archive.com/linux-media@vger.kernel.org/msg110956.html > > version 2: > - Fix a Kbuild warning in probe: > http://www.mail-archive.com/linux-media@vger.kernel.org/msg110678.html > - Fix a warning in dcmi_queue_setup() > - dt-bindings: warn on sensor signals level inversion in board example > - Typos fixing > > version 1: > - Initial submission > > === > = v4l2-compliance = > === > Below is the v4l2-compliance report for this current version of the DCMI > camera interface. > v4l2-compliance has been built from v4l-utils-1.12.3. Please test with 'v4l2-compliance -s -f' as well and mail me the output of that test. Once you have the Acks for the DT/bindings patches just let me know and I'll make a pull request. Regards, Hans > > v4l2-compliance SHA : f5f45e17ee98a0ebad7836ade2b34ceec909d751 > > Driver Info: > Driver name : stm32-dcmi > Card type : STM32 Digital Camera Memory Int > Bus info : platform:dcmi > Driver version: 4.11.0 > Capabilities : 0x8521 > Video Capture > Read/Write > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x0521 > Video Capture > Read/Write > Streaming > Extended Pix Format > > Compliance test for device /dev/video0 (not using libv4l2): > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second video open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > test for unlimited opens: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > test VIDIOC_LOG_STATUS: OK > > Input ioctls: > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 1 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Test input 0: > > Control ioctls: > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK > test VIDIOC_QUERYCTRL: OK > test VIDIOC_G/S_CTRL: OK > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 3 Private Controls: 0 > > Format ioctls: > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > test VIDIOC_G/S_PARM: OK (Not Supported) > test VIDIOC_G_FBUF: OK (Not Supported) > test VIDIOC_G_FMT: OK > test VIDIOC_TRY_FMT: OK > test VIDIOC_S_FMT: OK > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > test Cropping: OK (Not Supported) > test Composing: OK (Not Supported) > test Scaling: OK > > Codec ioctls: > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) > test VIDIOC_G_ENC_INDEX: OK (Not Supported) > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) > > Buffer ioctls: > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK > test VIDIOC_EXPBUF: OK > > Test input 0: > > Streaming ioctls: > test read/write: OK > t
Re: [git:media_tree/master] [media] gspca: konica: add missing endpoint sanity check
On 04/10/2017 10:18 AM, Johan Hovold wrote: > On Wed, Apr 05, 2017 at 06:07:31PM +, Mauro Carvalho Chehab wrote: >> This is an automatic generated email to let you know that the >> following patch were queued: >> >> Subject: [media] gspca: konica: add missing endpoint sanity check >> Author: Johan Hovold >> Date:Mon Mar 13 09:53:59 2017 -0300 > > This was the sixth and final patch in a series; are you picking up the > first five as well? Yes. Those are in another pull request that hasn't been merged yet. I've no idea why this patch ended up in a different pull request from the others. Regards, Hans
Re: [PATCH 09/12] [media] s5p-mfc: use setup_timer
On 04/09/2017 03:34 AM, Geliang Tang wrote: Use setup_timer() instead of init_timer() to simplify the code. Signed-off-by: Geliang Tang Applied, thanks.
Re: [git:media_tree/master] [media] gspca: konica: add missing endpoint sanity check
On Wed, Apr 05, 2017 at 06:07:31PM +, Mauro Carvalho Chehab wrote: > This is an automatic generated email to let you know that the > following patch were queued: > > Subject: [media] gspca: konica: add missing endpoint sanity check > Author: Johan Hovold > Date:Mon Mar 13 09:53:59 2017 -0300 This was the sixth and final patch in a series; are you picking up the first five as well? Thanks, Johan
[PATCH for v4.12] v4l2-tpg: don't clamp XV601/709 to lim range
The XV601/709 encodings are special: they signal limited range, but use the full range to encode a larger gamut with R', G' and B' values outside the [0-1] range. So don't clamp to limited range for these two encodings. 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 e47b46e2d26c..3dd22da7e17d 100644 --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c @@ -927,7 +927,14 @@ static void precalculate_color(struct tpg_data *tpg, int k) y >>= 4; cb >>= 4; cr >>= 4; - if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) { + /* +* XV601/709 use the header/footer margins to encode R', G' +* and B' values outside the range [0-1]. So do not clamp +* XV601/709 values. +*/ + if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE && + tpg->real_ycbcr_enc != V4L2_YCBCR_ENC_XV601 && + tpg->real_ycbcr_enc != V4L2_YCBCR_ENC_XV709) { y = clamp(y, 16, 235); cb = clamp(cb, 16, 240); cr = clamp(cr, 16, 240);
[PATCH for v4.12] videodev2.h: fix outdated comment
The XV601/709 Y'CbCr encoding was changed to limited range, but the comment still indicates full range. Signed-off-by: Hans Verkuil --- diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 316be62f3a45..5d842a61d94a 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -362,8 +362,7 @@ enum v4l2_quantization { /* * The default for R'G'B' quantization is always full range, except * for the BT2020 colorspace. For Y'CbCr the quantization is always -* limited range, except for COLORSPACE_JPEG, XV601 or XV709: those -* are full range. +* limited range, except for COLORSPACE_JPEG: this is full range. */ V4L2_QUANTIZATION_DEFAULT = 0, V4L2_QUANTIZATION_FULL_RANGE = 1,