Webcam produces error on Dell XPS 9370, but seems to work
Using my webcom on my Dell XPS 9370, running latest Debian buster/sid produces a error in dmesg when running guvcview, though it seems the camera works fine from a user perspective. Full dmesg is: [0.00] Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.16.0-1-amd64 root=UUID=8f621675-b0e5-4ac7-8ef1-604cb643d57d ro loglevel=0 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable [0.00] BIOS-e820: [mem 0x0009e000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x2d6d8fff] usable [0.00] BIOS-e820: [mem 0x2d6d9000-0x2d6d9fff] ACPI NVS [0.00] BIOS-e820: [mem 0x2d6da000-0x2d6dafff] reserved [0.00] BIOS-e820: [mem 0x2d6db000-0x3ecdcfff] usable [0.00] BIOS-e820: [mem 0x3ecdd000-0x3f09afff] reserved [0.00] BIOS-e820: [mem 0x3f09b000-0x3f0e7fff] ACPI data [0.00] BIOS-e820: [mem 0x3f0e8000-0x3f79] ACPI NVS [0.00] BIOS-e820: [mem 0x3f7a-0x3ff26fff] reserved [0.00] BIOS-e820: [mem 0x3ff27000-0x3fffefff] type 20 [0.00] BIOS-e820: [mem 0x3000-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x47ff] reserved [0.00] BIOS-e820: [mem 0x4800-0x48df] usable [0.00] BIOS-e820: [mem 0x48e0-0x4f7f] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0004ae7f] usable [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v2.40 by American Megatrends [0.00] efi: ACPI=0x3f0ab000 ACPI 2.0=0x3f0ab000 SMBIOS=0xf SMBIOS 3.0=0xf0020 ESRT=0x3fdd9018 MEMATTR=0x3c2a1298 [0.00] secureboot: Secure boot could not be determined (mode 0) [0.00] SMBIOS 3.0.0 present. [0.00] DMI: Dell Inc. XPS 13 9370/0F6P3V, BIOS 1.3.2 05/07/2018 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x4ae800 max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 008000 mask 7F8000 uncachable [0.00] 1 base 006000 mask 7FE000 uncachable [0.00] 2 base 005000 mask 7FF000 uncachable [0.00] 3 base 004C00 mask 7FFC00 uncachable [0.00] 4 base 004B00 mask 7FFF00 uncachable [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] 8 disabled [0.00] 9 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.00] e820: last_pfn = 0x48e00 max_arch_pfn = 0x4 [0.00] esrt: Reserving ESRT space from 0x3fdd9018 to 0x3fdd9050. [0.00] Base memory trampoline at [(ptrval)] 98000 size 24576 [0.00] Using GB pages for direct mapping [0.00] BRK [0x15e2c000, 0x15e2cfff] PGTABLE [0.00] BRK [0x15e2d000, 0x15e2dfff] PGTABLE [0.00] BRK [0x15e2e000, 0x15e2efff] PGTABLE [0.00] BRK [0x15e2f000, 0x15e2] PGTABLE [0.00] BRK [0x15e3, 0x15e30fff] PGTABLE [0.
Re: [PATCH] v4l: Add support for STD ioctls on subdev nodes
On 17/05/18 04:00, Niklas Söderlund wrote: Missing commit log. > Signed-off-by: Niklas Söderlund > --- > Documentation/media/uapi/v4l/vidioc-g-std.rst| 14 ++ > Documentation/media/uapi/v4l/vidioc-querystd.rst | 11 +++ What about ENUMSTD? Regards, Hans > drivers/media/v4l2-core/v4l2-subdev.c| 12 > include/uapi/linux/v4l2-subdev.h | 3 +++ > 4 files changed, 32 insertions(+), 8 deletions(-) > > --- > > Hi Hans, > > I have tested this on Renesas Gen3 Salvator-XS M3-N using the AFE > subdevice from the adv748x driver together with the R-Car VIN and CSI-2 > pipeline. > > I wrote a prototype patch for v4l2-ctl which adds three new options > (--get-subdev-standard, --set-subdev-standard and > --get-subdev-detected-standard) to ease testing which I plan to submit > after some cleanup if this patch receives positive feedback. > > If you or anyone else is interested in testing this patch the v4l2-utils > prototype patches are available at > > git://git.ragnatech.se/v4l-utils#subdev-std > > Regards, > // Niklas > > diff --git a/Documentation/media/uapi/v4l/vidioc-g-std.rst > b/Documentation/media/uapi/v4l/vidioc-g-std.rst > index 90791ab51a5371b8..8d94f0404df270db 100644 > --- a/Documentation/media/uapi/v4l/vidioc-g-std.rst > +++ b/Documentation/media/uapi/v4l/vidioc-g-std.rst > @@ -2,14 +2,14 @@ > > .. _VIDIOC_G_STD: > > - > -ioctl VIDIOC_G_STD, VIDIOC_S_STD > - > +** > +ioctl VIDIOC_G_STD, VIDIOC_S_STD, VIDIOC_SUBDEV_G_STD, VIDIOC_SUBDEV_S_STD > +** > > Name > > > -VIDIOC_G_STD - VIDIOC_S_STD - Query or select the video standard of the > current input > +VIDIOC_G_STD - VIDIOC_S_STD - VIDIOC_SUBDEV_G_STD - VIDIOC_SUBDEV_S_STD - > Query or select the video standard of the current input > > > Synopsis > @@ -21,6 +21,12 @@ Synopsis > .. c:function:: int ioctl( int fd, VIDIOC_S_STD, const v4l2_std_id *argp ) > :name: VIDIOC_S_STD > > +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_G_STD, v4l2_std_id *argp ) > +:name: VIDIOC_SUBDEV_G_STD > + > +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_S_STD, const v4l2_std_id > *argp ) > +:name: VIDIOC_SUBDEV_S_STD > + > > Arguments > = > diff --git a/Documentation/media/uapi/v4l/vidioc-querystd.rst > b/Documentation/media/uapi/v4l/vidioc-querystd.rst > index cf40bca19b9f8665..a8385cc7481869dd 100644 > --- a/Documentation/media/uapi/v4l/vidioc-querystd.rst > +++ b/Documentation/media/uapi/v4l/vidioc-querystd.rst > @@ -2,14 +2,14 @@ > > .. _VIDIOC_QUERYSTD: > > -* > -ioctl VIDIOC_QUERYSTD > -* > +* > +ioctl VIDIOC_QUERYSTD, VIDIOC_SUBDEV_QUERYSTD > +* > > Name > > > -VIDIOC_QUERYSTD - Sense the video standard received by the current input > +VIDIOC_QUERYSTD - VIDIOC_SUBDEV_QUERYSTD - Sense the video standard received > by the current input > > > Synopsis > @@ -18,6 +18,9 @@ Synopsis > .. c:function:: int ioctl( int fd, VIDIOC_QUERYSTD, v4l2_std_id *argp ) > :name: VIDIOC_QUERYSTD > > +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_QUERYSTD, v4l2_std_id *argp > ) > +:name: VIDIOC_SUBDEV_QUERYSTD > + > > Arguments > = > diff --git a/drivers/media/v4l2-core/v4l2-subdev.c > b/drivers/media/v4l2-core/v4l2-subdev.c > index f9eed938d3480b74..a156b1812e923721 100644 > --- a/drivers/media/v4l2-core/v4l2-subdev.c > +++ b/drivers/media/v4l2-core/v4l2-subdev.c > @@ -494,6 +494,18 @@ static long subdev_do_ioctl(struct file *file, unsigned > int cmd, void *arg) > > case VIDIOC_SUBDEV_S_DV_TIMINGS: > return v4l2_subdev_call(sd, video, s_dv_timings, arg); > + > + case VIDIOC_SUBDEV_G_STD: > + return v4l2_subdev_call(sd, video, g_std, arg); > + > + case VIDIOC_SUBDEV_S_STD: { > + v4l2_std_id *std = arg; > + > + return v4l2_subdev_call(sd, video, s_std, *std); > + } > + > + case VIDIOC_SUBDEV_QUERYSTD: > + return v4l2_subdev_call(sd, video, querystd, arg); > #endif > default: > return v4l2_subdev_call(sd, core, ioctl, cmd, arg); > diff --git a/include/uapi/linux/v4l2-subdev.h > b/include/uapi/linux/v4l2-subdev.h > index c95a53e6743cb040..133696a1f324ffdc 100644 > --- a/include/uapi/linux/v4l2-subdev.h > +++ b/include/uapi/linux/v4l2-subdev.h > @@ -170,8 +170,11 @@ struct v4l2_subdev_selection { > #define VIDIOC_SUBDEV_G_SELECTION_IOWR('V', 61, struct > v4l2_subdev_selection) > #define VIDIOC_SUBDEV_S_SELECTION_IOWR('V', 62, struct > v4l2_subdev_selection) > /* The following ioctls are identical to the ioctls in videodev2.h */ > +#
Re: [PATCH 2/6] dt-bindings: media: rcar-vin: Document data-active
Hi Niklas, On Wed, May 16, 2018 at 11:55:38PM +0200, Niklas Söderlund wrote: > Hi Jacopo, > > Thanks for your work. > > On 2018-05-16 18:32:28 +0200, Jacopo Mondi wrote: > > Document 'data-active' property in R-Car VIN device tree bindings. > > The property is optional when running with explicit synchronization > > (eg. BT.601) but mandatory when embedded synchronization is in use (eg. > > BT.656) as specified by the hardware manual. > > > > Signed-off-by: Jacopo Mondi > > --- > > Documentation/devicetree/bindings/media/rcar_vin.txt | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt > > b/Documentation/devicetree/bindings/media/rcar_vin.txt > > index c53ce4e..17eac8a 100644 > > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt > > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt > > @@ -63,6 +63,11 @@ from local SoC CSI-2 receivers (port1) depending on SoC. > > If both HSYNC and VSYNC polarities are not specified, embedded > > synchronization is selected. > > > > +- data-active: active state of data enable signal (CLOCKENB pin). > > I'm not sure what you mean by active state here. video-interfaces.txt > defines data-active as 'similar to HSYNC and VSYNC, specifies data line > polarity' so I assume this is the polarity of the CLOCKENB pin? Yes, I can change this if it feels confusing to you. > > > + 0/1 for LOW/HIGH respectively. If not specified, use HSYNC as > > + data enable signal. When using embedded synchronization this > > + property is mandatory. > > I'm confused, why is this mandatory if we have no embedded sync (that is > hsync-active and vsync-active not defined)? I can't find any reference > to this in the Gen2 datasheet but I'm sure I'm just missing it :-) > Not exactly, it becomes mandatory IF we have embedded sync. Here it is my reasoning: In the documentation of CHS bit of Vn_DMR2 register [1] the following is specified: "When using ITU-R BT.601, BT.709, BT.1358 interface, and the VIn_CLKENB pin is unused, the CHS bit must be set to 1." And setting the CHS bit to 1: "HSYNC signal (VIn_HSYNC#) input from the pin is internally used as the clock enable signal" So, if 'data-active' property is not specified I assume CLCKENB is not used, and set the CHS bit. What if we are using BT656 and there is no HSYNC? Then specifying 'data-active' becomes mandatory, as otherwise we set the CHS bit and wait for HSYNC pin transitions that won't happen. This is probably wrong, as in the Koelsch case, there is no guarantee that CLKENB is connected, and what I should have done is probably set the CHS bit only when running on V4L2_MBUS_PARALLEL, and leave CHS (and CES, if 'data-active' is not specified) untouched, as we're doing today when running on V4L2_MBUS_BT656. Does this work better in your opinion? This also makes patch [6/6] (where I was adding 'data-active' to Gen-2 boards) not required. Thanks j [1] 26.2.18 Video n Data Mode Register 2 (VnDMR2) Datasheet version, R19UH0105EJ0100 Rev.1.00 Apr 30, 2018 > > + > > - port 1 - sub-nodes describing one or more endpoints connected to > >the VIN from local SoC CSI-2 receivers. The endpoint numbers must > >use the following schema. > > -- > > 2.7.4 > > > > -- > Regards, > Niklas Söderlund signature.asc Description: PGP signature
[Xen-devel][RFC 0/3] dma-buf support for gntdev
From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if reworked to utilize the proposed solution, can greatly benefit as well. The original rationale behind this work was to enable zero-copying use-cases while working with Xen para-virtual display driver [4]: when using Xen PV DRM frontend driver then on backend side one will need to do copying of display buffers' contents (filled by the frontend's user-space) into buffers allocated at the backend side. Taking into account the size of display buffers and frames per second it may result in unneeded huge data bus occupation and performance loss. The helper driver [4] allows implementing zero-copying use-cases when using Xen para-virtualized frontend display driver by implementing a DRM/KMS helper driver running on backend's side. It utilizes PRIME buffers API (implemented on top of Linux dma-buf) to share frontend's buffers with physical device drivers on backend's side: - a dumb buffer created on backend's side can be shared with the Xen PV frontend driver, so it directly writes into backend's domain memory (into the buffer exported from DRM/KMS driver of a physical display device) - a dumb buffer allocated by the frontend can be imported into physical device DRM/KMS driver, thus allowing to achieve no copying as well Finally, it was discussed and decided ([1], [5]) that it is worth implementing such use-cases via extension of the existing Xen gntdev driver instead of introducing new DRM specific driver. Please note, that the support of dma-buf is Linux only, as dma-buf is a Linux only thing. Now to the proposed solution. The changes to the existing Xen drivers in the Linux kernel fall into 2 categories: 1. DMA-able memory buffer allocation and ballooning in/out the pages of such a buffer. This is required if we are about to share dma-buf with the hardware that does require those to be allocated with dma_alloc_xxx API. (It is still possible to allocate a dma-buf from any other memory, e.g. system pages). 2. Extension of the gntdev driver to enable it to import/export dma-buf’s. The first two patches in this series solve #1 and the last one is for #2. The corresponding libxengnttab changes are available at [6]. All the above was tested with display backend [7] and its accompanying helper library [8] on Renesas ARM64 based board. *To all the communities*: I would like to ask you to review the proposed solution and give feedback on it, so I can improve and send final patches for review (this is still work in progress, but enough to start discussing the implementation). Thank you in advance, Oleksandr Andrushchenko [1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173163.html [2] https://elixir.bootlin.com/linux/v4.17-rc5/source/Documentation/driver-api/dma-buf.rst [3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html [4] https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/xen [5] https://patchwork.kernel.org/patch/10279681/ [6] https://github.com/andr2000/xen/tree/xen_dma_buf_v1 [7] https://github.com/andr2000/displ_be/tree/xen_dma_buf_v1 [8] https://github.com/andr2000/libxenbe/tree/xen_dma_buf_v1 Oleksandr Andrushchenko (3): xen/balloon: Allow allocating DMA buffers xen/grant-table: Extend API to work with DMA buffers xen/gntdev: Add support for Linux dma buffers drivers/xen/balloon.c | 214 +++-- drivers/xen/gntdev.c | 954 +- drivers/xen/grant-table.c | 49 ++ drivers/xen/xen-balloon.c | 2 + include/uapi/xen/gntdev.h | 101 include/xen/balloon.h | 11 +- include/xen/gntdev_exp.h | 23 + include/xen/grant_table.h | 7 + 8 files changed, 1310 insertions(+), 51 deletions(-) create mode 100644 include/xen/gntdev_exp.h -- 2.17.0
[Xen-devel][RFC 3/3] xen/gntdev: Add support for Linux dma buffers
From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/gntdev.c | 954 +- include/uapi/xen/gntdev.h | 101 include/xen/gntdev_exp.h | 23 + 3 files changed, 1066 insertions(+), 12 deletions(-) create mode 100644 include/xen/gntdev_exp.h diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 9510f228efe9..0ee88e193362 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -4,6 +4,8 @@ * Device for accessing (in user-space) pages that have been granted by other * domains. * + * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c. + * * Copyright (c) 2006-2007, D G Murray. * (c) 2009 Gerd Hoffmann * @@ -37,6 +39,9 @@ #include #include +#include +#include + #include #include #include @@ -61,16 +66,39 @@ static atomic_t pages_mapped = ATOMIC_INIT(0); static int use_ptemod; #define populate_freeable_maps use_ptemod +#ifndef GRANT_INVALID_REF +/* + * Note on usage of grant reference 0 as invalid grant reference: + * grant reference 0 is valid, but never exposed to a driver, + * because of the fact it is already in use/reserved by the PV console. + */ +#define GRANT_INVALID_REF 0 +#endif + struct gntdev_priv { /* maps with visible offsets in the file descriptor */ struct list_head maps; /* maps that are not visible; will be freed on munmap. * Only populated if populate_freeable_maps == 1 */ struct list_head freeable_maps; + /* List of dma-bufs. */ + struct list_head dma_bufs; /* lock protects maps and freeable_maps */ struct mutex lock; struct mm_struct *mm; struct mmu_notifier mn; + + /* Private data of the hyper DMA buffers. */ + + struct device *dev; + /* List of exported DMA buffers. */ + struct list_head dmabuf_exp_list; + /* List of wait objects. */ + struct list_head dmabuf_exp_wait_list; + /* List of imported DMA buffers. */ + struct list_head dmabuf_imp_list; + /* This is the lock which protects dma_buf_xxx lists. */ + struct mutex dmabuf_lock; }; struct unmap_notify { @@ -95,10 +123,65 @@ struct grant_map { struct gnttab_unmap_grant_ref *kunmap_ops; struct page **pages; unsigned long pages_vm_start; + + /* +* All the fields starting with dmabuf_ are only valid if this +* mapping is used for exporting a DMA buffer. +* If dmabuf_vaddr is not NULL then this mapping is backed by DMA +* capable memory. +*/ + + /* Flags used to create this DMA buffer: GNTDEV_DMABUF_FLAG_XXX. */ + bool dmabuf_flags; + /* Virtual/CPU address of the DMA buffer. */ + void *dmabuf_vaddr; + /* Bus address of the DMA buffer. */ + dma_addr_t dmabuf_bus_addr; +}; + +struct hyper_dmabuf { + struct gntdev_priv *priv; + struct dma_buf *dmabuf; + struct list_head next; + int fd; + + union { + struct { + /* Exported buffers are reference counted. */ + struct kref refcount; + struct grant_map *map; + } exp; + struct { + /* Granted references of the imported buffer. */ + grant_ref_t *refs; + /* Scatter-gather table of the imported buffer. */ + struct sg_table *sgt; + /* dma-buf attachment of the imported buffer. */ + struct dma_buf_attachment *attach; + } imp; + } u; + + /* Number of pages this buffer has. */ + int nr_pages; + /* Pages of this buffer. */ + struct page **pages; +}; + +struct hyper_dmabuf_wait_obj { + struct list_head next; + struct hyper_dmabuf *hyper_dmabuf; + struct completion completion; +}; + +struct hyper_dambuf_attachment { + struct sg_table *sgt; + enum dma_data_direction dir; }; static int unmap_grant_pages(struct grant_map *map, int offset, int pages); +static struct miscdevice gntdev_miscdev; + /* -- */ static void gntdev_print_maps(struct gntdev_priv *priv, @@ -120,8 +203,17 @@ static void gntdev_free_map(struct grant_map *map) if (map == NULL) return; - if (map->pages) + if (map->dmabuf_vaddr) { + bool coherent = map->dmabuf_flags & + GNTDEV_DMABUF_FLAG_DMA_COHERENT; + + gnttab_dma_free_pages(gntdev_miscdev.this_device, + coherent, map->count, map->pages, + map->dmabuf_vaddr, map->dmabuf_bus_addr); + } else if (map->pages) { gnttab_free_pages(map->count, map->pages); + } + kfree(map->pages); kfre
[Xen-devel][RFC 2/3] xen/grant-table: Extend API to work with DMA buffers
From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/grant-table.c | 49 +++ include/xen/grant_table.h | 7 ++ 2 files changed, 56 insertions(+) diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index bb36b1e1dbcc..c27bcc420575 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -729,6 +729,55 @@ void gnttab_free_pages(int nr_pages, struct page **pages) } EXPORT_SYMBOL(gnttab_free_pages); +int gnttab_dma_alloc_pages(struct device *dev, bool coherent, + int nr_pages, struct page **pages, + void **vaddr, dma_addr_t *dev_bus_addr) +{ + int i; + int ret; + + ret = alloc_dma_xenballooned_pages(dev, coherent, nr_pages, pages, + vaddr, dev_bus_addr); + if (ret < 0) + return ret; + + for (i = 0; i < nr_pages; i++) { +#if BITS_PER_LONG < 64 + struct xen_page_foreign *foreign; + + foreign = kzalloc(sizeof(*foreign), GFP_KERNEL); + if (!foreign) { + gnttab_dma_free_pages(dev, flags, nr_pages, pages, + *vaddr, *dev_bus_addr); + return -ENOMEM; + } + set_page_private(pages[i], (unsigned long)foreign); +#endif + SetPagePrivate(pages[i]); + } + return 0; +} +EXPORT_SYMBOL(gnttab_dma_alloc_pages); + +void gnttab_dma_free_pages(struct device *dev, bool coherent, + int nr_pages, struct page **pages, + void *vaddr, dma_addr_t dev_bus_addr) +{ + int i; + + for (i = 0; i < nr_pages; i++) { + if (PagePrivate(pages[i])) { +#if BITS_PER_LONG < 64 + kfree((void *)page_private(pages[i])); +#endif + ClearPagePrivate(pages[i]); + } + } + free_dma_xenballooned_pages(dev, coherent, nr_pages, pages, + vaddr, dev_bus_addr); +} +EXPORT_SYMBOL(gnttab_dma_free_pages); + /* Handling of paged out grant targets (GNTST_eagain) */ #define MAX_DELAY 256 static inline void diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h index 34b1379f9777..20ee2b5ba965 100644 --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -195,6 +195,13 @@ void gnttab_free_auto_xlat_frames(void); int gnttab_alloc_pages(int nr_pages, struct page **pages); void gnttab_free_pages(int nr_pages, struct page **pages); +int gnttab_dma_alloc_pages(struct device *dev, bool coherent, + int nr_pages, struct page **pages, + void **vaddr, dma_addr_t *dev_bus_addr); +void gnttab_dma_free_pages(struct device *dev, bool coherent, + int nr_pages, struct page **pages, + void *vaddr, dma_addr_t dev_bus_addr); + int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, struct gnttab_map_grant_ref *kmap_ops, struct page **pages, unsigned int count); -- 2.17.0
[Xen-devel][RFC 1/3] xen/balloon: Allow allocating DMA buffers
From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/balloon.c | 214 +++--- drivers/xen/xen-balloon.c | 2 + include/xen/balloon.h | 11 +- 3 files changed, 188 insertions(+), 39 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index e4db19e88ab1..e3a145aa9f29 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -415,8 +415,10 @@ static bool balloon_is_inflated(void) return balloon_stats.balloon_low || balloon_stats.balloon_high; } -static enum bp_state increase_reservation(unsigned long nr_pages) +static enum bp_state increase_reservation(unsigned long nr_pages, + struct page **ext_pages) { + enum bp_state ret = BP_DONE; int rc; unsigned long i; struct page *page; @@ -425,32 +427,49 @@ static enum bp_state increase_reservation(unsigned long nr_pages) .extent_order = EXTENT_ORDER, .domid= DOMID_SELF }; + xen_pfn_t *frames; - if (nr_pages > ARRAY_SIZE(frame_list)) - nr_pages = ARRAY_SIZE(frame_list); + if (nr_pages > ARRAY_SIZE(frame_list)) { + frames = kcalloc(nr_pages, sizeof(xen_pfn_t), GFP_KERNEL); + if (!frames) + return BP_ECANCELED; + } else { + frames = frame_list; + } - page = list_first_entry_or_null(&ballooned_pages, struct page, lru); - for (i = 0; i < nr_pages; i++) { - if (!page) { - nr_pages = i; - break; - } + /* XENMEM_populate_physmap requires a PFN based on Xen +* granularity. +*/ + if (ext_pages) { + for (i = 0; i < nr_pages; i++) + frames[i] = page_to_xen_pfn(ext_pages[i]); + } else { + page = list_first_entry_or_null(&ballooned_pages, + struct page, lru); + for (i = 0; i < nr_pages; i++) { + if (!page) { + nr_pages = i; + break; + } - /* XENMEM_populate_physmap requires a PFN based on Xen -* granularity. -*/ - frame_list[i] = page_to_xen_pfn(page); - page = balloon_next_page(page); + frames[i] = page_to_xen_pfn(page); + page = balloon_next_page(page); + } } - set_xen_guest_handle(reservation.extent_start, frame_list); + set_xen_guest_handle(reservation.extent_start, frames); reservation.nr_extents = nr_pages; rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation); - if (rc <= 0) - return BP_EAGAIN; + if (rc <= 0) { + ret = BP_EAGAIN; + goto out; + } for (i = 0; i < rc; i++) { - page = balloon_retrieve(false); + if (ext_pages) + page = ext_pages[i]; + else + page = balloon_retrieve(false); BUG_ON(page == NULL); #ifdef CONFIG_XEN_HAVE_PVMMU @@ -463,14 +482,14 @@ static enum bp_state increase_reservation(unsigned long nr_pages) if (!xen_feature(XENFEAT_auto_translated_physmap)) { unsigned long pfn = page_to_pfn(page); - set_phys_to_machine(pfn, frame_list[i]); + set_phys_to_machine(pfn, frames[i]); /* Link back into the page tables if not highmem. */ if (!PageHighMem(page)) { int ret; ret = HYPERVISOR_update_va_mapping( (unsigned long)__va(pfn << PAGE_SHIFT), - mfn_pte(frame_list[i], PAGE_KERNEL), + mfn_pte(frames[i], PAGE_KERNEL), 0); BUG_ON(ret); } @@ -478,15 +497,22 @@ static enum bp_state increase_reservation(unsigned long nr_pages) #endif /* Relinquish the page back to the allocator. */ - __free_reserved_page(page); + if (!ext_pages) + __free_reserved_page(page); } - balloon_stats.current_pages += rc; + if (!ext_pages) + balloon_stats.current_pages += rc; - return BP_DONE; +out: + if (frames != frame_list) + kfree(frames); + + return ret; } -static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp) +static enum bp_state decrease_reservation(unsigned long n
Re: [PATCH 3/6] media: rcar-vin: Handle data-active property
Hi Niklas, On Wed, May 16, 2018 at 11:58:47PM +0200, Niklas Söderlund wrote: > Hi Jacopo, > > Thanks for your work. > > On 2018-05-16 18:32:29 +0200, Jacopo Mondi wrote: > > The data-active property has to be specified when running with embedded > > synchronization. The VIN peripheral can use HSYNC in place of CLOCKENB > > when the CLOCKENB pin is not connected, this requires explicit > > synchronization to be in use. > > Is this really the intent of the data-active property? I read the > video-interfaces.txt document as such as if no hsync-active, > vsync-active and data-active we should use the embedded synchronization > else set the polarity for the requested pins. What am I not > understanding here? Almost correct. The presence of hsync-active, vsync-active and field-evev-active properties determinate the bus type we're running on. If none of the is specified, the bus is marked 'BT656' and we assume the system is using embedded synchronization. data-active does not take part in the bus identification, and my reasoning was the other way around as explained in reply to your comment on [2/6], and as explained there my reasoning is probably wrong, and we should set CHS -only- when running with explicit synchronization, instead of making it mandatory when running with embedded syncs. Thanks and sorry for my confusion. j > > > > > Now that the driver supports 'data-active' property, it makes not sense > > to zero the mbus configuration flags when running with implicit synch > > (V4L2_MBUS_BT656). > > > > Signed-off-by: Jacopo Mondi > > --- > > drivers/media/platform/rcar-vin/rcar-core.c | 10 -- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c > > b/drivers/media/platform/rcar-vin/rcar-core.c > > index d3072e1..075d08f 100644 > > --- a/drivers/media/platform/rcar-vin/rcar-core.c > > +++ b/drivers/media/platform/rcar-vin/rcar-core.c > > @@ -531,15 +531,21 @@ static int rvin_digital_parse_v4l2(struct device *dev, > > return -ENOTCONN; > > > > vin->mbus_cfg.type = vep->bus_type; > > + vin->mbus_cfg.flags = vep->bus.parallel.flags; > > > > switch (vin->mbus_cfg.type) { > > case V4L2_MBUS_PARALLEL: > > vin_dbg(vin, "Found PARALLEL media bus\n"); > > - vin->mbus_cfg.flags = vep->bus.parallel.flags; > > break; > > case V4L2_MBUS_BT656: > > vin_dbg(vin, "Found BT656 media bus\n"); > > - vin->mbus_cfg.flags = 0; > > + > > + if (!(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_HIGH) && > > + !(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_LOW)) { > > + vin_err(vin, > > + "Missing data enable signal polarity > > property\n"); > > I fear this can't be an error as that would break backward comp ability > with existing dtb's. > > > + return -EINVAL; > > + } > > break; > > default: > > vin_err(vin, "Unknown media bus type\n"); > > -- > > 2.7.4 > > > > -- > Regards, > Niklas Söderlund signature.asc Description: PGP signature
Re: [PATCH 4/6] media: rcar-vin: Handle CLOCKENB pin polarity
Hi Niklas, On Thu, May 17, 2018 at 12:11:03AM +0200, Niklas Söderlund wrote: > Hi Jacopo, > > Thanks for your patch. > > I'm happy that you dig into this as it clearly needs doing! > > On 2018-05-16 18:32:30 +0200, Jacopo Mondi wrote: > > Handle CLOCKENB pin polarity, or use HSYNC in its place if polarity is > > not specified. > > > > Signed-off-by: Jacopo Mondi > > --- > > drivers/media/platform/rcar-vin/rcar-dma.c | 11 +++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c > > b/drivers/media/platform/rcar-vin/rcar-dma.c > > index ac07f99..7a84eae 100644 > > --- a/drivers/media/platform/rcar-vin/rcar-dma.c > > +++ b/drivers/media/platform/rcar-vin/rcar-dma.c > > @@ -123,6 +123,8 @@ > > /* Video n Data Mode Register 2 bits */ > > #define VNDMR2_VPS (1 << 30) > > #define VNDMR2_HPS (1 << 29) > > +#define VNDMR2_CES (1 << 28) > > +#define VNDMR2_CHS (1 << 23) > > #define VNDMR2_FTEV(1 << 17) > > #define VNDMR2_VLV(n) ((n & 0xf) << 12) > > > > @@ -691,6 +693,15 @@ static int rvin_setup(struct rvin_dev *vin) > > dmr2 |= VNDMR2_VPS; > > > > /* > > +* Clock-enable active level select. > > +* Use HSYNC as enable if not specified > > +*/ > > + if (vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_LOW) > > + dmr2 |= VNDMR2_CES; > > + else if (!(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_HIGH)) > > + dmr2 |= VNDMR2_CHS; > > After studying the datasheet for a while I'm getting more and more > convinced this should be (with context leftout in this patch context) > something like this: > > /* Hsync Signal Polarity Select */ > if (!(vin->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)) > dmr2 |= VNDMR2_HPS; > > /* Vsync Signal Polarity Select */ > if (!(vin->mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)) > dmr2 |= VNDMR2_VPS; > > /* Clock Enable Signal Polarity Select */ > if (!(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_LOW)) > dmr2 |= VNDMR2_CES; No, set CES if V4L2_MBUS_DATA_ACTIVE_LOW is specified, not the other way around. See the CES bit description: Clock Enable Signal Polarity Select This bit specifies the polarity of the input clock enable signal in the ITU- R BT.601. 0: Active high 1: Active low > > /* Use HSYNC as clock enable if VIn_CLKENB is not available. */ > if (!(vin->mbus_cfg.flags & (V4L2_MBUS_DATA_ACTIVE_LOW | > V4L2_MBUS_DATA_ACTIVE_HIGH))) > dmr2 |= VNDMR2_CHS; > > Or am I misunderstanding something? Isn't that what my code is doing? if (flags & LOW) dmr2 |= CES; else if (!(flags & HIGH)) // if we get here, LOW is not set too dmr2 |= CHS; Anyway, if you agree with my previous replies, we should set CHS only when running with explicit syncs (V4L2_MBUS_PARALLEL). Thanks j > > > + > > + /* > > * Output format > > */ > > switch (vin->format.pixelformat) { > > -- > > 2.7.4 > > > > -- > Regards, > Niklas Söderlund signature.asc Description: PGP signature
Re: [PATCH 3/6] media: rcar-vin: Handle data-active property
Hello! On 5/16/2018 7:32 PM, Jacopo Mondi wrote: The data-active property has to be specified when running with embedded Prop names are typically enclosed in "". synchronization. The VIN peripheral can use HSYNC in place of CLOCKENB CLKENB, maybe? when the CLOCKENB pin is not connected, this requires explicit synchronization to be in use. Now that the driver supports 'data-active' property, it makes not sense "data-active", s/not/no/. to zero the mbus configuration flags when running with implicit synch Sync is better. :-) (V4L2_MBUS_BT656). Signed-off-by: Jacopo Mondi [...] MBR, Sergei
Re: [PATCH v2 00/12] media: ov5640: Misc cleanup and improvements
Hi, On Mon, May 07, 2018 at 06:00:55PM -0700, Sam Bobrowicz wrote: > > Hi, > > > > Here is a "small" series that mostly cleans up the ov5640 driver code, > > slowly getting rid of the big data array for more understandable code > > (hopefully). > > > > The biggest addition would be the clock rate computation at runtime, > > instead of relying on those arrays to setup the clock tree > > properly. As a side effect, it fixes the framerate that was off by > > around 10% on the smaller resolutions, and we now support 60fps. > > > > This also introduces a bunch of new features. > > > > Let me know what you think, > > Maxime > > > > Changes from v1: > > - Integrated Hugues' suggestions to fix v4l2-compliance > > - Fixed the bus width with JPEG > > - Dropped the clock rate calculation loops for something simpler as > > suggested by Sakari > > - Cache the exposure value instead of using the control value > > - Rebased on top of 4.17 > > > > Maxime Ripard (10): > > media: ov5640: Don't force the auto exposure state at start time > > media: ov5640: Init properly the SCLK dividers > > media: ov5640: Change horizontal and vertical resolutions name > > media: ov5640: Add horizontal and vertical totals > > media: ov5640: Program the visible resolution > > media: ov5640: Adjust the clock based on the expected rate > > media: ov5640: Compute the clock rate at runtime > > media: ov5640: Enhance FPS handling > > media: ov5640: Add 60 fps support > > media: ov5640: Remove duplicate auto-exposure setup > > > > Mylène Josserand (2): > > media: ov5640: Add auto-focus feature > > media: ov5640: Add light frequency control > > > > drivers/media/i2c/ov5640.c | 752 + > > 1 file changed, 422 insertions(+), 330 deletions(-) > > > > -- > > 2.17.0 > > > > As discussed, MIPI required some additional work. Please see the > patches here which add support for MIPI: > https://www.dropbox.com/s/73epty7808yzq1t/ov5640_mipi_fixes.zip?dl=0 > > The first 3 patches are fixes I believe should be made to earlier > patches prior to submitting v2 of this series. The remaining 4 patches > should probably just be added onto the end of this series as-is (or > with feedback incorporated if needed). > > I will note that this is still not working correctly on my system for > any resolution that requires a 672 Mbps mipi rate. This includes > 1080p@30hz, full@15hz, and 720p@60hz. My CSI2 receiver is reporting > CRC errors though, so this could be an integrity issue on my module. > I'm curious to hear if others have success at these resolutions. > > Please try this out on other MIPI and DVP platforms with as many > different resolutions as possible and let me know if it works. I've took some of your changes to remain as feature stable as possible in my series. Some other changes (like the PLL2 setup), while totally welcome, should be in a separate, subsequent series. DVP works as expected, after looking at the feedback from Loic (and the clock tree especially), some of the comments you made (like the bit divider being meaningless for DVP) are not totally accurate, so I've tried to make the best blend of all the feedback you gave. It still works properly with DVP, but I still don't have a MIPI camera to test, so I'm not sure this works, even though I should have the same setup than the one you reported. Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v2 11/12] media: ov5640: Add 60 fps support
Hi Hugues, On Tue, May 15, 2018 at 01:33:55PM +, Hugues FRUCHET wrote: > I've taken the whole serie and made some tests on STM32 platform using > DVP parallel interface. > Now JPEG is OK and I've not seen any regressions appart on framerate > control linked to this current patchset. Thanks a lot for your feedback, I've (hopefully) fixed all the issues you reported here, most of the time taking your fix directly, except for 2 where I reworked the code instead. > Here are issues observed around framerate control: > 1) Framerate enumeration is buggy and all resolutions are claimed > supporting 15/30/60: > v4l2-ctl --list-formats-ext > ioctl: VIDIOC_ENUM_FMT > Index : 0 > Type: Video Capture > Pixel Format: 'JPEG' (compressed) > Name: JFIF JPEG > Size: Discrete 176x144 > Interval: Discrete 0.067s (15.000 fps) > Interval: Discrete 0.033s (30.000 fps) > Interval: Discrete 0.017s (60.000 fps) One small question though, I don't seem to have that output for v4l2-ctl, is some hook needed in the v4l2 device for it to work? Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
[PATCH v3 04/12] media: ov5640: Remove redundant defines
The OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT and OV5640_SCLK_ROOT_DIVIDER_DEFAULT defines represent exactly the same setup, and are at the same value, than the more consistent with the rest of the driver OV5640_SCLK2X_ROOT_DIV and OV5640_SCLK_ROOT_DIV. Remove them. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index 45e5ba32b8d1..ce9bfaafb675 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -93,9 +93,6 @@ #define OV5640_REG_SDE_CTRL5 0x5585 #define OV5640_REG_AVG_READOUT 0x56a1 -#define OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT 1 -#define OV5640_SCLK_ROOT_DIVIDER_DEFAULT 2 - enum ov5640_mode_id { OV5640_MODE_QCIF_176_144 = 0, OV5640_MODE_QVGA_320_240, @@ -1961,8 +1958,8 @@ static int ov5640_restore_mode(struct ov5640_dev *sensor) return ret; ret = ov5640_mod_reg(sensor, OV5640_REG_SYS_ROOT_DIVIDER, 0x3f, -(ilog2(OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT) << 2) | -ilog2(OV5640_SCLK_ROOT_DIVIDER_DEFAULT)); +(ilog2(OV5640_SCLK2X_ROOT_DIV) << 2) | +ilog2(OV5640_SCLK_ROOT_DIV)); if (ret) return ret; -- 2.17.0
[PATCH v3 10/12] media: ov5640: Make the FPS clamping / rounding more extendable
The current code uses an algorithm to clamp the FPS values and round them to the closest supported one that isn't really allows to be extended to more than two values. Rework it a bit to make it much easier to extend the amount of FPS options we support. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index b9a8f3feed74..0f6c39080d69 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -1890,7 +1890,8 @@ static int ov5640_try_frame_interval(struct ov5640_dev *sensor, { const struct ov5640_mode_info *mode; enum ov5640_frame_rate rate = OV5640_30_FPS; - u32 minfps, maxfps, fps; + int minfps, maxfps, best_fps, fps; + int i; minfps = ov5640_framerates[OV5640_15_FPS]; maxfps = ov5640_framerates[OV5640_30_FPS]; @@ -1901,19 +1902,21 @@ static int ov5640_try_frame_interval(struct ov5640_dev *sensor, return OV5640_30_FPS; } - fps = DIV_ROUND_CLOSEST(fi->denominator, fi->numerator); + fps = clamp_val(DIV_ROUND_CLOSEST(fi->denominator, fi->numerator), + minfps, maxfps); + + best_fps = minfps; + for (i = 0; i < ARRAY_SIZE(ov5640_framerates); i++) { + int curr_fps = ov5640_framerates[i]; + + if (abs(curr_fps - fps) < abs(best_fps - fps)) { + best_fps = curr_fps; + rate = i; + } + } fi->numerator = 1; - if (fps > maxfps) - fi->denominator = maxfps; - else if (fps < minfps) - fi->denominator = minfps; - else if (2 * fps >= 2 * minfps + (maxfps - minfps)) - fi->denominator = maxfps; - else - fi->denominator = minfps; - - rate = (fi->denominator == minfps) ? OV5640_15_FPS : OV5640_30_FPS; + fi->denominator = best_fps; mode = ov5640_find_mode(sensor, rate, width, height, false); return mode ? rate : -EINVAL; -- 2.17.0
[PATCH v3 05/12] media: ov5640: Remove redundant register setup
The MIPI divider is also cleared as part of the clock setup sequence, so we can remove that code. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index ce9bfaafb675..77864a1a5eb0 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -1281,16 +1281,6 @@ static int ov5640_set_stream_dvp(struct ov5640_dev *sensor, bool on) */ if (on) { - /* -* reset MIPI PCLK/SERCLK divider -* -* SC PLL CONTRL1 0 -* - [3..0]:MIPI PCLK/SERCLK divider -*/ - ret = ov5640_mod_reg(sensor, OV5640_REG_SC_PLL_CTRL1, 0x0f, 0); - if (ret) - return ret; - /* * configure parallel port control lines polarity * -- 2.17.0
[PATCH v3 11/12] media: ov5640: Add 60 fps support
Now that we have everything in place to compute the clock rate at runtime, we can enable the 60fps framerate for the mode we tested it with. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 30 -- 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index 0f6c39080d69..a8852ded60b6 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -109,6 +109,7 @@ enum ov5640_mode_id { enum ov5640_frame_rate { OV5640_15_FPS = 0, OV5640_30_FPS, + OV5640_60_FPS, OV5640_NUM_FRAMERATES, }; @@ -137,6 +138,7 @@ MODULE_PARM_DESC(virtual_channel, static const int ov5640_framerates[] = { [OV5640_15_FPS] = 15, [OV5640_30_FPS] = 30, + [OV5640_60_FPS] = 60, }; /* regulator supplies */ @@ -1439,12 +1441,23 @@ ov5640_find_mode(struct ov5640_dev *sensor, enum ov5640_frame_rate fr, /* try to find another mode */ continue; + /* Only 640x480 can operate at 60fps (for now) */ + if (fr == OV5640_60_FPS && + !(width == 640 && height == 480)) + /* try to find another mode */ + continue; + break; } } - if (nearest && i < 0) - mode = &ov5640_mode_data[0]; + /* VGA is the only mode that supports all the framerates */ + if (i < 0) { + if (!nearest) + return NULL; + + mode = &ov5640_mode_data[OV5640_MODE_VGA_640_480]; + } return mode; } @@ -1894,12 +1907,13 @@ static int ov5640_try_frame_interval(struct ov5640_dev *sensor, int i; minfps = ov5640_framerates[OV5640_15_FPS]; - maxfps = ov5640_framerates[OV5640_30_FPS]; + maxfps = ov5640_framerates[OV5640_60_FPS]; if (fi->numerator == 0) { fi->denominator = maxfps; fi->numerator = 1; - return OV5640_30_FPS; + rate = OV5640_60_FPS; + goto find_mode; } fps = clamp_val(DIV_ROUND_CLOSEST(fi->denominator, fi->numerator), @@ -1918,6 +1932,7 @@ static int ov5640_try_frame_interval(struct ov5640_dev *sensor, fi->numerator = 1; fi->denominator = best_fps; +find_mode: mode = ov5640_find_mode(sensor, rate, width, height, false); return mode ? rate : -EINVAL; } @@ -2495,8 +2510,11 @@ static int ov5640_s_frame_interval(struct v4l2_subdev *sd, frame_rate = ov5640_try_frame_interval(sensor, &fi->interval, mode->hact, mode->vact); - if (frame_rate < 0) - frame_rate = OV5640_15_FPS; + if (frame_rate < 0) { + /* Always return a valid frame interval value */ + fi->interval = sensor->frame_interval; + goto out; + } sensor->current_fr = frame_rate; sensor->frame_interval = fi->interval; -- 2.17.0
[PATCH v3 06/12] media: ov5640: Compute the clock rate at runtime
The clock rate, while hardcoded until now, is actually a function of the resolution, framerate and bytes per pixel. Now that we have an algorithm to adjust our clock rate, we can select it dynamically when we change the mode. This changes a bit the clock rate being used, with the following effect: +--+--+--+--+-+-++---+ | Hact | Vact | Htot | Vtot | FPS | Hardcoded clock | Computed clock | Deviation | +--+--+--+--+-+-++---+ | 640 | 480 | 1896 | 1080 | 15 |5600 | 61430400 | 8.84 % | | 640 | 480 | 1896 | 1080 | 30 | 11200 | 122860800 | 8.84 % | | 1024 | 768 | 1896 | 1080 | 15 |5600 | 61430400 | 8.84 % | | 1024 | 768 | 1896 | 1080 | 30 | 11200 | 122860800 | 8.84 % | | 320 | 240 | 1896 | 984 | 15 |5600 | 55969920 | 0.05 % | | 320 | 240 | 1896 | 984 | 30 | 11200 | 111939840 | 0.05 % | | 176 | 144 | 1896 | 984 | 15 |5600 | 55969920 | 0.05 % | | 176 | 144 | 1896 | 984 | 30 | 11200 | 111939840 | 0.05 % | | 720 | 480 | 1896 | 984 | 15 |5600 | 55969920 | 0.05 % | | 720 | 480 | 1896 | 984 | 30 | 11200 | 111939840 | 0.05 % | | 720 | 576 | 1896 | 984 | 15 |5600 | 55969920 | 0.05 % | | 720 | 576 | 1896 | 984 | 30 | 11200 | 111939840 | 0.05 % | | 1280 | 720 | 1892 | 740 | 15 |4200 | 42002400 | 0.01 % | | 1280 | 720 | 1892 | 740 | 30 |8400 | 84004800 | 0.01 % | | 1920 | 1080 | 2500 | 1120 | 15 |8400 | 8400 | 0.00 % | | 1920 | 1080 | 2500 | 1120 | 30 | 16800 | 16800 | 0.00 % | | 2592 | 1944 | 2844 | 1944 | 15 |8400 | 165862080 | 49.36 % | +--+--+--+--+-+-++---+ Only the 640x480, 1024x768 and 2592x1944 modes are significantly affected by the new formula. In this case, 640x480 and 1024x768 are actually fixed by this change. Indeed, the sensor was sending data at, for example, 27.33fps instead of 30fps. This is -9%, which is roughly what we're seeing in the array. Testing these modes with the new clock setup actually fix that error, and data are now sent at around 30fps. 2592x1944, on the other hand, is probably due to the fact that this mode can only be used using MIPI-CSI2, in a two lane mode, and never really tested with a DVP bus. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index 77864a1a5eb0..e9bd0aa55409 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -1886,7 +1886,8 @@ static int ov5640_set_mode(struct ov5640_dev *sensor, * which is 8 bits per pixel. */ bpp = sensor->fmt.code == MEDIA_BUS_FMT_JPEG_1X8 ? 8 : 16; - rate = mode->pixel_clock * bpp; + rate = mode->vtot * mode->htot * bpp; + rate *= ov5640_framerates[sensor->current_fr]; if (sensor->ep.bus_type == V4L2_MBUS_CSI2) { rate = rate / sensor->ep.bus.mipi_csi2.num_data_lanes; ret = ov5640_set_mipi_pclk(sensor, rate); -- 2.17.0
[PATCH v3 09/12] media: ov5640: Make the return rate type more explicit
In the ov5640_try_frame_interval function, the ret variable actually holds the frame rate index to use, which is represented by the enum ov5640_frame_rate in the driver. Make it more obvious. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index 785a692946b6..b9a8f3feed74 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -1889,8 +1889,8 @@ static int ov5640_try_frame_interval(struct ov5640_dev *sensor, u32 width, u32 height) { const struct ov5640_mode_info *mode; + enum ov5640_frame_rate rate = OV5640_30_FPS; u32 minfps, maxfps, fps; - int ret; minfps = ov5640_framerates[OV5640_15_FPS]; maxfps = ov5640_framerates[OV5640_30_FPS]; @@ -1913,10 +1913,10 @@ static int ov5640_try_frame_interval(struct ov5640_dev *sensor, else fi->denominator = minfps; - ret = (fi->denominator == minfps) ? OV5640_15_FPS : OV5640_30_FPS; + rate = (fi->denominator == minfps) ? OV5640_15_FPS : OV5640_30_FPS; - mode = ov5640_find_mode(sensor, ret, width, height, false); - return mode ? ret : -EINVAL; + mode = ov5640_find_mode(sensor, rate, width, height, false); + return mode ? rate : -EINVAL; } static int ov5640_get_fmt(struct v4l2_subdev *sd, -- 2.17.0
[PATCH v3 07/12] media: ov5640: Remove pixel clock rates
The pixel clock rates were introduced to report the initially static clock rate. Since this is now handled dynamically, we can remove them entirely. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 21 + 1 file changed, 1 insertion(+), 20 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index e9bd0aa55409..48f3c9e640ed 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -171,7 +171,6 @@ struct ov5640_mode_info { u32 htot; u32 vact; u32 vtot; - u32 pixel_clock; const struct reg_value *reg_data; u32 reg_data_size; }; @@ -691,7 +690,6 @@ static const struct reg_value ov5640_setting_15fps_QSXGA_2592_1944[] = { /* power-on sensor init reg table */ static const struct ov5640_mode_info ov5640_mode_init_data = { 0, SUBSAMPLING, 640, 1896, 480, 984, - 5600, ov5640_init_setting_30fps_VGA, ARRAY_SIZE(ov5640_init_setting_30fps_VGA), }; @@ -701,91 +699,74 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = { { {OV5640_MODE_QCIF_176_144, SUBSAMPLING, 176, 1896, 144, 984, -2800, ov5640_setting_15fps_QCIF_176_144, ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144)}, {OV5640_MODE_QVGA_320_240, SUBSAMPLING, 320, 1896, 240, 984, -2800, ov5640_setting_15fps_QVGA_320_240, ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240)}, {OV5640_MODE_VGA_640_480, SUBSAMPLING, 640, 1896, 480, 1080, -2800, ov5640_setting_15fps_VGA_640_480, ARRAY_SIZE(ov5640_setting_15fps_VGA_640_480)}, {OV5640_MODE_NTSC_720_480, SUBSAMPLING, 720, 1896, 480, 984, -2800, ov5640_setting_15fps_NTSC_720_480, ARRAY_SIZE(ov5640_setting_15fps_NTSC_720_480)}, {OV5640_MODE_PAL_720_576, SUBSAMPLING, 720, 1896, 576, 984, -2800, ov5640_setting_15fps_PAL_720_576, ARRAY_SIZE(ov5640_setting_15fps_PAL_720_576)}, {OV5640_MODE_XGA_1024_768, SUBSAMPLING, 1024, 1896, 768, 1080, -2800, ov5640_setting_15fps_XGA_1024_768, ARRAY_SIZE(ov5640_setting_15fps_XGA_1024_768)}, {OV5640_MODE_720P_1280_720, SUBSAMPLING, 1280, 1892, 720, 740, -2100, ov5640_setting_15fps_720P_1280_720, ARRAY_SIZE(ov5640_setting_15fps_720P_1280_720)}, {OV5640_MODE_1080P_1920_1080, SCALING, 1920, 2500, 1080, 1120, -4200, ov5640_setting_15fps_1080P_1920_1080, ARRAY_SIZE(ov5640_setting_15fps_1080P_1920_1080)}, {OV5640_MODE_QSXGA_2592_1944, SCALING, 2592, 2844, 1944, 1968, -8400, ov5640_setting_15fps_QSXGA_2592_1944, ARRAY_SIZE(ov5640_setting_15fps_QSXGA_2592_1944)}, }, { {OV5640_MODE_QCIF_176_144, SUBSAMPLING, 176, 1896, 144, 984, -5600, ov5640_setting_30fps_QCIF_176_144, ARRAY_SIZE(ov5640_setting_30fps_QCIF_176_144)}, {OV5640_MODE_QVGA_320_240, SUBSAMPLING, 320, 1896, 240, 984, -5600, ov5640_setting_30fps_QVGA_320_240, ARRAY_SIZE(ov5640_setting_30fps_QVGA_320_240)}, {OV5640_MODE_VGA_640_480, SUBSAMPLING, 640, 1896, 480, 1080, -5600, ov5640_setting_30fps_VGA_640_480, ARRAY_SIZE(ov5640_setting_30fps_VGA_640_480)}, {OV5640_MODE_NTSC_720_480, SUBSAMPLING, 720, 1896, 480, 984, -5600, ov5640_setting_30fps_NTSC_720_480, ARRAY_SIZE(ov5640_setting_30fps_NTSC_720_480)}, {OV5640_MODE_PAL_720_576, SUBSAMPLING, 720, 1896, 576, 984, -5600, ov5640_setting_30fps_PAL_720_576, ARRAY_SIZE(ov5640_setting_30fps_PAL_720_576)}, {OV5640_MODE_XGA_1024_768, SUBSAMPLING, 1024, 1896, 768, 1080, -5600, ov5640_setting_30fps_XGA_1024_768, ARRAY_SIZE(ov5640_setting_30fps_XGA_1024_768)}, {OV5640_MODE_720P_1280_720, SUBSAMPLING, 1280, 1892, 720, 740, -4200, ov5640_setting_30fps_720P_1280_720, ARRAY_SIZE(ov5640_setting_30fps_720P_1280_720)}, {OV5640_MODE_1080P_1920_1080, SCA
[PATCH v3 08/12] media: ov5640: Enhance FPS handling
Now that we have moved the clock generation logic out of the bytes array, these arrays are identical between the 15fps and 30fps variants. Remove the duplicate entries, and convert the code accordingly. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 316 +++-- 1 file changed, 60 insertions(+), 256 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index 48f3c9e640ed..785a692946b6 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -334,64 +334,7 @@ static const struct reg_value ov5640_init_setting_30fps_VGA[] = { {0x3a1f, 0x14, 0, 0}, {0x3008, 0x02, 0, 0}, {0x3c00, 0x04, 0, 300}, }; -static const struct reg_value ov5640_setting_30fps_VGA_640_480[] = { - {0x3c07, 0x08, 0, 0}, - {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, - {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, - {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0}, - {0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0}, - {0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0}, - {0x3810, 0x00, 0, 0}, - {0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0}, - {0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0}, - {0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0}, - {0x3a03, 0xd8, 0, 0}, {0x3a08, 0x01, 0, 0}, {0x3a09, 0x0e, 0, 0}, - {0x3a0a, 0x00, 0, 0}, {0x3a0b, 0xf6, 0, 0}, {0x3a0e, 0x03, 0, 0}, - {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0}, - {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0}, - {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0}, - {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x3503, 0x00, 0, 0}, -}; - -static const struct reg_value ov5640_setting_15fps_VGA_640_480[] = { - {0x3c07, 0x08, 0, 0}, - {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, - {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, - {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0}, - {0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0}, - {0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0}, - {0x3810, 0x00, 0, 0}, - {0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0}, - {0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0}, - {0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0}, - {0x3a03, 0xd8, 0, 0}, {0x3a08, 0x01, 0, 0}, {0x3a09, 0x27, 0, 0}, - {0x3a0a, 0x00, 0, 0}, {0x3a0b, 0xf6, 0, 0}, {0x3a0e, 0x03, 0, 0}, - {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0}, - {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0}, - {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0}, - {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, -}; - -static const struct reg_value ov5640_setting_30fps_XGA_1024_768[] = { - {0x3c07, 0x08, 0, 0}, - {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, - {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, - {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0}, - {0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0}, - {0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0}, - {0x3810, 0x00, 0, 0}, - {0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0}, - {0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0}, - {0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0}, - {0x3a03, 0xd8, 0, 0}, {0x3a08, 0x01, 0, 0}, {0x3a09, 0x0e, 0, 0}, - {0x3a0a, 0x00, 0, 0}, {0x3a0b, 0xf6, 0, 0}, {0x3a0e, 0x03, 0, 0}, - {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0}, - {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0}, - {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0}, - {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x3503, 0x00, 0, 0}, -}; - -static const struct reg_value ov5640_setting_15fps_XGA_1024_768[] = { +static const struct reg_value ov5640_setting_VGA_640_480[] = { {0x3c07, 0x08, 0, 0}, {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, @@ -410,7 +353,7 @@ static const struct reg_value ov5640_setting_15fps_XGA_1024_768[] = { {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, }; -static const struct reg_value ov5640_setting_30fps_QVGA_320_240[] = { +static const struct reg_value ov5640_setting_XGA_1024_768[] = { {0x3c07, 0x08, 0, 0}, {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, @@ -429,7 +372,7 @@
[PATCH v3 12/12] media: ov5640: Remove duplicate auto-exposure setup
The autoexposure setup in the 1080p init array is redundant with the default value of the sensor. Remove it. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index a8852ded60b6..6df227b22303 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -498,7 +498,7 @@ static const struct reg_value ov5640_setting_1080P_1920_1080[] = { {0x3a0e, 0x03, 0, 0}, {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x04, 0, 0}, {0x3a15, 0x60, 0, 0}, {0x4713, 0x02, 0, 0}, {0x4407, 0x04, 0, 0}, {0x460b, 0x37, 0, 0}, {0x460c, 0x20, 0, 0}, {0x3824, 0x04, 0, 0}, - {0x4005, 0x1a, 0, 0}, {0x3008, 0x02, 0, 0}, {0x3503, 0, 0, 0}, + {0x4005, 0x1a, 0, 0}, {0x3008, 0x02, 0, 0}, }; static const struct reg_value ov5640_setting_QSXGA_2592_1944[] = { -- 2.17.0
[PATCH v3 02/12] media: ov5640: Adjust the clock based on the expected rate
The clock structure for the PCLK is quite obscure in the documentation, and was hardcoded through the bytes array of each and every mode. This is troublesome, since we cannot adjust it at runtime based on other parameters (such as the number of bytes per pixel), and we can't support either framerates that have not been used by the various vendors, since we don't have the needed initialization sequence. We can however understand how the clock tree works, and then implement some functions to derive the various parameters from a given rate. And now that those parameters are calculated at runtime, we can remove them from the initialization sequence. The modes also gained a new parameter which is the clock that they are running at, from the register writes they were doing, so for now the switch to the new algorithm should be transparent. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 289 - 1 file changed, 288 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index 4bd968b478db..63923d85a31f 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -174,6 +174,7 @@ struct ov5640_mode_info { u32 htot; u32 vact; u32 vtot; + u32 pixel_clock; const struct reg_value *reg_data; u32 reg_data_size; }; @@ -695,6 +696,7 @@ static const struct reg_value ov5640_setting_15fps_QSXGA_2592_1944[] = { /* power-on sensor init reg table */ static const struct ov5640_mode_info ov5640_mode_init_data = { 0, SUBSAMPLING, 640, 1896, 480, 984, + 5600, ov5640_init_setting_30fps_VGA, ARRAY_SIZE(ov5640_init_setting_30fps_VGA), }; @@ -704,74 +706,91 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = { { {OV5640_MODE_QCIF_176_144, SUBSAMPLING, 176, 1896, 144, 984, +2800, ov5640_setting_15fps_QCIF_176_144, ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144)}, {OV5640_MODE_QVGA_320_240, SUBSAMPLING, 320, 1896, 240, 984, +2800, ov5640_setting_15fps_QVGA_320_240, ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240)}, {OV5640_MODE_VGA_640_480, SUBSAMPLING, 640, 1896, 480, 1080, +2800, ov5640_setting_15fps_VGA_640_480, ARRAY_SIZE(ov5640_setting_15fps_VGA_640_480)}, {OV5640_MODE_NTSC_720_480, SUBSAMPLING, 720, 1896, 480, 984, +2800, ov5640_setting_15fps_NTSC_720_480, ARRAY_SIZE(ov5640_setting_15fps_NTSC_720_480)}, {OV5640_MODE_PAL_720_576, SUBSAMPLING, 720, 1896, 576, 984, +2800, ov5640_setting_15fps_PAL_720_576, ARRAY_SIZE(ov5640_setting_15fps_PAL_720_576)}, {OV5640_MODE_XGA_1024_768, SUBSAMPLING, 1024, 1896, 768, 1080, +2800, ov5640_setting_15fps_XGA_1024_768, ARRAY_SIZE(ov5640_setting_15fps_XGA_1024_768)}, {OV5640_MODE_720P_1280_720, SUBSAMPLING, 1280, 1892, 720, 740, +2100, ov5640_setting_15fps_720P_1280_720, ARRAY_SIZE(ov5640_setting_15fps_720P_1280_720)}, {OV5640_MODE_1080P_1920_1080, SCALING, 1920, 2500, 1080, 1120, +4200, ov5640_setting_15fps_1080P_1920_1080, ARRAY_SIZE(ov5640_setting_15fps_1080P_1920_1080)}, {OV5640_MODE_QSXGA_2592_1944, SCALING, 2592, 2844, 1944, 1968, +8400, ov5640_setting_15fps_QSXGA_2592_1944, ARRAY_SIZE(ov5640_setting_15fps_QSXGA_2592_1944)}, }, { {OV5640_MODE_QCIF_176_144, SUBSAMPLING, 176, 1896, 144, 984, +5600, ov5640_setting_30fps_QCIF_176_144, ARRAY_SIZE(ov5640_setting_30fps_QCIF_176_144)}, {OV5640_MODE_QVGA_320_240, SUBSAMPLING, 320, 1896, 240, 984, +5600, ov5640_setting_30fps_QVGA_320_240, ARRAY_SIZE(ov5640_setting_30fps_QVGA_320_240)}, {OV5640_MODE_VGA_640_480, SUBSAMPLING, 640, 1896, 480, 1080, +5600, ov5640_setting_30fps_VGA_640_480, ARRAY_SIZE(ov5640_setting_30fps_VGA_640_480)}, {OV5640_MODE_NTSC_720_480, SUBSAMPLING, 720, 1896, 480, 984, +5600, ov5640_setting_30fps_NTSC_720_480, ARRAY_SIZE(ov5640_setting_30fps_NTSC_720_480)}, {OV5640_MODE_PAL_720_576, SUBSAMPL
[PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization
Part of the hardcoded initialization sequence is to set up the proper clock dividers. However, this is now done dynamically through proper code and as such, the static one is now redundant. Let's remove it. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 46 ++ 1 file changed, 22 insertions(+), 24 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index 63923d85a31f..45e5ba32b8d1 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -256,8 +256,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct v4l2_ctrl *ctrl) static const struct reg_value ov5640_init_setting_30fps_VGA[] = { {0x3103, 0x11, 0, 0}, {0x3008, 0x82, 0, 5}, {0x3008, 0x42, 0, 0}, {0x3103, 0x03, 0, 0}, {0x3017, 0x00, 0, 0}, {0x3018, 0x00, 0, 0}, - {0x3034, 0x18, 0, 0}, {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, - {0x3037, 0x13, 0, 0}, {0x3630, 0x36, 0, 0}, + {0x3630, 0x36, 0, 0}, {0x3631, 0x0e, 0, 0}, {0x3632, 0xe2, 0, 0}, {0x3633, 0x12, 0, 0}, {0x3621, 0xe0, 0, 0}, {0x3704, 0xa0, 0, 0}, {0x3703, 0x5a, 0, 0}, {0x3715, 0x78, 0, 0}, {0x3717, 0x01, 0, 0}, {0x370b, 0x60, 0, 0}, @@ -340,7 +339,7 @@ static const struct reg_value ov5640_init_setting_30fps_VGA[] = { }; static const struct reg_value ov5640_setting_30fps_VGA_640_480[] = { - {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0}, + {0x3c07, 0x08, 0, 0}, {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0}, @@ -359,7 +358,7 @@ static const struct reg_value ov5640_setting_30fps_VGA_640_480[] = { }; static const struct reg_value ov5640_setting_15fps_VGA_640_480[] = { - {0x3035, 0x22, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0}, + {0x3c07, 0x08, 0, 0}, {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0}, @@ -378,7 +377,7 @@ static const struct reg_value ov5640_setting_15fps_VGA_640_480[] = { }; static const struct reg_value ov5640_setting_30fps_XGA_1024_768[] = { - {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0}, + {0x3c07, 0x08, 0, 0}, {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0}, @@ -394,11 +393,10 @@ static const struct reg_value ov5640_setting_30fps_XGA_1024_768[] = { {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0}, {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0}, {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x3503, 0x00, 0, 0}, - {0x3035, 0x12, 0, 0}, }; static const struct reg_value ov5640_setting_15fps_XGA_1024_768[] = { - {0x3035, 0x22, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0}, + {0x3c07, 0x08, 0, 0}, {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0}, @@ -417,7 +415,7 @@ static const struct reg_value ov5640_setting_15fps_XGA_1024_768[] = { }; static const struct reg_value ov5640_setting_30fps_QVGA_320_240[] = { - {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0}, + {0x3c07, 0x08, 0, 0}, {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0}, @@ -436,7 +434,7 @@ static const struct reg_value ov5640_setting_30fps_QVGA_320_240[] = { }; static const struct reg_value ov5640_setting_15fps_QVGA_320_240[] = { - {0x3035, 0x22, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0}, + {0x3c07, 0x08, 0, 0}, {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0}, @@ -455,7 +453,7 @@ static const struct reg_value ov5640_setting_15fps_QVGA_320_240[] = { }; static const struct reg_value ov5640_setting_30fps_QCIF_176_144[] = { - {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0}, + {0x3c07, 0x08, 0, 0}, {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0}, {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0}, {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0}, @@ -474,7 +472,7 @@ static const struct reg_value ov5640_setting_30fp
[PATCH v3 01/12] media: ov5640: Fix timings setup code
From: Samuel Bobrowicz The current code, when changing the mode and changing the scaling or sampling parameters, will look at the horizontal and vertical total size, which, since 5999f381e023 ("media: ov5640: Add horizontal and vertical totals") has been moved from the static register initialization to after the mode change. That means that the values are no longer set up before the code retrieves them, which is obviously a bug. Fixes: 5999f381e023 ("media: ov5640: Add horizontal and vertical totals") Signed-off-by: Samuel Bobrowicz Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index e480e53b369b..4bd968b478db 100644 --- a/drivers/media/i2c/ov5640.c +++ b/drivers/media/i2c/ov5640.c @@ -1462,6 +1462,10 @@ static int ov5640_set_mode_exposure_calc(struct ov5640_dev *sensor, if (ret < 0) return ret; + ret = ov5640_set_timings(sensor, mode); + if (ret < 0) + return ret; + /* read capture VTS */ ret = ov5640_get_vts(sensor); if (ret < 0) @@ -1589,6 +1593,10 @@ static int ov5640_set_mode_direct(struct ov5640_dev *sensor, if (ret < 0) return ret; + ret = ov5640_set_timings(sensor, mode); + if (ret < 0) + return ret; + /* turn auto gain/exposure back on for direct mode */ ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_gain, 1); if (ret) @@ -1633,10 +1641,6 @@ static int ov5640_set_mode(struct ov5640_dev *sensor, ret = ov5640_set_mode_direct(sensor, mode, exposure); } - if (ret < 0) - return ret; - - ret = ov5640_set_timings(sensor, mode); if (ret < 0) return ret; -- 2.17.0
[PATCH v3 00/12] media: ov5640: Misc cleanup and improvements
Hi, Here is a "small" series that mostly cleans up the ov5640 driver code, slowly getting rid of the big data array for more understandable code (hopefully). The biggest addition would be the clock rate computation at runtime, instead of relying on those arrays to setup the clock tree properly. As a side effect, it fixes the framerate that was off by around 10% on the smaller resolutions, and we now support 60fps. This also introduces a bunch of new features. Let me know what you think, Maxime Changes from v2: - Rebased on latest Sakari PR - Fixed the issues reported by Hugues: improper FPS returned for formats, improper rounding of the FPS, some with his suggestions, some by simplifying the logic. - Expanded the clock tree comments based on the feedback from Samuel Bobrowicz and Loic Poulain - Merged some of the changes made by Samuel Bobrowicz to fix the MIPI rate computation, fix the call sites of the ov5640_set_timings function, the auto-exposure calculation call, etc. - Split the patches into smaller ones in order to make it more readable (hopefully) Changes from v1: - Integrated Hugues' suggestions to fix v4l2-compliance - Fixed the bus width with JPEG - Dropped the clock rate calculation loops for something simpler as suggested by Sakari - Cache the exposure value instead of using the control value - Rebased on top of 4.17 Maxime Ripard (11): media: ov5640: Adjust the clock based on the expected rate media: ov5640: Remove the clocks registers initialization media: ov5640: Remove redundant defines media: ov5640: Remove redundant register setup media: ov5640: Compute the clock rate at runtime media: ov5640: Remove pixel clock rates media: ov5640: Enhance FPS handling media: ov5640: Make the return rate type more explicit media: ov5640: Make the FPS clamping / rounding more extendable media: ov5640: Add 60 fps support media: ov5640: Remove duplicate auto-exposure setup Samuel Bobrowicz (1): media: ov5640: Fix timings setup code drivers/media/i2c/ov5640.c | 701 + 1 file changed, 392 insertions(+), 309 deletions(-) -- 2.17.0
[PATCH] media: vivid: potential integer overflow in vidioc_g_edid()
If we pick a very large "edid->blocks" value then the "edid->start_block + edid->blocks" addition could wrap around. Fixes: ef834f7836ec ("[media] vivid: add the video capture and output parts") Signed-off-by: Dan Carpenter diff --git a/drivers/media/platform/vivid/vivid-vid-common.c b/drivers/media/platform/vivid/vivid-vid-common.c index e5914be0e12d..be531caa2cdf 100644 --- a/drivers/media/platform/vivid/vivid-vid-common.c +++ b/drivers/media/platform/vivid/vivid-vid-common.c @@ -860,7 +860,7 @@ int vidioc_g_edid(struct file *file, void *_fh, return -ENODATA; if (edid->start_block >= dev->edid_blocks) return -EINVAL; - if (edid->start_block + edid->blocks > dev->edid_blocks) + if (edid->blocks > dev->edid_blocks - edid->start_block) edid->blocks = dev->edid_blocks - edid->start_block; if (adap) cec_set_edid_phys_addr(dev->edid, dev->edid_blocks * 128, adap->phys_addr);
Re: [PATCH] rcar-vin: sync which hardware buffer to start capture from
Hello! On 5/17/2018 2:22 AM, Niklas Söderlund wrote: When starting the VIN capture procedure we are not guaranteed that the first buffer writing to is VnMB1 to which we assigned the first buffer Written, perhaps? queued. This is problematic for two reasons. Buffers might not be dequeued in the same order they where queued for capture. Future features planed for the VIN driver is support for outputing frames in Outputting. SEQ_TB/BT format and to do that it's important that capture starts from the first buffer slot, VnMB1. We are guaranteed that capturing always happens in sequence (VnMB1 -> VnMB2 -> VnMB3 -> VnMB1). So drop up to two frames when starting capturing so that the driver always returns buffers in the same order they are queued and prepare for SEQ_TB/BT output. Signed-off-by: Niklas Söderlund --- drivers/media/platform/rcar-vin/rcar-dma.c | 16 +++- drivers/media/platform/rcar-vin/rcar-vin.h | 2 ++ 2 files changed, 17 insertions(+), 1 deletion(-) [...] MBR, Sergei
Re: [PATCH] dt-bindings: media: rcar_vin: fix style for ports and endpoints
On 5/17/2018 2:32 AM, Niklas Söderlund wrote: The style for referring to ports and endpoint are wrong. Refer to them using lowercase and a unit address, port@x and endpoint@x. Signed-off-by: Niklas Söderlund Reported-by: Geert Uytterhoeven More typos, yay! :-) --- .../devicetree/bindings/media/rcar_vin.txt| 20 +-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt index c2c57dcf73f4851b..a574b9c037c05a3c 100644 --- a/Documentation/devicetree/bindings/media/rcar_vin.txt +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt @@ -45,23 +45,23 @@ The per-board settings Gen2 platforms: The per-board settings Gen3 platforms: Gen3 platforms can support both a single connected parallel input source -from external SoC pins (port0) and/or multiple parallel input sources -from local SoC CSI-2 receivers (port1) depending on SoC. +from external SoC pins (port@0) and/or multiple parallel input sources +from local SoC CSI-2 receivers (port@1) depending on SoC. - renesas,id - ID number of the VIN, VINx in the documentation. - ports -- port 0 - sub-node describing a single endpoint connected to the VIN +- port@0 - sub-node describing a single endpoint connected to the VIN from external SoC pins described in video-interfaces.txt[1]. - Describing more then one endpoint in port 0 is invalid. Only VIN - instances that are connected to external pins should have port 0. -- port 1 - sub-nodes describing one or more endpoints connected to + Describing more then one endpoint in port@0 is invalid. Only VIN s/then/than/. + instances that are connected to external pins should have port@0. +- port@1 - sub-nodes describing one or more endpoints connected to the VIN from local SoC CSI-2 receivers. The endpoint numbers must use the following schema. [...] MBR, Sergei
[PATCH] media: v4l2-ioctl: prevent underflow in v4l_enumoutput()
My Smatch allmodconfig build only detects one function implementing vpbe_device_ops->enum_outputs and that's vpbe_enum_outputs(). The problem really happens in that function when we do: int temp_index = output->index; if (temp_index >= cfg->num_outputs) return -EINVAL; Unfortunately, both temp_index and cfg->num_outputs are type int so we have a potential read before the start of the array if "temp_index" is negative. I could have fixed the bug in that function but it's more secure and future proof to block that bug earlier in a central place. There is no one who need p->index to be more than INT_MAX. Fixes: 66715cdc3224 ("[media] davinci vpbe: VPBE display driver") Signed-off-by: Dan Carpenter diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index a40dbec271f1..115757ab8bc0 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -1099,6 +1099,9 @@ static int v4l_enumoutput(const struct v4l2_ioctl_ops *ops, if (is_valid_ioctl(vfd, VIDIOC_S_STD)) p->capabilities |= V4L2_OUT_CAP_STD; + if (p->index > INT_MAX) + return -EINVAL; + return ops->vidioc_enum_output(file, fh, p); }
Re: [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties
Hi Niklas, On Thu, May 17, 2018 at 12:13:07AM +0200, Niklas Söderlund wrote: > Hi Jacopo, > > Thanks for your work. > > On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote: > > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN > > driver and only confuse users. Remove them in all Gen2 SoC that used > > them. > > > > Signed-off-by: Jacopo Mondi > > --- > > arch/arm/boot/dts/r8a7790-lager.dts | 3 --- > > arch/arm/boot/dts/r8a7791-koelsch.dts | 3 --- > > arch/arm/boot/dts/r8a7791-porter.dts | 1 - > > arch/arm/boot/dts/r8a7793-gose.dts| 3 --- > > arch/arm/boot/dts/r8a7794-alt.dts | 1 - > > arch/arm/boot/dts/r8a7794-silk.dts| 1 - > > 6 files changed, 12 deletions(-) > > > > diff --git a/arch/arm/boot/dts/r8a7790-lager.dts > > b/arch/arm/boot/dts/r8a7790-lager.dts > > index 063fdb6..b56b309 100644 > > --- a/arch/arm/boot/dts/r8a7790-lager.dts > > +++ b/arch/arm/boot/dts/r8a7790-lager.dts > > @@ -873,10 +873,8 @@ > > port { > > vin0ep2: endpoint { > > remote-endpoint = <&adv7612_out>; > > - bus-width = <24>; > > I can't really make up my mind if this is a good thing or not. Device > tree describes the hardware and not what the drivers make use of. And > the fact is that this bus is 24 bits wide. So I'm not sure we should > remove these properties. But I would love to hear what others think > about this. > Just to point out those properties are not even documented in rcar-vin bindings (actually, none of them was). I feel it's wrong to have them here, as someone may think that changing their value should actually change the VIN interface behavior, which it's not true, leading to massive confusion and quite some code digging for no reason (and they will get mad at us at some point, probably :) Thanks j > > hsync-active = <0>; > > vsync-active = <0>; > > - pclk-sample = <1>; > > data-active = <1>; > > }; > > }; > > @@ -895,7 +893,6 @@ > > > > vin1ep0: endpoint { > > remote-endpoint = <&adv7180>; > > - bus-width = <8>; > > }; > > }; > > }; > > diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts > > b/arch/arm/boot/dts/r8a7791-koelsch.dts > > index f40321a..9967666 100644 > > --- a/arch/arm/boot/dts/r8a7791-koelsch.dts > > +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts > > @@ -849,10 +849,8 @@ > > > > vin0ep2: endpoint { > > remote-endpoint = <&adv7612_out>; > > - bus-width = <24>; > > hsync-active = <0>; > > vsync-active = <0>; > > - pclk-sample = <1>; > > data-active = <1>; > > }; > > }; > > @@ -870,7 +868,6 @@ > > > > vin1ep: endpoint { > > remote-endpoint = <&adv7180>; > > - bus-width = <8>; > > }; > > }; > > }; > > diff --git a/arch/arm/boot/dts/r8a7791-porter.dts > > b/arch/arm/boot/dts/r8a7791-porter.dts > > index c14e6fe..055a7f1 100644 > > --- a/arch/arm/boot/dts/r8a7791-porter.dts > > +++ b/arch/arm/boot/dts/r8a7791-porter.dts > > @@ -391,7 +391,6 @@ > > > > vin0ep: endpoint { > > remote-endpoint = <&adv7180>; > > - bus-width = <8>; > > }; > > }; > > }; > > diff --git a/arch/arm/boot/dts/r8a7793-gose.dts > > b/arch/arm/boot/dts/r8a7793-gose.dts > > index 9ed6961..9d3fba2 100644 > > --- a/arch/arm/boot/dts/r8a7793-gose.dts > > +++ b/arch/arm/boot/dts/r8a7793-gose.dts > > @@ -759,10 +759,8 @@ > > > > vin0ep2: endpoint { > > remote-endpoint = <&adv7612_out>; > > - bus-width = <24>; > > hsync-active = <0>; > > vsync-active = <0>; > > - pclk-sample = <1>; > > data-active = <1>; > > }; > > }; > > @@ -781,7 +779,6 @@ > > > > vin1ep: endpoint { > > remote-endpoint = <&adv7180_out>; > > - bus-width = <8>; > > }; > > }; > > }; > > diff --git a/arch/arm/boot/dts/r8a7794-alt.dts > > b/arch/arm/boot/dts/r8a7794-alt.dts > > index 26a8834..4bbb9cc 100644 > > --- a/arch/arm/boot/dts/r8a7794-alt.dts > > +++ b/arch/arm/boot/dts/r8a7794-alt.dts > > @@ -380,7 +380,6 @@ > > > > vin0ep: endpoint { > > remote-endpoint = <&adv7180>; > > - bus-width = <8>; > > }; > > }; > > }; > > diff --git a/arch/arm/boot/dts/r8a7794-silk.dts > > b/arch/arm/boot/dts/r8a7794-silk.dts > > index 351cb3b..c0c5d31 100644 > > --- a/arch/arm/boot/dts/r8a7794-silk.dts > > +++ b/arch/arm/boot/dts/r8a7794-silk.dts > > @@ -480,7 +480,6 @@ > > > > vin0ep: endpoint { > > remote-endpoint = <&adv7180>; > > -
Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements
Hi, On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote: Here is a "small" series that mostly cleans up the ov5640 driver code, slowly getting rid of the big data array for more understandable code (hopefully). The biggest addition would be the clock rate computation at runtime, instead of relying on those arrays to setup the clock tree properly. As a side effect, it fixes the framerate that was off by around 10% on the smaller resolutions, and we now support 60fps. This also introduces a bunch of new features. I'd like to give this a try. What tree should this patch set be applied on? I had no luck with media_tree/for-4.18-6. Thanks, Daniel Let me know what you think, Maxime Changes from v2: - Rebased on latest Sakari PR - Fixed the issues reported by Hugues: improper FPS returned for formats, improper rounding of the FPS, some with his suggestions, some by simplifying the logic. - Expanded the clock tree comments based on the feedback from Samuel Bobrowicz and Loic Poulain - Merged some of the changes made by Samuel Bobrowicz to fix the MIPI rate computation, fix the call sites of the ov5640_set_timings function, the auto-exposure calculation call, etc. - Split the patches into smaller ones in order to make it more readable (hopefully) Changes from v1: - Integrated Hugues' suggestions to fix v4l2-compliance - Fixed the bus width with JPEG - Dropped the clock rate calculation loops for something simpler as suggested by Sakari - Cache the exposure value instead of using the control value - Rebased on top of 4.17 Maxime Ripard (11): media: ov5640: Adjust the clock based on the expected rate media: ov5640: Remove the clocks registers initialization media: ov5640: Remove redundant defines media: ov5640: Remove redundant register setup media: ov5640: Compute the clock rate at runtime media: ov5640: Remove pixel clock rates media: ov5640: Enhance FPS handling media: ov5640: Make the return rate type more explicit media: ov5640: Make the FPS clamping / rounding more extendable media: ov5640: Add 60 fps support media: ov5640: Remove duplicate auto-exposure setup Samuel Bobrowicz (1): media: ov5640: Fix timings setup code drivers/media/i2c/ov5640.c | 701 + 1 file changed, 392 insertions(+), 309 deletions(-)
Re: [PATCH v9 6/8] media: vsp1: Refactor display list configure operations
Hi Kieran, Thank you for the patch. On Thursday, 3 May 2018 16:35:45 EEST Kieran Bingham wrote: > The entities provide a single .configure operation which configures the > object into the target display list, based on the vsp1_entity_params > selection. > > Split the configure function into three parts, '.configure_stream()', > '.configure_frame()', and '.configure_partition()' to facilitate > splitting the configuration of each parameter class into separate > display list bodies. > > Signed-off-by: Kieran Bingham > > --- > The checkpatch warning: > > WARNING: function definition argument 'struct vsp1_dl_list *' should > also have an identifier name > > has been ignored to match the existing code style. > > v8: > - Add support for the UIF > - Remove unrelated whitespace change > - Fix comment location for clu_configure_stream() > - Update configure documentations > - Implement configure_partition separation. > > v7 > - Fix formatting and white space > - s/prepare/configure_stream/ > - s/configure/configure_frame/ > --- > drivers/media/platform/vsp1/vsp1_brx.c| 12 +- > drivers/media/platform/vsp1/vsp1_clu.c| 77 ++ > drivers/media/platform/vsp1/vsp1_drm.c| 12 +- > drivers/media/platform/vsp1/vsp1_entity.c | 24 ++- > drivers/media/platform/vsp1/vsp1_entity.h | 39 +-- > drivers/media/platform/vsp1/vsp1_hgo.c| 12 +- > drivers/media/platform/vsp1/vsp1_hgt.c| 12 +- > drivers/media/platform/vsp1/vsp1_hsit.c | 12 +- > drivers/media/platform/vsp1/vsp1_lif.c| 12 +- > drivers/media/platform/vsp1/vsp1_lut.c| 47 +--- > drivers/media/platform/vsp1/vsp1_rpf.c| 168 ++--- > drivers/media/platform/vsp1/vsp1_sru.c| 12 +- > drivers/media/platform/vsp1/vsp1_uds.c| 56 ++-- > drivers/media/platform/vsp1/vsp1_uif.c| 16 +- > drivers/media/platform/vsp1/vsp1_video.c | 28 +-- > drivers/media/platform/vsp1/vsp1_wpf.c| 303 --- > 16 files changed, 422 insertions(+), 420 deletions(-) [snip] > diff --git a/drivers/media/platform/vsp1/vsp1_clu.c > b/drivers/media/platform/vsp1/vsp1_clu.c index ea83f1b7d125..0a978980d447 > 100644 > --- a/drivers/media/platform/vsp1/vsp1_clu.c > +++ b/drivers/media/platform/vsp1/vsp1_clu.c > @@ -168,58 +168,50 @@ static const struct v4l2_subdev_ops clu_ops = { > /* > * VSP1 Entity Operations > */ > +static void clu_configure_stream(struct vsp1_entity *entity, > + struct vsp1_pipeline *pipe, > + struct vsp1_dl_list *dl) > +{ > + struct vsp1_clu *clu = to_clu(&entity->subdev); > + struct v4l2_mbus_framefmt *format; > I would have kept this blank line before the function. > -static void clu_configure(struct vsp1_entity *entity, > - struct vsp1_pipeline *pipe, > - struct vsp1_dl_list *dl, > - enum vsp1_entity_params params) > + /* > + * The yuv_mode can't be changed during streaming. Cache it internally > + * for future runtime configuration calls. > + */ > + format = vsp1_entity_get_pad_format(&clu->entity, > + clu->entity.config, > + CLU_PAD_SINK); > + clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32; > +} [snip] > diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c > b/drivers/media/platform/vsp1/vsp1_wpf.c index 65ed2f849551..da287c27b324 > 100644 > --- a/drivers/media/platform/vsp1/vsp1_wpf.c > +++ b/drivers/media/platform/vsp1/vsp1_wpf.c [snip] > +static void wpf_configure_frame(struct vsp1_entity *entity, > + struct vsp1_pipeline *pipe, > + struct vsp1_dl_list *dl) > +{ > + struct vsp1_rwpf *wpf = to_rwpf(&entity->subdev); > + unsigned long flags; > + u32 outfmt = 0; No need to initialize outfmt to 0. > + This blank line isn't needed. > + const unsigned int mask = BIT(WPF_CTRL_VFLIP) > + | BIT(WPF_CTRL_HFLIP); > + > + spin_lock_irqsave(&wpf->flip.lock, flags); > + wpf->flip.active = (wpf->flip.active & ~mask) > + | (wpf->flip.pending & mask); > + spin_unlock_irqrestore(&wpf->flip.lock, flags); > + > + outfmt = (wpf->alpha << VI6_WPF_OUTFMT_PDV_SHIFT) | wpf->outfmt; > + > + if (wpf->flip.active & BIT(WPF_CTRL_VFLIP)) > + outfmt |= VI6_WPF_OUTFMT_FLP; > + if (wpf->flip.active & BIT(WPF_CTRL_HFLIP)) > + outfmt |= VI6_WPF_OUTFMT_HFLP; > + > + vsp1_wpf_write(wpf, dl, VI6_WPF_OUTFMT, outfmt); > +} [snip] Apart from that, Reviewed-by: Laurent Pinchart If you agree with those small changes there's no need to resubmit, I'll fix when applying. -- Regards, Laurent Pinchart
[PATCH] media: v4l2-ctrl: Add control for VP9 profile
Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired profile for VP9 encoder and querying for supported profiles by VP9 encoder or decoder. An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be used for querying since it is not a menu control but an integer control, which cannot return an arbitrary set of supported profiles. The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as with controls for other codec profiles. (e.g. H264) Signed-off-by: Keiichi Watanabe --- .../media/uapi/v4l/extended-controls.rst | 26 +++ drivers/media/v4l2-core/v4l2-ctrls.c | 12 + include/uapi/linux/v4l2-controls.h| 8 ++ 3 files changed, 46 insertions(+) diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst index 03931f9b1285..4f7f128a4998 100644 --- a/Documentation/media/uapi/v4l/extended-controls.rst +++ b/Documentation/media/uapi/v4l/extended-controls.rst @@ -1959,6 +1959,32 @@ enum v4l2_vp8_golden_frame_sel - Select the desired profile for VPx encoder. Acceptable values are 0, 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3. +.. _v4l2-mpeg-video-vp9-profile: + +``V4L2_CID_MPEG_VIDEO_VP9_PROFILE`` +(enum) + +enum v4l2_mpeg_video_vp9_profile - +This control allows to select the profile for VP9 encoder. +This is also used to enumerate supported profiles by VP9 encoder or decoder. +Possible values are: + + + +.. flat-table:: +:header-rows: 0 +:stub-columns: 0 + +* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_0`` + - Profile 0 +* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_1`` + - Profile 1 +* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_2`` + - Profile 2 +* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_3`` + - Profile 3 + + High Efficiency Video Coding (HEVC/H.265) Control Reference --- diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c index d29e45516eb7..401ce21c2e63 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id) "Use Previous Specific Frame", NULL, }; + static const char * const vp9_profile[] = { + "0", + "1", + "2", + "3", + NULL, + }; static const char * const flash_led_mode[] = { "Off", @@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id) return mpeg4_profile; case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL: return vpx_golden_frame_sel; + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE: + return vp9_profile; case V4L2_CID_JPEG_CHROMA_SUBSAMPLING: return jpeg_chroma_subsampling; case V4L2_CID_DV_TX_MODE: @@ -841,6 +850,8 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX P-Frame QP Value"; case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX Profile"; + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE: return "VP9 Profile"; + /* HEVC controls */ case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value"; case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP: return "HEVC P-Frame QP Value"; @@ -1180,6 +1191,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type, case V4L2_CID_DEINTERLACING_MODE: case V4L2_CID_TUNE_DEEMPHASIS: case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL: + case V4L2_CID_MPEG_VIDEO_VP9_PROFILE: case V4L2_CID_DETECT_MD_MODE: case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE: case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL: diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h index 8d473c979b61..56203b7b715c 100644 --- a/include/uapi/linux/v4l2-controls.h +++ b/include/uapi/linux/v4l2-controls.h @@ -589,6 +589,14 @@ enum v4l2_vp8_golden_frame_sel { #define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510) #define V4L2_CID_MPEG_VIDEO_VPX_PROFILE (V4L2_CID_MPEG_BASE+511) +#define V4L2_CID_MPEG_VIDEO_VP9_PROFILE (V4L2_CID_MPEG_BASE+512) +enum v4l2_mpeg_video_vp9_profile { + V4L2_MPEG_VIDEO_VP9_PROFILE_0 = 0, + V4L2_MPEG_VIDEO_VP9_PROFILE_1 = 1, + V4L2_MPEG_VIDEO_VP9_PROFILE_2 = 2, + V4L2_MPEG_VIDEO_VP9_PROFILE_3 = 3, +}; + /* CIDs for HEVC encoding. */ #define V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP(V4L2_CID_MPEG_BASE + 600) -- 2.17.0.441.gb46fe60e1d-goog
Re: [PATCH v9 7/8] media: vsp1: Adapt entities to configure into a body
Hi Kieran, Thank you for the patch. On Thursday, 3 May 2018 16:35:46 EEST Kieran Bingham wrote: > Currently the entities store their configurations into a display list. > Adapt this such that the code can be configured into a body directly, > allowing greater flexibility and control of the content. > > All users of vsp1_dl_list_write() are removed in this process, thus it > too is removed. > > A helper, vsp1_dl_list_get_body0() is provided to access the internal body0 > from the display list. > > Signed-off-by: Kieran Bingham > Reviewed-by: Laurent Pinchart > --- > v9: > - Pass the DL through configure_partition() calls > > v8: > - Fixed comment style and indentation > - Supported UIF > - Supported new configure_partition() functionality > > v7: > - Rebase > - s/prepare/configure_stream/ > - s/configure/configure_frame/ > --- > drivers/media/platform/vsp1/vsp1_brx.c| 22 ++-- > drivers/media/platform/vsp1/vsp1_clu.c| 23 ++--- > drivers/media/platform/vsp1/vsp1_dl.c | 12 ++- > drivers/media/platform/vsp1/vsp1_dl.h | 2 +- > drivers/media/platform/vsp1/vsp1_drm.c| 12 --- > drivers/media/platform/vsp1/vsp1_entity.c | 22 ++-- > drivers/media/platform/vsp1/vsp1_entity.h | 18 ++ > drivers/media/platform/vsp1/vsp1_hgo.c| 16 - > drivers/media/platform/vsp1/vsp1_hgt.c| 18 +- > drivers/media/platform/vsp1/vsp1_hsit.c | 10 ++--- > drivers/media/platform/vsp1/vsp1_lif.c| 15 > drivers/media/platform/vsp1/vsp1_lut.c| 23 ++--- > drivers/media/platform/vsp1/vsp1_pipe.c | 4 +- > drivers/media/platform/vsp1/vsp1_pipe.h | 3 +- > drivers/media/platform/vsp1/vsp1_rpf.c| 44 > drivers/media/platform/vsp1/vsp1_sru.c| 14 > drivers/media/platform/vsp1/vsp1_uds.c| 25 +++--- > drivers/media/platform/vsp1/vsp1_uds.h| 2 +- > drivers/media/platform/vsp1/vsp1_uif.c| 21 +-- > drivers/media/platform/vsp1/vsp1_video.c | 16 ++--- > drivers/media/platform/vsp1/vsp1_wpf.c| 42 --- > 21 files changed, 194 insertions(+), 170 deletions(-) [snip] > diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c > b/drivers/media/platform/vsp1/vsp1_rpf.c index deb86cc235ef..8fae7c485642 > 100644 > --- a/drivers/media/platform/vsp1/vsp1_rpf.c > +++ b/drivers/media/platform/vsp1/vsp1_rpf.c [snip] > @@ -192,7 +195,6 @@ static void rpf_configure_partition(struct vsp1_entity > *entity, const struct vsp1_format_info *fmtinfo = rpf->fmtinfo; > const struct v4l2_pix_format_mplane *format = &rpf->format; > struct v4l2_rect crop; > - No need to remove this blank line. Apart from that, Reviewed-by: Laurent Pinchart There's no need to resubmit, I'll fix when applying. > /* >* Source size and crop offsets. >* [snip] -- Regards, Laurent Pinchart
[ragnatech:media-tree 13/389] drivers/video/fbdev//omap2/omapfb/dss/dispc.c:1859:2: warning: this 'else' clause does not guard...
tree: git://git.ragnatech.se/linux media-tree head: 7e6b6b945272c20f6b78d319e07f27897a8373c9 commit: 7378f1149884b183631c6c16c0f1c62bcd7d759d [13/389] media: omap2: omapfb: allow building it with COMPILE_TEST config: mips-allyesconfig (attached as .config) compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 7378f1149884b183631c6c16c0f1c62bcd7d759d # save the attached .config to linux build tree make.cross ARCH=mips All warnings (new ones prefixed by >>): drivers/video/fbdev//omap2/omapfb/dss/dispc.c: In function 'pixinc': >> drivers/video/fbdev//omap2/omapfb/dss/dispc.c:1859:2: warning: this 'else' >> clause does not guard... [-Wmisleading-indentation] else ^~~~ drivers/video/fbdev//omap2/omapfb/dss/dispc.c:1861:3: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else' return 0; ^~ vim +/else +1859 drivers/video/fbdev//omap2/omapfb/dss/dispc.c f76ee892 Tomi Valkeinen 2015-12-09 1850 f76ee892 Tomi Valkeinen 2015-12-09 1851 static s32 pixinc(int pixels, u8 ps) f76ee892 Tomi Valkeinen 2015-12-09 1852 { f76ee892 Tomi Valkeinen 2015-12-09 1853if (pixels == 1) f76ee892 Tomi Valkeinen 2015-12-09 1854return 1; f76ee892 Tomi Valkeinen 2015-12-09 1855else if (pixels > 1) f76ee892 Tomi Valkeinen 2015-12-09 1856return 1 + (pixels - 1) * ps; f76ee892 Tomi Valkeinen 2015-12-09 1857else if (pixels < 0) f76ee892 Tomi Valkeinen 2015-12-09 1858return 1 - (-pixels + 1) * ps; f76ee892 Tomi Valkeinen 2015-12-09 @1859else f76ee892 Tomi Valkeinen 2015-12-09 1860BUG(); f76ee892 Tomi Valkeinen 2015-12-09 1861return 0; f76ee892 Tomi Valkeinen 2015-12-09 1862 } f76ee892 Tomi Valkeinen 2015-12-09 1863 :: The code at line 1859 was first introduced by commit :: f76ee892a99e68b55402b8d4b8aeffcae2aff34d omapfb: copy omapdss & displays for omapfb :: TO: Tomi Valkeinen :: CC: Tomi Valkeinen --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v2 1/4] media: rcar-vin: Parse digital input in mc-path
Hi Niklas, thanks for review. On Wed, May 16, 2018 at 10:32:49PM +0200, Niklas Söderlund wrote: > Hi Jacopo, > > Thanks for your work! > > First let me apologies for the use of the keyword 'digital' in the > driver it should have been parallel... Someday we should remedy this. > > If you touch any parts of the code where such a transition make sens I > would not complain about the intermixed use of digital/parallel. Once > your work is done we could follow up with a cleanup patch to complete > the transition. Or if you rather stick with digital here I'm fine with > that too. I would go with a major s/digital/parallel/ after this has been merged, if that' fine with you. > > On 2018-05-16 14:16:53 +0200, Jacopo Mondi wrote: > > Add support for digital input subdevices to Gen-3 rcar-vin. > > The Gen-3, media-controller compliant, version has so far only accepted > > CSI-2 input subdevices. Remove assumptions on the supported bus_type and > > accepted number of subdevices, and allow digital input connections on > > port@0. > > > > Signed-off-by: Jacopo Mondi > > --- > > drivers/media/platform/rcar-vin/rcar-core.c | 99 > > +++-- > > drivers/media/platform/rcar-vin/rcar-vin.h | 15 + > > 2 files changed, 93 insertions(+), 21 deletions(-) > > > > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c > > b/drivers/media/platform/rcar-vin/rcar-core.c > > index d3072e1..0ea21ab 100644 > > --- a/drivers/media/platform/rcar-vin/rcar-core.c > > +++ b/drivers/media/platform/rcar-vin/rcar-core.c > > @@ -562,7 +562,7 @@ static int rvin_digital_graph_init(struct rvin_dev *vin) > > return ret; > > > > if (!vin->digital) > > - return -ENODEV; > > + return -ENOTCONN; > > > > vin_dbg(vin, "Found digital subdevice %pOF\n", > > to_of_node(vin->digital->asd.match.fwnode)); > > @@ -703,15 +703,13 @@ static int rvin_mc_parse_of_endpoint(struct device > > *dev, > > { > > struct rvin_dev *vin = dev_get_drvdata(dev); > > > > - if (vep->base.port != 1 || vep->base.id >= RVIN_CSI_MAX) > > + if (vep->base.port != RVIN_PORT_CSI2 || vep->base.id >= RVIN_CSI_MAX) > > I don't like this RVIN_PORT_CSI2. It makes the code harder to read as I > have have to go and lookup which port RVIN_PORT_CSI2 represents. I would Why do you have to go and look? It's an enum, it abstracts away the numerical value it represents with a human readable string. If you want to check which number it represent you can got and look at the enum definition, once. While reading the code, the most important part is "this is the CSI-2 port" or "this is port 1"? You wrote the driver and for you there is no ambiguity there, I understand. > rater just keep vep->base.port != 1 as I think it's much clearer whats > going on. And it's not as we will move the CSI-2 input to a different > port as it's described in the bindings. That's one more reason to have an enum for that. Anyway, that's pure bikeshedding, I like discussing these things too but I'm surely not making an argument for this. If you don't like the enum I'll remove that. > > > return -EINVAL; > > > > if (!of_device_is_available(to_of_node(asd->match.fwnode))) { > > - > > vin_dbg(vin, "OF device %pOF disabled, ignoring\n", > > to_of_node(asd->match.fwnode)); > > return -ENOTCONN; > > - > > } > > > > if (vin->group->csi[vep->base.id].fwnode) { > > @@ -720,6 +718,8 @@ static int rvin_mc_parse_of_endpoint(struct device *dev, > > return -ENOTCONN; > > } > > > > + vin->mbus_cfg.type = V4L2_MBUS_CSI2; > > + vin->mbus_cfg.flags = 0; > > I like this move of mbus_cfg handling! Makes the two cases more aligned > which are good. Unfortunately I fear it needs more work :-( > > With this series addition of parallel input support. There are now two > input types CSI-2 and parallel which can be changed at runtime for the > same VIN. The mbus connected to the VIN will therefor be different Wait, are you suggesting the parallel input connection can be switched with CSI-2 ones at runtime? I undestand the CSI-2 - VIN routing as the physical connections are already in place in the SoC, but if we're connecting a parallel input to a VIN instance that accepts an input connection then that hardly can be switched to another port with a software configuration. My understanding was even different: when a port has a digital video input connected, a CSI-2 input cannot be routed there, because, well, there is already a non modifiable connection, possibly part of the PCB design. > depending on which media graph link is connected to a particular VIN and > this effects hardware configuration, see 'vin->mbus_cfg.type == > V4L2_MBUS_CSI2' in rvin_setup(). > > Maybe the best solution is to move mbus_cfg into struct > rvin_graph_entity, rename that struct rvin_parallel_input and cache the > parallel input settings in there, much like we do today for the pads.
Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1
On 05/16/2018 08:14 PM, Gustavo A. R. Silva wrote: On 05/15/2018 02:39 PM, Dan Carpenter wrote: Dan, These are all the Spectre media issues I see smatch is reporting in linux-next-20180515: drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() warn: potential spectre issue 'pin->error_inj_args' drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() warn: potential spectre issue 'ca->slot_info' (local cap) drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: potential spectre issue 'p->ule_next_hdr' I pulled the latest changes from the smatch repository and compiled it. I'm running smatch v0.5.0-4459-g2f66d40 now. Is this the latest version? I wonder if there is anything I might be missing. You'd need to rebuild the db (possibly twice but definitely once). Hi Dan, After rebuilding the db (once), these are all the Spectre media warnings I get: drivers/media/pci/ddbridge/ddbridge-core.c:233 ddb_redirect() warn: potential spectre issue 'ddbs' drivers/media/pci/ddbridge/ddbridge-core.c:243 ddb_redirect() warn: potential spectre issue 'pdev->port' drivers/media/pci/ddbridge/ddbridge-core.c:252 ddb_redirect() warn: potential spectre issue 'idev->input' drivers/media/dvb-core/dvb_ca_en50221.c:1400 dvb_ca_en50221_io_do_ioctl() warn: potential spectre issue 'ca->slot_info' (local cap) drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() warn: potential spectre issue 'ca->slot_info' (local cap) drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: potential spectre issue 'p->ule_next_hdr' drivers/media/dvb-core/dvb_net.c:1483 dvb_net_do_ioctl() warn: potential spectre issue 'dvbnet->device' (local cap) drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() warn: potential spectre issue 'pin->error_inj_args' I just want to double check if you are getting the same output. In case you are getting the same, then what Mauro commented about these issues: https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7277 being resolved by commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 seems to be correct. Interesting, I've rebuild the db twice and now I get a total of 75 Spectre warnings in drivers/media -- Gustavo
[PATCH 1/3] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil
From: Alan Chiang Dongwoon DW9807 is a voice coil lens driver. Signed-off-by: Alan Chiang Signed-off-by: Andy Yeh Reviewed-by: Rob Herring Signed-off-by: Sakari Ailus --- Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt | 9 + 1 file changed, 9 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt new file mode 100644 index ..0a1a860beaff --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt @@ -0,0 +1,9 @@ +Dongwoon Anatech DW9807 voice coil lens driver + +DW9807 is a 10-bit DAC with current sink capability. It is intended for +controlling voice coil lenses. + +Mandatory properties: + +- compatible: "dongwoon,dw9807" +- reg: I2C slave address -- 2.11.0
[PATCH 3/3] media: imx258: Add imx258 camera sensor driver
From: Jason Chen Add a V4L2 sub-device driver for the Sony IMX258 image sensor. This is a camera sensor using the I2C bus for control and the CSI-2 bus for data. Signed-off-by: Jason Chen Signed-off-by: Andy Yeh Signed-off-by: Alan Chiang Reviewed-by: Tomasz Figa Signed-off-by: Sakari Ailus --- MAINTAINERS|7 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/imx258.c | 1320 4 files changed, 1339 insertions(+) create mode 100644 drivers/media/i2c/imx258.c diff --git a/MAINTAINERS b/MAINTAINERS index 6304b696c698..c82c30059679 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13076,6 +13076,13 @@ S: Maintained F: drivers/ssb/ F: include/linux/ssb/ +SONY IMX258 SENSOR DRIVER +M: Sakari Ailus +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: drivers/media/i2c/imx258.c + SONY IMX274 SENSOR DRIVER M: Leon Luo L: linux-media@vger.kernel.org diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index e6a721c5e3b0..1f9d7c6aa31a 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -585,6 +585,17 @@ config VIDEO_APTINA_PLL config VIDEO_SMIAPP_PLL tristate +config VIDEO_IMX258 + tristate "Sony IMX258 sensor support" + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + depends on MEDIA_CAMERA_SUPPORT + ---help--- + This is a Video4Linux2 sensor-level driver for the Sony + IMX258 camera. + + To compile this driver as a module, choose M here: the + module will be called imx258. + config VIDEO_IMX274 tristate "Sony IMX274 sensor support" depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 5cf15edacb2b..16fc34eda5cc 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -102,6 +102,7 @@ obj-$(CONFIG_VIDEO_I2C) += video-i2c.o obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o obj-$(CONFIG_VIDEO_OV2659) += ov2659.o obj-$(CONFIG_VIDEO_TC358743) += tc358743.o +obj-$(CONFIG_VIDEO_IMX258) += imx258.o obj-$(CONFIG_VIDEO_IMX274) += imx274.o obj-$(CONFIG_SDR_MAX2175) += max2175.o diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c new file mode 100644 index ..fad3012f4fe5 --- /dev/null +++ b/drivers/media/i2c/imx258.c @@ -0,0 +1,1320 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (C) 2018 Intel Corporation + +#include +#include +#include +#include +#include +#include +#include +#include + +#define IMX258_REG_VALUE_08BIT 1 +#define IMX258_REG_VALUE_16BIT 2 + +#define IMX258_REG_MODE_SELECT 0x0100 +#define IMX258_MODE_STANDBY0x00 +#define IMX258_MODE_STREAMING 0x01 + +/* Chip ID */ +#define IMX258_REG_CHIP_ID 0x0016 +#define IMX258_CHIP_ID 0x0258 + +/* V_TIMING internal */ +#define IMX258_VTS_30FPS 0x0c98 +#define IMX258_VTS_30FPS_2K0x0638 +#define IMX258_VTS_30FPS_VGA 0x034c +#define IMX258_VTS_MAX 0x + +/*Frame Length Line*/ +#define IMX258_FLL_MIN 0x08a6 +#define IMX258_FLL_MAX 0x +#define IMX258_FLL_STEP1 +#define IMX258_FLL_DEFAULT 0x0c98 + +/* HBLANK control - read only */ +#define IMX258_PPL_DEFAULT 5352 + +/* Exposure control */ +#define IMX258_REG_EXPOSURE0x0202 +#define IMX258_EXPOSURE_MIN4 +#define IMX258_EXPOSURE_STEP 1 +#define IMX258_EXPOSURE_DEFAULT0x640 +#define IMX258_EXPOSURE_MAX65535 + +/* Analog gain control */ +#define IMX258_REG_ANALOG_GAIN 0x0204 +#define IMX258_ANA_GAIN_MIN0 +#define IMX258_ANA_GAIN_MAX0x1fff +#define IMX258_ANA_GAIN_STEP 1 +#define IMX258_ANA_GAIN_DEFAULT0x0 + +/* Digital gain control */ +#define IMX258_REG_GR_DIGITAL_GAIN 0x020e +#define IMX258_REG_R_DIGITAL_GAIN 0x0210 +#define IMX258_REG_B_DIGITAL_GAIN 0x0212 +#define IMX258_REG_GB_DIGITAL_GAIN 0x0214 +#define IMX258_DGTL_GAIN_MIN 0 +#define IMX258_DGTL_GAIN_MAX 4096/* Max = 0xFFF */ +#define IMX258_DGTL_GAIN_DEFAULT 1024 +#define IMX258_DGTL_GAIN_STEP 1 + +/* Test Pattern Control */ +#define IMX258_REG_TEST_PATTERN0x0600 +#define IMX258_TEST_PATTERN_DISABLE0 +#define IMX258_TEST_PATTERN_SOLID_COLOR1 +#define IMX258_TEST_PATTERN_COLOR_BARS 2 +#define IMX258_TEST_PATTERN_GREY_COLOR 3 +#define IMX258_TEST_PATTERN_PN94 + +/* Orientation */ +#define REG_MIRROR_FLIP_CONTROL0x0101 +#define REG_CONFIG_MIRROR_FLIP 0x03 +#define REG_CONFIG_FLIP_TEST_PATTERN 0x02 + +struct imx258_reg { + u16 address;
[PATCH 0/3] dw9807 and imx258 drivers
Re-submitting with correct SoB lines. The removal of the unused retry variable has been merged to the dw9807 driver patch. Alan Chiang (2): media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil media: dw9807: Add dw9807 vcm driver Jason Chen (1): media: imx258: Add imx258 camera sensor driver .../bindings/media/i2c/dongwoon,dw9807.txt |9 + MAINTAINERS| 14 + drivers/media/i2c/Kconfig | 21 + drivers/media/i2c/Makefile |2 + drivers/media/i2c/dw9807.c | 329 + drivers/media/i2c/imx258.c | 1320 6 files changed, 1695 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt create mode 100644 drivers/media/i2c/dw9807.c create mode 100644 drivers/media/i2c/imx258.c -- 2.11.0
[PATCH 2/3] media: dw9807: Add dw9807 vcm driver
From: Alan Chiang DW9807 is a 10 bit DAC from Dongwoon, designed for linear control of voice coil motor. This driver creates a V4L2 subdevice and provides control to set the desired focus. Signed-off-by: Alan Chiang Signed-off-by: Andy Yeh Reviewed-by: Jacopo Mondi Reviewed-by: Tomasz Figa Signed-off-by: Sakari Ailus --- MAINTAINERS| 7 + drivers/media/i2c/Kconfig | 10 ++ drivers/media/i2c/Makefile | 1 + drivers/media/i2c/dw9807.c | 329 + 4 files changed, 347 insertions(+) create mode 100644 drivers/media/i2c/dw9807.c diff --git a/MAINTAINERS b/MAINTAINERS index 519f172c9267..6304b696c698 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4382,6 +4382,13 @@ T: git git://linuxtv.org/media_tree.git S: Maintained F: drivers/media/i2c/dw9714.c +DONGWOON DW9807 LENS VOICE COIL DRIVER +M: Sakari Ailus +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: drivers/media/i2c/dw9807.c + DOUBLETALK DRIVER M: "James R. Van Zandt" L: blinux-l...@redhat.com diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index b95b44702ccb..e6a721c5e3b0 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -336,6 +336,16 @@ config VIDEO_DW9714 capability. This is designed for linear control of voice coil motors, controlled via I2C serial interface. +config VIDEO_DW9807 + tristate "DW9807 lens voice coil support" + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER + depends on VIDEO_V4L2_SUBDEV_API + ---help--- + This is a driver for the DW9807 camera lens voice coil. + DW9807 is a 10 bit DAC with 100mA output current sink + capability. This is designed for linear control of + voice coil motors, controlled via I2C serial interface. + config VIDEO_SAA7110 tristate "Philips SAA7110 video decoder" depends on VIDEO_V4L2 && I2C diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index ff6e2914abda..5cf15edacb2b 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o obj-$(CONFIG_VIDEO_AD5820) += ad5820.o obj-$(CONFIG_VIDEO_DW9714) += dw9714.o +obj-$(CONFIG_VIDEO_DW9807) += dw9807.o obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o diff --git a/drivers/media/i2c/dw9807.c b/drivers/media/i2c/dw9807.c new file mode 100644 index ..6ebb98717fb1 --- /dev/null +++ b/drivers/media/i2c/dw9807.c @@ -0,0 +1,329 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (C) 2018 Intel Corporation + +#include +#include +#include +#include +#include +#include +#include +#include + +#define DW9807_MAX_FOCUS_POS 1023 +/* + * This sets the minimum granularity for the focus positions. + * A value of 1 gives maximum accuracy for a desired focus position. + */ +#define DW9807_FOCUS_STEPS 1 +/* + * This acts as the minimum granularity of lens movement. + * Keep this value power of 2, so the control steps can be + * uniformly adjusted for gradual lens movement, with desired + * number of control steps. + */ +#define DW9807_CTRL_STEPS 16 +#define DW9807_CTRL_DELAY_US 1000 + +#define DW9807_CTL_ADDR0x02 +/* + * DW9807 separates two registers to control the VCM position. + * One for MSB value, another is LSB value. + */ +#define DW9807_MSB_ADDR0x03 +#define DW9807_LSB_ADDR0x04 +#define DW9807_STATUS_ADDR 0x05 +#define DW9807_MODE_ADDR 0x06 +#define DW9807_RESONANCE_ADDR 0x07 + +#define MAX_RETRY 10 + +struct dw9807_device { + struct v4l2_ctrl_handler ctrls_vcm; + struct v4l2_subdev sd; + u16 current_val; +}; + +static inline struct dw9807_device *sd_to_dw9807_vcm( + struct v4l2_subdev *subdev) +{ + return container_of(subdev, struct dw9807_device, sd); +} + +static int dw9807_i2c_check(struct i2c_client *client) +{ + const char status_addr = DW9807_STATUS_ADDR; + char status_result; + int ret; + + ret = i2c_master_send(client, &status_addr, sizeof(status_addr)); + if (ret < 0) { + dev_err(&client->dev, "I2C write STATUS address fail ret = %d\n", + ret); + return ret; + } + + ret = i2c_master_recv(client, &status_result, sizeof(status_result)); + if (ret < 0) { + dev_err(&client->dev, "I2C read STATUS value fail ret = %d\n", + ret); + return ret; + } + + return status_result; +} + +static int dw9807_set_dac(struct i2c_client *client, u16 data) +{ + const char tx_data[3] = { + DW9807_MSB_ADDR, ((data >> 8) & 0x03), (data &
Re: [PATCH v2 1/4] media: rcar-vin: Parse digital input in mc-path
Hi Jacopo, On 2018-05-17 12:13:06 +0200, Jacopo Mondi wrote: > Hi Niklas, >thanks for review. > > On Wed, May 16, 2018 at 10:32:49PM +0200, Niklas Söderlund wrote: > > Hi Jacopo, > > > > Thanks for your work! > > > > First let me apologies for the use of the keyword 'digital' in the > > driver it should have been parallel... Someday we should remedy this. > > > > If you touch any parts of the code where such a transition make sens I > > would not complain about the intermixed use of digital/parallel. Once > > your work is done we could follow up with a cleanup patch to complete > > the transition. Or if you rather stick with digital here I'm fine with > > that too. > > I would go with a major s/digital/parallel/ after this has been > merged, if that' fine with you. I'm totally fine whit that. > > > > On 2018-05-16 14:16:53 +0200, Jacopo Mondi wrote: > > > Add support for digital input subdevices to Gen-3 rcar-vin. > > > The Gen-3, media-controller compliant, version has so far only accepted > > > CSI-2 input subdevices. Remove assumptions on the supported bus_type and > > > accepted number of subdevices, and allow digital input connections on > > > port@0. > > > > > > Signed-off-by: Jacopo Mondi > > > --- > > > drivers/media/platform/rcar-vin/rcar-core.c | 99 > > > +++-- > > > drivers/media/platform/rcar-vin/rcar-vin.h | 15 + > > > 2 files changed, 93 insertions(+), 21 deletions(-) > > > > > > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c > > > b/drivers/media/platform/rcar-vin/rcar-core.c > > > index d3072e1..0ea21ab 100644 > > > --- a/drivers/media/platform/rcar-vin/rcar-core.c > > > +++ b/drivers/media/platform/rcar-vin/rcar-core.c > > > @@ -562,7 +562,7 @@ static int rvin_digital_graph_init(struct rvin_dev > > > *vin) > > > return ret; > > > > > > if (!vin->digital) > > > - return -ENODEV; > > > + return -ENOTCONN; > > > > > > vin_dbg(vin, "Found digital subdevice %pOF\n", > > > to_of_node(vin->digital->asd.match.fwnode)); > > > @@ -703,15 +703,13 @@ static int rvin_mc_parse_of_endpoint(struct device > > > *dev, > > > { > > > struct rvin_dev *vin = dev_get_drvdata(dev); > > > > > > - if (vep->base.port != 1 || vep->base.id >= RVIN_CSI_MAX) > > > + if (vep->base.port != RVIN_PORT_CSI2 || vep->base.id >= RVIN_CSI_MAX) > > > > I don't like this RVIN_PORT_CSI2. It makes the code harder to read as I > > have have to go and lookup which port RVIN_PORT_CSI2 represents. I would > > Why do you have to go and look? It's an enum, it abstracts away the numerical > value it represents with a human readable string. If you want to check > which number it represent you can got and look at the enum definition, > once. While reading the code, the most important part is "this is the CSI-2 > port" or "this is port 1"? You wrote the driver and for you there is > no ambiguity there, I understand. > > > rater just keep vep->base.port != 1 as I think it's much clearer whats > > going on. And it's not as we will move the CSI-2 input to a different > > port as it's described in the bindings. > > That's one more reason to have an enum for that. > > Anyway, that's pure bikeshedding, I like discussing these things > too but I'm surely not making an argument for this. If you don't like > the enum I'll remove that. I'm sorry, I don't like the enum :-( > > > > > > return -EINVAL; > > > > > > if (!of_device_is_available(to_of_node(asd->match.fwnode))) { > > > - > > > vin_dbg(vin, "OF device %pOF disabled, ignoring\n", > > > to_of_node(asd->match.fwnode)); > > > return -ENOTCONN; > > > - > > > } > > > > > > if (vin->group->csi[vep->base.id].fwnode) { > > > @@ -720,6 +718,8 @@ static int rvin_mc_parse_of_endpoint(struct device > > > *dev, > > > return -ENOTCONN; > > > } > > > > > > + vin->mbus_cfg.type = V4L2_MBUS_CSI2; > > > + vin->mbus_cfg.flags = 0; > > > > I like this move of mbus_cfg handling! Makes the two cases more aligned > > which are good. Unfortunately I fear it needs more work :-( > > > > With this series addition of parallel input support. There are now two > > input types CSI-2 and parallel which can be changed at runtime for the > > same VIN. The mbus connected to the VIN will therefor be different > > Wait, are you suggesting the parallel input connection can be switched > with CSI-2 ones at runtime? I undestand the CSI-2 - VIN routing as the > physical connections are already in place in the SoC, but if we're > connecting a parallel input to a VIN instance that accepts an input > connection then that hardly can be switched to another port with a > software configuration. Sure it can. Check 'Figure 26.2.1 Functional Block Diagram of Video Input Modules 4 to 7 (VIN4 to VIN7) (R-Car H3, M3-W)'. Here VIN4 and VIN5 can have both a parallel input and a CSI-2 input. In the block diagram the "CSI or Digial Pin" is the VNMC_DPINE register and the "CS
Re: [PATCH] v4l: Add support for STD ioctls on subdev nodes
Hi Hans, Thanks for your feedback. On 2018-05-17 10:04:35 +0200, Hans Verkuil wrote: > On 17/05/18 04:00, Niklas Söderlund wrote: > > Missing commit log. I checked other commits doing the same thing, they had no commit log and that was enough reason for me to be lazy. Will fix in v2. And thanks for forcing me to improve :-) > > > Signed-off-by: Niklas Söderlund > > --- > > Documentation/media/uapi/v4l/vidioc-g-std.rst| 14 ++ > > Documentation/media/uapi/v4l/vidioc-querystd.rst | 11 +++ > > What about ENUMSTD? I did check about the possibility to add support for ENUMSTD. When digging around I got the feeling ENUMSTD was a videodev specific ioctl. As you bring it up here I assume that is not the case, I will see if I can add it for v2. > > Regards, > > Hans > > > drivers/media/v4l2-core/v4l2-subdev.c| 12 > > include/uapi/linux/v4l2-subdev.h | 3 +++ > > 4 files changed, 32 insertions(+), 8 deletions(-) > > > > --- > > > > Hi Hans, > > > > I have tested this on Renesas Gen3 Salvator-XS M3-N using the AFE > > subdevice from the adv748x driver together with the R-Car VIN and CSI-2 > > pipeline. > > > > I wrote a prototype patch for v4l2-ctl which adds three new options > > (--get-subdev-standard, --set-subdev-standard and > > --get-subdev-detected-standard) to ease testing which I plan to submit > > after some cleanup if this patch receives positive feedback. > > > > If you or anyone else is interested in testing this patch the v4l2-utils > > prototype patches are available at > > > > git://git.ragnatech.se/v4l-utils#subdev-std > > > > Regards, > > // Niklas > > > > diff --git a/Documentation/media/uapi/v4l/vidioc-g-std.rst > > b/Documentation/media/uapi/v4l/vidioc-g-std.rst > > index 90791ab51a5371b8..8d94f0404df270db 100644 > > --- a/Documentation/media/uapi/v4l/vidioc-g-std.rst > > +++ b/Documentation/media/uapi/v4l/vidioc-g-std.rst > > @@ -2,14 +2,14 @@ > > > > .. _VIDIOC_G_STD: > > > > - > > -ioctl VIDIOC_G_STD, VIDIOC_S_STD > > - > > +** > > +ioctl VIDIOC_G_STD, VIDIOC_S_STD, VIDIOC_SUBDEV_G_STD, VIDIOC_SUBDEV_S_STD > > +** > > > > Name > > > > > > -VIDIOC_G_STD - VIDIOC_S_STD - Query or select the video standard of the > > current input > > +VIDIOC_G_STD - VIDIOC_S_STD - VIDIOC_SUBDEV_G_STD - VIDIOC_SUBDEV_S_STD - > > Query or select the video standard of the current input > > > > > > Synopsis > > @@ -21,6 +21,12 @@ Synopsis > > .. c:function:: int ioctl( int fd, VIDIOC_S_STD, const v4l2_std_id *argp ) > > :name: VIDIOC_S_STD > > > > +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_G_STD, v4l2_std_id *argp ) > > +:name: VIDIOC_SUBDEV_G_STD > > + > > +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_S_STD, const v4l2_std_id > > *argp ) > > +:name: VIDIOC_SUBDEV_S_STD > > + > > > > Arguments > > = > > diff --git a/Documentation/media/uapi/v4l/vidioc-querystd.rst > > b/Documentation/media/uapi/v4l/vidioc-querystd.rst > > index cf40bca19b9f8665..a8385cc7481869dd 100644 > > --- a/Documentation/media/uapi/v4l/vidioc-querystd.rst > > +++ b/Documentation/media/uapi/v4l/vidioc-querystd.rst > > @@ -2,14 +2,14 @@ > > > > .. _VIDIOC_QUERYSTD: > > > > -* > > -ioctl VIDIOC_QUERYSTD > > -* > > +* > > +ioctl VIDIOC_QUERYSTD, VIDIOC_SUBDEV_QUERYSTD > > +* > > > > Name > > > > > > -VIDIOC_QUERYSTD - Sense the video standard received by the current input > > +VIDIOC_QUERYSTD - VIDIOC_SUBDEV_QUERYSTD - Sense the video standard > > received by the current input > > > > > > Synopsis > > @@ -18,6 +18,9 @@ Synopsis > > .. c:function:: int ioctl( int fd, VIDIOC_QUERYSTD, v4l2_std_id *argp ) > > :name: VIDIOC_QUERYSTD > > > > +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_QUERYSTD, v4l2_std_id > > *argp ) > > +:name: VIDIOC_SUBDEV_QUERYSTD > > + > > > > Arguments > > = > > diff --git a/drivers/media/v4l2-core/v4l2-subdev.c > > b/drivers/media/v4l2-core/v4l2-subdev.c > > index f9eed938d3480b74..a156b1812e923721 100644 > > --- a/drivers/media/v4l2-core/v4l2-subdev.c > > +++ b/drivers/media/v4l2-core/v4l2-subdev.c > > @@ -494,6 +494,18 @@ static long subdev_do_ioctl(struct file *file, > > unsigned int cmd, void *arg) > > > > case VIDIOC_SUBDEV_S_DV_TIMINGS: > > return v4l2_subdev_call(sd, video, s_dv_timings, arg); > > + > > + case VIDIOC_SUBDEV_G_STD: > > + return v4l2_subdev_call(sd, video, g_std, arg); > > + > > + case VIDIOC_SUBDEV_S_STD: { > > + v4l2_std_id *std = arg; > > + > > + return v4l2_subdev_call(sd, video, s_std, *std); > >
Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements
Hi, On Thu, May 17, 2018 at 11:24:04AM +0200, Daniel Mack wrote: > Hi, > > On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote: > > Here is a "small" series that mostly cleans up the ov5640 driver code, > > slowly getting rid of the big data array for more understandable code > > (hopefully). > > > > The biggest addition would be the clock rate computation at runtime, > > instead of relying on those arrays to setup the clock tree > > properly. As a side effect, it fixes the framerate that was off by > > around 10% on the smaller resolutions, and we now support 60fps. > > > > This also introduces a bunch of new features. > > I'd like to give this a try. What tree should this patch set be applied on? > I had no luck with media_tree/for-4.18-6. Maybe it wasn't the latest after all, sorry. It's based on Sakari's for-4.18-3 PR (67f76c65e94f). Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements
On Thu, May 17, 2018 at 01:22:07PM +0200, Maxime Ripard wrote: > Hi, > > On Thu, May 17, 2018 at 11:24:04AM +0200, Daniel Mack wrote: > > Hi, > > > > On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote: > > > Here is a "small" series that mostly cleans up the ov5640 driver code, > > > slowly getting rid of the big data array for more understandable code > > > (hopefully). > > > > > > The biggest addition would be the clock rate computation at runtime, > > > instead of relying on those arrays to setup the clock tree > > > properly. As a side effect, it fixes the framerate that was off by > > > around 10% on the smaller resolutions, and we now support 60fps. > > > > > > This also introduces a bunch of new features. > > > > I'd like to give this a try. What tree should this patch set be applied on? > > I had no luck with media_tree/for-4.18-6. > > Maybe it wasn't the latest after all, sorry. It's based on Sakari's > for-4.18-3 PR (67f76c65e94f). I've pushed these here: https://git.linuxtv.org/sailus/media_tree.git/log/?h=for-4.18-5> -- Sakari Ailus e-mail: sakari.ai...@iki.fi
[PATCH 0/4] Venus updates - PIL
Hello, The patch set mainly adds PIL functionality in video driver. There are boards with qcom video hardware but does not have trustzone. For such boards, the PIL added now will load the video firmware and reset the ARM9. The patch set is based on top of recent venus updates v2 patches posted by Stanimir Varbanov. Comments are welcome! regards, Vikash Vikash Garodia (4): soc: qcom: mdt_loader: Add check to make scm calls media: venus: add a routine to reset ARM9 venus: add check to make scm calls media: venus: add PIL support .../devicetree/bindings/media/qcom,venus.txt | 8 +- drivers/media/platform/qcom/venus/core.c | 67 +++- drivers/media/platform/qcom/venus/core.h | 6 + drivers/media/platform/qcom/venus/firmware.c | 189 ++--- drivers/media/platform/qcom/venus/firmware.h | 11 +- drivers/media/platform/qcom/venus/hfi_venus.c | 26 ++- drivers/media/platform/qcom/venus/hfi_venus_io.h | 5 + drivers/soc/qcom/mdt_loader.c | 21 ++- 8 files changed, 281 insertions(+), 52 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 2/4] media: venus: add a routine to reset ARM9
Add a new routine to reset the ARM9 and brings it out of reset. This is in preparation to add PIL functionality in venus driver. Signed-off-by: Vikash Garodia --- drivers/media/platform/qcom/venus/firmware.c | 26 drivers/media/platform/qcom/venus/firmware.h | 1 + drivers/media/platform/qcom/venus/hfi_venus_io.h | 5 + 3 files changed, 32 insertions(+) diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c index c4a5778..8f25375 100644 --- a/drivers/media/platform/qcom/venus/firmware.c +++ b/drivers/media/platform/qcom/venus/firmware.c @@ -14,6 +14,7 @@ #include #include +#include #include #include #include @@ -22,11 +23,36 @@ #include #include +#include "core.h" #include "firmware.h" +#include "hfi_venus_io.h" #define VENUS_PAS_ID 9 #define VENUS_FW_MEM_SIZE (6 * SZ_1M) +void venus_reset_hw(struct venus_core *core) +{ + void __iomem *reg_base = core->base; + + writel(0, reg_base + WRAPPER_FW_START_ADDR); + writel(VENUS_FW_MEM_SIZE, reg_base + WRAPPER_FW_END_ADDR); + writel(0, reg_base + WRAPPER_CPA_START_ADDR); + writel(VENUS_FW_MEM_SIZE, reg_base + WRAPPER_CPA_END_ADDR); + writel(0x0, reg_base + WRAPPER_CPU_CGC_DIS); + writel(0x0, reg_base + WRAPPER_CPU_CLOCK_CONFIG); + + /* Make sure all register writes are committed. */ + mb(); + + /* +* Need to wait 10 cycles of internal clocks before bringing ARM9 +* out of reset. +*/ + udelay(1); + + /* Bring Arm9 out of reset */ + writel_relaxed(0, reg_base + WRAPPER_A9SS_SW_RESET); +} int venus_boot(struct device *dev, const char *fwname) { const struct firmware *mdt; diff --git a/drivers/media/platform/qcom/venus/firmware.h b/drivers/media/platform/qcom/venus/firmware.h index 428efb5..d56f5b2 100644 --- a/drivers/media/platform/qcom/venus/firmware.h +++ b/drivers/media/platform/qcom/venus/firmware.h @@ -18,5 +18,6 @@ int venus_boot(struct device *dev, const char *fwname); int venus_shutdown(struct device *dev); +void venus_reset_hw(struct venus_core *core); #endif diff --git a/drivers/media/platform/qcom/venus/hfi_venus_io.h b/drivers/media/platform/qcom/venus/hfi_venus_io.h index 76f4793..39afa5d 100644 --- a/drivers/media/platform/qcom/venus/hfi_venus_io.h +++ b/drivers/media/platform/qcom/venus/hfi_venus_io.h @@ -109,6 +109,11 @@ #define WRAPPER_CPU_CGC_DIS(WRAPPER_BASE + 0x2010) #define WRAPPER_CPU_STATUS (WRAPPER_BASE + 0x2014) #define WRAPPER_SW_RESET (WRAPPER_BASE + 0x3000) +#define WRAPPER_CPA_START_ADDR (WRAPPER_BASE + 0x1020) +#define WRAPPER_CPA_END_ADDR (WRAPPER_BASE + 0x1024) +#define WRAPPER_FW_START_ADDR (WRAPPER_BASE + 0x1028) +#define WRAPPER_FW_END_ADDR(WRAPPER_BASE + 0x102C) +#define WRAPPER_A9SS_SW_RESET (WRAPPER_BASE + 0x3000) /* Venus 4xx */ #define WRAPPER_VCODEC0_MMCC_POWER_STATUS (WRAPPER_BASE + 0x90) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 3/4] venus: add check to make scm calls
In order to invoke scm calls, ensure that the platform has the required support to invoke the scm calls in secure world. This code is in preparation to add PIL functionality in venus driver. Signed-off-by: Vikash Garodia --- drivers/media/platform/qcom/venus/hfi_venus.c | 26 +++--- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c index f61d34b..9bcce94 100644 --- a/drivers/media/platform/qcom/venus/hfi_venus.c +++ b/drivers/media/platform/qcom/venus/hfi_venus.c @@ -27,6 +27,7 @@ #include "hfi_msgs.h" #include "hfi_venus.h" #include "hfi_venus_io.h" +#include "firmware.h" #define HFI_MASK_QHDR_TX_TYPE 0xff00 #define HFI_MASK_QHDR_RX_TYPE 0x00ff @@ -570,13 +571,19 @@ static int venus_halt_axi(struct venus_hfi_device *hdev) static int venus_power_off(struct venus_hfi_device *hdev) { int ret; + void __iomem *reg_base; if (!hdev->power_enabled) return 0; - ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0); - if (ret) - return ret; + if (qcom_scm_is_available()) { + ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0); + if (ret) + return ret; + } else { + reg_base = hdev->core->base; + writel_relaxed(1, reg_base + WRAPPER_A9SS_SW_RESET); + } ret = venus_halt_axi(hdev); if (ret) @@ -594,9 +601,13 @@ static int venus_power_on(struct venus_hfi_device *hdev) if (hdev->power_enabled) return 0; - ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_RESUME, 0); - if (ret) - goto err; + if (qcom_scm_is_available()) { + ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_RESUME, 0); + if (ret) + goto err; + } else { + venus_reset_hw(hdev->core); + } ret = venus_run(hdev); if (ret) @@ -607,7 +618,8 @@ static int venus_power_on(struct venus_hfi_device *hdev) return 0; err_suspend: - qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0); + if (qcom_scm_is_available()) + qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0); err: hdev->power_enabled = false; return ret; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 1/4] soc: qcom: mdt_loader: Add check to make scm calls
In order to invoke scm calls, ensure that the platform has the required support to invoke the scm calls in secure world. Signed-off-by: Vikash Garodia --- drivers/soc/qcom/mdt_loader.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c index 17b314d..db55d53 100644 --- a/drivers/soc/qcom/mdt_loader.c +++ b/drivers/soc/qcom/mdt_loader.c @@ -121,10 +121,12 @@ int qcom_mdt_load(struct device *dev, const struct firmware *fw, if (!fw_name) return -ENOMEM; - ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size); - if (ret) { - dev_err(dev, "invalid firmware metadata\n"); - goto out; + if (qcom_scm_is_available()) { + ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size); + if (ret) { + dev_err(dev, "invalid firmware metadata\n"); + goto out; + } } for (i = 0; i < ehdr->e_phnum; i++) { @@ -144,10 +146,13 @@ int qcom_mdt_load(struct device *dev, const struct firmware *fw, } if (relocate) { - ret = qcom_scm_pas_mem_setup(pas_id, mem_phys, max_addr - min_addr); - if (ret) { - dev_err(dev, "unable to setup relocation\n"); - goto out; + if (qcom_scm_is_available()) { + ret = qcom_scm_pas_mem_setup(pas_id, mem_phys, + max_addr - min_addr); + if (ret) { + dev_err(dev, "unable to setup relocation\n"); + goto out; + } } /* -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 4/4] media: venus: add PIL support
This adds support to load the video firmware and bring ARM9 out of reset. This is useful for platforms which does not have trustzone to reset the ARM9. Signed-off-by: Vikash Garodia --- .../devicetree/bindings/media/qcom,venus.txt | 8 +- drivers/media/platform/qcom/venus/core.c | 67 +++-- drivers/media/platform/qcom/venus/core.h | 6 + drivers/media/platform/qcom/venus/firmware.c | 163 + drivers/media/platform/qcom/venus/firmware.h | 10 +- 5 files changed, 217 insertions(+), 37 deletions(-) diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt index 00d0d1b..0ff0f2d 100644 --- a/Documentation/devicetree/bindings/media/qcom,venus.txt +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt @@ -53,7 +53,7 @@ * Subnodes The Venus video-codec node must contain two subnodes representing -video-decoder and video-encoder. +video-decoder and video-encoder, one optional firmware subnode. Every of video-encoder or video-decoder subnode should have: @@ -79,6 +79,8 @@ Every of video-encoder or video-decoder subnode should have: power domain which is responsible for collapsing and restoring power to the subcore. +The firmware sub node must contain the iommus specifiers for ARM9. + * An Example video-codec@1d0 { compatible = "qcom,msm8916-venus"; @@ -105,4 +107,8 @@ Every of video-encoder or video-decoder subnode should have: clock-names = "core"; power-domains = <&mmcc VENUS_CORE1_GDSC>; }; + firmware { + compatible = "qcom,venus-pil-no-tz"; + iommus = <&apps_smmu 0x10b2 0x0>; + } }; diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c index 1308488..16910558 100644 --- a/drivers/media/platform/qcom/venus/core.c +++ b/drivers/media/platform/qcom/venus/core.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include @@ -30,6 +31,7 @@ #include "vdec.h" #include "venc.h" #include "firmware.h" +#include "hfi_venus.h" static void venus_event_notify(struct venus_core *core, u32 event) { @@ -76,7 +78,7 @@ static void venus_sys_error_handler(struct work_struct *work) hfi_core_deinit(core, true); hfi_destroy(core); mutex_lock(&core->lock); - venus_shutdown(core->dev); + venus_shutdown(core); pm_runtime_put_sync(core->dev); @@ -84,7 +86,7 @@ static void venus_sys_error_handler(struct work_struct *work) pm_runtime_get_sync(core->dev); - ret |= venus_boot(core->dev, core->res->fwname); + ret |= venus_boot(core); ret |= hfi_core_resume(core, true); @@ -179,6 +181,20 @@ static u32 to_v4l2_codec_type(u32 codec) } } +static int store_firmware_dev(struct device *dev, void *data) +{ + struct venus_core *core; + + core = (struct venus_core *)data; + if (!core) + return -EINVAL; + + if (of_device_is_compatible(dev->of_node, "qcom,venus-pil-no-tz")) + core->fw.dev = dev; + + return 0; +} + static int venus_enumerate_codecs(struct venus_core *core, u32 type) { const struct hfi_inst_ops dummy_ops = {}; @@ -229,6 +245,7 @@ static int venus_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; struct venus_core *core; struct resource *r; + struct iommu_domain *iommu_domain; int ret; core = devm_kzalloc(dev, sizeof(*core), GFP_KERNEL); @@ -279,7 +296,14 @@ static int venus_probe(struct platform_device *pdev) if (ret < 0) goto err_runtime_disable; - ret = venus_boot(dev, core->res->fwname); + ret = of_platform_populate(dev->of_node, NULL, NULL, dev); + if (ret) + goto err_runtime_disable; + + /* Attempt to register child devices */ + ret = device_for_each_child(dev, core, store_firmware_dev); + + ret = venus_boot(core); if (ret) goto err_runtime_disable; @@ -303,14 +327,17 @@ static int venus_probe(struct platform_device *pdev) if (ret) goto err_core_deinit; - ret = of_platform_populate(dev->of_node, NULL, NULL, dev); + ret = pm_runtime_put_sync(dev); if (ret) goto err_dev_unregister; - ret = pm_runtime_put_sync(dev); - if (ret) + iommu_domain = iommu_get_domain_for_dev(dev); + if (!iommu_domain) goto err_dev_unregister; + iommu_domain->geometry.aperture_start = VENUS_FW_MEM_SIZE; + iommu_domain->geometry.aperture_end = VENUS_MAX_MEM_REGION; + return 0; err_dev_unregister: @@ -318,7 +345,7 @@ static int venus_probe(struct platform_device *pd
Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1
Em Thu, 17 May 2018 05:36:03 -0500 "Gustavo A. R. Silva" escreveu: > > > On 05/16/2018 08:14 PM, Gustavo A. R. Silva wrote: > > > > > > On 05/15/2018 02:39 PM, Dan Carpenter wrote: > >> You'd need to rebuild the db (possibly twice but definitely once). How? Here, I just pull from your git tree and do a "make". At most, make clean; make. > >> > > > > Hi Dan, > > > > After rebuilding the db (once), these are all the Spectre media warnings > > I get: > > > > drivers/media/pci/ddbridge/ddbridge-core.c:233 ddb_redirect() warn: > > potential spectre issue 'ddbs' > > drivers/media/pci/ddbridge/ddbridge-core.c:243 ddb_redirect() warn: > > potential spectre issue 'pdev->port' > > drivers/media/pci/ddbridge/ddbridge-core.c:252 ddb_redirect() warn: > > potential spectre issue 'idev->input' > > drivers/media/dvb-core/dvb_ca_en50221.c:1400 > > dvb_ca_en50221_io_do_ioctl() warn: potential spectre issue > > 'ca->slot_info' (local cap) > > drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() > > warn: potential spectre issue 'ca->slot_info' (local cap) > > drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: > > potential spectre issue 'p->ule_next_hdr' > > drivers/media/dvb-core/dvb_net.c:1483 dvb_net_do_ioctl() warn: potential > > spectre issue 'dvbnet->device' (local cap) > > drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() > > warn: potential spectre issue 'pin->error_inj_args' > > > > I just want to double check if you are getting the same output. In case > > you are getting the same, then what Mauro commented about these issues: > > > > https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7277 > > > > being resolved by commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 seems > > to be correct. > > > > Interesting, I've rebuild the db twice and now I get a total of 75 > Spectre warnings in drivers/media That makes more sense to me, as the same pattern is used by almost all VIDIOC_ENUM_foo ioctls. Thanks, Mauro
Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1
Em Thu, 17 May 2018 08:34:40 -0300 Mauro Carvalho Chehab escreveu: > Em Thu, 17 May 2018 05:36:03 -0500 > "Gustavo A. R. Silva" escreveu: > > > > > > > On 05/16/2018 08:14 PM, Gustavo A. R. Silva wrote: > > > > > > > > > On 05/15/2018 02:39 PM, Dan Carpenter wrote: > > > >> You'd need to rebuild the db (possibly twice but definitely once). > > How? Here, I just pull from your git tree and do a "make". At most, > make clean; make. Never mind. Found it using grep. I'm running this: make allyesconfig /devel/smatch/smatch_scripts/build_kernel_data.sh /devel/smatch/smatch_scripts/build_kernel_data.sh > > > >> > > > > > > Hi Dan, > > > > > > After rebuilding the db (once), these are all the Spectre media warnings > > > I get: > > > > > > drivers/media/pci/ddbridge/ddbridge-core.c:233 ddb_redirect() warn: > > > potential spectre issue 'ddbs' > > > drivers/media/pci/ddbridge/ddbridge-core.c:243 ddb_redirect() warn: > > > potential spectre issue 'pdev->port' > > > drivers/media/pci/ddbridge/ddbridge-core.c:252 ddb_redirect() warn: > > > potential spectre issue 'idev->input' > > > drivers/media/dvb-core/dvb_ca_en50221.c:1400 > > > dvb_ca_en50221_io_do_ioctl() warn: potential spectre issue > > > 'ca->slot_info' (local cap) > > > drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() > > > warn: potential spectre issue 'ca->slot_info' (local cap) > > > drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: > > > potential spectre issue 'p->ule_next_hdr' > > > drivers/media/dvb-core/dvb_net.c:1483 dvb_net_do_ioctl() warn: potential > > > spectre issue 'dvbnet->device' (local cap) > > > drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() > > > warn: potential spectre issue 'pin->error_inj_args' > > > > > > I just want to double check if you are getting the same output. In case > > > you are getting the same, then what Mauro commented about these issues: > > > > > > https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7277 > > > > > > being resolved by commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 seems > > > to be correct. > > > > > > > Interesting, I've rebuild the db twice and now I get a total of 75 > > Spectre warnings in drivers/media > > That makes more sense to me, as the same pattern is used by almost all > VIDIOC_ENUM_foo ioctls. > > Thanks, > Mauro Thanks, Mauro
Re: [PATCH v3 1/2] media: rc: introduce BPF_PROG_RAWIR_EVENT
2018-05-16 22:04 UTC+0100 ~ Sean Young > Add support for BPF_PROG_RAWIR_EVENT. This type of BPF program can call > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report > that the last key should be repeated. > > The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall; > the target_fd must be the /dev/lircN device. > > Signed-off-by: Sean Young > --- > drivers/media/rc/Kconfig | 13 ++ > drivers/media/rc/Makefile | 1 + > drivers/media/rc/bpf-rawir-event.c | 363 + > drivers/media/rc/lirc_dev.c| 24 ++ > drivers/media/rc/rc-core-priv.h| 24 ++ > drivers/media/rc/rc-ir-raw.c | 14 +- > include/linux/bpf_rcdev.h | 30 +++ > include/linux/bpf_types.h | 3 + > include/uapi/linux/bpf.h | 55 - > kernel/bpf/syscall.c | 7 + > 10 files changed, 531 insertions(+), 3 deletions(-) > create mode 100644 drivers/media/rc/bpf-rawir-event.c > create mode 100644 include/linux/bpf_rcdev.h > [...] Hi Sean, Please find below some nitpicks on the documentation for the two helpers. > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > index d94d333a8225..243e141e8a5b 100644 > --- a/include/uapi/linux/bpf.h > +++ b/include/uapi/linux/bpf.h [...] > @@ -1902,6 +1904,35 @@ union bpf_attr { > * egress otherwise). This is the only flag supported for now. > * Return > * **SK_PASS** on success, or **SK_DROP** on error. > + * > + * int bpf_rc_keydown(void *ctx, u32 protocol, u32 scancode, u32 toggle) > + * Description > + * Report decoded scancode with toggle value. For use in > + * BPF_PROG_TYPE_RAWIR_EVENT, to report a successfully Could you please use bold RST markup for constants and function names? Typically for BPF_PROG_TYPE_RAWIR_EVENT here and the enum below. > + * decoded scancode. This is will generate a keydown event, s/This is will/This will/? > + * and a keyup event once the scancode is no longer repeated. > + * > + * *ctx* pointer to bpf_rawir_event, *protocol* is decoded > + * protocol (see RC_PROTO_* enum). This documentation is intended to be compiled as a man page. Could you please use a complete sentence here? Also, this could do with additional markup as well: **struct bpf_rawir_event**. > + * > + * Some protocols include a toggle bit, in case the button > + * was released and pressed again between consecutive scancodes, > + * copy this bit into *toggle* if it exists, else set to 0. > + * > + * Return The "Return" lines here and in the second helper use space indent instead as tabs (as all other lines do). Would you mind fixing it for consistency? > + * Always return 0 (for now) Other helpers use just "0" in that case, but I do not really mind. Out of curiosity, do you have anything specific in mind for changing the return value here in the future? > + * > + * int bpf_rc_repeat(void *ctx) > + * Description > + * Repeat the last decoded scancode; some IR protocols like > + * NEC have a special IR message for repeat last button, s/repeat/repeating/? > + * in case user is holding a button down; the scancode is > + * not repeated. > + * > + * *ctx* pointer to bpf_rawir_event. Please use a complete sentence here as well, if you do not mind. > + * > + * Return > + * Always return 0 (for now) > */ Thanks, Quentin
Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1
Em Thu, 17 May 2018 08:43:24 -0300 Mauro Carvalho Chehab escreveu: > > > > On 05/15/2018 02:39 PM, Dan Carpenter wrote: > > > > > >> You'd need to rebuild the db (possibly twice but definitely once). > > > > How? Here, I just pull from your git tree and do a "make". At most, > > make clean; make. > > Never mind. Found it using grep. I'm running this: > > make allyesconfig > /devel/smatch/smatch_scripts/build_kernel_data.sh > /devel/smatch/smatch_scripts/build_kernel_data.sh It seems that something is broken... getting this error/warning: DBD::SQLite::db do failed: unrecognized token: "'end + strlen(" " at /devel/smatch/smatch_scripts/../smatch_data/db/fill_db_sql.pl line 32, line 2938054. Thanks, Mauro
[PATCH v4 00/12] media: staging/imx7: add i.MX7 media driver
Hi, This series introduces the Media driver to work with the i.MX7 SoC. it uses the already existing imx media core drivers but since the i.MX7, contrary to i.MX5/6, do not have an IPU and because of that some changes in the imx media core are made along this series to make it support that case. This patches adds CSI and MIPI-CSI2 drivers for i.MX7, along with several configurations changes for this to work as a capture subsystem. Some bugs are also fixed along the line. And necessary documentation. For a more detailed view of the capture paths, pads links in the i.MX7 please take a look at the documentation in PATCH 14. The system used to test and develop this was the Warp7 board with an OV2680 sensor, which output format is 10-bit bayer. So, only MIPI interface was tested, a scenario with an parallel input would nice to have. *Important note*, this code depends on Steve Longerbeam series [0]: [PATCH v4 00/13] media: imx: Switch to subdev notifiers which the merging status is not clear to me, but the changes in there make senses to this series Bellow goes an example of the output of the pads and links and the output of v4l2-compliance testing. The v4l-utils version used is: v4l2-compliance SHA : 47d43b130dc6e9e0edc900759fb37649208371e4 from Apr 4th. The Media Driver fail some tests but this failures are coming from code out of scope of this series (video-mux, imx-capture), and some from the sensor OV2680 but that I think not related with the sensor driver but with the testing and core. The csi and mipi-csi entities pass all compliance tests. Cheers, Rui [0]: https://www.mail-archive.com/linux-media@vger.kernel.org/msg131186.html v3->v4: Philipp Zabel: - refactor initialization code from media device probe to be possible to used from other modules - Remove index of csi from all accurrencs (dts, code, documentation) - Remove need for capture node for imx7 - fix pinctrl for ov2680 - add reviewed tag to add multiplexer controls patch Fabio Estevam: - remove always on from new regulator Randy Dunlap: - several text editing fixes in documentation Myself: - rebase on top of v4 of Steve series - change CSI probe to initialize imx media device - remove csi mux parallel endpoint from mux to avoid warning message v2->v3: Philipp Zabel: - use of_match_device in imx-media-dev instead of of_device_match - fix number of data lanes from 4 to 2 - change the clock definitions and use of mipi - move hs-settle from endpoint Rob Herring: - fix phy-supply description - add vendor properties - fix examples indentations Stephen Boyd: patch 3/14 - fix double sign-off - add fixes tag Dong Aisheng: patch 3/14 - fix double sign-off - add Acked-by tag Shawn Guo: patch 4/14 - remove line breakage in parent redifiniton - added Acked-by tag - dropped CMA area increase and add more verbose information in case of dma allocation failure patch 9/14 - remove extra line between cells and reg masks Myself: - rework on frame end in csi - add rxcount in csi driver - add power supplies to ov2680 node and fix gpio polarity v1->v2: Dan Carpenter: - fix return paths and codes; - fix clk_frequency validation and return code; - handle the csi remove (release resources that was missing) - revert the logic arround the ipu_present flag Philipp Zabel: - drop patch that changed the rgb formats and address the pixel/bus format in mipi_csis code. MySelf: - add patch that add ov2680 node to the warp7 dts, so the all data path is complete. - add linux-clk mailing list to the clock patches cc: media-ctl -p Media controller API version 4.17.0 Media device information driver imx-media model imx-media serial bus info hw revision 0x0 driver version 4.17.0 Device topology - entity 1: csi (2 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 pad0: Sink [fmt:SBGGR10_1X10/800x600 field:none] <- "csi_mux":2 [ENABLED] pad1: Source [fmt:SBGGR10_1X10/800x600 field:none] -> "csi capture":0 [ENABLED] - entity 4: csi capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: Sink <- "csi":1 [ENABLED] - entity 10: csi_mux (3 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Sink [fmt:unknown/0x0] pad1: Sink [fmt:SBGGR10_1X10/800x600 field:none] <- "imx7-mipi-csis.0":1 [ENABLED] pad2: Source [fmt:SBGGR10_1X10/800x600 field:none] -> "csi":0 [ENABLED] - entity 14: imx7-mipi-csis.0 (2 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:SBGGR10_1X10/800x600 fi
[PATCH v4 01/12] media: staging/imx: refactor imx media device probe
Refactor and move media device initialization code to a new common module, so it can be used by other devices, this will allow for example a near to introduce imx7 CSI driver, to use this media device. Also introduce a new flag to control the presence of IPU or not (imx6/5 has this but imx7 does not). Signed-off-by: Rui Miguel Silva --- drivers/staging/media/imx/Makefile| 1 + .../staging/media/imx/imx-media-dev-common.c | 102 ++ drivers/staging/media/imx/imx-media-dev.c | 89 --- .../staging/media/imx/imx-media-internal-sd.c | 3 + drivers/staging/media/imx/imx-media-of.c | 6 +- drivers/staging/media/imx/imx-media.h | 18 6 files changed, 150 insertions(+), 69 deletions(-) create mode 100644 drivers/staging/media/imx/imx-media-dev-common.c diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile index 698a4210316e..a30b3033f9a3 100644 --- a/drivers/staging/media/imx/Makefile +++ b/drivers/staging/media/imx/Makefile @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o +imx-media-objs += imx-media-dev-common.o imx-media-common-objs := imx-media-utils.o imx-media-fim.o imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o diff --git a/drivers/staging/media/imx/imx-media-dev-common.c b/drivers/staging/media/imx/imx-media-dev-common.c new file mode 100644 index ..7e9613ca5b5f --- /dev/null +++ b/drivers/staging/media/imx/imx-media-dev-common.c @@ -0,0 +1,102 @@ +// SPDX-License-Identifier: GPL +/* + * V4L2 Media Controller Driver for Freescale common i.MX5/6/7 SOC + * + * Copyright (c) 2018 Linaro Ltd + * Copyright (c) 2016 Mentor Graphics Inc. + */ + +#include +#include +#include "imx-media.h" + +static const struct v4l2_async_notifier_operations imx_media_subdev_ops = { + .bound = imx_media_subdev_bound, + .complete = imx_media_probe_complete, +}; + +static const struct media_device_ops imx_media_md_ops = { + .link_notify = imx_media_link_notify, +}; + +struct imx_media_dev *imx_media_dev_init(struct device *dev, bool ipu_present) +{ + struct imx_media_dev *imxmd; + int ret; + + imxmd = devm_kzalloc(dev, sizeof(*imxmd), GFP_KERNEL); + if (!imxmd) + return ERR_PTR(-ENOMEM); + + dev_set_drvdata(dev, imxmd); + + strlcpy(imxmd->md.model, "imx-media", sizeof(imxmd->md.model)); + imxmd->md.ops = &imx_media_md_ops; + imxmd->md.dev = dev; + + imxmd->ipu_present = ipu_present; + + mutex_init(&imxmd->mutex); + + imxmd->v4l2_dev.mdev = &imxmd->md; + strlcpy(imxmd->v4l2_dev.name, "imx-media", + sizeof(imxmd->v4l2_dev.name)); + + media_device_init(&imxmd->md); + + ret = v4l2_device_register(dev, &imxmd->v4l2_dev); + if (ret < 0) { + v4l2_err(&imxmd->v4l2_dev, +"Failed to register v4l2_device: %d\n", ret); + goto cleanup; + } + + dev_set_drvdata(imxmd->v4l2_dev.dev, imxmd); + + INIT_LIST_HEAD(&imxmd->vdev_list); + + return imxmd; + +cleanup: + media_device_cleanup(&imxmd->md); + + return ERR_PTR(ret); +} +EXPORT_SYMBOL_GPL(imx_media_dev_init); + +int imx_media_dev_notifier_register(struct imx_media_dev *imxmd) +{ + int ret; + + /* no subdevs? just bail */ + if (imxmd->notifier.num_subdevs == 0) { + v4l2_err(&imxmd->v4l2_dev, "no subdevs\n"); + return -ENODEV; + } + + /* prepare the async subdev notifier and register it */ + imxmd->notifier.ops = &imx_media_subdev_ops; + ret = v4l2_async_notifier_register(&imxmd->v4l2_dev, + &imxmd->notifier); + if (ret) { + v4l2_err(&imxmd->v4l2_dev, +"v4l2_async_notifier_register failed with %d\n", ret); + return ret; + } + + return 0; +} +EXPORT_SYMBOL_GPL(imx_media_dev_notifier_register); + +void imx_media_dev_cleanup(struct imx_media_dev *imxmd) +{ + v4l2_device_unregister(&imxmd->v4l2_dev); + media_device_cleanup(&imxmd->md); +} +EXPORT_SYMBOL_GPL(imx_media_dev_cleanup); + +void imx_media_dev_notifier_unregister(struct imx_media_dev *imxmd) +{ + v4l2_async_notifier_cleanup(&imxmd->notifier); +} +EXPORT_SYMBOL_GPL(imx_media_dev_notifier_unregister); diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c index 7e7bd1c6c81b..6160070b72fb 100644 --- a/drivers/staging/media/imx/imx-media-dev.c +++ b/drivers/staging/media/imx/imx-media-dev.c @@ -87,6 +87,9 @@ static int imx_media_get_ipu(struct imx_media_dev *imxmd, struct ipu_soc *ipu; int ipu_id; + if (!imxmd->ipu_present) + return 0; + ipu = dev_get_drvdata(csi_sd->dev->parent); if (!ipu) { v4l2_err
[PATCH v4 10/12] ARM: dts: imx7s-warp: add ov2680 sensor node
Warp7 comes with a Omnivision OV2680 sensor, add the node here to make complete the camera data path for this system. Add the needed regulator to the analog voltage supply, the port and endpoints in mipi_csi node and the pinctrl for the reset gpio. Signed-off-by: Rui Miguel Silva --- arch/arm/boot/dts/imx7s-warp.dts | 44 1 file changed, 44 insertions(+) diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts index cb175ee2fc9d..bf04e13afd02 100644 --- a/arch/arm/boot/dts/imx7s-warp.dts +++ b/arch/arm/boot/dts/imx7s-warp.dts @@ -91,6 +91,14 @@ regulator-always-on; }; + reg_peri_3p15v: regulator-peri-3p15v { + compatible = "regulator-fixed"; + regulator-name = "peri_3p15v_reg"; + regulator-min-microvolt = <315>; + regulator-max-microvolt = <315>; + regulator-always-on; + }; + sound { compatible = "simple-audio-card"; simple-audio-card,name = "imx7-sgtl5000"; @@ -218,6 +226,27 @@ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c2>; status = "okay"; + + ov2680: camera@36 { + compatible = "ovti,ov2680"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ov2680>; + reg = <0x36>; + clocks = <&osc>; + clock-names = "xvclk"; + reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>; + DOVDD-supply = <&sw2_reg>; + DVDD-supply = <&sw2_reg>; + AVDD-supply = <®_peri_3p15v>; + + port { + ov2680_to_mipi: endpoint { + remote-endpoint = <&mipi_from_sensor>; + clock-lanes = <0>; + data-lanes = <1>; + }; + }; + }; }; &i2c4 { @@ -352,6 +381,15 @@ #size-cells = <0>; fsl,csis-hs-settle = <3>; + port@0 { + reg = <0>; + + mipi_from_sensor: endpoint { + remote-endpoint = <&ov2680_to_mipi>; + data-lanes = <1>; + }; + }; + port@1 { reg = <1>; @@ -408,6 +446,12 @@ >; }; + pinctrl_ov2680: ov2660grp { + fsl,pins = < + MX7D_PAD_LPSR_GPIO1_IO03__GPIO1_IO3 0x14 + >; + }; + pinctrl_sai1: sai1grp { fsl,pins = < MX7D_PAD_SAI1_RX_DATA__SAI1_RX_DATA00x1f -- 2.17.0
[PATCH v4 04/12] clk: imx7d: reset parent for mipi csi root
To guarantee that we do not get Overflow in image FIFO the outer bandwidth has to be faster than inputer bandwidth. For that it must be possible to set a faster frequency clock. So set new parent to sys_pfd3 clock for the mipi csi block. Cc: linux-...@vger.kernel.org Acked-by: Shawn Guo Signed-off-by: Rui Miguel Silva --- drivers/clk/imx/clk-imx7d.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c index f7f4db2e6fa6..27877d05faa2 100644 --- a/drivers/clk/imx/clk-imx7d.c +++ b/drivers/clk/imx/clk-imx7d.c @@ -891,6 +891,8 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node) clk_set_parent(clks[IMX7D_PLL_AUDIO_MAIN_BYPASS], clks[IMX7D_PLL_AUDIO_MAIN]); clk_set_parent(clks[IMX7D_PLL_VIDEO_MAIN_BYPASS], clks[IMX7D_PLL_VIDEO_MAIN]); + clk_set_parent(clks[IMX7D_MIPI_CSI_ROOT_SRC], clks[IMX7D_PLL_SYS_PFD3_CLK]); + /* use old gpt clk setting, gpt1 root clk must be twice as gpt counter freq */ clk_set_parent(clks[IMX7D_GPT1_ROOT_SRC], clks[IMX7D_OSC_24M_CLK]); -- 2.17.0
[PATCH v4 07/12] ARM: dts: imx7s: add mipi phy power domain
Add power domain index 0 related with mipi-phy to imx7s. Signed-off-by: Rui Miguel Silva --- arch/arm/boot/dts/imx7s.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi index 4d42335c0dee..67450ad89940 100644 --- a/arch/arm/boot/dts/imx7s.dtsi +++ b/arch/arm/boot/dts/imx7s.dtsi @@ -636,6 +636,12 @@ #address-cells = <1>; #size-cells = <0>; + pgc_mipi_phy: pgc-power-domain@0 { + #power-domain-cells = <0>; + reg = <0>; + power-supply = <®_1p0d>; + }; + pgc_pcie_phy: pgc-power-domain@1 { #power-domain-cells = <0>; reg = <1>; -- 2.17.0
[PATCH v4 02/12] media: staging/imx7: add imx7 CSI subdev driver
This add the media entity subdevice and control driver for the i.MX7 CMOS Sensor Interface. Signed-off-by: Rui Miguel Silva --- drivers/staging/media/imx/Kconfig |9 +- drivers/staging/media/imx/Makefile |2 + drivers/staging/media/imx/imx7-media-csi.c | 1352 3 files changed, 1362 insertions(+), 1 deletion(-) create mode 100644 drivers/staging/media/imx/imx7-media-csi.c diff --git a/drivers/staging/media/imx/Kconfig b/drivers/staging/media/imx/Kconfig index bfc17de56b17..40a11f988fc6 100644 --- a/drivers/staging/media/imx/Kconfig +++ b/drivers/staging/media/imx/Kconfig @@ -11,7 +11,7 @@ config VIDEO_IMX_MEDIA driver for the i.MX5/6 SOC. if VIDEO_IMX_MEDIA -menu "i.MX5/6 Media Sub devices" +menu "i.MX5/6/7 Media Sub devices" config VIDEO_IMX_CSI tristate "i.MX5/6 Camera Sensor Interface driver" @@ -20,5 +20,12 @@ config VIDEO_IMX_CSI ---help--- A video4linux camera sensor interface driver for i.MX5/6. +config VIDEO_IMX7_CSI + tristate "i.MX7 Camera Sensor Interface driver" + depends on VIDEO_IMX_MEDIA && VIDEO_DEV && I2C + default y + ---help--- + A video4linux camera sensor interface driver for i.MX7. + endmenu endif diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile index a30b3033f9a3..074f016d3519 100644 --- a/drivers/staging/media/imx/Makefile +++ b/drivers/staging/media/imx/Makefile @@ -12,3 +12,5 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-ic.o obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o + +obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o diff --git a/drivers/staging/media/imx/imx7-media-csi.c b/drivers/staging/media/imx/imx7-media-csi.c new file mode 100644 index ..d739eb8be402 --- /dev/null +++ b/drivers/staging/media/imx/imx7-media-csi.c @@ -0,0 +1,1352 @@ +// SPDX-License-Identifier: GPL +/* + * V4L2 Capture CSI Subdev for Freescale i.MX7 SOC + * + * Copyright (c) 2018 Linaro Ltd + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include +#include "imx-media.h" + +#define IMX7_CSI_PAD_SINK 0 +#define IMX7_CSI_PAD_SRC 1 +#define IMX7_CSI_PADS_NUM 2 + +/* reset values */ +#define CSICR1_RESET_VAL 0x4800 +#define CSICR2_RESET_VAL 0x0 +#define CSICR3_RESET_VAL 0x0 + +/* csi control reg 1 */ +#define BIT_SWAP16_EN BIT(31) +#define BIT_EXT_VSYNC BIT(30) +#define BIT_EOF_INT_EN BIT(29) +#define BIT_PRP_IF_EN BIT(28) +#define BIT_CCIR_MODE BIT(27) +#define BIT_COF_INT_EN BIT(26) +#define BIT_SF_OR_INTENBIT(25) +#define BIT_RF_OR_INTENBIT(24) +#define BIT_SFF_DMA_DONE_INTEN BIT(22) +#define BIT_STATFF_INTEN BIT(21) +#define BIT_FB2_DMA_DONE_INTEN BIT(20) +#define BIT_FB1_DMA_DONE_INTEN BIT(19) +#define BIT_RXFF_INTEN BIT(18) +#define BIT_SOF_POLBIT(17) +#define BIT_SOF_INTEN BIT(16) +#define BIT_MCLKDIV(0xF << 12) +#define BIT_HSYNC_POL BIT(11) +#define BIT_CCIR_ENBIT(10) +#define BIT_MCLKEN BIT(9) +#define BIT_FCCBIT(8) +#define BIT_PACK_DIR BIT(7) +#define BIT_CLR_STATFIFO BIT(6) +#define BIT_CLR_RXFIFO BIT(5) +#define BIT_GCLK_MODE BIT(4) +#define BIT_INV_DATA BIT(3) +#define BIT_INV_PCLK BIT(2) +#define BIT_REDGE BIT(1) +#define BIT_PIXEL_BIT BIT(0) + +#define SHIFT_MCLKDIV 12 + +/* control reg 3 */ +#define BIT_FRMCNT (0x << 16) +#define BIT_FRMCNT_RST BIT(15) +#define BIT_DMA_REFLASH_RFFBIT(14) +#define BIT_DMA_REFLASH_SFFBIT(13) +#define BIT_DMA_REQ_EN_RFF BIT(12) +#define BIT_DMA_REQ_EN_SFF BIT(11) +#define BIT_STATFF_LEVEL (0x7 << 8) +#define BIT_HRESP_ERR_EN BIT(7) +#define BIT_RXFF_LEVEL (0x7 << 4) +#define BIT_TWO_8BIT_SENSORBIT(3) +#define BIT_ZERO_PACK_EN BIT(2) +#define BIT_ECC_INT_EN BIT(1) +#define BIT_ECC_AUTO_ENBIT(0) + +#define SHIFT_FRMCNT 16 +#define SHIFT_RXFIFO_LEVEL 4 + +/* csi status reg */ +#define BIT_ADDR_CH_ERR_INTBIT(28) +#define BIT_FIELD0_INT BIT(27) +#define BIT_FIELD1_INT BIT(26) +#define BIT_SFF_OR_INT BIT(25) +#define BIT_RFF_OR_INT BIT(24) +#define BIT_DMA_TSF_DONE_SFF BIT(22) +#define BIT_STATFF_INT BIT(21) +#define BIT_DMA_TSF_DONE_FB2 BIT(20) +#define BIT_DMA_TSF_DONE_FB1 BIT(19) +#define BIT_RXFF_INT BIT(18) +#define BIT_EOF_INTBIT(17) +#define BIT_SOF_INTBIT(16) +#define BIT_F2_INT BIT(15) +#define BIT_F1_INT BIT(14) +#define BIT_COF_INTBIT
[PATCH v4 05/12] media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7
Adds MIPI CSI-2 subdev for i.MX7 to connect with sensors with a MIPI CSI-2 interface. Signed-off-by: Rui Miguel Silva --- drivers/staging/media/imx/Makefile |1 + drivers/staging/media/imx/imx7-mipi-csis.c | 1154 2 files changed, 1155 insertions(+) create mode 100644 drivers/staging/media/imx/imx7-mipi-csis.c diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile index 074f016d3519..d2d909a36239 100644 --- a/drivers/staging/media/imx/Makefile +++ b/drivers/staging/media/imx/Makefile @@ -14,3 +14,4 @@ obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-media-csi.o +obj-$(CONFIG_VIDEO_IMX7_CSI) += imx7-mipi-csis.o diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c new file mode 100644 index ..e56facea36ba --- /dev/null +++ b/drivers/staging/media/imx/imx7-mipi-csis.c @@ -0,0 +1,1154 @@ +// SPDX-License-Identifier: GPL +/* + * Freescale i.MX7 SoC series MIPI-CSI V3.3 receiver driver + * + * Copyright (C) 2018 Linaro Ltd + * Copyright (C) 2015-2016 Freescale Semiconductor, Inc. All Rights Reserved. + * Copyright (C) 2011 - 2013 Samsung Electronics Co., Ltd. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "imx-media.h" + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, "Debug level (0-2)"); + +#define CSIS_DRIVER_NAME "imx7-mipi-csis" +#define CSIS_SUBDEV_NAME CSIS_DRIVER_NAME + +#define CSIS_PAD_SINK 0 +#define CSIS_PAD_SOURCE1 +#define CSIS_PADS_NUM 2 + +#define MIPI_CSIS_DEF_PIX_WIDTH640 +#define MIPI_CSIS_DEF_PIX_HEIGHT 480 + +/* Register map definition */ + +/* CSIS common control */ +#define MIPI_CSIS_CMN_CTRL 0x04 +#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW BIT(16) +#define MIPI_CSIS_CMN_CTRL_INTER_MODE BIT(10) +#define MIPI_CSIS_CMN_CTRL_UPDATE_SHADOW_CTRL BIT(2) +#define MIPI_CSIS_CMN_CTRL_RESET BIT(1) +#define MIPI_CSIS_CMN_CTRL_ENABLE BIT(0) + +#define MIPI_CSIS_CMN_CTRL_LANE_NR_OFFSET 8 +#define MIPI_CSIS_CMN_CTRL_LANE_NR_MASK(3 << 8) + +/* CSIS clock control */ +#define MIPI_CSIS_CLK_CTRL 0x08 +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH3(x)(x << 28) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH2(x)(x << 24) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH1(x)(x << 20) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_TRAIL_CH0(x)(x << 16) +#define MIPI_CSIS_CLK_CTRL_CLKGATE_EN_MSK (0xf << 4) +#define MIPI_CSIS_CLK_CTRL_WCLK_SRCBIT(0) + +/* CSIS Interrupt mask */ +#define MIPI_CSIS_INTMSK 0x10 +#define MIPI_CSIS_INTMSK_EVEN_BEFORE BIT(31) +#define MIPI_CSIS_INTMSK_EVEN_AFTERBIT(30) +#define MIPI_CSIS_INTMSK_ODD_BEFOREBIT(29) +#define MIPI_CSIS_INTMSK_ODD_AFTER BIT(28) +#define MIPI_CSIS_INTMSK_FRAME_START BIT(24) +#define MIPI_CSIS_INTMSK_FRAME_END BIT(20) +#define MIPI_CSIS_INTMSK_ERR_SOT_HSBIT(16) +#define MIPI_CSIS_INTMSK_ERR_LOST_FS BIT(12) +#define MIPI_CSIS_INTMSK_ERR_LOST_FE BIT(8) +#define MIPI_CSIS_INTMSK_ERR_OVER BIT(4) +#define MIPI_CSIS_INTMSK_ERR_WRONG_CFG BIT(3) +#define MIPI_CSIS_INTMSK_ERR_ECC BIT(2) +#define MIPI_CSIS_INTMSK_ERR_CRC BIT(1) +#define MIPI_CSIS_INTMSK_ERR_UNKNOWN BIT(0) + +/* CSIS Interrupt source */ +#define MIPI_CSIS_INTSRC 0x14 +#define MIPI_CSIS_INTSRC_EVEN_BEFORE BIT(31) +#define MIPI_CSIS_INTSRC_EVEN_AFTERBIT(30) +#define MIPI_CSIS_INTSRC_EVEN BIT(30) +#define MIPI_CSIS_INTSRC_ODD_BEFOREBIT(29) +#define MIPI_CSIS_INTSRC_ODD_AFTER BIT(28) +#define MIPI_CSIS_INTSRC_ODD (0x3 << 28) +#define MIPI_CSIS_INTSRC_NON_IMAGE_DATA(0xf << 28) +#define MIPI_CSIS_INTSRC_FRAME_START BIT(24) +#define MIPI_CSIS_INTSRC_FRAME_END BIT(20) +#define MIPI_CSIS_INTSRC_ERR_SOT_HSBIT(16) +#define MIPI_CSIS_INTSRC_ERR_LOST_FS BIT(12) +#define MIPI_CSIS_INTSRC_ERR_LOST_FE BIT(8) +#define MIPI_CSIS_INTSRC_ERR_OVER BIT(4) +#define MIPI_CSIS_INTSRC_ERR_WRONG_CFG BIT(3) +#define MIPI_CSIS_INTSRC_ERR_ECC BIT(2) +#define MIPI_CSIS_INTSRC_ERR_CRC BIT(1) +#define MIPI_CSIS_INTSRC_ERR_UNKNOWN BIT(0) +#define MIPI_CSIS_INTSRC_ERRORS0xf + +/* D-PHY status control */ +#define MIPI_CSIS_DPHYSTATUS 0x20 +#define MIPI_CSIS_DPHYSTATUS_ULPS_DAT BIT(8) +#define MIPI_CSIS_DPHYSTATUS_STOPSTATE_DAT BIT(4) +#define MIPI_CSIS_DPHYSTATUS_ULPS_CLK BIT(1) +#define MIPI_CSIS_DPHYSTATUS_STOPSTATE_CLK BIT(0) + +/* D-PHY common control */ +#define MIPI_CSIS_DPHYCTRL 0x24 +#define MIP
[PATCH v4 06/12] media: dt-bindings: add bindings for i.MX7 media driver
Add bindings documentation for i.MX7 media drivers. Signed-off-by: Rui Miguel Silva --- .../devicetree/bindings/media/imx7.txt| 145 ++ 1 file changed, 145 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/imx7.txt diff --git a/Documentation/devicetree/bindings/media/imx7.txt b/Documentation/devicetree/bindings/media/imx7.txt new file mode 100644 index ..161cff8e6442 --- /dev/null +++ b/Documentation/devicetree/bindings/media/imx7.txt @@ -0,0 +1,145 @@ +Freescale i.MX7 Media Video Device +== + +Video Media Controller node +--- + +This is the media controller node for video capture support. It is a +virtual device that lists the camera serial interface nodes that the +media device will control. + +Required properties: +- compatible : "fsl,imx7-capture-subsystem"; +- ports : Should contain a list of phandles pointing to camera + sensor interface port of CSI + +example: + +capture-subsystem { + compatible = "fsl,imx7-capture-subsystem"; + ports = <&csi>; +}; + + +mipi_csi2 node +-- + +This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is +compatible with previous version of Samsung D-phy. + +Required properties: + +- compatible: "fsl,imx7-mipi-csi2"; +- reg : base address and length of the register set for the device; +- interrupts: should contain MIPI CSIS interrupt; +- clocks: list of clock specifiers, see +Documentation/devicetree/bindings/clock/clock-bindings.txt for details; +- clock-names : must contain "pclk", "wrap" and "phy" entries, matching + entries in the clock property; +- power-domains : a phandle to the power domain, see + Documentation/devicetree/bindings/power/power_domain.txt for details. +- reset-names : should include following entry "mrst"; +- resets: a list of phandle, should contain reset entry of + reset-names; +- phy-supply: from the generic phy bindings, a phandle to a regulator that + provides power to MIPI CSIS core; +- bus-width : maximum number of data lanes supported (SoC specific); + +Optional properties: + +- clock-frequency : The IP's main (system bus) clock frequency in Hz, default + value when this property is not specified is 166 MHz; + +port node +- + +- reg: (required) can take the values 0 or 1, where 0 is the + related sink port and port 1 should be the source one; + +endpoint node +- + +- data-lanes: (required) an array specifying active physical MIPI-CSI2 + data input lanes and their mapping to logical lanes; the + array's content is unused, only its length is meaningful; + +- fsl,csis-hs-settle : (optional) differential receiver (HS-RX) settle time; + +example: + +mipi_csi: mipi-csi@3075 { +#address-cells = <1>; +#size-cells = <0>; + +compatible = "fsl,imx7-mipi-csi2"; +reg = <0x3075 0x1>; +interrupts = ; +clocks = <&clks IMX7D_IPG_ROOT_CLK>, +<&clks IMX7D_MIPI_CSI_ROOT_CLK>, +<&clks IMX7D_MIPI_DPHY_ROOT_CLK>; +clock-names = "pclk", "wrap", "phy"; +clock-names = "mipi", "phy"; +clock-frequency = <16600>; +power-domains = <&pgc_mipi_phy>; +phy-supply = <®_1p0d>; +resets = <&src IMX7_RESET_MIPI_PHY_MRST>; +reset-names = "mrst"; +bus-width = <4>; +fsl,csis-hs-settle = <3>; +fsl,csis-clk-settle = <0>; + +port@0 { +reg = <0>; + +mipi_from_sensor: endpoint { +remote-endpoint = <&ov2680_to_mipi>; +data-lanes = <1>; +}; +}; + +port@1 { +reg = <1>; + +mipi_vc0_to_csi_mux: endpoint { +remote-endpoint = <&csi_mux_from_mipi_vc0>; +}; +}; +}; + + +csi node + + +This is device node for the CMOS Sensor Interface (CSI) which enables the chip +to connect directly to external CMOS image sensors. + +Required properties: + +- compatible: "fsl,imx7-csi"; +- reg : base address and length of the register set for the device; +- interrupts: should contain CSI interrupt; +- clocks: list of clock specifiers, see +Documentation/devicetree/bindings/clock/clock-bindings.txt for details; +- clock-names : must contain "axi", "mclk" and "dcic" entries, matching + entries in the clock property;
[PATCH v4 08/12] ARM: dts: imx7s: add multiplexer controls
The IOMUXC General Purpose Register has bitfield to control video bus multiplexer to control the CSI input between the MIPI-CSI2 and parallel interface. Add that register and mask. Signed-off-by: Rui Miguel Silva Reviewed-by: Philipp Zabel --- arch/arm/boot/dts/imx7s.dtsi | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi index 67450ad89940..3590dab529f9 100644 --- a/arch/arm/boot/dts/imx7s.dtsi +++ b/arch/arm/boot/dts/imx7s.dtsi @@ -520,8 +520,14 @@ gpr: iomuxc-gpr@3034 { compatible = "fsl,imx7d-iomuxc-gpr", - "fsl,imx6q-iomuxc-gpr", "syscon"; + "fsl,imx6q-iomuxc-gpr", "syscon", "simple-mfd"; reg = <0x3034 0x1>; + + mux: mux-controller { + compatible = "mmio-mux"; + #mux-control-cells = <1>; + mux-reg-masks = <0x14 0x0010>; + }; }; ocotp: ocotp-ctrl@3035 { -- 2.17.0
[PATCH v4 09/12] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections
This patch adds the device tree nodes for csi, video multiplexer and mipi-csi besides the graph connecting the necessary endpoints to make the media capture entities to work in imx7 Warp board. Also add the pin control related with the mipi_csi in that board. Signed-off-by: Rui Miguel Silva --- arch/arm/boot/dts/imx7s-warp.dts | 51 arch/arm/boot/dts/imx7s.dtsi | 28 ++ 2 files changed, 79 insertions(+) diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts index 8a30b148534d..cb175ee2fc9d 100644 --- a/arch/arm/boot/dts/imx7s-warp.dts +++ b/arch/arm/boot/dts/imx7s-warp.dts @@ -310,6 +310,57 @@ status = "okay"; }; +&gpr { + csi_mux { + compatible = "video-mux"; + mux-controls = <&mux 0>; + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + + csi_mux_from_mipi_vc0: endpoint { + remote-endpoint = <&mipi_vc0_to_csi_mux>; + }; + }; + + port@2 { + reg = <2>; + + csi_mux_to_csi: endpoint { + remote-endpoint = <&csi_from_csi_mux>; + }; + }; + }; +}; + +&csi { + status = "okay"; + + port { + csi_from_csi_mux: endpoint { + remote-endpoint = <&csi_mux_to_csi>; + }; + }; +}; + +&mipi_csi { + clock-frequency = <16600>; + status = "okay"; + #address-cells = <1>; + #size-cells = <0>; + fsl,csis-hs-settle = <3>; + + port@1 { + reg = <1>; + + mipi_vc0_to_csi_mux: endpoint { + remote-endpoint = <&csi_mux_from_mipi_vc0>; + }; + }; +}; + &wdog1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_wdog>; diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi index 3590dab529f9..0bae41f2944c 100644 --- a/arch/arm/boot/dts/imx7s.dtsi +++ b/arch/arm/boot/dts/imx7s.dtsi @@ -46,6 +46,7 @@ #include #include #include +#include #include "imx7d-pinfunc.h" / { @@ -738,6 +739,17 @@ status = "disabled"; }; + csi: csi@3071 { + compatible = "fsl,imx7-csi"; + reg = <0x3071 0x1>; + interrupts = ; + clocks = <&clks IMX7D_CLK_DUMMY>, + <&clks IMX7D_CSI_MCLK_ROOT_CLK>, + <&clks IMX7D_CLK_DUMMY>; + clock-names = "axi", "mclk", "dcic"; + status = "disabled"; + }; + lcdif: lcdif@3073 { compatible = "fsl,imx7d-lcdif", "fsl,imx28-lcdif"; reg = <0x3073 0x1>; @@ -747,6 +759,22 @@ clock-names = "pix", "axi"; status = "disabled"; }; + + mipi_csi: mipi-csi@3075 { + compatible = "fsl,imx7-mipi-csi2"; + reg = <0x3075 0x1>; + interrupts = ; + clocks = <&clks IMX7D_IPG_ROOT_CLK>, + <&clks IMX7D_MIPI_CSI_ROOT_CLK>, + <&clks IMX7D_MIPI_DPHY_ROOT_CLK>; + clock-names = "pclk", "wrap", "phy"; + power-domains = <&pgc_mipi_phy>; + phy-supply = <®_1p0d>; + resets = <&src IMX7_RESET_MIPI_PHY_MRST>; + reset-names = "mrst"; + bus-width = <2>; + status = "disabled"; + }; }; aips3: aips-bus@3080 { -- 2.17.0
[PATCH v4 03/12] clk: imx7d: fix mipi dphy div parent
Fix the mipi dphy root divider to mipi_dphy_pre_div, this would remove a orphan clock and set the correct parent. before: cat clk_orphan_summary enable prepare protect clock countcountcountrate accuracy phase mipi_dphy_post_div 110 0 0 0 mipi_dphy_root_clk110 0 0 0 cat clk_dump | grep mipi_dphy mipi_dphy_post_div110 0 0 0 mipi_dphy_root_clk110 0 0 0 after: cat clk_dump | grep mipi_dphy mipi_dphy_src 1102400 0 0 mipi_dphy_cg 1102400 0 0 mipi_dphy_pre_div 1102400 0 0 mipi_dphy_post_div 1102400 0 0 mipi_dphy_root_clk 1102400 0 0 Fixes: 8f6d8094b215 ("ARM: imx: add imx7d clk tree support") Cc: linux-...@vger.kernel.org Acked-by: Dong Aisheng Signed-off-by: Rui Miguel Silva --- drivers/clk/imx/clk-imx7d.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c index 975a20d3cc94..f7f4db2e6fa6 100644 --- a/drivers/clk/imx/clk-imx7d.c +++ b/drivers/clk/imx/clk-imx7d.c @@ -729,7 +729,7 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node) clks[IMX7D_LCDIF_PIXEL_ROOT_DIV] = imx_clk_divider2("lcdif_pixel_post_div", "lcdif_pixel_pre_div", base + 0xa300, 0, 6); clks[IMX7D_MIPI_DSI_ROOT_DIV] = imx_clk_divider2("mipi_dsi_post_div", "mipi_dsi_pre_div", base + 0xa380, 0, 6); clks[IMX7D_MIPI_CSI_ROOT_DIV] = imx_clk_divider2("mipi_csi_post_div", "mipi_csi_pre_div", base + 0xa400, 0, 6); - clks[IMX7D_MIPI_DPHY_ROOT_DIV] = imx_clk_divider2("mipi_dphy_post_div", "mipi_csi_dphy_div", base + 0xa480, 0, 6); + clks[IMX7D_MIPI_DPHY_ROOT_DIV] = imx_clk_divider2("mipi_dphy_post_div", "mipi_dphy_pre_div", base + 0xa480, 0, 6); clks[IMX7D_SAI1_ROOT_DIV] = imx_clk_divider2("sai1_post_div", "sai1_pre_div", base + 0xa500, 0, 6); clks[IMX7D_SAI2_ROOT_DIV] = imx_clk_divider2("sai2_post_div", "sai2_pre_div", base + 0xa580, 0, 6); clks[IMX7D_SAI3_ROOT_DIV] = imx_clk_divider2("sai3_post_div", "sai3_pre_div", base + 0xa600, 0, 6); -- 2.17.0
[PATCH v4 11/12] media: imx7.rst: add documentation for i.MX7 media driver
Add rst document to describe the i.MX7 media driver and also a working example from the Warp7 board usage with a OV2680 sensor. Signed-off-by: Rui Miguel Silva --- .../devicetree/bindings/media/imx7.txt| 20 --- Documentation/media/v4l-drivers/imx7.rst | 157 ++ Documentation/media/v4l-drivers/index.rst | 1 + 3 files changed, 158 insertions(+), 20 deletions(-) create mode 100644 Documentation/media/v4l-drivers/imx7.rst diff --git a/Documentation/devicetree/bindings/media/imx7.txt b/Documentation/devicetree/bindings/media/imx7.txt index 161cff8e6442..a26372630377 100644 --- a/Documentation/devicetree/bindings/media/imx7.txt +++ b/Documentation/devicetree/bindings/media/imx7.txt @@ -1,26 +1,6 @@ Freescale i.MX7 Media Video Device == -Video Media Controller node - -This is the media controller node for video capture support. It is a -virtual device that lists the camera serial interface nodes that the -media device will control. - -Required properties: -- compatible : "fsl,imx7-capture-subsystem"; -- ports : Should contain a list of phandles pointing to camera - sensor interface port of CSI - -example: - -capture-subsystem { - compatible = "fsl,imx7-capture-subsystem"; - ports = <&csi>; -}; - - mipi_csi2 node -- diff --git a/Documentation/media/v4l-drivers/imx7.rst b/Documentation/media/v4l-drivers/imx7.rst new file mode 100644 index ..cd1195d391c5 --- /dev/null +++ b/Documentation/media/v4l-drivers/imx7.rst @@ -0,0 +1,157 @@ +i.MX7 Video Capture Driver +== + +Introduction + + +The i.MX7 contrary to the i.MX5/6 family does not contain an Image Processing +Unit (IPU); because of that the capabilities to perform operations or +manipulation of the capture frames are less feature rich. + +For image capture the i.MX7 has three units: +- CMOS Sensor Interface (CSI) +- Video Multiplexer +- MIPI CSI-2 Receiver + +:: + |\ + MIPI Camera Input ---> MIPI CSI-2 --- > | \ + | \ + | M | + | U | --> CSI ---> Capture + | X | + | / + Parallel Camera Input > | / + |/ + +For additional information, please refer to the latest versions of the i.MX7 +reference manual [#f1]_. + +Entities + + +imx7-mipi-csi2 +-- + +This is the MIPI CSI-2 receiver entity. It has one sink pad to receive the pixel +data from MIPI CSI-2 camera sensor. It has one source pad, corresponding to the +virtual channel 0. This module is compliant to previous version of Samsung +D-phy, and supports two D-PHY Rx Data lanes. + +csi_mux +--- + +This is the video multiplexer. It has two sink pads to select from either camera +sensor with a parallel interface or from MIPI CSI-2 virtual channel 0. It has +a single source pad that routes to the CSI. + +csi +--- + +The CSI enables the chip to connect directly to external CMOS image sensor. CSI +can interface directly with Parallel and MIPI CSI-2 buses. It has 256 x 64 FIFO +to store received image pixel data and embedded DMA controllers to transfer data +from the FIFO through AHB bus. + +This entity has one sink pad that receives from the csi_mux entity and a single +source pad that routes video frames directly to memory buffers. This pad is +routed to a capture device node. + +Usage Notes +--- + +To aid in configuration and for backward compatibility with V4L2 applications +that access controls only from video device nodes, the capture device interfaces +inherit controls from the active entities in the current pipeline, so controls +can be accessed either directly from the subdev or from the active capture +device interface. For example, the sensor controls are available either from the +sensor subdevs or from the active capture device. + +Warp7 with OV2680 +- + +On this platform an OV2680 MIPI CSI-2 module is connected to the internal MIPI +CSI-2 receiver. The following example configures a video capture pipeline with +an output of 800x600, and BGGR 10 bit bayer format: + +.. code-block:: none + # Setup links + media-ctl -l "'ov2680 1-0036':0 -> 'imx7-mipi-csis.0':0[1]" + media-ctl -l "'imx7-mipi-csis.0':1 -> 'csi_mux':1[1]" + media-ctl -l "'csi_mux':2 -> 'csi':0[1]" + media-ctl -l "'csi':1 -> 'csi capture':0[1]" + + # Configure pads for pipeline + media-ctl -V "'ov2680 1-0036':0 [fmt:SBGGR10_1X10/800x600 field:none]" + media-ctl -V "'csi_mux':1 [fmt:SBGGR10_1X10/800x600 field:none]" + media-ctl -V "'csi_mux':2 [fmt:SBGGR10_1X10/800x600 field:none]" + media-ctl -V "'imx7-mipi-csis.0':0 [fmt:SBGGR10_1X10/800x600 field:none]" + med
[PATCH v4 12/12] media: staging/imx: add i.MX7 entries to TODO file
Add some i.MX7 related entries to TODO file. Signed-off-by: Rui Miguel Silva --- drivers/staging/media/imx/TODO | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/staging/media/imx/TODO b/drivers/staging/media/imx/TODO index aeeb15494a49..6f29b5ca5324 100644 --- a/drivers/staging/media/imx/TODO +++ b/drivers/staging/media/imx/TODO @@ -45,3 +45,12 @@ Which means a port must not contain mixed-use endpoints, they must all refer to media links between V4L2 subdevices. + +- i.MX7: all of the above, since it uses the imx media core + +- i.MX7: use Frame Interval Monitor + +- i.MX7: runtime testing with parallel sensor, links setup and streaming + +- i.MX7: runtime testing with different formats, for the time only 10-bit bayer + is tested -- 2.17.0
Re: [PATCH v9 6/8] media: vsp1: Refactor display list configure operations
Hi Laurent, Thanks for the review, On 17/05/18 10:41, Laurent Pinchart wrote: > Hi Kieran, > > Thank you for the patch. > > On Thursday, 3 May 2018 16:35:45 EEST Kieran Bingham wrote: >> The entities provide a single .configure operation which configures the >> object into the target display list, based on the vsp1_entity_params >> selection. >> >> Split the configure function into three parts, '.configure_stream()', >> '.configure_frame()', and '.configure_partition()' to facilitate >> splitting the configuration of each parameter class into separate >> display list bodies. >> >> Signed-off-by: Kieran Bingham >> >> --- >> The checkpatch warning: >> >> WARNING: function definition argument 'struct vsp1_dl_list *' should >> also have an identifier name >> >> has been ignored to match the existing code style. >> >> v8: >> - Add support for the UIF >> - Remove unrelated whitespace change >> - Fix comment location for clu_configure_stream() >> - Update configure documentations >> - Implement configure_partition separation. >> >> v7 >> - Fix formatting and white space >> - s/prepare/configure_stream/ >> - s/configure/configure_frame/ >> --- >> drivers/media/platform/vsp1/vsp1_brx.c| 12 +- >> drivers/media/platform/vsp1/vsp1_clu.c| 77 ++ >> drivers/media/platform/vsp1/vsp1_drm.c| 12 +- >> drivers/media/platform/vsp1/vsp1_entity.c | 24 ++- >> drivers/media/platform/vsp1/vsp1_entity.h | 39 +-- >> drivers/media/platform/vsp1/vsp1_hgo.c| 12 +- >> drivers/media/platform/vsp1/vsp1_hgt.c| 12 +- >> drivers/media/platform/vsp1/vsp1_hsit.c | 12 +- >> drivers/media/platform/vsp1/vsp1_lif.c| 12 +- >> drivers/media/platform/vsp1/vsp1_lut.c| 47 +--- >> drivers/media/platform/vsp1/vsp1_rpf.c| 168 ++--- >> drivers/media/platform/vsp1/vsp1_sru.c| 12 +- >> drivers/media/platform/vsp1/vsp1_uds.c| 56 ++-- >> drivers/media/platform/vsp1/vsp1_uif.c| 16 +- >> drivers/media/platform/vsp1/vsp1_video.c | 28 +-- >> drivers/media/platform/vsp1/vsp1_wpf.c| 303 --- >> 16 files changed, 422 insertions(+), 420 deletions(-) > > [snip] > >> diff --git a/drivers/media/platform/vsp1/vsp1_clu.c >> b/drivers/media/platform/vsp1/vsp1_clu.c index ea83f1b7d125..0a978980d447 >> 100644 >> --- a/drivers/media/platform/vsp1/vsp1_clu.c >> +++ b/drivers/media/platform/vsp1/vsp1_clu.c >> @@ -168,58 +168,50 @@ static const struct v4l2_subdev_ops clu_ops = { >> /* >> * VSP1 Entity Operations >> */ >> +static void clu_configure_stream(struct vsp1_entity *entity, >> + struct vsp1_pipeline *pipe, >> + struct vsp1_dl_list *dl) >> +{ >> +struct vsp1_clu *clu = to_clu(&entity->subdev); >> +struct v4l2_mbus_framefmt *format; >> > > I would have kept this blank line before the function. I would have thought I would too :) > >> -static void clu_configure(struct vsp1_entity *entity, >> - struct vsp1_pipeline *pipe, >> - struct vsp1_dl_list *dl, >> - enum vsp1_entity_params params) >> +/* >> + * The yuv_mode can't be changed during streaming. Cache it internally >> + * for future runtime configuration calls. >> + */ >> +format = vsp1_entity_get_pad_format(&clu->entity, >> +clu->entity.config, >> +CLU_PAD_SINK); >> +clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32; >> +} > > [snip] > >> diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c >> b/drivers/media/platform/vsp1/vsp1_wpf.c index 65ed2f849551..da287c27b324 >> 100644 >> --- a/drivers/media/platform/vsp1/vsp1_wpf.c >> +++ b/drivers/media/platform/vsp1/vsp1_wpf.c > > [snip] > >> +static void wpf_configure_frame(struct vsp1_entity *entity, >> +struct vsp1_pipeline *pipe, >> +struct vsp1_dl_list *dl) >> +{ >> +struct vsp1_rwpf *wpf = to_rwpf(&entity->subdev); >> +unsigned long flags; >> +u32 outfmt = 0; > > No need to initialize outfmt to 0. Ah yes, indeed!. >> + > > This blank line isn't needed. > >> +const unsigned int mask = BIT(WPF_CTRL_VFLIP) >> +| BIT(WPF_CTRL_HFLIP); >> + >> +spin_lock_irqsave(&wpf->flip.lock, flags); >> +wpf->flip.active = (wpf->flip.active & ~mask) >> + | (wpf->flip.pending & mask); >> +spin_unlock_irqrestore(&wpf->flip.lock, flags); >> + >> +outfmt = (wpf->alpha << VI6_WPF_OUTFMT_PDV_SHIFT) | wpf->outfmt; >> + >> +if (wpf->flip.active & BIT(WPF_CTRL_VFLIP)) >> +outfmt |= VI6_WPF_OUTFMT_FLP; >> +if (wpf->flip.active & BIT(WPF_CTRL_HFLIP)) >> +outfmt |= VI6_WPF_OUTFMT_HFLP; >> + >> +vsp1_wpf_write(wpf, dl, VI6_WPF_OUTFMT, outfmt); >> +} > > [snip] > > Apart from that, > > Re
Re: [PATCH v2 11/12] media: ov5640: Add 60 fps support
Hi Maxime, Thanks for fixes ! No special modification of v4l2-ctl, I'm using currently v4l-utils 1.12.3. What output do you have ? Best regards, Hugues. On 05/17/2018 10:52 AM, Maxime Ripard wrote: > Hi Hugues, > > On Tue, May 15, 2018 at 01:33:55PM +, Hugues FRUCHET wrote: >> I've taken the whole serie and made some tests on STM32 platform using >> DVP parallel interface. >> Now JPEG is OK and I've not seen any regressions appart on framerate >> control linked to this current patchset. > > Thanks a lot for your feedback, I've (hopefully) fixed all the issues > you reported here, most of the time taking your fix directly, except > for 2 where I reworked the code instead. > >> Here are issues observed around framerate control: >> 1) Framerate enumeration is buggy and all resolutions are claimed >> supporting 15/30/60: >> v4l2-ctl --list-formats-ext >> ioctl: VIDIOC_ENUM_FMT >> Index : 0 >> Type: Video Capture >> Pixel Format: 'JPEG' (compressed) >> Name: JFIF JPEG >> Size: Discrete 176x144 >> Interval: Discrete 0.067s (15.000 fps) >> Interval: Discrete 0.033s (30.000 fps) >> Interval: Discrete 0.017s (60.000 fps) > > One small question though, I don't seem to have that output for > v4l2-ctl, is some hook needed in the v4l2 device for it to work? > > Maxime >
Re: [PATCH v3 1/2] media: rc: introduce BPF_PROG_RAWIR_EVENT
Hi Quentin, On Thu, May 17, 2018 at 01:10:56PM +0100, Quentin Monnet wrote: > 2018-05-16 22:04 UTC+0100 ~ Sean Young > > Add support for BPF_PROG_RAWIR_EVENT. This type of BPF program can call > > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report > > that the last key should be repeated. > > > > The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall; > > the target_fd must be the /dev/lircN device. > > > > Signed-off-by: Sean Young > > --- > > drivers/media/rc/Kconfig | 13 ++ > > drivers/media/rc/Makefile | 1 + > > drivers/media/rc/bpf-rawir-event.c | 363 + > > drivers/media/rc/lirc_dev.c| 24 ++ > > drivers/media/rc/rc-core-priv.h| 24 ++ > > drivers/media/rc/rc-ir-raw.c | 14 +- > > include/linux/bpf_rcdev.h | 30 +++ > > include/linux/bpf_types.h | 3 + > > include/uapi/linux/bpf.h | 55 - > > kernel/bpf/syscall.c | 7 + > > 10 files changed, 531 insertions(+), 3 deletions(-) > > create mode 100644 drivers/media/rc/bpf-rawir-event.c > > create mode 100644 include/linux/bpf_rcdev.h > > > > [...] > > Hi Sean, > > Please find below some nitpicks on the documentation for the two helpers. I agree with all your points. I will reword and fix this for v4. Thanks, Sean > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > index d94d333a8225..243e141e8a5b 100644 > > --- a/include/uapi/linux/bpf.h > > +++ b/include/uapi/linux/bpf.h > > [...] > > > @@ -1902,6 +1904,35 @@ union bpf_attr { > > * egress otherwise). This is the only flag supported for now. > > * Return > > * **SK_PASS** on success, or **SK_DROP** on error. > > + * > > + * int bpf_rc_keydown(void *ctx, u32 protocol, u32 scancode, u32 toggle) > > + * Description > > + * Report decoded scancode with toggle value. For use in > > + * BPF_PROG_TYPE_RAWIR_EVENT, to report a successfully > > Could you please use bold RST markup for constants and function names? > Typically for BPF_PROG_TYPE_RAWIR_EVENT here and the enum below. > > > + * decoded scancode. This is will generate a keydown event, > > s/This is will/This will/? > > > + * and a keyup event once the scancode is no longer repeated. > > + * > > + * *ctx* pointer to bpf_rawir_event, *protocol* is decoded > > + * protocol (see RC_PROTO_* enum). > > This documentation is intended to be compiled as a man page. Could you > please use a complete sentence here? > Also, this could do with additional markup as well: **struct > bpf_rawir_event**. > > > + * > > + * Some protocols include a toggle bit, in case the button > > + * was released and pressed again between consecutive scancodes, > > + * copy this bit into *toggle* if it exists, else set to 0. > > + * > > + * Return > > The "Return" lines here and in the second helper use space indent > instead as tabs (as all other lines do). Would you mind fixing it for > consistency? > > > + * Always return 0 (for now) > > Other helpers use just "0" in that case, but I do not really mind. > Out of curiosity, do you have anything specific in mind for changing the > return value here in the future? I don't expect this is to change, so I should just "0". > > > + * > > + * int bpf_rc_repeat(void *ctx) > > + * Description > > + * Repeat the last decoded scancode; some IR protocols like > > + * NEC have a special IR message for repeat last button, > > s/repeat/repeating/? > > > + * in case user is holding a button down; the scancode is > > + * not repeated. > > + * > > + * *ctx* pointer to bpf_rawir_event. > > Please use a complete sentence here as well, if you do not mind. > > > + * > > + * Return > > + * Always return 0 (for now) > > */ > Thanks, > Quentin
[PATCH v2 0/2] v4l: Add support for STD ioctls on subdev nodes
Hi Hans, This series enables the video standards to be controlled directly on the subdev device node. This is needed as there is no way to control the standard of a subdevice if it's part of a media controller centric setup as oppose to a video centric one. I have tested this on Renesas Gen3 Salvator-XS M3-N using the AFE subdevice from the adv748x driver together with the R-Car VIN and CSI-2 pipeline. And verified ENUMSTD still works for video device centric devices on Renesas Gen2 Koelsch board. I wrote a prototype patch for v4l2-ctl which adds four new options (--get-subdev-standard, --get-subdev-standard, --set-subdev-standard and --get-subdev-detected-standard) to ease testing which I plan to submit after some cleanup if this patch receives positive feedback. If you or anyone else is interested in testing this patch the v4l2-utils prototype patches are available at git://git.ragnatech.se/v4l-utils#subdev-std * Changes since v1 - Add VIDIOC_SUBDEV_ENUMSTD. Niklas Söderlund (2): v4l2-ioctl: create helper to fill in v4l2_standard for ENUMSTD v4l: Add support for STD ioctls on subdev nodes .../media/uapi/v4l/vidioc-enumstd.rst | 11 ++-- Documentation/media/uapi/v4l/vidioc-g-std.rst | 14 ++-- .../media/uapi/v4l/vidioc-querystd.rst| 11 ++-- drivers/media/v4l2-core/v4l2-ioctl.c | 66 +++ drivers/media/v4l2-core/v4l2-subdev.c | 22 +++ include/media/v4l2-ioctl.h| 11 include/uapi/linux/v4l2-subdev.h | 4 ++ 7 files changed, 98 insertions(+), 41 deletions(-) -- 2.17.0
[PATCH v2 1/2] v4l2-ioctl: create helper to fill in v4l2_standard for ENUMSTD
Prepare for adding a new IOCTL VIDIOC_SUBDEV_ENUMSTD which would enumerate the standards for a subdevice by breaking out the code which could be shared between the video and subdevice versions of this IOCTL. Signed-off-by: Niklas Söderlund --- drivers/media/v4l2-core/v4l2-ioctl.c | 66 include/media/v4l2-ioctl.h | 11 + 2 files changed, 48 insertions(+), 29 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index a40dbec271f1d9fe..1b5893373358ad5e 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -125,6 +125,42 @@ int v4l2_video_std_construct(struct v4l2_standard *vs, } EXPORT_SYMBOL(v4l2_video_std_construct); +/* Fill in the fields of a v4l2_standard structure according to the + * 'id' and 'vs->index' parameters. Returns negative on error. */ +int v4l_video_std_enumstd(struct v4l2_standard *vs, v4l2_std_id id) +{ + v4l2_std_id curr_id = 0; + unsigned int index = vs->index, i, j = 0; + const char *descr = ""; + + /* Return -ENODATA if the id for the current input + or output is 0, meaning that it doesn't support this API. */ + if (id == 0) + return -ENODATA; + + /* Return norm array in a canonical way */ + for (i = 0; i <= index && id; i++) { + /* last std value in the standards array is 0, so this + while always ends there since (id & 0) == 0. */ + while ((id & standards[j].std) != standards[j].std) + j++; + curr_id = standards[j].std; + descr = standards[j].descr; + j++; + if (curr_id == 0) + break; + if (curr_id != V4L2_STD_PAL && + curr_id != V4L2_STD_SECAM && + curr_id != V4L2_STD_NTSC) + id &= ~curr_id; + } + if (i <= index) + return -EINVAL; + + v4l2_video_std_construct(vs, curr_id, descr); + return 0; +} + /* - */ /* some arrays for pretty-printing debug messages of enum types */ @@ -1753,36 +1789,8 @@ static int v4l_enumstd(const struct v4l2_ioctl_ops *ops, { struct video_device *vfd = video_devdata(file); struct v4l2_standard *p = arg; - v4l2_std_id id = vfd->tvnorms, curr_id = 0; - unsigned int index = p->index, i, j = 0; - const char *descr = ""; - - /* Return -ENODATA if the tvnorms for the current input - or output is 0, meaning that it doesn't support this API. */ - if (id == 0) - return -ENODATA; - /* Return norm array in a canonical way */ - for (i = 0; i <= index && id; i++) { - /* last std value in the standards array is 0, so this - while always ends there since (id & 0) == 0. */ - while ((id & standards[j].std) != standards[j].std) - j++; - curr_id = standards[j].std; - descr = standards[j].descr; - j++; - if (curr_id == 0) - break; - if (curr_id != V4L2_STD_PAL && - curr_id != V4L2_STD_SECAM && - curr_id != V4L2_STD_NTSC) - id &= ~curr_id; - } - if (i <= index) - return -EINVAL; - - v4l2_video_std_construct(p, curr_id, descr); - return 0; + return v4l_video_std_enumstd(p, vfd->tvnorms); } static int v4l_s_std(const struct v4l2_ioctl_ops *ops, diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h index a7b3f7c75d628b06..fa0463a1b19dc880 100644 --- a/include/media/v4l2-ioctl.h +++ b/include/media/v4l2-ioctl.h @@ -642,6 +642,17 @@ void v4l2_video_std_frame_period(int id, struct v4l2_fract *frameperiod); int v4l2_video_std_construct(struct v4l2_standard *vs, int id, const char *name); +/** + * v4l_video_std_enumstd - Ancillary routine that fills in the fields of + * a &v4l2_standard structure according to the @id and @vs->index + * parameters. + * + * @vs: struct &v4l2_standard pointer to be filled. + * @id: analog TV sdandard ID. + * + */ +int v4l_video_std_enumstd(struct v4l2_standard *vs, v4l2_std_id id); + /** * v4l_printk_ioctl - Ancillary routine that prints the ioctl in a * human-readable format. -- 2.17.0
[PATCH v2 2/2] v4l: Add support for STD ioctls on subdev nodes
There is no way to control the standard of subdevices which are part of a media device. The ioctls which exists all target video devices explicitly and the idea is that the video device should talk to the subdevice. For subdevices part of a media graph this is not possible and the standard must be controlled on the subdev device directly. Add four new ioctls to be able to directly interact with subdevices and control the video standard; VIDIOC_SUBDEV_ENUMSTD, VIDIOC_SUBDEV_G_STD, VIDIOC_SUBDEV_S_STD and VIDIOC_SUBDEV_QUERYSTD. Signed-off-by: Niklas Söderlund --- * Changes since v1 - Added VIDIOC_SUBDEV_ENUMSTD. --- .../media/uapi/v4l/vidioc-enumstd.rst | 11 ++ Documentation/media/uapi/v4l/vidioc-g-std.rst | 14 .../media/uapi/v4l/vidioc-querystd.rst| 11 ++ drivers/media/v4l2-core/v4l2-subdev.c | 22 +++ include/uapi/linux/v4l2-subdev.h | 4 5 files changed, 50 insertions(+), 12 deletions(-) diff --git a/Documentation/media/uapi/v4l/vidioc-enumstd.rst b/Documentation/media/uapi/v4l/vidioc-enumstd.rst index b7fda29f46a139a0..2644a62acd4b6822 100644 --- a/Documentation/media/uapi/v4l/vidioc-enumstd.rst +++ b/Documentation/media/uapi/v4l/vidioc-enumstd.rst @@ -2,14 +2,14 @@ .. _VIDIOC_ENUMSTD: - -ioctl VIDIOC_ENUMSTD - +*** +ioctl VIDIOC_ENUMSTD, VIDIOC_SUBDEV_ENUMSTD +*** Name -VIDIOC_ENUMSTD - Enumerate supported video standards +VIDIOC_ENUMSTD - VIDIOC_SUBDEV_ENUMSTD - Enumerate supported video standards Synopsis @@ -18,6 +18,9 @@ Synopsis .. c:function:: int ioctl( int fd, VIDIOC_ENUMSTD, struct v4l2_standard *argp ) :name: VIDIOC_ENUMSTD +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_ENUMSTD, struct v4l2_standard *argp ) +:name: VIDIOC_SUBDEV_ENUMSTD + Arguments = diff --git a/Documentation/media/uapi/v4l/vidioc-g-std.rst b/Documentation/media/uapi/v4l/vidioc-g-std.rst index 90791ab51a5371b8..8d94f0404df270db 100644 --- a/Documentation/media/uapi/v4l/vidioc-g-std.rst +++ b/Documentation/media/uapi/v4l/vidioc-g-std.rst @@ -2,14 +2,14 @@ .. _VIDIOC_G_STD: - -ioctl VIDIOC_G_STD, VIDIOC_S_STD - +** +ioctl VIDIOC_G_STD, VIDIOC_S_STD, VIDIOC_SUBDEV_G_STD, VIDIOC_SUBDEV_S_STD +** Name -VIDIOC_G_STD - VIDIOC_S_STD - Query or select the video standard of the current input +VIDIOC_G_STD - VIDIOC_S_STD - VIDIOC_SUBDEV_G_STD - VIDIOC_SUBDEV_S_STD - Query or select the video standard of the current input Synopsis @@ -21,6 +21,12 @@ Synopsis .. c:function:: int ioctl( int fd, VIDIOC_S_STD, const v4l2_std_id *argp ) :name: VIDIOC_S_STD +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_G_STD, v4l2_std_id *argp ) +:name: VIDIOC_SUBDEV_G_STD + +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_S_STD, const v4l2_std_id *argp ) +:name: VIDIOC_SUBDEV_S_STD + Arguments = diff --git a/Documentation/media/uapi/v4l/vidioc-querystd.rst b/Documentation/media/uapi/v4l/vidioc-querystd.rst index cf40bca19b9f8665..a8385cc7481869dd 100644 --- a/Documentation/media/uapi/v4l/vidioc-querystd.rst +++ b/Documentation/media/uapi/v4l/vidioc-querystd.rst @@ -2,14 +2,14 @@ .. _VIDIOC_QUERYSTD: -* -ioctl VIDIOC_QUERYSTD -* +* +ioctl VIDIOC_QUERYSTD, VIDIOC_SUBDEV_QUERYSTD +* Name -VIDIOC_QUERYSTD - Sense the video standard received by the current input +VIDIOC_QUERYSTD - VIDIOC_SUBDEV_QUERYSTD - Sense the video standard received by the current input Synopsis @@ -18,6 +18,9 @@ Synopsis .. c:function:: int ioctl( int fd, VIDIOC_QUERYSTD, v4l2_std_id *argp ) :name: VIDIOC_QUERYSTD +.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_QUERYSTD, v4l2_std_id *argp ) +:name: VIDIOC_SUBDEV_QUERYSTD + Arguments = diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c index f9eed938d3480b74..27a2c633f2323f5f 100644 --- a/drivers/media/v4l2-core/v4l2-subdev.c +++ b/drivers/media/v4l2-core/v4l2-subdev.c @@ -494,6 +494,28 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) case VIDIOC_SUBDEV_S_DV_TIMINGS: return v4l2_subdev_call(sd, video, s_dv_timings, arg); + + case VIDIOC_SUBDEV_G_STD: + return v4l2_subdev_call(sd, video, g_std, arg); + + case VIDIOC_SUBDEV_S_STD: { + v4l2_std_id *std = arg; + + return v4l2_subdev_call(sd, video, s_std, *std); + } + + case VIDIOC_SUBDEV_ENUMSTD: { + struct v4l2_standard
Re: [PATCH 0/7] i2c: clean up include/linux/i2c-*
On Thu, Apr 19, 2018 at 10:00:06PM +0200, Wolfram Sang wrote: > Move all plain platform_data includes to the platform_data-dir > (except for i2c-pnx which can be moved into the driver itself). > > My preference is to take these patches via the i2c tree. I can provide an > immutable branch if needed. But we can also discuss those going in via > arch-trees if dependencies are against us. All applied to for-next! The immutable branch is here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/platform_data-immutable Thanks, Wolfram signature.asc Description: PGP signature
Re: [PATCH v7 8/8] media: vsp1: Move video configuration to a cached dlb
Hi Kieran, On Monday, 30 April 2018 20:48:03 EEST Kieran Bingham wrote: > On 07/04/18 01:23, Laurent Pinchart wrote: > > On Thursday, 8 March 2018 02:05:31 EEST Kieran Bingham wrote: > >> We are now able to configure a pipeline directly into a local display > >> list body. Take advantage of this fact, and create a cacheable body to > >> store the configuration of the pipeline in the video object. > >> > >> vsp1_video_pipeline_run() is now the last user of the pipe->dl object. > >> Convert this function to use the cached video->config body and obtain a > >> local display list reference. > >> > >> Attach the video->config body to the display list when needed before > >> committing to hardware. > >> > >> The pipe object is marked as un-configured when resuming from a suspend. > >> This ensures that when the hardware is reset - our cached configuration > >> will be re-attached to the next committed DL. > >> > >> Signed-off-by: Kieran Bingham > >> --- > >> > >> v3: > >> - 's/fragment/body/', 's/fragments/bodies/' > >> - video dlb cache allocation increased from 2 to 3 dlbs > >> > >> Our video DL usage now looks like the below output: > >> > >> dl->body0 contains our disposable runtime configuration. Max 41. > >> dl_child->body0 is our partition specific configuration. Max 12. > >> dl->bodies shows our constant configuration and LUTs. > >> > >> These two are LUT/CLU: > >> * dl->bodies[x]->num_entries 256 / max 256 > >> * dl->bodies[x]->num_entries 4914 / max 4914 > >> > >> Which shows that our 'constant' configuration cache is currently > >> utilised to a maximum of 64 entries. > >> > >> trace-cmd report | \ > >> > >> grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq; > >> > >> dl->body0->num_entries 13 / max 128 > >> dl->body0->num_entries 14 / max 128 > >> dl->body0->num_entries 16 / max 128 > >> dl->body0->num_entries 20 / max 128 > >> dl->body0->num_entries 27 / max 128 > >> dl->body0->num_entries 34 / max 128 > >> dl->body0->num_entries 41 / max 128 > >> dl_child->body0->num_entries 10 / max 128 > >> dl_child->body0->num_entries 12 / max 128 > >> dl->bodies[x]->num_entries 15 / max 128 > >> dl->bodies[x]->num_entries 16 / max 128 > >> dl->bodies[x]->num_entries 17 / max 128 > >> dl->bodies[x]->num_entries 18 / max 128 > >> dl->bodies[x]->num_entries 20 / max 128 > >> dl->bodies[x]->num_entries 21 / max 128 > >> dl->bodies[x]->num_entries 256 / max 256 > >> dl->bodies[x]->num_entries 31 / max 128 > >> dl->bodies[x]->num_entries 32 / max 128 > >> dl->bodies[x]->num_entries 39 / max 128 > >> dl->bodies[x]->num_entries 40 / max 128 > >> dl->bodies[x]->num_entries 47 / max 128 > >> dl->bodies[x]->num_entries 48 / max 128 > >> dl->bodies[x]->num_entries 4914 / max 4914 > >> dl->bodies[x]->num_entries 55 / max 128 > >> dl->bodies[x]->num_entries 56 / max 128 > >> dl->bodies[x]->num_entries 63 / max 128 > >> dl->bodies[x]->num_entries 64 / max 128 > > > > This might be useful to capture in the main part of the commit message. > > > >> v4: > >> - Adjust pipe configured flag to be reset on resume rather than suspend > >> - rename dl_child, dl_next > >> > >> drivers/media/platform/vsp1/vsp1_pipe.c | 7 +++- > >> drivers/media/platform/vsp1/vsp1_pipe.h | 4 +- > >> drivers/media/platform/vsp1/vsp1_video.c | 67 - > >> drivers/media/platform/vsp1/vsp1_video.h | 2 +- > >> 4 files changed, 54 insertions(+), 26 deletions(-) > >> > >> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c > >> b/drivers/media/platform/vsp1/vsp1_pipe.c index > >> 5012643583b6..fa445b1a2e38 > >> 100644 > >> --- a/drivers/media/platform/vsp1/vsp1_pipe.c > >> +++ b/drivers/media/platform/vsp1/vsp1_pipe.c > >> @@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe) > >>vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index), > >> VI6_CMD_STRCMD); > >>pipe->state = VSP1_PIPELINE_RUNNING; > >> + pipe->configured = true; > >>} > >> > >>pipe->buffers_ready = 0; > >> @@ -470,6 +471,12 @@ void vsp1_pipelines_resume(struct vsp1_device *vsp1) > >>continue; > >> > >>spin_lock_irqsave(&pipe->irqlock, flags); > >> + /* > >> + * The hardware may have been reset during a suspend and will > >> + * need a full reconfiguration > >> + */ > > > > s/reconfiguration/reconfiguration./ > > > >> + pipe->configured = false; > >> + > > > > Where does that full reconfiguration occur, given that the > > vsp1_pipeline_run() right below sets pipe->configured to true without > > performing reconfiguration ? Q > It's magic isn't it :D > > If the pipe->configured flag gets set to false, the next execution of > vsp1_pipeline_run() attaches the video->pipe_config (the cached > configuration, containing the route_setup() and the configure_stream() > entries) to the display lis
Re: [PATCH 1/4] soc: qcom: mdt_loader: Add check to make scm calls
On Thu, May 17, 2018 at 05:02:17PM +0530, Vikash Garodia wrote: > In order to invoke scm calls, ensure that the platform > has the required support to invoke the scm calls in > secure world. > > Signed-off-by: Vikash Garodia > --- > drivers/soc/qcom/mdt_loader.c | 21 + > 1 file changed, 13 insertions(+), 8 deletions(-) > > diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c > index 17b314d..db55d53 100644 > --- a/drivers/soc/qcom/mdt_loader.c > +++ b/drivers/soc/qcom/mdt_loader.c > @@ -121,10 +121,12 @@ int qcom_mdt_load(struct device *dev, const struct > firmware *fw, > if (!fw_name) > return -ENOMEM; > > - ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size); > - if (ret) { > - dev_err(dev, "invalid firmware metadata\n"); > - goto out; > + if (qcom_scm_is_available()) { > + ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size); > + if (ret) { > + dev_err(dev, "invalid firmware metadata\n"); > + goto out; > + } > } > > for (i = 0; i < ehdr->e_phnum; i++) { > @@ -144,10 +146,13 @@ int qcom_mdt_load(struct device *dev, const struct > firmware *fw, > } > > if (relocate) { > - ret = qcom_scm_pas_mem_setup(pas_id, mem_phys, max_addr - > min_addr); > - if (ret) { > - dev_err(dev, "unable to setup relocation\n"); > - goto out; > + if (qcom_scm_is_available()) { > + ret = qcom_scm_pas_mem_setup(pas_id, mem_phys, > + max_addr - min_addr); > + if (ret) { > + dev_err(dev, "unable to setup relocation\n"); > + goto out; > + } > } > As far as I can tell you can make it all the way through the function with 'ret' uninitialized if qcom_scm_is_available() returns false which is a bug, but I'm confused why you would even bother loading the firmware even if you didn't have SCM. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 2/4] media: venus: add a routine to reset ARM9
On Thu, May 17, 2018 at 05:02:18PM +0530, Vikash Garodia wrote: > Add a new routine to reset the ARM9 and brings it > out of reset. This is in preparation to add PIL > functionality in venus driver. > > Signed-off-by: Vikash Garodia > --- > drivers/media/platform/qcom/venus/firmware.c | 26 > > drivers/media/platform/qcom/venus/firmware.h | 1 + > drivers/media/platform/qcom/venus/hfi_venus_io.h | 5 + > 3 files changed, 32 insertions(+) > > diff --git a/drivers/media/platform/qcom/venus/firmware.c > b/drivers/media/platform/qcom/venus/firmware.c > index c4a5778..8f25375 100644 > --- a/drivers/media/platform/qcom/venus/firmware.c > +++ b/drivers/media/platform/qcom/venus/firmware.c > @@ -14,6 +14,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -22,11 +23,36 @@ > #include > #include > > +#include "core.h" > #include "firmware.h" > +#include "hfi_venus_io.h" > > #define VENUS_PAS_ID 9 > #define VENUS_FW_MEM_SIZE(6 * SZ_1M) > > +void venus_reset_hw(struct venus_core *core) > +{ > + void __iomem *reg_base = core->base; > + > + writel(0, reg_base + WRAPPER_FW_START_ADDR); > + writel(VENUS_FW_MEM_SIZE, reg_base + WRAPPER_FW_END_ADDR); > + writel(0, reg_base + WRAPPER_CPA_START_ADDR); > + writel(VENUS_FW_MEM_SIZE, reg_base + WRAPPER_CPA_END_ADDR); > + writel(0x0, reg_base + WRAPPER_CPU_CGC_DIS); > + writel(0x0, reg_base + WRAPPER_CPU_CLOCK_CONFIG); If you are going to have a bunch of writel() functions followed by a barrier it wouldn't hurt to use writel_relaxed() instead. Jordan > + /* Make sure all register writes are committed. */ > + mb(); > + > + /* > + * Need to wait 10 cycles of internal clocks before bringing ARM9 > + * out of reset. > + */ > + udelay(1); > + > + /* Bring Arm9 out of reset */ > + writel_relaxed(0, reg_base + WRAPPER_A9SS_SW_RESET); > +} > int venus_boot(struct device *dev, const char *fwname) > { > const struct firmware *mdt; > diff --git a/drivers/media/platform/qcom/venus/firmware.h > b/drivers/media/platform/qcom/venus/firmware.h > index 428efb5..d56f5b2 100644 > --- a/drivers/media/platform/qcom/venus/firmware.h > +++ b/drivers/media/platform/qcom/venus/firmware.h > @@ -18,5 +18,6 @@ > > int venus_boot(struct device *dev, const char *fwname); > int venus_shutdown(struct device *dev); > +void venus_reset_hw(struct venus_core *core); > > #endif > diff --git a/drivers/media/platform/qcom/venus/hfi_venus_io.h > b/drivers/media/platform/qcom/venus/hfi_venus_io.h > index 76f4793..39afa5d 100644 > --- a/drivers/media/platform/qcom/venus/hfi_venus_io.h > +++ b/drivers/media/platform/qcom/venus/hfi_venus_io.h > @@ -109,6 +109,11 @@ > #define WRAPPER_CPU_CGC_DIS (WRAPPER_BASE + 0x2010) > #define WRAPPER_CPU_STATUS (WRAPPER_BASE + 0x2014) > #define WRAPPER_SW_RESET (WRAPPER_BASE + 0x3000) > +#define WRAPPER_CPA_START_ADDR (WRAPPER_BASE + 0x1020) > +#define WRAPPER_CPA_END_ADDR (WRAPPER_BASE + 0x1024) > +#define WRAPPER_FW_START_ADDR(WRAPPER_BASE + 0x1028) > +#define WRAPPER_FW_END_ADDR (WRAPPER_BASE + 0x102C) > +#define WRAPPER_A9SS_SW_RESET(WRAPPER_BASE + 0x3000) > > /* Venus 4xx */ > #define WRAPPER_VCODEC0_MMCC_POWER_STATUS(WRAPPER_BASE + 0x90) -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v3 1/2] media: rc: introduce BPF_PROG_RAWIR_EVENT
On Wed, May 16, 2018 at 2:04 PM, Sean Young wrote: > Add support for BPF_PROG_RAWIR_EVENT. This type of BPF program can call > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report > that the last key should be repeated. > > The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall; > the target_fd must be the /dev/lircN device. > > Signed-off-by: Sean Young > --- > drivers/media/rc/Kconfig | 13 ++ > drivers/media/rc/Makefile | 1 + > drivers/media/rc/bpf-rawir-event.c | 363 + > drivers/media/rc/lirc_dev.c| 24 ++ > drivers/media/rc/rc-core-priv.h| 24 ++ > drivers/media/rc/rc-ir-raw.c | 14 +- > include/linux/bpf_rcdev.h | 30 +++ > include/linux/bpf_types.h | 3 + > include/uapi/linux/bpf.h | 55 - > kernel/bpf/syscall.c | 7 + > 10 files changed, 531 insertions(+), 3 deletions(-) > create mode 100644 drivers/media/rc/bpf-rawir-event.c > create mode 100644 include/linux/bpf_rcdev.h > > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig > index eb2c3b6eca7f..2172d65b0213 100644 > --- a/drivers/media/rc/Kconfig > +++ b/drivers/media/rc/Kconfig > @@ -25,6 +25,19 @@ config LIRC >passes raw IR to and from userspace, which is needed for >IR transmitting (aka "blasting") and for the lirc daemon. > > +config BPF_RAWIR_EVENT > + bool "Support for eBPF programs attached to lirc devices" > + depends on BPF_SYSCALL > + depends on RC_CORE=y > + depends on LIRC > + help > + Allow attaching eBPF programs to a lirc device using the bpf(2) > + syscall command BPF_PROG_ATTACH. This is supported for raw IR > + receivers. > + > + These eBPF programs can be used to decode IR into scancodes, for > + IR protocols not supported by the kernel decoders. > + > menuconfig RC_DECODERS > bool "Remote controller decoders" > depends on RC_CORE > diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile > index 2e1c87066f6c..74907823bef8 100644 > --- a/drivers/media/rc/Makefile > +++ b/drivers/media/rc/Makefile > @@ -5,6 +5,7 @@ obj-y += keymaps/ > obj-$(CONFIG_RC_CORE) += rc-core.o > rc-core-y := rc-main.o rc-ir-raw.o > rc-core-$(CONFIG_LIRC) += lirc_dev.o > +rc-core-$(CONFIG_BPF_RAWIR_EVENT) += bpf-rawir-event.o > obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o > obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o > obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o > diff --git a/drivers/media/rc/bpf-rawir-event.c > b/drivers/media/rc/bpf-rawir-event.c > new file mode 100644 > index ..7cb48b8d87b5 > --- /dev/null > +++ b/drivers/media/rc/bpf-rawir-event.c > @@ -0,0 +1,363 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// bpf-rawir-event.c - handles bpf > +// > +// Copyright (C) 2018 Sean Young > + > +#include > +#include > +#include > +#include "rc-core-priv.h" > + > +/* > + * BPF interface for raw IR > + */ > +const struct bpf_prog_ops rawir_event_prog_ops = { > +}; > + > +BPF_CALL_1(bpf_rc_repeat, struct bpf_rawir_event*, event) > +{ > + struct ir_raw_event_ctrl *ctrl; > + > + ctrl = container_of(event, struct ir_raw_event_ctrl, bpf_rawir_event); > + > + rc_repeat(ctrl->dev); > + > + return 0; > +} > + > +static const struct bpf_func_proto rc_repeat_proto = { > + .func = bpf_rc_repeat, > + .gpl_only = true, /* rc_repeat is EXPORT_SYMBOL_GPL */ > + .ret_type = RET_INTEGER, > + .arg1_type = ARG_PTR_TO_CTX, > +}; > + > +BPF_CALL_4(bpf_rc_keydown, struct bpf_rawir_event*, event, u32, protocol, > + u32, scancode, u32, toggle) > +{ > + struct ir_raw_event_ctrl *ctrl; > + > + ctrl = container_of(event, struct ir_raw_event_ctrl, bpf_rawir_event); > + > + rc_keydown(ctrl->dev, protocol, scancode, toggle != 0); > + > + return 0; > +} > + > +static const struct bpf_func_proto rc_keydown_proto = { > + .func = bpf_rc_keydown, > + .gpl_only = true, /* rc_keydown is EXPORT_SYMBOL_GPL */ > + .ret_type = RET_INTEGER, > + .arg1_type = ARG_PTR_TO_CTX, > + .arg2_type = ARG_ANYTHING, > + .arg3_type = ARG_ANYTHING, > + .arg4_type = ARG_ANYTHING, > +}; > + > +static const struct bpf_func_proto * > +rawir_event_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) > +{ > + switch (func_id) { > + case BPF_FUNC_rc_repeat: > + return &rc_repeat_proto; > + case BPF_FUNC_rc_keydown: > + return &rc_keydown_proto; > + case BPF_FUNC_map_lookup_elem: > + return &bpf_map_lookup_elem_proto; > + case BPF_FUNC_map_update_elem: > + return &bpf_map_update_elem_proto; > + case BPF_FUNC_map_delete_elem: > + return &bpf_map_delete_elem_proto; > + case BPF_FUNC_ktime_get_ns: > + return &bpf
Re: [PATCH v7 8/8] media: vsp1: Move video configuration to a cached dlb
Hi Laurent, On 17/05/18 15:35, Laurent Pinchart wrote: > Hi Kieran, > > On Monday, 30 April 2018 20:48:03 EEST Kieran Bingham wrote: >> On 07/04/18 01:23, Laurent Pinchart wrote: >>> On Thursday, 8 March 2018 02:05:31 EEST Kieran Bingham wrote: We are now able to configure a pipeline directly into a local display list body. Take advantage of this fact, and create a cacheable body to store the configuration of the pipeline in the video object. vsp1_video_pipeline_run() is now the last user of the pipe->dl object. Convert this function to use the cached video->config body and obtain a local display list reference. Attach the video->config body to the display list when needed before committing to hardware. The pipe object is marked as un-configured when resuming from a suspend. This ensures that when the hardware is reset - our cached configuration will be re-attached to the next committed DL. Signed-off-by: Kieran Bingham --- v3: - 's/fragment/body/', 's/fragments/bodies/' - video dlb cache allocation increased from 2 to 3 dlbs Our video DL usage now looks like the below output: dl->body0 contains our disposable runtime configuration. Max 41. dl_child->body0 is our partition specific configuration. Max 12. dl->bodies shows our constant configuration and LUTs. These two are LUT/CLU: * dl->bodies[x]->num_entries 256 / max 256 * dl->bodies[x]->num_entries 4914 / max 4914 Which shows that our 'constant' configuration cache is currently utilised to a maximum of 64 entries. trace-cmd report | \ grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq; dl->body0->num_entries 13 / max 128 dl->body0->num_entries 14 / max 128 dl->body0->num_entries 16 / max 128 dl->body0->num_entries 20 / max 128 dl->body0->num_entries 27 / max 128 dl->body0->num_entries 34 / max 128 dl->body0->num_entries 41 / max 128 dl_child->body0->num_entries 10 / max 128 dl_child->body0->num_entries 12 / max 128 dl->bodies[x]->num_entries 15 / max 128 dl->bodies[x]->num_entries 16 / max 128 dl->bodies[x]->num_entries 17 / max 128 dl->bodies[x]->num_entries 18 / max 128 dl->bodies[x]->num_entries 20 / max 128 dl->bodies[x]->num_entries 21 / max 128 dl->bodies[x]->num_entries 256 / max 256 dl->bodies[x]->num_entries 31 / max 128 dl->bodies[x]->num_entries 32 / max 128 dl->bodies[x]->num_entries 39 / max 128 dl->bodies[x]->num_entries 40 / max 128 dl->bodies[x]->num_entries 47 / max 128 dl->bodies[x]->num_entries 48 / max 128 dl->bodies[x]->num_entries 4914 / max 4914 dl->bodies[x]->num_entries 55 / max 128 dl->bodies[x]->num_entries 56 / max 128 dl->bodies[x]->num_entries 63 / max 128 dl->bodies[x]->num_entries 64 / max 128 >>> >>> This might be useful to capture in the main part of the commit message. >>> v4: - Adjust pipe configured flag to be reset on resume rather than suspend - rename dl_child, dl_next drivers/media/platform/vsp1/vsp1_pipe.c | 7 +++- drivers/media/platform/vsp1/vsp1_pipe.h | 4 +- drivers/media/platform/vsp1/vsp1_video.c | 67 - drivers/media/platform/vsp1/vsp1_video.h | 2 +- 4 files changed, 54 insertions(+), 26 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c b/drivers/media/platform/vsp1/vsp1_pipe.c index 5012643583b6..fa445b1a2e38 100644 --- a/drivers/media/platform/vsp1/vsp1_pipe.c +++ b/drivers/media/platform/vsp1/vsp1_pipe.c @@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe) vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index), VI6_CMD_STRCMD); pipe->state = VSP1_PIPELINE_RUNNING; + pipe->configured = true; } pipe->buffers_ready = 0; @@ -470,6 +471,12 @@ void vsp1_pipelines_resume(struct vsp1_device *vsp1) continue; spin_lock_irqsave(&pipe->irqlock, flags); + /* + * The hardware may have been reset during a suspend and will + * need a full reconfiguration + */ >>> >>> s/reconfiguration/reconfiguration./ >>> + pipe->configured = false; + >>> >>> Where does that full reconfiguration occur, given that the >>> vsp1_pipeline_run() right below sets pipe->configured to true without >>> performing reconfiguration ? > Q >> It's magic isn't it :D >> >> If the pipe->configured flag gets set to false, the next execution of >> vsp1_pipeline_run() attaches the video->pipe_config (the cached >> configuration, containing the route_setup() and
[PATCH v4] media: Remove depends on HAS_DMA in case of platform dependency
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Note: - The various VIDEOBUF*DMA* symbols had to loose their dependencies on HAS_DMA, as they are selected by several individual drivers. Signed-off-by: Geert Uytterhoeven Reviewed-by: Mark Brown Acked-by: Robin Murphy --- From: kbuild test robot tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git no-dma-compile-testing-v4-media branch HEAD: 9fd4215b490cae0bb6dd058a18a19e60dbcd3020 media: Remove depends on HAS_DMA in case of platform dependency elapsed time: 41m configs tested: 99 --- v4: - Rebase to media-next on 2018-05-17, v3: - Rebase to v4.17-rc1, - Handle new VIDEO_RENESAS_CEU symbol, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA, - Drop new dependencies of VIDEO_IPU3_CIO2 and DVB_C8SECTPFE on HAS_DMA, - Split per subsystem. --- drivers/media/common/videobuf2/Kconfig | 2 -- drivers/media/pci/dt3155/Kconfig | 1 - drivers/media/pci/intel/ipu3/Kconfig | 1 - drivers/media/pci/solo6x10/Kconfig | 1 - drivers/media/pci/sta2x11/Kconfig| 1 - drivers/media/pci/tw5864/Kconfig | 1 - drivers/media/pci/tw686x/Kconfig | 1 - drivers/media/platform/Kconfig | 43 +--- drivers/media/platform/am437x/Kconfig| 2 +- drivers/media/platform/atmel/Kconfig | 4 +-- drivers/media/platform/davinci/Kconfig | 6 drivers/media/platform/marvell-ccic/Kconfig | 2 -- drivers/media/platform/rcar-vin/Kconfig | 2 +- drivers/media/platform/soc_camera/Kconfig| 3 +- drivers/media/platform/sti/c8sectpfe/Kconfig | 2 +- drivers/media/v4l2-core/Kconfig | 2 -- drivers/staging/media/davinci_vpfe/Kconfig | 1 - drivers/staging/media/omap4iss/Kconfig | 1 - 18 files changed, 20 insertions(+), 56 deletions(-) diff --git a/drivers/media/common/videobuf2/Kconfig b/drivers/media/common/videobuf2/Kconfig index 17c32ea58395d78f..4ed11b46676ac4d0 100644 --- a/drivers/media/common/videobuf2/Kconfig +++ b/drivers/media/common/videobuf2/Kconfig @@ -12,7 +12,6 @@ config VIDEOBUF2_MEMOPS config VIDEOBUF2_DMA_CONTIG tristate - depends on HAS_DMA select VIDEOBUF2_CORE select VIDEOBUF2_MEMOPS select DMA_SHARED_BUFFER @@ -25,7 +24,6 @@ config VIDEOBUF2_VMALLOC config VIDEOBUF2_DMA_SG tristate - depends on HAS_DMA select VIDEOBUF2_CORE select VIDEOBUF2_MEMOPS diff --git a/drivers/media/pci/dt3155/Kconfig b/drivers/media/pci/dt3155/Kconfig index 5145e0dfa2aa9e12..858b0f2f15bef9c8 100644 --- a/drivers/media/pci/dt3155/Kconfig +++ b/drivers/media/pci/dt3155/Kconfig @@ -1,7 +1,6 @@ config VIDEO_DT3155 tristate "DT3155 frame grabber" depends on PCI && VIDEO_DEV && VIDEO_V4L2 - depends on HAS_DMA select VIDEOBUF2_DMA_CONTIG default n ---help--- diff --git a/drivers/media/pci/intel/ipu3/Kconfig b/drivers/media/pci/intel/ipu3/Kconfig index 45cf99a512e484d5..c8bd98d7564afdfb 100644 --- a/drivers/media/pci/intel/ipu3/Kconfig +++ b/drivers/media/pci/intel/ipu3/Kconfig @@ -4,7 +4,6 @@ config VIDEO_IPU3_CIO2 depends on VIDEO_V4L2_SUBDEV_API depends on (X86 && ACPI) || COMPILE_TEST depends on MEDIA_CONTROLLER - depends on HAS_DMA select V4L2_FWNODE select VIDEOBUF2_DMA_SG diff --git a/drivers/media/pci/solo6x10/Kconfig b/drivers/media/pci/solo6x10/Kconfig index 0fb91dc7ca73529e..d9e06a6bf1ebc1a7 100644 --- a/drivers/media/pci/solo6x10/Kconfig +++ b/drivers/media/pci/solo6x10/Kconfig @@ -1,7 +1,6 @@ config VIDEO_SOLO6X10 tristate "Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)" depends on PCI && VIDEO_DEV && SND && I2C - depends on HAS_DMA select BITREVERSE select FONT_SUPPORT select FONT_8x16 diff --git a/drivers/media/pci/sta2x11/Kconfig b/drivers/media/pci/sta2x11/Kconfig index 7af3f1cbcea824b9..4407b9f881e400d8 100644 --- a/drivers/media/pci/sta2x11/Kconfig +++ b/drivers/media/pci/sta2x11/Kconfig @@ -1,7 +1,6 @@ config STA2X11_VIP tristate "STA2X11 VIP Video For Linux" depends on STA2X11 || COMPILE_TEST - depends on HAS_DMA select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT select VIDEOBUF2_DMA_CONTIG depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS diff --git a/drivers/media/pci/tw5864/Kconfig b/drivers/media/pci/tw5864/
Re: [PATCH v3 2/2] bpf: add selftest for rawir_event type program
On Wed, May 16, 2018 at 2:04 PM, Sean Young wrote: > This is simple test over rc-loopback. > > Signed-off-by: Sean Young > --- > tools/bpf/bpftool/prog.c | 1 + > tools/include/uapi/linux/bpf.h| 57 +++- > tools/lib/bpf/libbpf.c| 1 + > tools/testing/selftests/bpf/Makefile | 8 +- > tools/testing/selftests/bpf/bpf_helpers.h | 6 + > tools/testing/selftests/bpf/test_rawir.sh | 37 + > .../selftests/bpf/test_rawir_event_kern.c | 26 > .../selftests/bpf/test_rawir_event_user.c | 130 ++ > 8 files changed, 261 insertions(+), 5 deletions(-) > create mode 100755 tools/testing/selftests/bpf/test_rawir.sh > create mode 100644 tools/testing/selftests/bpf/test_rawir_event_kern.c > create mode 100644 tools/testing/selftests/bpf/test_rawir_event_user.c Could you copy include/uapi/linux/lirc.h file to tools directory as well. Otherwise, I will get the following compilation error: gcc -Wall -O2 -I../../../include/uapi -I../../../lib -I../../../lib/bpf -I../../../../include/generated -I../../../include test_rawir_event_user.c /home/yhs/work/bpf-next/tools/testing/selftests/bpf/libbpf.a -lcap -lelf -lrt -lpthread -o /home/yhs/work/bpf-next/tools/testing/selftests/bpf/test_rawir_event_user test_rawir_event_user.c: In function ‘main’: test_rawir_event_user.c:60:15: error: ‘LIRC_MODE_SCANCODE’ undeclared (first use in this function); did you mean ‘LIRC_MODE_LIRCCODE’? mode = LIRC_MODE_SCANCODE; ^~ LIRC_MODE_LIRCCODE test_rawir_event_user.c:60:15: note: each undeclared identifier is reported only once for each function it appears in test_rawir_event_user.c:93:29: error: storage size of ‘lsc’ isn’t known struct lirc_scancode lsc; ^~~ test_rawir_event_user.c:93:29: warning: unused variable ‘lsc’ [-Wunused-variable] > > diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c > index 9bdfdf2d3fbe..8889a4ee8577 100644 > --- a/tools/bpf/bpftool/prog.c > +++ b/tools/bpf/bpftool/prog.c > @@ -71,6 +71,7 @@ static const char * const prog_type_name[] = { > [BPF_PROG_TYPE_SK_MSG] = "sk_msg", > [BPF_PROG_TYPE_RAW_TRACEPOINT] = "raw_tracepoint", > [BPF_PROG_TYPE_CGROUP_SOCK_ADDR] = "cgroup_sock_addr", > + [BPF_PROG_TYPE_RAWIR_EVENT] = "rawir_event", > }; > > static void print_boot_time(__u64 nsecs, char *buf, unsigned int size) > diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h > index 1205d86a7a29..243e141e8a5b 100644 > --- a/tools/include/uapi/linux/bpf.h > +++ b/tools/include/uapi/linux/bpf.h > @@ -141,6 +141,7 @@ enum bpf_prog_type { > BPF_PROG_TYPE_SK_MSG, > BPF_PROG_TYPE_RAW_TRACEPOINT, > BPF_PROG_TYPE_CGROUP_SOCK_ADDR, > + BPF_PROG_TYPE_RAWIR_EVENT, > }; > > enum bpf_attach_type { > @@ -158,6 +159,7 @@ enum bpf_attach_type { > BPF_CGROUP_INET6_CONNECT, > BPF_CGROUP_INET4_POST_BIND, > BPF_CGROUP_INET6_POST_BIND, > + BPF_RAWIR_EVENT, > __MAX_BPF_ATTACH_TYPE > }; > > @@ -1829,7 +1831,6 @@ union bpf_attr { > * Return > * 0 on success, or a negative error in case of failure. > * > - * > * int bpf_fib_lookup(void *ctx, struct bpf_fib_lookup *params, int plen, > u32 flags) > * Description > * Do FIB lookup in kernel tables using parameters in *params*. > @@ -1856,6 +1857,7 @@ union bpf_attr { > * Egress device index on success, 0 if packet needs to continue > * up the stack for further processing or a negative error in > case > * of failure. > + * > * int bpf_sock_hash_update(struct bpf_sock_ops_kern *skops, struct bpf_map > *map, void *key, u64 flags) > * Description > * Add an entry to, or update a sockhash *map* referencing > sockets. > @@ -1902,6 +1904,35 @@ union bpf_attr { > * egress otherwise). This is the only flag supported for now. > * Return > * **SK_PASS** on success, or **SK_DROP** on error. > + * > + * int bpf_rc_keydown(void *ctx, u32 protocol, u32 scancode, u32 toggle) > + * Description > + * Report decoded scancode with toggle value. For use in > + * BPF_PROG_TYPE_RAWIR_EVENT, to report a successfully > + * decoded scancode. This is will generate a keydown event, > + * and a keyup event once the scancode is no longer repeated. > + * > + * *ctx* pointer to bpf_rawir_event, *protocol* is decoded > + * protocol (see RC_PROTO_* enum). > + * > + * Some protocols include a toggle bit, in case the button > + * was released and pressed again between consecutive scancodes, > + * copy this bit into *toggle* if it exists, else set to 0. > + * > + * Return > + * Always return 0 (for now) >
[PATCH v10 1/8] media: vsp1: Reword uses of 'fragment' as 'body'
Throughout the codebase, the term 'fragment' is used to represent a display list body. This term duplicates the 'body' which is already in use. The datasheet references these objects as a body, therefore replace all mentions of a fragment with a body, along with the corresponding pluralised terms. Signed-off-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_clu.c | 10 +- drivers/media/platform/vsp1/vsp1_dl.c | 111 -- drivers/media/platform/vsp1/vsp1_dl.h | 13 +-- drivers/media/platform/vsp1/vsp1_lut.c | 8 +- 4 files changed, 70 insertions(+), 72 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_clu.c b/drivers/media/platform/vsp1/vsp1_clu.c index 96a448e1504c..ebfbb915dcdc 100644 --- a/drivers/media/platform/vsp1/vsp1_clu.c +++ b/drivers/media/platform/vsp1/vsp1_clu.c @@ -43,19 +43,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct v4l2_ctrl *ctrl) struct vsp1_dl_body *dlb; unsigned int i; - dlb = vsp1_dl_fragment_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17); + dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17); if (!dlb) return -ENOMEM; - vsp1_dl_fragment_write(dlb, VI6_CLU_ADDR, 0); + vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0); for (i = 0; i < 17 * 17 * 17; ++i) - vsp1_dl_fragment_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]); + vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]); spin_lock_irq(&clu->lock); swap(clu->clu, dlb); spin_unlock_irq(&clu->lock); - vsp1_dl_fragment_free(dlb); + vsp1_dl_body_free(dlb); return 0; } @@ -211,7 +211,7 @@ static void clu_configure(struct vsp1_entity *entity, spin_unlock_irqrestore(&clu->lock, flags); if (dlb) - vsp1_dl_list_add_fragment(dl, dlb); + vsp1_dl_list_add_body(dl, dlb); break; } } diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index 801dea475740..083da4f05c20 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -65,7 +65,7 @@ struct vsp1_dl_body { * @header: display list header, NULL for headerless lists * @dma: DMA address for the header * @body0: first display list body - * @fragments: list of extra display list bodies + * @bodies: list of extra display list bodies * @has_chain: if true, indicates that there's a partition chain * @chain: entry in the display list partition chain * @internal: whether the display list is used for internal purpose @@ -78,7 +78,7 @@ struct vsp1_dl_list { dma_addr_t dma; struct vsp1_dl_body body0; - struct list_head fragments; + struct list_head bodies; bool has_chain; struct list_head chain; @@ -97,13 +97,13 @@ enum vsp1_dl_mode { * @mode: display list operation mode (header or headerless) * @singleshot: execute the display list in single-shot mode * @vsp1: the VSP1 device - * @lock: protects the free, active, queued, pending and gc_fragments lists + * @lock: protects the free, active, queued, pending and gc_bodies lists * @free: array of all free display lists * @active: list currently being processed (loaded) by hardware * @queued: list queued to the hardware (written to the DL registers) * @pending: list waiting to be queued to the hardware - * @gc_work: fragments garbage collector work struct - * @gc_fragments: array of display list fragments waiting to be freed + * @gc_work: bodies garbage collector work struct + * @gc_bodies: array of display list bodies waiting to be freed */ struct vsp1_dl_manager { unsigned int index; @@ -118,7 +118,7 @@ struct vsp1_dl_manager { struct vsp1_dl_list *pending; struct work_struct gc_work; - struct list_head gc_fragments; + struct list_head gc_bodies; }; /* - @@ -156,18 +156,17 @@ static void vsp1_dl_body_cleanup(struct vsp1_dl_body *dlb) } /** - * vsp1_dl_fragment_alloc - Allocate a display list fragment + * vsp1_dl_body_alloc - Allocate a display list body * @vsp1: The VSP1 device - * @num_entries: The maximum number of entries that the fragment can contain + * @num_entries: The maximum number of entries that the body can contain * - * Allocate a display list fragment with enough memory to contain the requested + * Allocate a display list body with enough memory to contain the requested * number of entries. * - * Return a pointer to a fragment on success or NULL if memory can't be - * allocated. + * Return a pointer to a body on success or NULL if memory can't be allocated. */ -struct vsp1_dl_body *vsp1_dl_fragment_alloc(struct vsp1_device *vsp1, - unsigned
[PATCH v10 4/8] media: vsp1: Convert display lists to use new body pool
Adapt the dl->body0 object to use an object from the body pool. This greatly reduces the pressure on the TLB for IPMMU use cases, as all of the lists use a single allocation for the main body. The CLU and LUT objects pre-allocate a pool containing three bodies, allowing a userspace update before the hardware has committed a previous set of tables. Bodies are no longer 'freed' in interrupt context, but instead released back to their respective pools. This allows us to remove the garbage collector in the DLM. Signed-off-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_clu.c | 27 ++- drivers/media/platform/vsp1/vsp1_clu.h | 1 +- drivers/media/platform/vsp1/vsp1_dl.c | 221 ++ drivers/media/platform/vsp1/vsp1_dl.h | 3 +- drivers/media/platform/vsp1/vsp1_lut.c | 27 ++- drivers/media/platform/vsp1/vsp1_lut.h | 1 +- 6 files changed, 100 insertions(+), 180 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_clu.c b/drivers/media/platform/vsp1/vsp1_clu.c index ebfbb915dcdc..8efa12f5e53f 100644 --- a/drivers/media/platform/vsp1/vsp1_clu.c +++ b/drivers/media/platform/vsp1/vsp1_clu.c @@ -19,6 +19,8 @@ #define CLU_MIN_SIZE 4U #define CLU_MAX_SIZE 8190U +#define CLU_SIZE (17 * 17 * 17) + /* - * Device Access */ @@ -43,19 +45,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct v4l2_ctrl *ctrl) struct vsp1_dl_body *dlb; unsigned int i; - dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17); + dlb = vsp1_dl_body_get(clu->pool); if (!dlb) return -ENOMEM; vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0); - for (i = 0; i < 17 * 17 * 17; ++i) + for (i = 0; i < CLU_SIZE; ++i) vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]); spin_lock_irq(&clu->lock); swap(clu->clu, dlb); spin_unlock_irq(&clu->lock); - vsp1_dl_body_free(dlb); + vsp1_dl_body_put(dlb); return 0; } @@ -216,8 +218,16 @@ static void clu_configure(struct vsp1_entity *entity, } } +static void clu_destroy(struct vsp1_entity *entity) +{ + struct vsp1_clu *clu = to_clu(&entity->subdev); + + vsp1_dl_body_pool_destroy(clu->pool); +} + static const struct vsp1_entity_operations clu_entity_ops = { .configure = clu_configure, + .destroy = clu_destroy, }; /* - @@ -243,6 +253,17 @@ struct vsp1_clu *vsp1_clu_create(struct vsp1_device *vsp1) if (ret < 0) return ERR_PTR(ret); + /* +* Pre-allocate a body pool, with 3 bodies allowing a userspace update +* before the hardware has committed a previous set of tables, handling +* both the queued and pending dl entries. One extra entry is added to +* the CLU_SIZE to allow for the VI6_CLU_ADDR header. +*/ + clu->pool = vsp1_dl_body_pool_create(clu->entity.vsp1, 3, CLU_SIZE + 1, +0); + if (!clu->pool) + return ERR_PTR(-ENOMEM); + /* Initialize the control handler. */ v4l2_ctrl_handler_init(&clu->ctrls, 2); v4l2_ctrl_new_custom(&clu->ctrls, &clu_table_control, NULL); diff --git a/drivers/media/platform/vsp1/vsp1_clu.h b/drivers/media/platform/vsp1/vsp1_clu.h index c45e6e707592..cef2f44481ba 100644 --- a/drivers/media/platform/vsp1/vsp1_clu.h +++ b/drivers/media/platform/vsp1/vsp1_clu.h @@ -32,6 +32,7 @@ struct vsp1_clu { spinlock_t lock; unsigned int mode; struct vsp1_dl_body *clu; + struct vsp1_dl_body_pool *pool; }; static inline struct vsp1_clu *to_clu(struct v4l2_subdev *subdev) diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index 41ace89a585b..617c46a03dec 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -108,7 +108,7 @@ struct vsp1_dl_list { struct vsp1_dl_header *header; dma_addr_t dma; - struct vsp1_dl_body body0; + struct vsp1_dl_body *body0; struct list_head bodies; bool has_chain; @@ -128,14 +128,12 @@ enum vsp1_dl_mode { * @mode: display list operation mode (header or headerless) * @singleshot: execute the display list in single-shot mode * @vsp1: the VSP1 device - * @lock: protects the free, active, queued, pending and gc_bodies lists + * @lock: protects the free, active, queued, and pending lists * @free: array of all free display lists * @active: list currently being processed (loaded) by hardware * @queued: list queued to the hardware (written to the DL registers) * @pending: list waiting to be queued to the ha
[PATCH v10 7/8] media: vsp1: Adapt entities to configure into a body
Currently the entities store their configurations into a display list. Adapt this such that the code can be configured into a body directly, allowing greater flexibility and control of the content. All users of vsp1_dl_list_write() are removed in this process, thus it too is removed. A helper, vsp1_dl_list_get_body0() is provided to access the internal body0 from the display list. Signed-off-by: Kieran Bingham [Don't remove blank line unnecessarily] Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_brx.c| 22 ++-- drivers/media/platform/vsp1/vsp1_clu.c| 23 ++--- drivers/media/platform/vsp1/vsp1_dl.c | 12 ++- drivers/media/platform/vsp1/vsp1_dl.h | 2 +- drivers/media/platform/vsp1/vsp1_drm.c| 12 --- drivers/media/platform/vsp1/vsp1_entity.c | 22 ++-- drivers/media/platform/vsp1/vsp1_entity.h | 18 ++ drivers/media/platform/vsp1/vsp1_hgo.c| 16 - drivers/media/platform/vsp1/vsp1_hgt.c| 18 +- drivers/media/platform/vsp1/vsp1_hsit.c | 10 +++--- drivers/media/platform/vsp1/vsp1_lif.c| 15 drivers/media/platform/vsp1/vsp1_lut.c| 23 ++--- drivers/media/platform/vsp1/vsp1_pipe.c | 4 +- drivers/media/platform/vsp1/vsp1_pipe.h | 3 +- drivers/media/platform/vsp1/vsp1_rpf.c| 43 drivers/media/platform/vsp1/vsp1_sru.c| 14 drivers/media/platform/vsp1/vsp1_uds.c| 25 +++--- drivers/media/platform/vsp1/vsp1_uds.h| 2 +- drivers/media/platform/vsp1/vsp1_uif.c| 21 ++-- drivers/media/platform/vsp1/vsp1_video.c | 16 ++--- drivers/media/platform/vsp1/vsp1_wpf.c| 42 --- 21 files changed, 194 insertions(+), 169 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_brx.c b/drivers/media/platform/vsp1/vsp1_brx.c index 011edac5ebc1..359917b5d842 100644 --- a/drivers/media/platform/vsp1/vsp1_brx.c +++ b/drivers/media/platform/vsp1/vsp1_brx.c @@ -26,10 +26,10 @@ * Device Access */ -static inline void vsp1_brx_write(struct vsp1_brx *brx, struct vsp1_dl_list *dl, - u32 reg, u32 data) +static inline void vsp1_brx_write(struct vsp1_brx *brx, + struct vsp1_dl_body *dlb, u32 reg, u32 data) { - vsp1_dl_list_write(dl, brx->base + reg, data); + vsp1_dl_body_write(dlb, brx->base + reg, data); } /* - @@ -283,7 +283,7 @@ static const struct v4l2_subdev_ops brx_ops = { static void brx_configure_stream(struct vsp1_entity *entity, struct vsp1_pipeline *pipe, -struct vsp1_dl_list *dl) +struct vsp1_dl_body *dlb) { struct vsp1_brx *brx = to_brx(&entity->subdev); struct v4l2_mbus_framefmt *format; @@ -305,7 +305,7 @@ static void brx_configure_stream(struct vsp1_entity *entity, * format at the pipeline output is premultiplied. */ flags = pipe->output ? pipe->output->format.flags : 0; - vsp1_brx_write(brx, dl, VI6_BRU_INCTRL, + vsp1_brx_write(brx, dlb, VI6_BRU_INCTRL, flags & V4L2_PIX_FMT_FLAG_PREMUL_ALPHA ? 0 : VI6_BRU_INCTRL_NRM); @@ -313,12 +313,12 @@ static void brx_configure_stream(struct vsp1_entity *entity, * Set the background position to cover the whole output image and * configure its color. */ - vsp1_brx_write(brx, dl, VI6_BRU_VIRRPF_SIZE, + vsp1_brx_write(brx, dlb, VI6_BRU_VIRRPF_SIZE, (format->width << VI6_BRU_VIRRPF_SIZE_HSIZE_SHIFT) | (format->height << VI6_BRU_VIRRPF_SIZE_VSIZE_SHIFT)); - vsp1_brx_write(brx, dl, VI6_BRU_VIRRPF_LOC, 0); + vsp1_brx_write(brx, dlb, VI6_BRU_VIRRPF_LOC, 0); - vsp1_brx_write(brx, dl, VI6_BRU_VIRRPF_COL, brx->bgcolor | + vsp1_brx_write(brx, dlb, VI6_BRU_VIRRPF_COL, brx->bgcolor | (0xff << VI6_BRU_VIRRPF_COL_A_SHIFT)); /* @@ -328,7 +328,7 @@ static void brx_configure_stream(struct vsp1_entity *entity, * unit. */ if (entity->type == VSP1_ENTITY_BRU) - vsp1_brx_write(brx, dl, VI6_BRU_ROP, + vsp1_brx_write(brx, dlb, VI6_BRU_ROP, VI6_BRU_ROP_DSTSEL_BRUIN(1) | VI6_BRU_ROP_CROP(VI6_ROP_NOP) | VI6_BRU_ROP_AROP(VI6_ROP_NOP)); @@ -370,7 +370,7 @@ static void brx_configure_stream(struct vsp1_entity *entity, if (!(entity->type == VSP1_ENTITY_BRU && i == 1)) ctrl |= VI6_BRU_CTRL_SRCSEL_BRUIN(i); - vsp1_brx_write(brx, dl, VI6_BRU_CTRL(i), ctrl); + vsp1_brx_write(brx, dlb, VI6_BRU_CTRL(i), ctrl); /*
[PATCH v10 5/8] media: vsp1: Use reference counting for bodies
Extend the display list body with a reference count, allowing bodies to be kept as long as a reference is maintained. This provides the ability to keep a cached copy of bodies which will not change, so that they can be re-applied to multiple display lists. Signed-off-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_clu.c | 7 ++- drivers/media/platform/vsp1/vsp1_dl.c | 16 ++-- drivers/media/platform/vsp1/vsp1_lut.c | 7 ++- 3 files changed, 26 insertions(+), 4 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_clu.c b/drivers/media/platform/vsp1/vsp1_clu.c index 8efa12f5e53f..ea83f1b7d125 100644 --- a/drivers/media/platform/vsp1/vsp1_clu.c +++ b/drivers/media/platform/vsp1/vsp1_clu.c @@ -212,8 +212,13 @@ static void clu_configure(struct vsp1_entity *entity, clu->clu = NULL; spin_unlock_irqrestore(&clu->lock, flags); - if (dlb) + if (dlb) { vsp1_dl_list_add_body(dl, dlb); + + /* Release our local reference. */ + vsp1_dl_body_put(dlb); + } + break; } } diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index 617c46a03dec..1407c90c6880 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include @@ -54,6 +55,8 @@ struct vsp1_dl_body { struct list_head list; struct list_head free; + refcount_t refcnt; + struct vsp1_dl_body_pool *pool; struct vsp1_device *vsp1; @@ -258,6 +261,7 @@ struct vsp1_dl_body *vsp1_dl_body_get(struct vsp1_dl_body_pool *pool) if (!list_empty(&pool->free)) { dlb = list_first_entry(&pool->free, struct vsp1_dl_body, free); list_del(&dlb->free); + refcount_set(&dlb->refcnt, 1); } spin_unlock_irqrestore(&pool->lock, flags); @@ -278,6 +282,9 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb) if (!dlb) return; + if (!refcount_dec_and_test(&dlb->refcnt)) + return; + dlb->num_entries = 0; spin_lock_irqsave(&dlb->pool->lock, flags); @@ -463,8 +470,11 @@ void vsp1_dl_list_write(struct vsp1_dl_list *dl, u32 reg, u32 data) * which bodies are added. * * Adding a body to a display list passes ownership of the body to the list. The - * caller must not touch the body after this call, and must not release it - * explicitly with vsp1_dl_body_put(). + * caller retains its reference to the fragment when adding it to the display + * list, but is not allowed to add new entries to the body. + * + * The reference must be explicitly released by a call to vsp1_dl_body_put() + * when the body isn't needed anymore. * * Additional bodies are only usable for display lists in header mode. * Attempting to add a body to a header-less display list will return an error. @@ -475,6 +485,8 @@ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl, struct vsp1_dl_body *dlb) if (dl->dlm->mode != VSP1_DL_MODE_HEADER) return -EINVAL; + refcount_inc(&dlb->refcnt); + list_add_tail(&dlb->list, &dl->bodies); return 0; diff --git a/drivers/media/platform/vsp1/vsp1_lut.c b/drivers/media/platform/vsp1/vsp1_lut.c index 6b358617ce15..b3ea90172439 100644 --- a/drivers/media/platform/vsp1/vsp1_lut.c +++ b/drivers/media/platform/vsp1/vsp1_lut.c @@ -168,8 +168,13 @@ static void lut_configure(struct vsp1_entity *entity, lut->lut = NULL; spin_unlock_irqrestore(&lut->lock, flags); - if (dlb) + if (dlb) { vsp1_dl_list_add_body(dl, dlb); + + /* Release our local reference. */ + vsp1_dl_body_put(dlb); + } + break; } } -- git-series 0.9.1
[PATCH v10 8/8] media: vsp1: Move video configuration to a cached dlb
We are now able to configure a pipeline directly into a local display list body. Take advantage of this fact, and create a cacheable body to store the configuration of the pipeline in the video object. vsp1_video_pipeline_run() is now the last user of the pipe->dl object. Convert this function to use the cached video->config body and obtain a local display list reference. Attach the video->config body to the display list when needed before committing to hardware. The pipe object is marked as un-configured when resuming from a suspend. This ensures that when the hardware is reset - our cached configuration will be re-attached to the next committed DL. Our video DL usage now looks like the below output: dl->body0 contains our disposable runtime configuration. Max 41. dl_child->body0 is our partition specific configuration. Max 12. dl->bodies shows our constant configuration and LUTs. These two are LUT/CLU: * dl->bodies[x]->num_entries 256 / max 256 * dl->bodies[x]->num_entries 4914 / max 4914 Which shows that our 'constant' configuration cache is currently utilised to a maximum of 64 entries. trace-cmd report | \ grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq; dl->body0->num_entries 13 / max 128 dl->body0->num_entries 14 / max 128 dl->body0->num_entries 16 / max 128 dl->body0->num_entries 20 / max 128 dl->body0->num_entries 27 / max 128 dl->body0->num_entries 34 / max 128 dl->body0->num_entries 41 / max 128 dl_child->body0->num_entries 10 / max 128 dl_child->body0->num_entries 12 / max 128 dl->bodies[x]->num_entries 15 / max 128 dl->bodies[x]->num_entries 16 / max 128 dl->bodies[x]->num_entries 17 / max 128 dl->bodies[x]->num_entries 18 / max 128 dl->bodies[x]->num_entries 20 / max 128 dl->bodies[x]->num_entries 21 / max 128 dl->bodies[x]->num_entries 256 / max 256 dl->bodies[x]->num_entries 31 / max 128 dl->bodies[x]->num_entries 32 / max 128 dl->bodies[x]->num_entries 39 / max 128 dl->bodies[x]->num_entries 40 / max 128 dl->bodies[x]->num_entries 47 / max 128 dl->bodies[x]->num_entries 48 / max 128 dl->bodies[x]->num_entries 4914 / max 4914 dl->bodies[x]->num_entries 55 / max 128 dl->bodies[x]->num_entries 56 / max 128 dl->bodies[x]->num_entries 63 / max 128 dl->bodies[x]->num_entries 64 / max 128 Signed-off-by: Kieran Bingham --- v10: - Removed pipe->configured flag, and use pipe->state == VSP1_PIPELINE_STOPPED instead. v8: - Fix comments - Rename video->pipe_config -> video->stream_config v4: - Adjust pipe configured flag to be reset on resume rather than suspend - rename dl_child, dl_next v3: - 's/fragment/body/', 's/fragments/bodies/' - video dlb cache allocation increased from 2 to 3 dlbs drivers/media/platform/vsp1/vsp1_pipe.h | 3 +- drivers/media/platform/vsp1/vsp1_video.c | 67 +++-- drivers/media/platform/vsp1/vsp1_video.h | 2 +- 3 files changed, 43 insertions(+), 29 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h b/drivers/media/platform/vsp1/vsp1_pipe.h index e00010693eef..be6ecab3cbed 100644 --- a/drivers/media/platform/vsp1/vsp1_pipe.h +++ b/drivers/media/platform/vsp1/vsp1_pipe.h @@ -102,7 +102,6 @@ struct vsp1_partition { * @uds: UDS entity, if present * @uds_input: entity at the input of the UDS, if the UDS is present * @entities: list of entities in the pipeline - * @dl: display list associated with the pipeline * @partitions: The number of partitions used to process one frame * @partition: The current partition for configuration to process * @part_table: The pre-calculated partitions used by the pipeline @@ -139,8 +138,6 @@ struct vsp1_pipeline { */ struct list_head entities; - struct vsp1_dl_list *dl; - unsigned int partitions; struct vsp1_partition *partition; struct vsp1_partition *part_table; diff --git a/drivers/media/platform/vsp1/vsp1_video.c b/drivers/media/platform/vsp1/vsp1_video.c index 72f29773eb1c..f2bc26d28396 100644 --- a/drivers/media/platform/vsp1/vsp1_video.c +++ b/drivers/media/platform/vsp1/vsp1_video.c @@ -390,44 +390,48 @@ static void vsp1_video_pipeline_run_partition(struct vsp1_pipeline *pipe, static void vsp1_video_pipeline_run(struct vsp1_pipeline *pipe) { struct vsp1_device *vsp1 = pipe->output->entity.vsp1; + struct vsp1_video *video = pipe->output->video; struct vsp1_entity *entity; struct vsp1_dl_body *dlb; + struct vsp1_dl_list *dl; unsigned int partition; - if (!pipe->dl) - pipe->dl = vsp1_dl_list_get(pipe->output->dlm); + dl = vsp1_dl_list_get(pipe->output->dlm); + + /* Attach our pipe configuration to fully initialise the hardware. */ + if (pipe->state == VSP1_PIPELINE_STOPPED) + vsp1_dl_list_add_body(dl, video->stream_config); - dlb = vsp1_dl_list_get_body0(pipe->dl); + dlb = vsp1_dl_list_get_body0(dl); list_for_each_ent
[PATCH v10 3/8] media: vsp1: Provide a body pool
Each display list allocates a body to store register values in a dma accessible buffer from a dma_alloc_wc() allocation. Each of these results in an entry in the IOMMU TLB, and a large number of display list allocations adds pressure to this resource. Reduce TLB pressure on the IPMMUs by allocating multiple display list bodies in a single allocation, and providing these to the display list through a 'body pool'. A pool can be allocated by the display list manager or entities which require their own body allocations. Signed-off-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_dl.c | 163 +++- drivers/media/platform/vsp1/vsp1_dl.h | 8 +- 2 files changed, 171 insertions(+) diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index 51965c30dec2..41ace89a585b 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -41,6 +41,8 @@ struct vsp1_dl_entry { /** * struct vsp1_dl_body - Display list body * @list: entry in the display list list of bodies + * @free: entry in the pool free body list + * @pool: pool to which this body belongs * @vsp1: the VSP1 device * @entries: array of entries * @dma: DMA address of the entries @@ -50,6 +52,9 @@ struct vsp1_dl_entry { */ struct vsp1_dl_body { struct list_head list; + struct list_head free; + + struct vsp1_dl_body_pool *pool; struct vsp1_device *vsp1; struct vsp1_dl_entry *entries; @@ -61,6 +66,30 @@ struct vsp1_dl_body { }; /** + * struct vsp1_dl_body_pool - display list body pool + * @dma: DMA address of the entries + * @size: size of the full DMA memory pool in bytes + * @mem: CPU memory pointer for the pool + * @bodies: Array of DLB structures for the pool + * @free: List of free DLB entries + * @lock: Protects the free list + * @vsp1: the VSP1 device + */ +struct vsp1_dl_body_pool { + /* DMA allocation */ + dma_addr_t dma; + size_t size; + void *mem; + + /* Body management */ + struct vsp1_dl_body *bodies; + struct list_head free; + spinlock_t lock; + + struct vsp1_device *vsp1; +}; + +/** * struct vsp1_dl_list - Display list * @list: entry in the display list manager lists * @dlm: the display list manager @@ -104,6 +133,7 @@ enum vsp1_dl_mode { * @active: list currently being processed (loaded) by hardware * @queued: list queued to the hardware (written to the DL registers) * @pending: list waiting to be queued to the hardware + * @pool: body pool for the display list bodies * @gc_work: bodies garbage collector work struct * @gc_bodies: array of display list bodies waiting to be freed */ @@ -119,6 +149,8 @@ struct vsp1_dl_manager { struct vsp1_dl_list *queued; struct vsp1_dl_list *pending; + struct vsp1_dl_body_pool *pool; + struct work_struct gc_work; struct list_head gc_bodies; }; @@ -127,6 +159,137 @@ struct vsp1_dl_manager { * Display List Body Management */ +/** + * vsp1_dl_body_pool_create - Create a pool of bodies from a single allocation + * @vsp1: The VSP1 device + * @num_bodies: The number of bodies to allocate + * @num_entries: The maximum number of entries that a body can contain + * @extra_size: Extra allocation provided for the bodies + * + * Allocate a pool of display list bodies each with enough memory to contain the + * requested number of entries plus the @extra_size. + * + * Return a pointer to a pool on success or NULL if memory can't be allocated. + */ +struct vsp1_dl_body_pool * +vsp1_dl_body_pool_create(struct vsp1_device *vsp1, unsigned int num_bodies, +unsigned int num_entries, size_t extra_size) +{ + struct vsp1_dl_body_pool *pool; + size_t dlb_size; + unsigned int i; + + pool = kzalloc(sizeof(*pool), GFP_KERNEL); + if (!pool) + return NULL; + + pool->vsp1 = vsp1; + + /* +* TODO: 'extra_size' is only used by vsp1_dlm_create(), to allocate +* extra memory for the display list header. We need only one header per +* display list, not per display list body, thus this allocation is +* extraneous and should be reworked in the future. +*/ + dlb_size = num_entries * sizeof(struct vsp1_dl_entry) + extra_size; + pool->size = dlb_size * num_bodies; + + pool->bodies = kcalloc(num_bodies, sizeof(*pool->bodies), GFP_KERNEL); + if (!pool->bodies) { + kfree(pool); + return NULL; + } + + pool->mem = dma_alloc_wc(vsp1->bus_master, pool->size, &pool->dma, +GFP_KERNEL); + if (!pool->mem) { + kfree(pool->bodies); + kfree(pool); + return NULL; + } + + spin_lock_init(&pool->lock); + INIT_LIST_HEAD(&pool->free); + + for (i = 0;
[PATCH v10 0/8] vsp1: TLB optimisation and DL caching
Each display list currently allocates an area of DMA memory to store register settings for the VSP1 to process. Each of these allocations adds pressure to the IPMMU TLB entries. We can reduce the pressure by pre-allocating larger areas and dividing the area across multiple bodies represented as a pool. With this reconfiguration of bodies, we can adapt the configuration code to separate out constant hardware configuration and cache it for re-use. The patches provided in this series can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git tags/vsp1/tlb-optimise/v10 Changelog: -- v10: - Rebase to latest linux-media/master - Remove pipe->configured flag, as pipe->state is suitable for the same purpose, as: (!pipe->configured) == (pipe->state == VSP1_PIPELINE_STOPPED) v9: - Pass the DL through configure_partition() calls - Remove redundant reference to gc_bodies v8: - Fix formatting and white space - Reword vsp1_dl_list_add_body() documentation - Update commit message on "Provide a body pool" - No longer pass unnecessary dlm->pool through vsp1_dl_list_alloc() - Add support for the new UIF entity - Fix comment location for clu_configure_stream() - Implement configure_partition separation - Rename video->pipe_config to video->stream_config v7: - Rebased on to linux-media/master (v4.16-rc4) - Clean up the formatting of the vsp1_dl_list_add_body() - Fix formatting and white space - s/prepare/configure_stream/ - s/configure/configure_frame/ v6: - Rebased on to linux-media/master (v4.16-rc1) - Removed DRM/UIF (DISCOM/ColorKey) updates v5: - Rebased on to renesas-drivers-2018-01-09-v4.15-rc7 to fix conflicts with DRM and UIF updates on VSP1 driver v4: - Rebased to v4.14 * v4l: vsp1: Use reference counting for bodies - Fix up reference handling comments * v4l: vsp1: Provide a body pool - Provide comment explaining extra allocation on body pool highlighting area for optimisation later. * v4l: vsp1: Refactor display list configure operations - Fix up comment to describe yuv_mode caching rather than format * vsp1: Adapt entities to configure into a body - Rename vsp1_dl_list_get_body() to vsp1_dl_list_get_body0() * v4l: vsp1: Move video configuration to a cached dlb - Adjust pipe configured flag to be reset on resume rather than suspend - rename dl_child, dl_next Testing: The VSP unit tests have been run on this patch set with the following results: root@Ubuntu-ARM64:~/vsp-tests# ./vsp-tests.sh --- Test loop 1 --- - vsp-unit-test-.sh Test Conditions: Platform Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ Kernel release4.17.0-rc4-arm64-renesas-00397-g3d2f6f2901b0 convert /usr/bin/convert compare /usr/bin/compare killall /usr/bin/killall raw2rgbpnm/usr/bin/raw2rgbpnm stress/usr/bin/stress yavta /usr/bin/yavta - vsp-unit-test-0001.sh Testing WPF packing in RGB332: pass Testing WPF packing in ARGB555: pass Testing WPF packing in XRGB555: pass Testing WPF packing in RGB565: pass Testing WPF packing in BGR24: pass Testing WPF packing in RGB24: pass Testing WPF packing in ABGR32: pass Testing WPF packing in ARGB32: pass Testing WPF packing in XBGR32: pass Testing WPF packing in XRGB32: pass - vsp-unit-test-0002.sh Testing WPF packing in NV12M: pass Testing WPF packing in NV16M: pass Testing WPF packing in NV21M: pass Testing WPF packing in NV61M: pass Testing WPF packing in UYVY: pass Testing WPF packing in VYUY: skip Testing WPF packing in YUV420M: pass Testing WPF packing in YUV422M: pass Testing WPF packing in YUV444M: pass Testing WPF packing in YVU420M: pass Testing WPF packing in YVU422M: pass Testing WPF packing in YVU444M: pass Testing WPF packing in YUYV: pass Testing WPF packing in YVYU: pass - vsp-unit-test-0003.sh Testing scaling from 640x640 to 640x480 in RGB24: pass Testing scaling from 1024x768 to 640x480 in RGB24: pass Testing scaling from 640x480 to 1024x768 in RGB24: pass Testing scaling from 640x640 to 640x480 in YUV444M: pass Testing scaling from 1024x768 to 640x480 in YUV444M: pass Testing scaling from 640x480 to 1024x768 in YUV444M: pass - vsp-unit-test-0004.sh Testing histogram in RGB24: pass Testing histogram in YUV444M: pass - vsp-unit-test-0005.sh Testing RPF.0: pass Testing RPF.1: pass Testing RPF.2: pass Testing RPF.3: pass Testing RPF.4: pass - vsp-unit-test-0006.sh Testing invalid pipeline with no RPF: pass Testing invalid pipeline with no WPF: pass - vsp-unit-test-0007.sh Testing BRU in RGB24 with 1 inputs: pass Testing BRU in RGB24 with 2 inputs: pass Testing BRU in RGB24 with 3 inputs: pass Testing BRU in RGB24 with 4 inputs: pass Testing BRU in RGB24 with 5 inputs: pass Testing BRU in YUV444M with 1 inputs: pass Testing BRU in YUV444M with 2 inputs: pass Testing BRU in YUV444M with 3 inputs: pass Testing BRU in YUV444M with 4 inputs: pass Testing BRU in YUV444M with 5
[PATCH v10 6/8] media: vsp1: Refactor display list configure operations
The entities provide a single .configure operation which configures the object into the target display list, based on the vsp1_entity_params selection. Split the configure function into three parts, '.configure_stream()', '.configure_frame()', and '.configure_partition()' to facilitate splitting the configuration of each parameter class into separate display list bodies. Signed-off-by: Kieran Bingham [Blank line reformatting, remote unneeded local variable initialization] Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_brx.c| 12 +- drivers/media/platform/vsp1/vsp1_clu.c| 78 ++ drivers/media/platform/vsp1/vsp1_drm.c| 12 +- drivers/media/platform/vsp1/vsp1_entity.c | 24 ++- drivers/media/platform/vsp1/vsp1_entity.h | 39 +-- drivers/media/platform/vsp1/vsp1_hgo.c| 12 +- drivers/media/platform/vsp1/vsp1_hgt.c| 12 +- drivers/media/platform/vsp1/vsp1_hsit.c | 12 +- drivers/media/platform/vsp1/vsp1_lif.c| 12 +- drivers/media/platform/vsp1/vsp1_lut.c| 47 +--- drivers/media/platform/vsp1/vsp1_rpf.c| 168 ++--- drivers/media/platform/vsp1/vsp1_sru.c| 12 +- drivers/media/platform/vsp1/vsp1_uds.c| 56 ++-- drivers/media/platform/vsp1/vsp1_uif.c| 16 +- drivers/media/platform/vsp1/vsp1_video.c | 28 +-- drivers/media/platform/vsp1/vsp1_wpf.c| 302 --- 16 files changed, 422 insertions(+), 420 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_brx.c b/drivers/media/platform/vsp1/vsp1_brx.c index 3beec18fd863..011edac5ebc1 100644 --- a/drivers/media/platform/vsp1/vsp1_brx.c +++ b/drivers/media/platform/vsp1/vsp1_brx.c @@ -281,19 +281,15 @@ static const struct v4l2_subdev_ops brx_ops = { * VSP1 Entity Operations */ -static void brx_configure(struct vsp1_entity *entity, - struct vsp1_pipeline *pipe, - struct vsp1_dl_list *dl, - enum vsp1_entity_params params) +static void brx_configure_stream(struct vsp1_entity *entity, +struct vsp1_pipeline *pipe, +struct vsp1_dl_list *dl) { struct vsp1_brx *brx = to_brx(&entity->subdev); struct v4l2_mbus_framefmt *format; unsigned int flags; unsigned int i; - if (params != VSP1_ENTITY_PARAMS_INIT) - return; - format = vsp1_entity_get_pad_format(&brx->entity, brx->entity.config, brx->entity.source_pad); @@ -400,7 +396,7 @@ static void brx_configure(struct vsp1_entity *entity, } static const struct vsp1_entity_operations brx_entity_ops = { - .configure = brx_configure, + .configure_stream = brx_configure_stream, }; /* - diff --git a/drivers/media/platform/vsp1/vsp1_clu.c b/drivers/media/platform/vsp1/vsp1_clu.c index ea83f1b7d125..34f17a82ac1f 100644 --- a/drivers/media/platform/vsp1/vsp1_clu.c +++ b/drivers/media/platform/vsp1/vsp1_clu.c @@ -169,57 +169,50 @@ static const struct v4l2_subdev_ops clu_ops = { * VSP1 Entity Operations */ -static void clu_configure(struct vsp1_entity *entity, - struct vsp1_pipeline *pipe, - struct vsp1_dl_list *dl, - enum vsp1_entity_params params) +static void clu_configure_stream(struct vsp1_entity *entity, +struct vsp1_pipeline *pipe, +struct vsp1_dl_list *dl) +{ + struct vsp1_clu *clu = to_clu(&entity->subdev); + struct v4l2_mbus_framefmt *format; + + /* +* The yuv_mode can't be changed during streaming. Cache it internally +* for future runtime configuration calls. +*/ + format = vsp1_entity_get_pad_format(&clu->entity, + clu->entity.config, + CLU_PAD_SINK); + clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32; +} + +static void clu_configure_frame(struct vsp1_entity *entity, + struct vsp1_pipeline *pipe, + struct vsp1_dl_list *dl) { struct vsp1_clu *clu = to_clu(&entity->subdev); struct vsp1_dl_body *dlb; unsigned long flags; u32 ctrl = VI6_CLU_CTRL_AAI | VI6_CLU_CTRL_MVS | VI6_CLU_CTRL_EN; - switch (params) { - case VSP1_ENTITY_PARAMS_INIT: { - /* -* The format can't be changed during streaming, only verify it -* at setup time and store the information internally for future -* runtime configuration calls. -*/ - struct v4l2_mbus_framefmt *format; - - format = vsp1_entity_get_pad_format(&clu->entity, - c
[PATCH v10 2/8] media: vsp1: Protect bodies against overflow
The body write function relies on the code never asking it to write more than the entries available in the list. Currently with each list body containing 256 entries, this is fine, but we can reduce this number greatly saving memory. In preparation of this add a level of protection to catch any buffer overflows. Signed-off-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_dl.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index 083da4f05c20..51965c30dec2 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -46,6 +46,7 @@ struct vsp1_dl_entry { * @dma: DMA address of the entries * @size: size of the DMA memory in bytes * @num_entries: number of stored entries + * @max_entries: number of entries available */ struct vsp1_dl_body { struct list_head list; @@ -56,6 +57,7 @@ struct vsp1_dl_body { size_t size; unsigned int num_entries; + unsigned int max_entries; }; /** @@ -138,6 +140,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1, dlb->vsp1 = vsp1; dlb->size = size; + dlb->max_entries = num_entries; dlb->entries = dma_alloc_wc(vsp1->bus_master, dlb->size, &dlb->dma, GFP_KERNEL); @@ -219,6 +222,10 @@ void vsp1_dl_body_free(struct vsp1_dl_body *dlb) */ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 reg, u32 data) { + if (WARN_ONCE(dlb->num_entries >= dlb->max_entries, + "DLB size exceeded (max %u)", dlb->max_entries)) + return; + dlb->entries[dlb->num_entries].addr = reg; dlb->entries[dlb->num_entries].data = data; dlb->num_entries++; -- git-series 0.9.1
Re: [PATCH v4 03/12] clk: imx7d: fix mipi dphy div parent
Quoting Rui Miguel Silva (2018-05-17 05:50:24) > Fix the mipi dphy root divider to mipi_dphy_pre_div, this would remove a > orphan > clock and set the correct parent. > > before: > cat clk_orphan_summary > enable prepare protect >clock countcountcountrate > accuracy phase > > mipi_dphy_post_div 110 0 > 0 0 > mipi_dphy_root_clk110 0 > 0 0 > > cat clk_dump | grep mipi_dphy > mipi_dphy_post_div110 0 > 0 0 > mipi_dphy_root_clk110 0 > 0 0 > > after: > cat clk_dump | grep mipi_dphy >mipi_dphy_src 1102400 > 0 0 >mipi_dphy_cg 1102400 > 0 0 > mipi_dphy_pre_div 1102400 > 0 0 > mipi_dphy_post_div 1102400 > 0 0 > mipi_dphy_root_clk 1102400 > 0 0 > > Fixes: 8f6d8094b215 ("ARM: imx: add imx7d clk tree support") > > Cc: linux-...@vger.kernel.org > Acked-by: Dong Aisheng > Signed-off-by: Rui Miguel Silva > --- I only get two patches out of the 12 and I don't get a cover letter. Did you want me to pick up these clk patches into clk-next? Where are the other patches? Can you cc lkml on all your kernel emails so I can easily find them?
Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1
On 05/17/2018 07:13 AM, Mauro Carvalho Chehab wrote: Em Thu, 17 May 2018 08:43:24 -0300 Mauro Carvalho Chehab escreveu: On 05/15/2018 02:39 PM, Dan Carpenter wrote: You'd need to rebuild the db (possibly twice but definitely once). How? Here, I just pull from your git tree and do a "make". At most, make clean; make. Never mind. Found it using grep. I'm running this: make allyesconfig /devel/smatch/smatch_scripts/build_kernel_data.sh /devel/smatch/smatch_scripts/build_kernel_data.sh It seems that something is broken... getting this error/warning: DBD::SQLite::db do failed: unrecognized token: "'end + strlen(" " at /devel/smatch/smatch_scripts/../smatch_data/db/fill_db_sql.pl line 32, line 2938054. Yep. I get the same warning multiple times. BTW, Mauro, you sent a patch to fix an spectre v1 issue in this file yesterday: dvb_ca_en50221.c:1480, but it seems there is another instance of the same issue some lines above: diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c b/drivers/media/dvb-core/dvb_ca_en50221.c index 1310526..7edd9db 100644 --- a/drivers/media/dvb-core/dvb_ca_en50221.c +++ b/drivers/media/dvb-core/dvb_ca_en50221.c @@ -1398,6 +1398,7 @@ static int dvb_ca_en50221_io_do_ioctl(struct file *file, info->type = CA_CI_LINK; info->flags = 0; + slot = array_index_nospec(slot, ca->slot_count + 1); sl = &ca->slot_info[slot]; if ((sl->slot_state != DVB_CA_SLOTSTATE_NONE) && (sl->slot_state != DVB_CA_SLOTSTATE_INVALID)) { Thanks -- Gustavo
[linux-next:master 875/8111] drivers/media//platform/fsl-viu.c:41:0: warning: "out_be32" redefined
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: fbbe3b8c2c9c5f84caf668703c26154cb4fbb9d1 commit: 29d750686331a1a9ceeb97e81d3770f57bed5f72 [875/8111] media: fsl-viu: allow building it with COMPILE_TEST config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 29d750686331a1a9ceeb97e81d3770f57bed5f72 # save the attached .config to linux build tree make.cross ARCH=m68k All warnings (new ones prefixed by >>): >> drivers/media//platform/fsl-viu.c:41:0: warning: "out_be32" redefined #define out_be32(v, a) iowrite32be(a, (void __iomem *)v) In file included from arch/m68k/include/asm/io_mm.h:27:0, from arch/m68k/include/asm/io.h:5, from include/linux/io.h:25, from drivers/media//platform/fsl-viu.c:23: arch/m68k/include/asm/raw_io.h:46:0: note: this is the location of the previous definition #define out_be32(addr,l) (void)((*(__force volatile u32 *) (addr)) = (l)) >> drivers/media//platform/fsl-viu.c:42:0: warning: "in_be32" redefined #define in_be32(a) ioread32be((void __iomem *)a) In file included from arch/m68k/include/asm/io_mm.h:27:0, from arch/m68k/include/asm/io.h:5, from include/linux/io.h:25, from drivers/media//platform/fsl-viu.c:23: arch/m68k/include/asm/raw_io.h:37:0: note: this is the location of the previous definition #define in_be32(addr) \ vim +/out_be32 +41 drivers/media//platform/fsl-viu.c > 23 #include 24 #include 25 #include 26 #include 27 #include 28 #include 29 #include 30 #include 31 #include 32 #include 33 #include 34 #include 35 36 #define DRV_NAME"fsl_viu" 37 #define VIU_VERSION "0.5.1" 38 39 /* Allow building this driver with COMPILE_TEST */ 40 #ifndef CONFIG_PPC > 41 #define out_be32(v, a) iowrite32be(a, (void __iomem *)v) > 42 #define in_be32(a) ioread32be((void __iomem *)a) 43 #endif 44 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[ANN] Meeting to discuss improvements to support MC-based cameras on generic apps
Hi all, The goal of this e-mail is to schedule a meeting in order to discuss improvements at the media subsystem in order to support complex camera hardware by usual apps. The main focus here is to allow supporting devices with MC-based hardware connected to a camera. In short, my proposal is to meet with the interested parties on solving this issue during the Open Source Summit in Japan, e. g. between June, 19-22, in Tokyo. I'd like to know who is interested on joining us for such meeting, and to hear a proposal of themes for discussions. I'm enclosing a detailed description of the problem, in order to allow the interested parties to be at the same page. Regards, Mauro --- 1. Introduction === 1.1 V4L2 Kernel aspects --- The media subsystem supports two types of devices: - "traditional" media hardware, supported via V4L2 API. On such hardware, opening a single device node (usually /dev/video0) is enough to control the entire device. We call it as devnode-based devices. - Media-controller based devices. On those devices, there are several /dev/video? nodes and several /dev/v4l2-subdev? nodes, plus a media controller device node (usually /dev/media0). We call it as mc-based devices. Controlling the hardware require opening the media device (/dev/media0), setup the pipeline and adjust the sub-devices via /dev/v4l2-subdev?. Only streaming is controlled by /dev/video?. All "standard" media applications, including open source ones (Camorama, Cheese, Xawtv, Firefox, Chromium, ...) and closed source ones (Skype, Chrome, ...) supports devnode-based devices. Support for mc-based devices currently require an specialized application in order to prepare the device for its usage (setup pipelines, adjust hardware controls, etc). Once pipeline is set, the streaming goes via /dev/video?, although usually some /dev/v4l2-subdev? devnodes should also be opened, in order to implement algorithms designed to make video quality reasonable. On such devices, it is not uncommon that the device used by the application to be a random number (on OMAP3 driver, typically, is either /dev/video4 or /dev/video6). One example of such hardware is at the OMAP3-based hardware: http://www.infradead.org/~mchehab/mc-next-gen/omap3-igepv2-with-tvp5150.png On the picture, there's a graph with the hardware blocks in blue/dark/blue and the corresponding devnode interfaces in yellow. The mc-based approach was taken when support for Nokia N9/N900 cameras was added (with has OMAP3 SoC). It is required because the camera hardware on SoC comes with a media processor (ISP), with does a lot more than just capturing, allowing complex algorithms to enhance image quality in runtime. Those algorithms are known as 3A - an acronym for 3 other acronyms: - AE (Auto Exposure); - AF (Auto Focus); - AWB (Auto White Balance). Setting a camera with such ISPs are harder because the pipelines to be set actually depends the requirements for those 3A algorithms to run. Also, usually, the 3A algorithms use some chipset-specific userspace API, that exports some image properties, calculated by the ISP, to speed up the convergence of those algorithms. Btw, usually, the 3A algorithms are IP-protected, provided by vendors as binary only blobs, although there are a few OSS implementations. 1.2 V4L2 userspace aspects -- Back when USB cameras were introduced, the hardware were really simple: they had a CCD camera sensor and a chip that bridges the data though USB. CCD camera sensors typically provide data using a bayer format, but they usually have their own proprietary ways to pack the data, in order to reduce the USB bandwidth (original cameras were USB 1.1). So, V4L2 has a myriad of different formats, in order to match each CCD camera sensor format. At the end of the day, applications were able to use only a subset of the available hardware, since they need to come with format converters for all formats the developer uses (usually a very small subset of the available ones). To end with this mess, an userspace library was written, called libv4l. It supports all those proprietary formats. So, applications can use a RGB or YUV format, without needing to concern about conversions. The way it works is by adding wrappers to system calls: open, close, ioctl, mmap, mmunmap. So, a conversion to use it is really simple: at the source code of the apps, all it was needed is to prepend the existing calls with "v4l2_", e. g. v4l2_open, v4l2_close, etc. All open source apps we know now supports libv4l. On a few (like gstreamer), support for it is optional. In order to support closed source, another wrapper was added, allowing to call any closed source application to use it, by using LD_PRELOAD. For example, using skype with it is as simple as calling it with: $ LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so /usr/bin/skypeforlinux 2. Current problems ==
Re: [PATCH v10 8/8] media: vsp1: Move video configuration to a cached dlb
Hi Kieran, Thank you for the patch. On Thursday, 17 May 2018 20:24:01 EEST Kieran Bingham wrote: > We are now able to configure a pipeline directly into a local display > list body. Take advantage of this fact, and create a cacheable body to > store the configuration of the pipeline in the video object. > > vsp1_video_pipeline_run() is now the last user of the pipe->dl object. > Convert this function to use the cached video->config body and obtain a > local display list reference. > > Attach the video->config body to the display list when needed before > committing to hardware. > > The pipe object is marked as un-configured when resuming from a suspend. Is this comment still valid ? > This ensures that when the hardware is reset - our cached configuration > will be re-attached to the next committed DL. > > Our video DL usage now looks like the below output: > > dl->body0 contains our disposable runtime configuration. Max 41. > dl_child->body0 is our partition specific configuration. Max 12. > dl->bodies shows our constant configuration and LUTs. > > These two are LUT/CLU: > * dl->bodies[x]->num_entries 256 / max 256 > * dl->bodies[x]->num_entries 4914 / max 4914 > > Which shows that our 'constant' configuration cache is currently > utilised to a maximum of 64 entries. > > trace-cmd report | \ > grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq; > > dl->body0->num_entries 13 / max 128 > dl->body0->num_entries 14 / max 128 > dl->body0->num_entries 16 / max 128 > dl->body0->num_entries 20 / max 128 > dl->body0->num_entries 27 / max 128 > dl->body0->num_entries 34 / max 128 > dl->body0->num_entries 41 / max 128 > dl_child->body0->num_entries 10 / max 128 > dl_child->body0->num_entries 12 / max 128 > dl->bodies[x]->num_entries 15 / max 128 > dl->bodies[x]->num_entries 16 / max 128 > dl->bodies[x]->num_entries 17 / max 128 > dl->bodies[x]->num_entries 18 / max 128 > dl->bodies[x]->num_entries 20 / max 128 > dl->bodies[x]->num_entries 21 / max 128 > dl->bodies[x]->num_entries 256 / max 256 > dl->bodies[x]->num_entries 31 / max 128 > dl->bodies[x]->num_entries 32 / max 128 > dl->bodies[x]->num_entries 39 / max 128 > dl->bodies[x]->num_entries 40 / max 128 > dl->bodies[x]->num_entries 47 / max 128 > dl->bodies[x]->num_entries 48 / max 128 > dl->bodies[x]->num_entries 4914 / max 4914 > dl->bodies[x]->num_entries 55 / max 128 > dl->bodies[x]->num_entries 56 / max 128 > dl->bodies[x]->num_entries 63 / max 128 > dl->bodies[x]->num_entries 64 / max 128 > > Signed-off-by: Kieran Bingham > --- > v10: > - Removed pipe->configured flag, and use >pipe->state == VSP1_PIPELINE_STOPPED instead. > > v8: > - Fix comments > - Rename video->pipe_config -> video->stream_config > > v4: > - Adjust pipe configured flag to be reset on resume rather than suspend > - rename dl_child, dl_next > > v3: > - 's/fragment/body/', 's/fragments/bodies/' > - video dlb cache allocation increased from 2 to 3 dlbs > > drivers/media/platform/vsp1/vsp1_pipe.h | 3 +- > drivers/media/platform/vsp1/vsp1_video.c | 67 +++-- > drivers/media/platform/vsp1/vsp1_video.h | 2 +- > 3 files changed, 43 insertions(+), 29 deletions(-) > > diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h > b/drivers/media/platform/vsp1/vsp1_pipe.h index e00010693eef..be6ecab3cbed > 100644 > --- a/drivers/media/platform/vsp1/vsp1_pipe.h > +++ b/drivers/media/platform/vsp1/vsp1_pipe.h > @@ -102,7 +102,6 @@ struct vsp1_partition { > * @uds: UDS entity, if present > * @uds_input: entity at the input of the UDS, if the UDS is present > * @entities: list of entities in the pipeline > - * @dl: display list associated with the pipeline > * @partitions: The number of partitions used to process one frame > * @partition: The current partition for configuration to process > * @part_table: The pre-calculated partitions used by the pipeline > @@ -139,8 +138,6 @@ struct vsp1_pipeline { >*/ > struct list_head entities; > > - struct vsp1_dl_list *dl; > - > unsigned int partitions; > struct vsp1_partition *partition; > struct vsp1_partition *part_table; > diff --git a/drivers/media/platform/vsp1/vsp1_video.c > b/drivers/media/platform/vsp1/vsp1_video.c index 72f29773eb1c..f2bc26d28396 > 100644 > --- a/drivers/media/platform/vsp1/vsp1_video.c > +++ b/drivers/media/platform/vsp1/vsp1_video.c > @@ -390,44 +390,48 @@ static void vsp1_video_pipeline_run_partition(struct > vsp1_pipeline *pipe, static void vsp1_video_pipeline_run(struct > vsp1_pipeline *pipe) > { > struct vsp1_device *vsp1 = pipe->output->entity.vsp1; > + struct vsp1_video *video = pipe->output->video; > struct vsp1_entity *entity; > struct vsp1_dl_body *dlb; > + struct vsp1_dl_list *dl; > unsigned int partition; > > - if (!pipe->dl) > - pipe->dl = vsp1_dl_list_get(pipe->output->dlm); > + dl = vsp1_dl_li
Re: [Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver
Hi Neil, I love your patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [also build test ERROR on v4.17-rc5 next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Neil-Armstrong/Add-ChromeOS-EC-CEC-Support/20180516-180519 base: git://linuxtv.org/media_tree.git master config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=m68k All errors (new ones prefixed by >>): drivers/media//platform/cros-ec-cec/cros-ec-cec.c: In function 'cros_ec_cec_get_notifier': >> drivers/media//platform/cros-ec-cec/cros-ec-cec.c:231:33: error: >> 'pci_bus_type' undeclared (first use in this function); did you mean >> 'pci_pcie_type'? d = bus_find_device_by_name(&pci_bus_type, NULL, ^~~~ pci_pcie_type drivers/media//platform/cros-ec-cec/cros-ec-cec.c:231:33: note: each undeclared identifier is reported only once for each function it appears in vim +231 drivers/media//platform/cros-ec-cec/cros-ec-cec.c 217 218 static int cros_ec_cec_get_notifier(struct device *dev, 219 struct cec_notifier **notify) 220 { 221 int i; 222 223 for (i = 0 ; i < ARRAY_SIZE(cec_dmi_match_table) ; ++i) { 224 const struct cec_dmi_match *m = &cec_dmi_match_table[i]; 225 226 if (dmi_match(DMI_SYS_VENDOR, m->sys_vendor) && 227 dmi_match(DMI_PRODUCT_NAME, m->product_name)) { 228 struct device *d; 229 230 /* Find the device, bail out if not yet registered */ > 231 d = bus_find_device_by_name(&pci_bus_type, NULL, 232 m->devname); 233 if (!d) 234 return -EPROBE_DEFER; 235 236 *notify = cec_notifier_get_conn(d, m->conn); 237 return 0; 238 } 239 } 240 241 /* Hardware support must be added in the cec_dmi_match_table */ 242 dev_warn(dev, "CEC notifier not configured for this hardware\n"); 243 244 return -ENODEV; 245 } 246 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v7 8/8] media: vsp1: Move video configuration to a cached dlb
Hi Kieran, On Thursday, 17 May 2018 20:06:46 EEST Kieran Bingham wrote: > On 17/05/18 15:35, Laurent Pinchart wrote: > > On Monday, 30 April 2018 20:48:03 EEST Kieran Bingham wrote: > >> On 07/04/18 01:23, Laurent Pinchart wrote: > >>> On Thursday, 8 March 2018 02:05:31 EEST Kieran Bingham wrote: > We are now able to configure a pipeline directly into a local display > list body. Take advantage of this fact, and create a cacheable body to > store the configuration of the pipeline in the video object. > > vsp1_video_pipeline_run() is now the last user of the pipe->dl object. > Convert this function to use the cached video->config body and obtain a > local display list reference. > > Attach the video->config body to the display list when needed before > committing to hardware. > > The pipe object is marked as un-configured when resuming from a > suspend. This ensures that when the hardware is reset - our cached > configuration will be re-attached to the next committed DL. > > Signed-off-by: Kieran Bingham > --- > > v3: > - 's/fragment/body/', 's/fragments/bodies/' > - video dlb cache allocation increased from 2 to 3 dlbs > > Our video DL usage now looks like the below output: > > dl->body0 contains our disposable runtime configuration. Max 41. > dl_child->body0 is our partition specific configuration. Max 12. > dl->bodies shows our constant configuration and LUTs. > > These two are LUT/CLU: > * dl->bodies[x]->num_entries 256 / max 256 > * dl->bodies[x]->num_entries 4914 / max 4914 > > Which shows that our 'constant' configuration cache is currently > utilised to a maximum of 64 entries. > > trace-cmd report | \ > > grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq; > > dl->body0->num_entries 13 / max 128 > dl->body0->num_entries 14 / max 128 > dl->body0->num_entries 16 / max 128 > dl->body0->num_entries 20 / max 128 > dl->body0->num_entries 27 / max 128 > dl->body0->num_entries 34 / max 128 > dl->body0->num_entries 41 / max 128 > dl_child->body0->num_entries 10 / max 128 > dl_child->body0->num_entries 12 / max 128 > dl->bodies[x]->num_entries 15 / max 128 > dl->bodies[x]->num_entries 16 / max 128 > dl->bodies[x]->num_entries 17 / max 128 > dl->bodies[x]->num_entries 18 / max 128 > dl->bodies[x]->num_entries 20 / max 128 > dl->bodies[x]->num_entries 21 / max 128 > dl->bodies[x]->num_entries 256 / max 256 > dl->bodies[x]->num_entries 31 / max 128 > dl->bodies[x]->num_entries 32 / max 128 > dl->bodies[x]->num_entries 39 / max 128 > dl->bodies[x]->num_entries 40 / max 128 > dl->bodies[x]->num_entries 47 / max 128 > dl->bodies[x]->num_entries 48 / max 128 > dl->bodies[x]->num_entries 4914 / max 4914 > dl->bodies[x]->num_entries 55 / max 128 > dl->bodies[x]->num_entries 56 / max 128 > dl->bodies[x]->num_entries 63 / max 128 > dl->bodies[x]->num_entries 64 / max 128 > >>> > >>> This might be useful to capture in the main part of the commit message. > >>> > v4: > - Adjust pipe configured flag to be reset on resume rather than > suspend > - rename dl_child, dl_next > > drivers/media/platform/vsp1/vsp1_pipe.c | 7 +++- > drivers/media/platform/vsp1/vsp1_pipe.h | 4 +- > drivers/media/platform/vsp1/vsp1_video.c | 67 ++- > drivers/media/platform/vsp1/vsp1_video.h | 2 +- > 4 files changed, 54 insertions(+), 26 deletions(-) > > diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c > b/drivers/media/platform/vsp1/vsp1_pipe.c index > 5012643583b6..fa445b1a2e38 > 100644 > --- a/drivers/media/platform/vsp1/vsp1_pipe.c > +++ b/drivers/media/platform/vsp1/vsp1_pipe.c > @@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe) > vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index), > VI6_CMD_STRCMD); > pipe->state = VSP1_PIPELINE_RUNNING; > +pipe->configured = true; > } > > pipe->buffers_ready = 0; > @@ -470,6 +471,12 @@ void vsp1_pipelines_resume(struct vsp1_device > *vsp1) > continue; > > spin_lock_irqsave(&pipe->irqlock, flags); > +/* > + * The hardware may have been reset during a suspend > and will > + * need a full reconfiguration > + */ > >>> > >>> s/reconfiguration/reconfiguration./ > >>> > +pipe->configured = false; > + > >>> >
Re: [PATCHv13 25/28] vim2m: support requests
Hi Hans, On Thu, May 03, 2018 at 04:53:15PM +0200, Hans Verkuil wrote: > From: Hans Verkuil > > Add support for requests to vim2m. > > Signed-off-by: Hans Verkuil > --- > drivers/media/platform/vim2m.c | 34 ++ > 1 file changed, 34 insertions(+) > > diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c > index a1b0bb08668d..7c86c711a4cd 100644 > --- a/drivers/media/platform/vim2m.c > +++ b/drivers/media/platform/vim2m.c > @@ -387,8 +387,26 @@ static void device_run(void *priv) > src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx); > dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx); > > + /* Apply request controls if needed */ > + if (src_buf->vb2_buf.req_obj.req) > + v4l2_ctrl_request_setup(src_buf->vb2_buf.req_obj.req, > + &ctx->hdl); > + if (dst_buf->vb2_buf.req_obj.req && > + dst_buf->vb2_buf.req_obj.req != src_buf->vb2_buf.req_obj.req) > + v4l2_ctrl_request_setup(dst_buf->vb2_buf.req_obj.req, > + &ctx->hdl); This seems wrong: you're making use of control values from two *different*, *unrelated* requests. I'd rather like that we didn't end up a request API for the mem2mem devices and another for the rest... albeit the kernel implementation could be the same or similar, it's still the uAPI that would have differing semantics between the two. > + > device_process(ctx, src_buf, dst_buf); > > + /* Complete request controls if needed */ > + if (src_buf->vb2_buf.req_obj.req) > + v4l2_ctrl_request_complete(src_buf->vb2_buf.req_obj.req, > + &ctx->hdl); > + if (dst_buf->vb2_buf.req_obj.req && > + dst_buf->vb2_buf.req_obj.req != src_buf->vb2_buf.req_obj.req) > + v4l2_ctrl_request_complete(dst_buf->vb2_buf.req_obj.req, > + &ctx->hdl); > + > /* Run a timer, which simulates a hardware irq */ > schedule_irq(dev, ctx->transtime); > } > @@ -823,12 +841,21 @@ static void vim2m_stop_streaming(struct vb2_queue *q) > vbuf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx); > if (vbuf == NULL) > return; > + v4l2_ctrl_request_complete(vbuf->vb2_buf.req_obj.req, > +&ctx->hdl); > spin_lock_irqsave(&ctx->dev->irqlock, flags); > v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR); > spin_unlock_irqrestore(&ctx->dev->irqlock, flags); > } > } > > +static void vim2m_buf_request_complete(struct vb2_buffer *vb) > +{ > + struct vim2m_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue); > + > + v4l2_ctrl_request_complete(vb->req_obj.req, &ctx->hdl); > +} > + > static const struct vb2_ops vim2m_qops = { > .queue_setup = vim2m_queue_setup, > .buf_prepare = vim2m_buf_prepare, > @@ -837,6 +864,7 @@ static const struct vb2_ops vim2m_qops = { > .stop_streaming = vim2m_stop_streaming, > .wait_prepare= vb2_ops_wait_prepare, > .wait_finish = vb2_ops_wait_finish, > + .buf_request_complete = vim2m_buf_request_complete, > }; > > static int queue_init(void *priv, struct vb2_queue *src_vq, struct vb2_queue > *dst_vq) > @@ -1003,6 +1031,11 @@ static const struct v4l2_m2m_ops m2m_ops = { > .job_abort = job_abort, > }; > > +static const struct media_device_ops m2m_media_ops = { > + .req_validate = vb2_request_validate, > + .req_queue = vb2_m2m_request_queue, > +}; > + > static int vim2m_probe(struct platform_device *pdev) > { > struct vim2m_dev *dev; > @@ -1027,6 +1060,7 @@ static int vim2m_probe(struct platform_device *pdev) > dev->mdev.dev = &pdev->dev; > strlcpy(dev->mdev.model, "vim2m", sizeof(dev->mdev.model)); > media_device_init(&dev->mdev); > + dev->mdev.ops = &m2m_media_ops; > dev->v4l2_dev.mdev = &dev->mdev; > dev->pad[0].flags = MEDIA_PAD_FL_SINK; > dev->pad[1].flags = MEDIA_PAD_FL_SOURCE; -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi
Re: [PATCH v3 2/2] bpf: add selftest for rawir_event type program
On Thu, May 17, 2018 at 10:17:59AM -0700, Y Song wrote: > On Wed, May 16, 2018 at 2:04 PM, Sean Young wrote: > > This is simple test over rc-loopback. > > > > Signed-off-by: Sean Young > > --- > > tools/bpf/bpftool/prog.c | 1 + > > tools/include/uapi/linux/bpf.h| 57 +++- > > tools/lib/bpf/libbpf.c| 1 + > > tools/testing/selftests/bpf/Makefile | 8 +- > > tools/testing/selftests/bpf/bpf_helpers.h | 6 + > > tools/testing/selftests/bpf/test_rawir.sh | 37 + > > .../selftests/bpf/test_rawir_event_kern.c | 26 > > .../selftests/bpf/test_rawir_event_user.c | 130 ++ > > 8 files changed, 261 insertions(+), 5 deletions(-) > > create mode 100755 tools/testing/selftests/bpf/test_rawir.sh > > create mode 100644 tools/testing/selftests/bpf/test_rawir_event_kern.c > > create mode 100644 tools/testing/selftests/bpf/test_rawir_event_user.c > > Could you copy include/uapi/linux/lirc.h file to tools directory as well. > Otherwise, I will get the following compilation error: > > gcc -Wall -O2 -I../../../include/uapi -I../../../lib > -I../../../lib/bpf -I../../../../include/generated -I../../../include >test_rawir_event_user.c > /home/yhs/work/bpf-next/tools/testing/selftests/bpf/libbpf.a -lcap > -lelf -lrt -lpthread -o > /home/yhs/work/bpf-next/tools/testing/selftests/bpf/test_rawir_event_user > test_rawir_event_user.c: In function ‘main’: > test_rawir_event_user.c:60:15: error: ‘LIRC_MODE_SCANCODE’ undeclared > (first use in this function); did you mean ‘LIRC_MODE_LIRCCODE’? > mode = LIRC_MODE_SCANCODE; >^~ >LIRC_MODE_LIRCCODE > test_rawir_event_user.c:60:15: note: each undeclared identifier is > reported only once for each function it appears in > test_rawir_event_user.c:93:29: error: storage size of ‘lsc’ isn’t known > struct lirc_scancode lsc; > ^~~ > test_rawir_event_user.c:93:29: warning: unused variable ‘lsc’ > [-Wunused-variable] Ah, good catch. Thanks for testing this. > > > > > diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c > > index 9bdfdf2d3fbe..8889a4ee8577 100644 > > --- a/tools/bpf/bpftool/prog.c > > +++ b/tools/bpf/bpftool/prog.c > > @@ -71,6 +71,7 @@ static const char * const prog_type_name[] = { > > [BPF_PROG_TYPE_SK_MSG] = "sk_msg", > > [BPF_PROG_TYPE_RAW_TRACEPOINT] = "raw_tracepoint", > > [BPF_PROG_TYPE_CGROUP_SOCK_ADDR] = "cgroup_sock_addr", > > + [BPF_PROG_TYPE_RAWIR_EVENT] = "rawir_event", > > }; > > > > static void print_boot_time(__u64 nsecs, char *buf, unsigned int size) > > diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h > > index 1205d86a7a29..243e141e8a5b 100644 > > --- a/tools/include/uapi/linux/bpf.h > > +++ b/tools/include/uapi/linux/bpf.h > > @@ -141,6 +141,7 @@ enum bpf_prog_type { > > BPF_PROG_TYPE_SK_MSG, > > BPF_PROG_TYPE_RAW_TRACEPOINT, > > BPF_PROG_TYPE_CGROUP_SOCK_ADDR, > > + BPF_PROG_TYPE_RAWIR_EVENT, > > }; > > > > enum bpf_attach_type { > > @@ -158,6 +159,7 @@ enum bpf_attach_type { > > BPF_CGROUP_INET6_CONNECT, > > BPF_CGROUP_INET4_POST_BIND, > > BPF_CGROUP_INET6_POST_BIND, > > + BPF_RAWIR_EVENT, > > __MAX_BPF_ATTACH_TYPE > > }; > > > > @@ -1829,7 +1831,6 @@ union bpf_attr { > > * Return > > * 0 on success, or a negative error in case of failure. > > * > > - * > > * int bpf_fib_lookup(void *ctx, struct bpf_fib_lookup *params, int plen, > > u32 flags) > > * Description > > * Do FIB lookup in kernel tables using parameters in *params*. > > @@ -1856,6 +1857,7 @@ union bpf_attr { > > * Egress device index on success, 0 if packet needs to > > continue > > * up the stack for further processing or a negative error in > > case > > * of failure. > > + * > > * int bpf_sock_hash_update(struct bpf_sock_ops_kern *skops, struct > > bpf_map *map, void *key, u64 flags) > > * Description > > * Add an entry to, or update a sockhash *map* referencing > > sockets. > > @@ -1902,6 +1904,35 @@ union bpf_attr { > > * egress otherwise). This is the only flag supported for now. > > * Return > > * **SK_PASS** on success, or **SK_DROP** on error. > > + * > > + * int bpf_rc_keydown(void *ctx, u32 protocol, u32 scancode, u32 toggle) > > + * Description > > + * Report decoded scancode with toggle value. For use in > > + * BPF_PROG_TYPE_RAWIR_EVENT, to report a successfully > > + * decoded scancode. This is will generate a keydown event, > > + * and a keyup event once the scancode is no longer repeated. > > + * > > + * *ctx* pointer to bpf_rawir_event, *protocol* is decoded > > + * protocol (see RC
Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps
Le jeudi 17 mai 2018 à 16:07 -0300, Mauro Carvalho Chehab a écrit : > Hi all, > > The goal of this e-mail is to schedule a meeting in order to discuss > improvements at the media subsystem in order to support complex > camera > hardware by usual apps. > > The main focus here is to allow supporting devices with MC-based > hardware connected to a camera. > > In short, my proposal is to meet with the interested parties on > solving > this issue during the Open Source Summit in Japan, e. g. between > June, 19-22, in Tokyo. > > I'd like to know who is interested on joining us for such meeting, > and to hear a proposal of themes for discussions. > > I'm enclosing a detailed description of the problem, in order to > allow the interested parties to be at the same page. It's unlikely I'll be able to attend this meeting, but I'd like to provide some initial input on this. Find inline some clarification on why libv4l2 is disabled by default in Gst, as it's not just performance. A major aspect that is totally absent of this mail is PipeWire. With the venue of sandboxed application, there is a need to control access to cameras through a daemon. The same daemon is also used to control access to screen capture on Wayland (instead of letting any random application capture your screen, like on X11). The effort is lead by the desktop team at RedHat (folks CCed). PipeWire already have V4L2 native support and is integrated in GStreamer already in a way that it can totally replace the V4L2 capture component there. PipeWire is plugin base, so more type of camera support (including proprietary ones) can be added. Remote daemon can also provide streams, as this is the case for compositors and screen casting. An extra benefit is that you can have multiple application reading frames from the same camera. It also allow sandboxed application (the do not have access to /dev) to use the cameras. PipeWire is much more then that, but let's focus on that. This is the direction we are heading on the "generic" / Desktop Linux. Porting Firefox and Chrome is obviously planed, as these beast are clear candidate for being sand-boxed and requires screen share feature for WebRTC. In this context, proprietary or HW specific algorithm could be implemented in userspace as PipeWire plugins, and then application will automatically be enable to enumerate and use these. I'm not saying the libv4l2 stuff is not needed short term, but it's just a short term thing in my opinion. > > Regards, > Mauro > > --- > > > 1. Introduction > === > > 1.1 V4L2 Kernel aspects > --- > > The media subsystem supports two types of devices: > > - "traditional" media hardware, supported via V4L2 API. On such > hardware, > opening a single device node (usually /dev/video0) is enough to > control > the entire device. We call it as devnode-based devices. > > - Media-controller based devices. On those devices, there are several > /dev/video? nodes and several /dev/v4l2-subdev? nodes, plus a media > controller device node (usually /dev/media0). > We call it as mc-based devices. Controlling the hardware require > opening the media device (/dev/media0), setup the pipeline and > adjust > the sub-devices via /dev/v4l2-subdev?. Only streaming is controlled > by /dev/video?. > > All "standard" media applications, including open source ones > (Camorama, > Cheese, Xawtv, Firefox, Chromium, ...) and closed source ones > (Skype, > Chrome, ...) supports devnode-based devices. > > Support for mc-based devices currently require an specialized > application > in order to prepare the device for its usage (setup pipelines, adjust > hardware controls, etc). Once pipeline is set, the streaming goes via > /dev/video?, although usually some /dev/v4l2-subdev? devnodes should > also > be opened, in order to implement algorithms designed to make video > quality > reasonable. On such devices, it is not uncommon that the device used > by the > application to be a random number (on OMAP3 driver, typically, is > either > /dev/video4 or /dev/video6). > > One example of such hardware is at the OMAP3-based hardware: > > http://www.infradead.org/~mchehab/mc-next-gen/omap3-igepv2-with > -tvp5150.png > > On the picture, there's a graph with the hardware blocks in > blue/dark/blue > and the corresponding devnode interfaces in yellow. > > The mc-based approach was taken when support for Nokia N9/N900 > cameras > was added (with has OMAP3 SoC). It is required because the camera > hardware > on SoC comes with a media processor (ISP), with does a lot more than > just > capturing, allowing complex algorithms to enhance image quality in > runtime. > Those algorithms are known as 3A - an acronym for 3 other acronyms: > > - AE (Auto Exposure); > - AF (Auto Focus); > - AWB (Auto White Balance). > > Setting a camera with such ISPs are harder because the pipelines to > be > set actually depends the requirements for those 3A a