[PATCH] doc-rst: support *sphinx build themes*
From: Markus Heiser
Load an additional configuration file into conf.py namespace.
The name of the configuration file is taken from the environment
SPHINX_CONF. The external configuration file extends (or overwrites) the
configuration values from the origin conf.py. With this you are
able to maintain *build themes*.
E.g. to create your own nit-picking *build theme*, create a file
Documentation/conf_nitpick.py::
nitpicky=True
nitpick_ignore = [
("c:func", "clock_gettime"),
...
]
and run make with SPHINX_CONF environment::
make SPHINX_CONF=conf_nitpick.py htmldocs
Signed-off-by: Markus Heiser
---
Documentation/conf.py | 9 +
Documentation/sphinx/load_config.py | 25 +
2 files changed, 34 insertions(+)
create mode 100644 Documentation/sphinx/load_config.py
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 96b7aa6..d502775 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -20,6 +20,8 @@ import os
# documentation root, use os.path.abspath to make it absolute, like shown here.
sys.path.insert(0, os.path.abspath('sphinx'))
+from load_config import loadConfig
+
# -- General configuration
# If your documentation needs a minimal Sphinx version, state it here.
@@ -419,3 +421,10 @@ pdf_documents = [
# line arguments.
kerneldoc_bin = '../scripts/kernel-doc'
kerneldoc_srctree = '..'
+
+
+#
--
+# Since loadConfig overwrites settings from the global namespace, it has to be
+# the last statement in the conf.py file
+#
--
+loadConfig(globals())
diff --git a/Documentation/sphinx/load_config.py
b/Documentation/sphinx/load_config.py
new file mode 100644
index 000..44bdd22
--- /dev/null
+++ b/Documentation/sphinx/load_config.py
@@ -0,0 +1,25 @@
+# -*- coding: utf-8; mode: python -*-
+# pylint: disable=R0903, C0330, R0914, R0912, E0401
+
+import os
+from sphinx.util.pycompat import execfile_
+
+#
--
+def loadConfig(namespace):
+#
--
+
+u"""Load an additional configuration file into *namespace*.
+
+The name of the configuration file is taken from the environment
+``SPHINX_CONF``. The external configuration file extends (or overwrites)
the
+configuration values from the origin ``conf.py``. With this you are able
to
+maintain *build themes*. """
+
+config_file = os.environ.get("SPHINX_CONF", None)
+if config_file is not None and os.path.exists(config_file):
+config_file = os.path.abspath(config_file)
+config = namespace.copy()
+config['__file__'] = config_file
+execfile_(config_file, config)
+del config['__file__']
+namespace.update(config)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] s5p-tv: remove obsolete driver
On 08/05/2016 03:38 PM, Hans Verkuil wrote: > The s5p-tv driver has been replaced by the exynos drm driver for quite a > long time now. Remove this driver to avoid having duplicate drivers, > of which this one is considered dead code by Samsung. > > Signed-off-by: Hans Verkuil Acked-by: Sylwester Nawrocki -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] v4l2-common: add s_selection helper function
Hi Tiffany, We just had a long discussion about whether or not -ERANGE should be returned if the constraint flags could not be satisfied, and the end result was that the driver should not return an error in that case, but just select a rectangle that works with the hardware and is closest to the requested rectangle. See the irc log for the discussion: https://linuxtv.org/irc/irclogger_log/v4l?date=2016-08-05,Fri This will simplify your code, and I'll drop this patch for a v4l2-common helper function, since that is no longer relevant. I will try to find time to fix the documentation (since that's wrong) and any drivers that do return ERANGE. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 11/11] Input: sur40 - use new V4L2 touch input type
On Thu 2016-06-30 18:38:54, Nick Dyer wrote:
> Support both V4L2_TCH_FMT_TU08 and V4L2_PIX_FMT_GREY for backwards
> compatibility.
>
> Note: I have not tested these changes (I have no access to the hardware)
> so not signing off.
Sign off means something else, see docs... and sign patches off :-).
Pavel
> ---
> drivers/input/touchscreen/sur40.c | 121
> +++---
> 1 file changed, 88 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/input/touchscreen/sur40.c
> b/drivers/input/touchscreen/sur40.c
> index 880c40b..9ba68cf 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> @@ -139,6 +139,27 @@ struct sur40_image_header {
> #define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
> #define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
>
> +static const struct v4l2_pix_format sur40_pix_format[] = {
> + {
> + .pixelformat = V4L2_TCH_FMT_TU08,
> + .width = SENSOR_RES_X / 2,
> + .height = SENSOR_RES_Y / 2,
> + .field = V4L2_FIELD_NONE,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> + .bytesperline = SENSOR_RES_X / 2,
> + .sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
> + },
> + {
> + .pixelformat = V4L2_PIX_FMT_GREY,
> + .width = SENSOR_RES_X / 2,
> + .height = SENSOR_RES_Y / 2,
> + .field = V4L2_FIELD_NONE,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> + .bytesperline = SENSOR_RES_X / 2,
> + .sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
> + }
> +};
> +
> /* master device state */
> struct sur40_state {
>
> @@ -149,6 +170,7 @@ struct sur40_state {
> struct v4l2_device v4l2;
> struct video_device vdev;
> struct mutex lock;
> + struct v4l2_pix_format pix_fmt;
>
> struct vb2_queue queue;
> struct vb2_alloc_ctx *alloc_ctx;
> @@ -170,7 +192,6 @@ struct sur40_buffer {
>
> /* forward declarations */
> static const struct video_device sur40_video_device;
> -static const struct v4l2_pix_format sur40_video_format;
> static const struct vb2_queue sur40_queue;
> static void sur40_process_video(struct sur40_state *sur40);
>
> @@ -421,7 +442,7 @@ static void sur40_process_video(struct sur40_state *sur40)
> goto err_poll;
> }
>
> - if (le32_to_cpu(img->size) != sur40_video_format.sizeimage) {
> + if (le32_to_cpu(img->size) != sur40->pix_fmt.sizeimage) {
> dev_err(sur40->dev, "image size mismatch\n");
> goto err_poll;
> }
> @@ -432,7 +453,7 @@ static void sur40_process_video(struct sur40_state *sur40)
>
> result = usb_sg_init(&sgr, sur40->usbdev,
> usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT), 0,
> - sgt->sgl, sgt->nents, sur40_video_format.sizeimage, 0);
> + sgt->sgl, sgt->nents, sur40->pix_fmt.sizeimage, 0);
> if (result < 0) {
> dev_err(sur40->dev, "error %d in usb_sg_init\n", result);
> goto err_poll;
> @@ -593,13 +614,14 @@ static int sur40_probe(struct usb_interface *interface,
> goto err_unreg_v4l2;
> }
>
> + sur40->pix_fmt = sur40_pix_format[0];
> sur40->vdev = sur40_video_device;
> sur40->vdev.v4l2_dev = &sur40->v4l2;
> sur40->vdev.lock = &sur40->lock;
> sur40->vdev.queue = &sur40->queue;
> video_set_drvdata(&sur40->vdev, sur40);
>
> - error = video_register_device(&sur40->vdev, VFL_TYPE_GRABBER, -1);
> + error = video_register_device(&sur40->vdev, VFL_TYPE_TOUCH, -1);
> if (error) {
> dev_err(&interface->dev,
> "Unable to register video subdevice.");
> @@ -662,10 +684,10 @@ static int sur40_queue_setup(struct vb2_queue *q,
> alloc_ctxs[0] = sur40->alloc_ctx;
>
> if (*nplanes)
> - return sizes[0] < sur40_video_format.sizeimage ? -EINVAL : 0;
> + return sizes[0] < sur40->pix_fmt.sizeimage ? -EINVAL : 0;
>
> *nplanes = 1;
> - sizes[0] = sur40_video_format.sizeimage;
> + sizes[0] = sur40->pix_fmt.sizeimage;
>
> return 0;
> }
> @@ -677,7 +699,7 @@ static int sur40_queue_setup(struct vb2_queue *q,
> static int sur40_buffer_prepare(struct vb2_buffer *vb)
> {
> struct sur40_state *sur40 = vb2_get_drv_priv(vb->vb2_queue);
> - unsigned long size = sur40_video_format.sizeimage;
> + unsigned long size = sur40->pix_fmt.sizeimage;
>
> if (vb2_plane_size(vb, 0) < size) {
> dev_err(&sur40->usbdev->dev, "buffer too small (%lu < %lu)\n",
> @@ -751,7 +773,7 @@ static int sur40_vidioc_querycap(struct file *file, void
> *priv,
> strlcpy(cap->driver, DRIVER_SHORT, sizeof(cap->driver));
> strlcpy(cap->card, DRIVER_LONG, sizeof(cap->card));
> usb_make_path(sur40->usbdev, cap->bus_info, sizeo
Re: [v4l-utils RFC 0/3] mediatext library and test program
Hi Hans,
On Fri, Jul 22, 2016 at 03:09:47PM +0200, Hans Verkuil wrote:
> Hi Sakari,
>
> First a practical matter: you should consider using the v4l-helpers.h: it
> will shield you and probably the end-user as well from lots of
> complexities, esp. the single vs multiplanar differences.
>
> I really need to spend some time documenting it, but it isn't all that
> difficult.
Thanks. I wasn't aware of this --- partly because I seldom write user space
software. :-) I took a glance and it appears applicable to me on video
nodes. I'll consider that when updating the set the next time.
>
>
> On 07/21/2016 05:15 PM, Sakari Ailus wrote:
> > Hi everyone,
> >
> > We've got a number of V4L2 (and MC) test programs for about as many reasons.
> > The existing programs are concentrated to work on a single device node at a
> > time, and with a single interface, be that Media controller or V4L2.
> >
> > The test programs are also command line controlled, working their way with
> > the device at hand based on the information passed to the test programs on
> > the command line. This has made perfect sense for the past 15 years, as long
> > as we've had such test programs: they have covered, for large part, needs to
> > perform testing in various cases without leaving significant gaps.
> >
> > With the upcoming request API, however, this has become insufficient. The
> > very nature of the request API requires that requests can contain resources
> > (e.g. memory buffers) that is associated to a number of video device nodes.
> > The requests may well be different from each other, including the types of
> > resources that are used for each request.
> >
> > So I decided we need a new test program. The scope for the original
> > mediatext library and test program were slightly different from what is in
> > this (very RFC) patchset. I deemed mediatext as the best starting point for
> > writing a new test program.
>
> Is this utility meant to testing different scenarios, or as a way to test
> drivers
> (compliance tests)? I think the first, right?
The first. I haven't thought of compliancy testing when writing the code.
Nothing prevents using it for that though but right now it's probably not
the best tool for that at the moment.
>
> > mediatext acts as an interface between an end user or a script and the
> > kernel interfaces, with an ability to work with multiple devices at a time,
> > including multiple video nodes:
> >
> >shell script
> >|
> >|
> >| <- two-way pipe
> >|
> >|
> >mediatext
> > / | \
> > / | \
> > /dev/video* | /dev/v4l-subdev*
> >|
> > /dev/mediaX
> >
> > The shell script (which could be any other program as well but shell scripts
> > are convenient for the purpose) is always in the control of the main loop of
> > the test. Events are delivered to the script by mediatext based on file
> > handle state changes, so the script has a possibility to react to each of
> > them (e.g. buffer becoming dequeueable on one of the video nodes).
> >
> > A simple example script for a UVC compliant Logitech webcam is below. It
> > opens the device based on the name of the entity, and sets up the device for
> > streaming with a specified format with three MMAP buffers. The first 50
> > frames are written to a file, and capturing is stopped once about 100 frames
> > have been captured. Dequeued buffers are immediately requeued, and this is
> > explicitly done by the shell script.
> >
> > -8<-
> > #!/bin/bash
> >
> > eval_line() {
> > while [ $# -ne 0 ]; do
> > local name=${1%=*}
> > local value=${1#*=}
> > p[$name]="$value"
> > shift
> > done
> > }
> >
> > coproc mediatext -d /dev/media0 2>&1
> >
> > cat <&${COPROC[1]}
> > v4l open entity="UVC Camera (046d:0825)" name=uvc
> > v4l fmt vdev=uvc type=CAPTURE width=320 height=240 \
> > pixelformat=YUYV bytesperline=0
> > v4l reqbufs vdev=uvc type=CAPTURE count=3 memory=MMAP
> > v4l qbuf vdev=uvc
> > v4l qbuf vdev=uvc
> > v4l qbuf vdev=uvc
> >
> > v4l streamon vdev=uvc type=CAPTURE
> > EOF
> >
> > while IFS= read -ru ${COPROC[0]} line; do
> > unset p; declare -A p
> > eval eval_line $line
> > echo $line
> > case ${p[event]} in
> > dqbuf)
> > if ((${p[seq]} < 50)); then
> > echo v4l write vdev=uvc \
> > sequence=${p[seq]} >&${COPROC[1]}
> > fi
> > if ((${p[seq]} > 100)); then
> > echo quit >&${COPROC[1]}
> > fi
> > cat <&${COPROC[1]}
> > v4l qbuf vdev=uvc
> > EOF
> > ;;
> >
Re: Functions and data structure cross references with Sphinx
Em Fri, 5 Aug 2016 14:22:19 +0200 Markus Heiser escreveu: > Am 05.08.2016 um 12:47 schrieb Mauro Carvalho Chehab > : > > > Em Fri, 5 Aug 2016 09:29:23 +0200 > > Markus Heiser escreveu: > > > > Is there a way for us to specify the nitpick_ignore list (or a different > > conf.py) via command line? > > Since conf.py is python, we could implement something, which loads a > "conditional configuration", e.g. loading a config with a nitpick_ignore > list in. Depending on an environment > > "SPHINX_BUILD_CONF=[strong|lazy]-nit-picking.py" > > we could load individual build-configs overwriting the default settings > from the origin conf.py. That would be interesting! > On which repo/branch you are working? .. I send you a RFC patch > for "conditional configurations". You can send it against either the media_tree.git[1] or the upstream one[2]. All Sphinx patches I have were merged there already (except for the experimental nickpick patch I attached on the previous e-mail). [1] https://git.linuxtv.org/media_tree.git/log/ [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ > > 3) The references generated from the header files I'm parsing don't > > use the c (or cpp) domain. They're declared at the media book as a > > normal reference: > > Documentation/media/uapi/v4l/field-order.rst:.. _v4l2-field: > > > Back to (3) ... as far as I know, there is no way to add a > *Internal Hyperlink Target* (e.g. "_v4l2-field:") to the C or > CPP domain. Argh! > > There is a ":any:" directive does something vice versa. > > http://www.sphinx-doc.org/en/stable/markup/inline.html#role-any > > But I think, this will not help referencing a type from a function > prototype to a *Internal Hyperlink Target*, like the struct described > under the "_v4l2-field:" target. Hmm... it might help, but this is Sphinx 1.3 or upper only. As we decide to set the minimal version bar to 1.2, we should avoid using it. > > If ":any:" does not help, we might find a solution with an additional > crossref-type or something similar: > > http://www.sphinx-doc.org/en/stable/extdev/appapi.html#sphinx.application.Sphinx.add_crossref_type > > But this needs some more thoughts. That sounds more promising, but we'll need a replacement for the :c:func: tag to use it. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Functions and data structure cross references with Sphinx
Am 05.08.2016 um 12:47 schrieb Mauro Carvalho Chehab : > Em Fri, 5 Aug 2016 09:29:23 +0200 > Markus Heiser escreveu: > >> Am 01.08.2016 um 13:25 schrieb Mauro Carvalho Chehab >> : >> >>> There's one remaining major issue I noticed after the conversion of the >>> media books to Sphinx: >>> >>> While sphinx complains if a cross-reference (using :ref:) points to an >>> undefined reference, the same doesn't happen if the reference uses >>> :c:func: and :c:type:. >>> >>> In practice, it means that, if we do some typo there, or if we forget to >>> add the function/struct prototype (or use the wrong domain, like :cpp:), >>> Sphinx won't generate the proper cross-reference, nor warning the user. >>> >>> That's specially bad for media, as, while we're using the c domain for >>> the kAPI and driver-specific books, we need to use the cpp domain on the >>> uAPI book - as the c domain doesn't allow multiple declarations for >>> syscalls, and we have multiple pages for read, write, open, close, >>> poll and ioctl. >>> >>> It would be good to have a way to run Sphinx on some "pedantic" >>> mode or have something similar to xmlint that would be complaining >>> about invalid c/cpp domain references. >>> >>> Thanks, >>> Mauro >> >> Hi Mauro, >> >> there is a nit-picky mode [1], which could be activated by setting >> "nitpicky=True" in the conf.py or alternative, set "-n" to the >> SPHINXOPTS: >> >> make SPHINXOPTS=-n htmldocs >> >> Within nit-picky mode, Sphinx will warn about **all** references. This >> might be more then you want. For this, in the conf.py you could >> assemble a "nitpick_ignore" list [2]. But I think, assemble the >> ignore list is quite a lot of work. >> >> [1] http://www.sphinx-doc.org/en/stable/config.html#confval-nitpicky >> [2] http://www.sphinx-doc.org/en/stable/config.html#confval-nitpick_ignore > > Yeah, this is what I was looking for. > > We indeed want to use this option on media, but there are some things > that need to be addressed. From some quick tests here, what I noticed > is: > > 1) Sphinx will generate several references that should be safely ignored > for everyone, like "enum", "u32", "int32_t", "bool", "NULL", etc; > > 2) the usage of cpp domain for system calls make several symbols to > not match, as the cpp function prototype will generate cross references > for the cpp domain, instead of using the c domain. So, we need a > better way to fix it using the c domain, or convert everything to the > cpp domain; > > 3) The references generated from the header files I'm parsing don't > use the c (or cpp) domain. They're declared at the media book as a > normal reference: > Documentation/media/uapi/v4l/field-order.rst:.. _v4l2-field: > > and cross-referenced with: > ref:`v4l2_field ` > > Is there a way to change it to the c domain? > > > 4) there are several references that, IMHO, should be nitpick-ignored > only when the book is generated stand alone. For example, at the > media docbooks, we have references for things like: > > - pci_dev, mutex, off_t, container_of, etc - those are generic > references for the symbols that every driver uses, but, as we > don't have the books with those converted yet, nitpick complains. > Once we have such references, they should be ignored *only* when > the book is generated standalone. As those are "core" symbols, > they should be already be documented, but the book was not > ported from DocBook yet. Once we have everything ported to > Sphinx, I would expect that they all will vanish (and, if not, > IMHO, documenting them should be prioritized). > > - References for subsystem-specific symbols like: spi_board_info, > led_classdev_flash, i2c_adapter, etc. Those would require that > the maintainers of the specific subsystems to add documentation > to them, as I bet several such symbols won't be currently > documented. So, even after the port, I afraid that we'll still > have several such symbols missing. > > To address (3), we need different sets of nitpick ignore lists. > > At least in my case, I have two different procedures, depending > on the time at the Kernel release cycle: > > a) daily patch merge workflow > -- > > In any case, for (3), I don't want to see those warnings during > my daily patch handling process where I rebuild documentation for > every patch that touches a documented file. I want to see only > things like: > Documentation/media/uapi/v4l/hist-v4l2.rst:1295: WARNING: c:type > reference target not found: struct v4l2_buffer > > With indicates that a new patch would be introducing documentation > gaps. > > So, we need a way to have a per-subsystem nitpick_ignore list > (or a way to pass such list via command line), for us to be able to > ignore "alien" symbols that aren't part of the subsystem we're > maintaining. > > b) preparation for the merge window > > > Late at the patch handling cycle, I run a very long task here that >
Re: Sphinx-doc: build over N processes in parallel
Am 05.08.2016 um 13:41 schrieb Mauro Carvalho Chehab : > Em Fri, 5 Aug 2016 11:56:44 +0200 > Markus Heiser escreveu: > >> Am 20.07.2016 um 16:04 schrieb Mauro Carvalho Chehab >> : >> >>> >>> A completely unrelated question: it seems that Sphinx is using just >>> one CPU to do its builds: >>> >>> %Cpu0 : 3,0 us, 7,6 sy, 0,0 ni, 89,4 id, 0,0 wa, 0,0 hi, 0,0 si, >>> 0,0 st >>> %Cpu1 :100,0 us, 0,0 sy, 0,0 ni, 0,0 id, 0,0 wa, 0,0 hi, 0,0 si, >>> 0,0 st >>> %Cpu2 : 1,3 us, 2,7 sy, 0,0 ni, 95,7 id, 0,3 wa, 0,0 hi, 0,0 si, >>> 0,0 st >>> %Cpu3 : 1,0 us, 3,3 sy, 0,0 ni, 95,7 id, 0,0 wa, 0,0 hi, 0,0 si, >>> 0,0 st >>> KiB Mem : 15861876 total, 5809820 free, 1750528 used, 8301528 buff/cache >>> KiB Swap: 8200188 total, 8200188 free,0 used. 13382964 avail Mem >>> >>> PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND >>> >>> 5660 mchehab 20 0 325256 89776 8300 R 99,7 0,6 0:22.25 >>> sphinx-bui+ >>> >>> Are there any way to speed it up and make it use all available CPUs? >> >> Hi Mauro, >> >> sorry for the late reply. There is a sphinx-build option "-j N" [1]. >> It is in a *experimental* state in Sphinx v1.2 and has been improved >> in v1.3. Set e.g. "-j2" to the SPHINXOPTS to use two cores. >> >> make SPHINXOPTS=-j2 htmldocs >> >> But take into account what the documentation says: """not all parts and >> not all builders of Sphinx can be parallelized.""". >> >> [1] >> http://www.sphinx-doc.org/en/stable/invocation.html#cmdoption-sphinx-build-j > > Good, thanks! > > Did some tests here on a machine with 32 CPU threads using a PCIe SSD disk, > using Sphinx 1.4.5. > > Using -j32, those are the timings: > > real 0m59.522s > user 1m29.968s > sys 0m4.975s > > not using it, I got: > > real 1m27.814s > user 1m26.465s > sys 0m1.842s > > Not much gain :( > > Regards, > Mauro I think, that only some reading / writing parts of the sphinx implementation are parallel and most of the stuff is sequential. I haven't looked through but I think, generating env and traversing trees etc. are always steps which has to be consecutively. I guess you will get same results with 2 or 4 threads :( --Markus-- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sphinx-doc: build over N processes in parallel
Em Fri, 5 Aug 2016 11:56:44 +0200 Markus Heiser escreveu: > Am 20.07.2016 um 16:04 schrieb Mauro Carvalho Chehab > : > > > > > A completely unrelated question: it seems that Sphinx is using just > > one CPU to do its builds: > > > > %Cpu0 : 3,0 us, 7,6 sy, 0,0 ni, 89,4 id, 0,0 wa, 0,0 hi, 0,0 si, > > 0,0 st > > %Cpu1 :100,0 us, 0,0 sy, 0,0 ni, 0,0 id, 0,0 wa, 0,0 hi, 0,0 si, > > 0,0 st > > %Cpu2 : 1,3 us, 2,7 sy, 0,0 ni, 95,7 id, 0,3 wa, 0,0 hi, 0,0 si, > > 0,0 st > > %Cpu3 : 1,0 us, 3,3 sy, 0,0 ni, 95,7 id, 0,0 wa, 0,0 hi, 0,0 si, > > 0,0 st > > KiB Mem : 15861876 total, 5809820 free, 1750528 used, 8301528 buff/cache > > KiB Swap: 8200188 total, 8200188 free,0 used. 13382964 avail Mem > > > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > > > > 5660 mchehab 20 0 325256 89776 8300 R 99,7 0,6 0:22.25 > > sphinx-bui+ > > > > Are there any way to speed it up and make it use all available CPUs? > > Hi Mauro, > > sorry for the late reply. There is a sphinx-build option "-j N" [1]. > It is in a *experimental* state in Sphinx v1.2 and has been improved > in v1.3. Set e.g. "-j2" to the SPHINXOPTS to use two cores. > > make SPHINXOPTS=-j2 htmldocs > > But take into account what the documentation says: """not all parts and > not all builders of Sphinx can be parallelized.""". > > [1] > http://www.sphinx-doc.org/en/stable/invocation.html#cmdoption-sphinx-build-j Good, thanks! Did some tests here on a machine with 32 CPU threads using a PCIe SSD disk, using Sphinx 1.4.5. Using -j32, those are the timings: real0m59.522s user1m29.968s sys 0m4.975s not using it, I got: real1m27.814s user1m26.465s sys 0m1.842s Not much gain :( Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3.1 05/11] v4l: Add packed Bayer raw12 pixel formats
These formats are compressed 12-bit raw bayer formats with four different
pixel orders. They are similar to 10-bit variants. The formats added by
this patch are
V4L2_PIX_FMT_SBGGR12P
V4L2_PIX_FMT_SGBRG12P
V4L2_PIX_FMT_SGRBG12P
V4L2_PIX_FMT_SRGGB12P
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
Fix line start offsets.
Documentation/media/uapi/v4l/pixfmt-rgb.rst | 1 +
Documentation/media/uapi/v4l/pixfmt-srggb12p.rst | 108 +++
drivers/media/v4l2-core/v4l2-ioctl.c | 12 ++-
include/uapi/linux/videodev2.h | 5 ++
4 files changed, 122 insertions(+), 4 deletions(-)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb12p.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
index 9cc9808..81412f7 100644
--- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
@@ -18,3 +18,4 @@ RGB Formats
pixfmt-srggb10alaw8
pixfmt-srggb10dpcm8
pixfmt-srggb12
+pixfmt-srggb12p
diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst
b/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst
new file mode 100644
index 000..f8e9912
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst
@@ -0,0 +1,108 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-SRGGB12P:
+.. _v4l2-pix-fmt-sbggr12p:
+.. _v4l2-pix-fmt-sgbrg12p:
+.. _v4l2-pix-fmt-sgrbg12p:
+
+***
+V4L2_PIX_FMT_SRGGB12P ('pRAA'), V4L2_PIX_FMT_SGRBG12P ('pgAA'),
V4L2_PIX_FMT_SGBRG12P ('pGAA'), V4L2_PIX_FMT_SBGGR12P ('pBAA'),
+***
+
+*man V4L2_PIX_FMT_SRGGB12P(2)*
+
+V4L2_PIX_FMT_SGRBG12P
+V4L2_PIX_FMT_SGBRG12P
+V4L2_PIX_FMT_SBGGR12P
+12-bit packed Bayer formats
+
+
+Description
+===
+
+These four pixel formats are packed raw sRGB / Bayer formats with 12
+bits per colour. Every two consecutive samples are packed into three
+bytes. Each of the first two bytes contain the 8 high order bits of
+the pixels, and the third byte contains the four least significants
+bits of each pixel, in the same order.
+
+Each n-pixel row contains n/2 green samples and n/2 blue or red
+samples, with alternating green-red and green-blue rows. They are
+conventionally described as GRGR... BGBG..., RGRG... GBGB..., etc.
+Below is an example of one of these formats:
+
+**Byte Order.**
+Each cell is one byte.
+
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+:widths: 2 1 1 1 1 1 1
+
+
+- .. row 1
+
+ - start + 0:
+
+ - B\ :sub:`00high`
+
+ - G\ :sub:`01high`
+
+ - G\ :sub:`01low`\ (bits 7--4) B\ :sub:`00low`\ (bits 3--0)
+
+ - B\ :sub:`02high`
+
+ - G\ :sub:`03high`
+
+ - G\ :sub:`03low`\ (bits 7--4) B\ :sub:`02low`\ (bits 3--0)
+
+- .. row 2
+
+ - start + 6:
+
+ - G\ :sub:`10high`
+
+ - R\ :sub:`11high`
+
+ - R\ :sub:`11low`\ (bits 7--4) G\ :sub:`10low`\ (bits 3--0)
+
+ - G\ :sub:`12high`
+
+ - R\ :sub:`13high`
+
+ - R\ :sub:`13low`\ (bits 3--2) G\ :sub:`12low`\ (bits 3--0)
+
+- .. row 3
+
+ - start + 12:
+
+ - B\ :sub:`20high`
+
+ - G\ :sub:`21high`
+
+ - G\ :sub:`21low`\ (bits 7--4) B\ :sub:`20low`\ (bits 3--0)
+
+ - B\ :sub:`22high`
+
+ - G\ :sub:`23high`
+
+ - G\ :sub:`23low`\ (bits 7--4) B\ :sub:`22low`\ (bits 3--0)
+
+- .. row 4
+
+ - start + 18:
+
+ - G\ :sub:`30high`
+
+ - R\ :sub:`31high`
+
+ - R\ :sub:`31low`\ (bits 7--4) G\ :sub:`30low`\ (bits 3--0)
+
+ - G\ :sub:`32high`
+
+ - R\ :sub:`33high`
+
+ - R\ :sub:`33low`\ (bits 3--2) G\ :sub:`32low`\ (bits 3--0)
+
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 51a0fa1..ebce910 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1213,10 +1213,6 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_SGBRG10: descr = "10-bit Bayer GBGB/RGRG"; break;
case V4L2_PIX_FMT_SGRBG10: descr = "10-bit Bayer GRGR/BGBG"; break;
case V4L2_PIX_FMT_SRGGB10: descr = "10-bit Bayer RGRG/GBGB"; break;
- case V4L2_PIX_FMT_SBGGR12: descr = "12-bit Bayer BGBG/GRGR"; break;
- case V4L2_PIX_FMT_SGBRG12: descr = "12-bit Bayer GBGB/RGRG"; break;
- case V4L2_PIX_FMT_SGRBG12: descr = "12-bit Bayer GRGR/BGBG"; break;
- case V4L2_PIX_FMT_SRGGB12: descr = "12-bit Bayer RGRG/GBGB"; break;
case V4L2_PIX_FMT_SBGGR10P: descr = "10-bit Bayer BGBG/GRGR
Packed"; break;
case V4L2_PIX_FMT_SGBRG10P: descr = "10-bit Bayer GBGB/RGRG
Re: [PATCH v3 00/11] New raw bayer format definitions, fixes
On Fri, Aug 05, 2016 at 01:45:30PM +0300, Sakari Ailus wrote: > Hi all, > > This is a third version of the new bayer format patchset. The second version > of the set may be found here: > > http://www.spinics.net/lists/linux-media/msg101498.html> > > These patches fix and add new raw bayer format definitions. 12-bit packed > V4L2 format definition is added as well as definitions of 14-bit media bus > codes as well as unpacked and packed V4L2 formats. > > No driver uses them right now, yet they're common formats needed by newer > devices that use higher bit depths so adding them would make sense. > > 16-bit pixel formats are added as well, and the 16-bit formats are now > expected to have 16 bits of data. 8-bit format documentation is unified. The HTML documentation can be found here: http://salottisipuli.retiisi.org.uk/~sailus/raw14-doc/media/uapi/v4l/pixfmt-rgb.html> -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 05/16] media: devnode: Refcount the media devnode
Hi Hans,
Hans Verkuil wrote:
>
>
> On 07/15/2016 12:35 AM, Sakari Ailus wrote:
>> Add reference count to the media devnode. The media_devnode is intended to
>> be embedded in another struct such as media_device.
>>
>> Signed-off-by: Sakari Ailus
>> ---
>> drivers/media/media-device.c | 7 +--
>> drivers/media/media-devnode.c | 114
>> +-
>> include/media/media-devnode.h | 47 +
>> 3 files changed, 133 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
>> index 8bdc316..a11b3be 100644
>> --- a/drivers/media/media-device.c
>> +++ b/drivers/media/media-device.c
>> @@ -531,7 +531,8 @@ static const struct media_file_operations
>> media_device_fops = {
>> static ssize_t show_model(struct device *cd,
>>struct device_attribute *attr, char *buf)
>> {
>> -struct media_device *mdev = to_media_device(to_media_devnode(cd));
>> +struct media_device *mdev = to_media_device(
>> +to_media_devnode_cdev(cd)->devnode);
>>
>> return sprintf(buf, "%.*s\n", (int)sizeof(mdev->model), mdev->model);
>> }
>> @@ -717,7 +718,7 @@ int __must_check __media_device_register(struct
>> media_device *mdev,
>> if (ret < 0)
>> return ret;
>>
>> -ret = device_create_file(&mdev->devnode.dev, &dev_attr_model);
>> +ret = device_create_file(&mdev->devnode.mdc->dev, &dev_attr_model);
>> if (ret < 0) {
>> media_devnode_unregister(&mdev->devnode);
>> return ret;
>> @@ -793,7 +794,7 @@ void media_device_unregister(struct media_device *mdev)
>>
>> mutex_unlock(&mdev->graph_mutex);
>>
>> -device_remove_file(&mdev->devnode.dev, &dev_attr_model);
>> +device_remove_file(&mdev->devnode.mdc->dev, &dev_attr_model);
>> dev_dbg(mdev->dev, "Media device unregistering\n");
>> media_devnode_unregister(&mdev->devnode);
>> }
>> diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c
>> index 7481c96..566ef08 100644
>> --- a/drivers/media/media-devnode.c
>> +++ b/drivers/media/media-devnode.c
>> @@ -57,25 +57,54 @@ static DEFINE_MUTEX(media_devnode_lock);
>> static DECLARE_BITMAP(media_devnode_nums, MEDIA_NUM_DEVICES);
>>
>> /* Called when the last user of the media device exits. */
>> -static void media_devnode_release(struct device *cd)
>> +static void media_devnode_device_release(struct device *cd)
>> {
>> -struct media_devnode *devnode = to_media_devnode(cd);
>> +struct media_devnode_cdev *mdc = to_media_devnode_cdev(cd);
>>
>> -mutex_lock(&media_devnode_lock);
>> +dev_dbg(cd, "release media devnode device\n");
>>
>> /* Delete the cdev on this minor as well */
>> -cdev_del(&devnode->cdev);
>> +cdev_del(&mdc->cdev);
>>
>> /* Mark device node number as free */
>> -clear_bit(devnode->minor, media_devnode_nums);
>> -
>> +mutex_lock(&media_devnode_lock);
>> +clear_bit(MINOR(mdc->cdev.dev), media_devnode_nums);
>> mutex_unlock(&media_devnode_lock);
>> +}
>> +
>> +static void media_devnode_release(struct kref *kref)
>> +{
>> +struct media_devnode *devnode =
>> +container_of(kref, struct media_devnode, kref);
>> +
>> +dev_dbg(&devnode->mdc->dev, "release media devnode\n");
>> +
>> +put_device(&devnode->mdc->dev);
>>
>> /* Release media_devnode and perform other cleanups as needed. */
>> if (devnode->release)
>> devnode->release(devnode);
>> }
>>
>> +void media_devnode_init(struct media_devnode *devnode)
>> +{
>> +kref_init(&devnode->kref);
>> +devnode->use_kref = true;
>> +}
>> +EXPORT_SYMBOL_GPL(media_devnode_init);
>> +
>> +void media_devnode_get(struct media_devnode *devnode)
>> +{
>> +kref_get(&devnode->kref);
>> +}
>> +EXPORT_SYMBOL_GPL(media_devnode_get);
>> +
>> +void media_devnode_put(struct media_devnode *devnode)
>> +{
>> +kref_put(&devnode->kref, media_devnode_release);
>> +}
>> +EXPORT_SYMBOL_GPL(media_devnode_put);
>> +
>> static struct bus_type media_bus_type = {
>> .name = MEDIA_NAME,
>> };
>> @@ -164,7 +193,8 @@ static int media_open(struct inode *inode, struct file
>> *filp)
>> * a crash.
>> */
>> mutex_lock(&media_devnode_lock);
>> -devnode = container_of(inode->i_cdev, struct media_devnode, cdev);
>> +devnode = container_of(inode->i_cdev,
>> + struct media_devnode_cdev, cdev)->devnode;
>> /* return ENXIO if the media device has been removed
>> already or if it is not registered anymore. */
>> if (!media_devnode_is_registered(devnode)) {
>> @@ -172,7 +202,10 @@ static int media_open(struct inode *inode, struct file
>> *filp)
>> return -ENXIO;
>> }
>> /* and increase the device refcount */
>> -get_device(&devnode->dev);
>> +if (devnode->use_kref)
>> +media_devnode_get(devnode);
>> +else
>> +get_device(&devnode->
[PATCH v3 07/11] doc-rst: Add 14-bit raw bayer pixel format definitions
The formats added by this patch are:
V4L2_PIX_FMT_SBGGR14
V4L2_PIX_FMT_SGBRG14
V4L2_PIX_FMT_SGRBG14
V4L2_PIX_FMT_SRGGB14
Signed-off-by: Jouni Ukkonen
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
Documentation/media/uapi/v4l/pixfmt-rgb.rst | 1 +
Documentation/media/uapi/v4l/pixfmt-srggb14.rst | 122
drivers/media/v4l2-core/v4l2-ioctl.c| 4 +
include/uapi/linux/videodev2.h | 4 +
4 files changed, 131 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb14.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
index 81412f7..548551a 100644
--- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
@@ -19,3 +19,4 @@ RGB Formats
pixfmt-srggb10dpcm8
pixfmt-srggb12
pixfmt-srggb12p
+pixfmt-srggb14
diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb14.rst
b/Documentation/media/uapi/v4l/pixfmt-srggb14.rst
new file mode 100644
index 000..829ce97
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb14.rst
@@ -0,0 +1,122 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-SRGGB14:
+.. _v4l2-pix-fmt-sbggr14:
+.. _v4l2-pix-fmt-sgbrg14:
+.. _v4l2-pix-fmt-sgrbg14:
+
+
+***
+V4L2_PIX_FMT_SRGGB14 ('RG14'), V4L2_PIX_FMT_SGRBG14 ('GR14'),
V4L2_PIX_FMT_SGBRG14 ('GB14'), V4L2_PIX_FMT_SBGGR14 ('BG14'),
+***
+
+*man V4L2_PIX_FMT_SRGGB14(2)*
+
+V4L2_PIX_FMT_SGRBG14
+V4L2_PIX_FMT_SGBRG14
+V4L2_PIX_FMT_SBGGR14
+14-bit Bayer formats expanded to 16 bits
+
+
+Description
+===
+
+These four pixel formats are raw sRGB / Bayer formats with 14 bits per
+colour. Each sample is stored in a 16-bit word, with two unused high
+bits filled with zeros. Each n-pixel row contains n/2 green samples
+and n/2 blue or red samples, with alternating red and blue rows. Bytes
+are stored in memory in little endian order. They are conventionally
+described as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an
+example of one of these formats:
+
+**Byte Order.**
+Each cell is one byte, the two most significant bits in the high bytes are
+zero.
+
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+:widths: 2 1 1 1 1 1 1 1 1
+
+
+- .. row 1
+
+ - start + 0:
+
+ - B\ :sub:`00low`
+
+ - B\ :sub:`00high`
+
+ - G\ :sub:`01low`
+
+ - G\ :sub:`01high`
+
+ - B\ :sub:`02low`
+
+ - B\ :sub:`02high`
+
+ - G\ :sub:`03low`
+
+ - G\ :sub:`03high`
+
+- .. row 2
+
+ - start + 8:
+
+ - G\ :sub:`10low`
+
+ - G\ :sub:`10high`
+
+ - R\ :sub:`11low`
+
+ - R\ :sub:`11high`
+
+ - G\ :sub:`12low`
+
+ - G\ :sub:`12high`
+
+ - R\ :sub:`13low`
+
+ - R\ :sub:`13high`
+
+- .. row 3
+
+ - start + 16:
+
+ - B\ :sub:`20low`
+
+ - B\ :sub:`20high`
+
+ - G\ :sub:`21low`
+
+ - G\ :sub:`21high`
+
+ - B\ :sub:`22low`
+
+ - B\ :sub:`22high`
+
+ - G\ :sub:`23low`
+
+ - G\ :sub:`23high`
+
+- .. row 4
+
+ - start + 24:
+
+ - G\ :sub:`30low`
+
+ - G\ :sub:`30high`
+
+ - R\ :sub:`31low`
+
+ - R\ :sub:`31high`
+
+ - G\ :sub:`32low`
+
+ - G\ :sub:`32high`
+
+ - R\ :sub:`33low`
+
+ - R\ :sub:`33high`
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index ebce910..29d9f8f 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1233,6 +1233,10 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_SGBRG12P: descr = "12-bit Bayer GBGB/RGRG
Packed"; break;
case V4L2_PIX_FMT_SGRBG12P: descr = "12-bit Bayer GRGR/BGBG
Packed"; break;
case V4L2_PIX_FMT_SRGGB12P: descr = "12-bit Bayer RGRG/GBGB
Packed"; break;
+ case V4L2_PIX_FMT_SBGGR14: descr = "14-bit Bayer BGBG/GRGR"; break;
+ case V4L2_PIX_FMT_SGBRG14: descr = "14-bit Bayer GBGB/RGRG"; break;
+ case V4L2_PIX_FMT_SGRBG14: descr = "14-bit Bayer GRGR/BGBG"; break;
+ case V4L2_PIX_FMT_SRGGB14: descr = "14-bit Bayer RGRG/GBGB"; break;
case V4L2_PIX_FMT_SBGGR16: descr = "16-bit Bayer BGBG/GRGR
(Exp.)"; break;
case V4L2_PIX_FMT_SN9C20X_I420: descr = "GSPCA SN9C20X I420"; break;
case V4L2_PIX_FMT_SPCA501: descr = "GSPCA SPCA501"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index c9b0055..dd7b29d 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -583,6 +583,10 @@ struct v4l2_p
[PATCH v3 01/11] doc-rst: Correct the ordering of LSBs of the 10-bit raw packed formats
The 10-bit packed raw bayer format documented that the data of the first pixel of a four-pixel group was found in the first byte and the two highest bits of the fifth byte. This was not entirely correct. The two bits in the fifth byte are the two lowest bits. The second pixel occupies the second byte and third and fourth least significant bits and so on. Signed-off-by: Sakari Ailus Acked-by: Aviv Greenberg Acked-by: Hans Verkuil --- Documentation/media/uapi/v4l/pixfmt-srggb10p.rst | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst index d71368f..32c067c 100644 --- a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst +++ b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst @@ -54,8 +54,8 @@ Each cell is one byte. - G\ :sub:`03high` - - B\ :sub:`00low`\ (bits 7--6) G\ :sub:`01low`\ (bits 5--4) - B\ :sub:`02low`\ (bits 3--2) G\ :sub:`03low`\ (bits 1--0) + - G\ :sub:`03low`\ (bits 7--6) B\ :sub:`02low`\ (bits 5--4) + G\ :sub:`01low`\ (bits 3--2) B\ :sub:`00low`\ (bits 1--0) - .. row 2 @@ -69,8 +69,8 @@ Each cell is one byte. - R\ :sub:`13high` - - G\ :sub:`10low`\ (bits 7--6) R\ :sub:`11low`\ (bits 5--4) - G\ :sub:`12low`\ (bits 3--2) R\ :sub:`13low`\ (bits 1--0) + - R\ :sub:`13low`\ (bits 7--6) G\ :sub:`12low`\ (bits 5--4) + R\ :sub:`11low`\ (bits 3--2) G\ :sub:`10low`\ (bits 1--0) - .. row 3 @@ -84,8 +84,8 @@ Each cell is one byte. - G\ :sub:`23high` - - B\ :sub:`20low`\ (bits 7--6) G\ :sub:`21low`\ (bits 5--4) - B\ :sub:`22low`\ (bits 3--2) G\ :sub:`23low`\ (bits 1--0) + - G\ :sub:`23low`\ (bits 7--6) B\ :sub:`22low`\ (bits 5--4) + G\ :sub:`21low`\ (bits 3--2) B\ :sub:`20low`\ (bits 1--0) - .. row 4 @@ -99,5 +99,5 @@ Each cell is one byte. - R\ :sub:`33high` - - G\ :sub:`30low`\ (bits 7--6) R\ :sub:`31low`\ (bits 5--4) - G\ :sub:`32low`\ (bits 3--2) R\ :sub:`33low`\ (bits 1--0) + - R\ :sub:`33low`\ (bits 7--6) G\ :sub:`32low`\ (bits 5--4) + R\ :sub:`31low`\ (bits 3--2) G\ :sub:`30low`\ (bits 1--0) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 10/11] doc-rst: 16-bit BGGR is always 16 bits
The V4L2_PIX_FMT_SBGGR16 format is documented to contain samples of fewer than 16 bits. However, we do have specific definitions for smaller sample sizes. Therefore, this note is redundant from the API point of view. Currently only two drivers, am437x and davinci, use the V4L2_PIX_FMT_SBGGR16 pixelformat currently. The sampling precision is understood to be 16 bits in all current cases. Remove the note on sampling precision. Signed-off-by: Sakari Ailus Acked-by: Lad, Prabhakar --- Documentation/media/uapi/v4l/pixfmt-sbggr16.rst | 3 --- 1 file changed, 3 deletions(-) diff --git a/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst b/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst index 14446ed..7844dc3 100644 --- a/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst +++ b/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst @@ -19,9 +19,6 @@ This format is similar to has a depth of 16 bits. The least significant byte is stored at lower memory addresses (little-endian). -..note:: The actual sampling precision may be lower than 16 bits, -for example 10 bits per pixel with values in tange 0 to 1023. - **Byte Order.** Each cell is one byte. -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 05/11] v4l: Add packed Bayer raw12 pixel formats
These formats are compressed 12-bit raw bayer formats with four different
pixel orders. They are similar to 10-bit variants. The formats added by
this patch are
V4L2_PIX_FMT_SBGGR12P
V4L2_PIX_FMT_SGBRG12P
V4L2_PIX_FMT_SGRBG12P
V4L2_PIX_FMT_SRGGB12P
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
Documentation/media/uapi/v4l/pixfmt-rgb.rst | 1 +
Documentation/media/uapi/v4l/pixfmt-srggb12p.rst | 108 +++
drivers/media/v4l2-core/v4l2-ioctl.c | 12 ++-
include/uapi/linux/videodev2.h | 5 ++
4 files changed, 122 insertions(+), 4 deletions(-)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb12p.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
index 9cc9808..81412f7 100644
--- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
@@ -18,3 +18,4 @@ RGB Formats
pixfmt-srggb10alaw8
pixfmt-srggb10dpcm8
pixfmt-srggb12
+pixfmt-srggb12p
diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst
b/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst
new file mode 100644
index 000..807ecf0
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst
@@ -0,0 +1,108 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-SRGGB12P:
+.. _v4l2-pix-fmt-sbggr12p:
+.. _v4l2-pix-fmt-sgbrg12p:
+.. _v4l2-pix-fmt-sgrbg12p:
+
+***
+V4L2_PIX_FMT_SRGGB12P ('pRAA'), V4L2_PIX_FMT_SGRBG12P ('pgAA'),
V4L2_PIX_FMT_SGBRG12P ('pGAA'), V4L2_PIX_FMT_SBGGR12P ('pBAA'),
+***
+
+*man V4L2_PIX_FMT_SRGGB12P(2)*
+
+V4L2_PIX_FMT_SGRBG12P
+V4L2_PIX_FMT_SGBRG12P
+V4L2_PIX_FMT_SBGGR12P
+12-bit packed Bayer formats
+
+
+Description
+===
+
+These four pixel formats are packed raw sRGB / Bayer formats with 12
+bits per colour. Every two consecutive samples are packed into three
+bytes. Each of the first two bytes contain the 8 high order bits of
+the pixels, and the third byte contains the four least significants
+bits of each pixel, in the same order.
+
+Each n-pixel row contains n/2 green samples and n/2 blue or red
+samples, with alternating green-red and green-blue rows. They are
+conventionally described as GRGR... BGBG..., RGRG... GBGB..., etc.
+Below is an example of one of these formats:
+
+**Byte Order.**
+Each cell is one byte.
+
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+:widths: 2 1 1 1 1 1 1
+
+
+- .. row 1
+
+ - start + 0:
+
+ - B\ :sub:`00high`
+
+ - G\ :sub:`01high`
+
+ - G\ :sub:`01low`\ (bits 7--4) B\ :sub:`00low`\ (bits 3--0)
+
+ - B\ :sub:`02high`
+
+ - G\ :sub:`03high`
+
+ - G\ :sub:`03low`\ (bits 7--4) B\ :sub:`02low`\ (bits 3--0)
+
+- .. row 2
+
+ - start + 5:
+
+ - G\ :sub:`10high`
+
+ - R\ :sub:`11high`
+
+ - R\ :sub:`11low`\ (bits 7--4) G\ :sub:`10low`\ (bits 3--0)
+
+ - G\ :sub:`12high`
+
+ - R\ :sub:`13high`
+
+ - R\ :sub:`13low`\ (bits 3--2) G\ :sub:`12low`\ (bits 3--0)
+
+- .. row 3
+
+ - start + 0:
+
+ - B\ :sub:`20high`
+
+ - G\ :sub:`21high`
+
+ - G\ :sub:`21low`\ (bits 7--4) B\ :sub:`20low`\ (bits 3--0)
+
+ - B\ :sub:`22high`
+
+ - G\ :sub:`23high`
+
+ - G\ :sub:`23low`\ (bits 7--4) B\ :sub:`22low`\ (bits 3--0)
+
+- .. row 4
+
+ - start + 5:
+
+ - G\ :sub:`30high`
+
+ - R\ :sub:`31high`
+
+ - R\ :sub:`31low`\ (bits 7--4) G\ :sub:`30low`\ (bits 3--0)
+
+ - G\ :sub:`32high`
+
+ - R\ :sub:`33high`
+
+ - R\ :sub:`33low`\ (bits 3--2) G\ :sub:`32low`\ (bits 3--0)
+
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 51a0fa1..ebce910 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1213,10 +1213,6 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_SGBRG10: descr = "10-bit Bayer GBGB/RGRG"; break;
case V4L2_PIX_FMT_SGRBG10: descr = "10-bit Bayer GRGR/BGBG"; break;
case V4L2_PIX_FMT_SRGGB10: descr = "10-bit Bayer RGRG/GBGB"; break;
- case V4L2_PIX_FMT_SBGGR12: descr = "12-bit Bayer BGBG/GRGR"; break;
- case V4L2_PIX_FMT_SGBRG12: descr = "12-bit Bayer GBGB/RGRG"; break;
- case V4L2_PIX_FMT_SGRBG12: descr = "12-bit Bayer GRGR/BGBG"; break;
- case V4L2_PIX_FMT_SRGGB12: descr = "12-bit Bayer RGRG/GBGB"; break;
case V4L2_PIX_FMT_SBGGR10P: descr = "10-bit Bayer BGBG/GRGR
Packed"; break;
case V4L2_PIX_FMT_SGBRG10P: descr = "10-bit Bayer GBGB/RGRG
Packed"; break;
ca
Re: Functions and data structure cross references with Sphinx
Em Fri, 5 Aug 2016 09:29:23 +0200 Markus Heiser escreveu: > Am 01.08.2016 um 13:25 schrieb Mauro Carvalho Chehab > : > > > There's one remaining major issue I noticed after the conversion of the > > media books to Sphinx: > > > > While sphinx complains if a cross-reference (using :ref:) points to an > > undefined reference, the same doesn't happen if the reference uses > > :c:func: and :c:type:. > > > > In practice, it means that, if we do some typo there, or if we forget to > > add the function/struct prototype (or use the wrong domain, like :cpp:), > > Sphinx won't generate the proper cross-reference, nor warning the user. > > > > That's specially bad for media, as, while we're using the c domain for > > the kAPI and driver-specific books, we need to use the cpp domain on the > > uAPI book - as the c domain doesn't allow multiple declarations for > > syscalls, and we have multiple pages for read, write, open, close, > > poll and ioctl. > > > > It would be good to have a way to run Sphinx on some "pedantic" > > mode or have something similar to xmlint that would be complaining > > about invalid c/cpp domain references. > > > > Thanks, > > Mauro > > Hi Mauro, > > there is a nit-picky mode [1], which could be activated by setting > "nitpicky=True" in the conf.py or alternative, set "-n" to the > SPHINXOPTS: > > make SPHINXOPTS=-n htmldocs > > Within nit-picky mode, Sphinx will warn about **all** references. This > might be more then you want. For this, in the conf.py you could > assemble a "nitpick_ignore" list [2]. But I think, assemble the > ignore list is quite a lot of work. > > [1] http://www.sphinx-doc.org/en/stable/config.html#confval-nitpicky > [2] http://www.sphinx-doc.org/en/stable/config.html#confval-nitpick_ignore Yeah, this is what I was looking for. We indeed want to use this option on media, but there are some things that need to be addressed. From some quick tests here, what I noticed is: 1) Sphinx will generate several references that should be safely ignored for everyone, like "enum", "u32", "int32_t", "bool", "NULL", etc; 2) the usage of cpp domain for system calls make several symbols to not match, as the cpp function prototype will generate cross references for the cpp domain, instead of using the c domain. So, we need a better way to fix it using the c domain, or convert everything to the cpp domain; 3) The references generated from the header files I'm parsing don't use the c (or cpp) domain. They're declared at the media book as a normal reference: Documentation/media/uapi/v4l/field-order.rst:.. _v4l2-field: and cross-referenced with: ref:`v4l2_field ` Is there a way to change it to the c domain? 4) there are several references that, IMHO, should be nitpick-ignored only when the book is generated stand alone. For example, at the media docbooks, we have references for things like: - pci_dev, mutex, off_t, container_of, etc - those are generic references for the symbols that every driver uses, but, as we don't have the books with those converted yet, nitpick complains. Once we have such references, they should be ignored *only* when the book is generated standalone. As those are "core" symbols, they should be already be documented, but the book was not ported from DocBook yet. Once we have everything ported to Sphinx, I would expect that they all will vanish (and, if not, IMHO, documenting them should be prioritized). - References for subsystem-specific symbols like: spi_board_info, led_classdev_flash, i2c_adapter, etc. Those would require that the maintainers of the specific subsystems to add documentation to them, as I bet several such symbols won't be currently documented. So, even after the port, I afraid that we'll still have several such symbols missing. To address (3), we need different sets of nitpick ignore lists. At least in my case, I have two different procedures, depending on the time at the Kernel release cycle: a) daily patch merge workflow -- In any case, for (3), I don't want to see those warnings during my daily patch handling process where I rebuild documentation for every patch that touches a documented file. I want to see only things like: Documentation/media/uapi/v4l/hist-v4l2.rst:1295: WARNING: c:type reference target not found: struct v4l2_buffer With indicates that a new patch would be introducing documentation gaps. So, we need a way to have a per-subsystem nitpick_ignore list (or a way to pass such list via command line), for us to be able to ignore "alien" symbols that aren't part of the subsystem we're maintaining. b) preparation for the merge window Late at the patch handling cycle, I run a very long task here that builds the media subsystem for 50+ different archs. I also check and fix smatch/sparse warnings. During such time, I would love to view the full list of missing symbols, in order to be able to
[PATCH v3 09/11] media: Add 1X16 16-bit raw bayer media bus code definitions
The codes will be called: MEDIA_BUS_FMT_SBGGR16_1X16 MEDIA_BUS_FMT_SGBRG16_1X16 MEDIA_BUS_FMT_SGRBG16_1X16 MEDIA_BUS_FMT_SRGGB16_1X16 Signed-off-by: Sakari Ailus --- Documentation/media/uapi/v4l/subdev-formats.rst | 290 +++- include/uapi/linux/media-bus-format.h | 6 +- 2 files changed, 294 insertions(+), 2 deletions(-) diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst b/Documentation/media/uapi/v4l/subdev-formats.rst index 238ecfc..6c1c5af 100644 --- a/Documentation/media/uapi/v4l/subdev-formats.rst +++ b/Documentation/media/uapi/v4l/subdev-formats.rst @@ -2782,7 +2782,7 @@ organization is given as an example for the first pixel only. - Code - - - :cspan:`13` Data organization + - :cspan:`15` Data organization - .. row 2 @@ -2790,6 +2790,10 @@ organization is given as an example for the first pixel only. - - Bit + - 15 + + - 14 + - 13 - 12 @@ -2837,6 +2841,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`7` - b\ :sub:`6` @@ -2872,6 +2880,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -2907,6 +2919,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -2942,6 +2958,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - r\ :sub:`7` - r\ :sub:`6` @@ -2977,6 +2997,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`7` - b\ :sub:`6` @@ -3012,6 +3036,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -3047,6 +3075,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -3082,6 +3114,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - r\ :sub:`7` - r\ :sub:`6` @@ -3117,6 +3153,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`7` - b\ :sub:`6` @@ -3152,6 +3192,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -3187,6 +3231,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -3222,6 +3270,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - r\ :sub:`7` - r\ :sub:`6` @@ -3257,6 +3309,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - 0 - 0 @@ -3290,6 +3346,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`7` - b\ :sub:`6` @@ -3325,6 +3385,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`7` - b\ :sub:`6` @@ -3358,6 +3422,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - 0 - 0 @@ -3393,6 +3461,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`9` - b\ :sub:`8` @@ -3426,6 +3498,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`1` - b\ :sub:`0` @@ -3461,6 +3537,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`1` - b\ :sub:`0` @@ -3494,6 +3574,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`9` - b\ :sub:`8` @@ -3525,6 +3609,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`9` - b\ :sub:`8` @@ -3560,6 +3648,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`9` - g\ :sub:`8` @@ -3595,6 +3687,10 @@ o
[PATCH v3 08/11] doc-rst: Add packed Bayer raw14 pixel formats
These formats are compressed 14-bit raw bayer formats with four different
pixel orders. They are similar to 10-bit variants. The formats added by
this patch are
V4L2_PIX_FMT_SBGGR14P
V4L2_PIX_FMT_SGBRG14P
V4L2_PIX_FMT_SGRBG14P
V4L2_PIX_FMT_SRGGB14P
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
Documentation/media/uapi/v4l/pixfmt-rgb.rst | 1 +
Documentation/media/uapi/v4l/pixfmt-srggb14p.rst | 127 +++
include/uapi/linux/videodev2.h | 5 +
3 files changed, 133 insertions(+)
create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb14p.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
index 548551a..69f11ab 100644
--- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
@@ -20,3 +20,4 @@ RGB Formats
pixfmt-srggb12
pixfmt-srggb12p
pixfmt-srggb14
+pixfmt-srggb14p
diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb14p.rst
b/Documentation/media/uapi/v4l/pixfmt-srggb14p.rst
new file mode 100644
index 000..88d20c0
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb14p.rst
@@ -0,0 +1,127 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-SRGGB14P:
+.. _v4l2-pix-fmt-sbggr14p:
+.. _v4l2-pix-fmt-sgbrg14p:
+.. _v4l2-pix-fmt-sgrbg14p:
+
+***
+V4L2_PIX_FMT_SRGGB14P ('pRCC'), V4L2_PIX_FMT_SGRBG14P ('pgCC'),
V4L2_PIX_FMT_SGBRG14P ('pGCC'), V4L2_PIX_FMT_SBGGR14P ('pBCC'),
+***
+
+*man V4L2_PIX_FMT_SRGGB14P(2)*
+
+V4L2_PIX_FMT_SGRBG14P
+V4L2_PIX_FMT_SGBRG14P
+V4L2_PIX_FMT_SBGGR14P
+14-bit packed Bayer formats
+
+
+Description
+===
+
+These four pixel formats are packed raw sRGB / Bayer formats with 14
+bits per colour. Every four consecutive samples are packed into seven
+bytes. Each of the first four bytes contain the eight high order bits
+of the pixels, and the three following bytes contains the six least
+significants bits of each pixel, in the same order.
+
+Each n-pixel row contains n/2 green samples and n/2 blue or red samples,
+with alternating green-red and green-blue rows. They are conventionally
+described as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example
+of one of these formats:
+
+**Byte Order.**
+Each cell is one byte.
+
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+:widths: 2 1 1 1 1 1 1 1
+
+
+- .. row 1
+
+ - start + 0:
+
+ - B\ :sub:`00high`
+
+ - G\ :sub:`01high`
+
+ - B\ :sub:`02high`
+
+ - G\ :sub:`03high`
+
+ - G\ :sub:`01low bits 1--0`\ (bits 7--6)
+ B\ :sub:`00low bits 5--0`\ (bits 5--0)
+
+ - R\ :sub:`02low bits 3--0`\ (bits 7--4)
+ G\ :sub:`01low bits 5--2`\ (bits 3--0)
+
+ - G\ :sub:`03low bits 5--0`\ (bits 7--2)
+ R\ :sub:`02low bits 5--4`\ (bits 1--0)
+
+- .. row 2
+
+ - start + 7:
+
+ - G\ :sub:`00high`
+
+ - R\ :sub:`01high`
+
+ - G\ :sub:`02high`
+
+ - R\ :sub:`03high`
+
+ - R\ :sub:`01low bits 1--0`\ (bits 7--6)
+ G\ :sub:`00low bits 5--0`\ (bits 5--0)
+
+ - G\ :sub:`02low bits 3--0`\ (bits 7--4)
+ R\ :sub:`01low bits 5--2`\ (bits 3--0)
+
+ - R\ :sub:`03low bits 5--0`\ (bits 7--2)
+ G\ :sub:`02low bits 5--4`\ (bits 1--0)
+
+- .. row 3
+
+ - start + 14
+
+ - B\ :sub:`20high`
+
+ - G\ :sub:`21high`
+
+ - B\ :sub:`22high`
+
+ - G\ :sub:`23high`
+
+ - G\ :sub:`21low bits 1--0`\ (bits 7--6)
+ B\ :sub:`20low bits 5--0`\ (bits 5--0)
+
+ - R\ :sub:`22low bits 3--0`\ (bits 7--4)
+ G\ :sub:`21low bits 5--2`\ (bits 3--0)
+
+ - G\ :sub:`23low bits 5--0`\ (bits 7--2)
+ R\ :sub:`22low bits 5--4`\ (bits 1--0)
+
+- .. row 4
+
+ - start + 21
+
+ - G\ :sub:`30high`
+
+ - R\ :sub:`31high`
+
+ - G\ :sub:`32high`
+
+ - R\ :sub:`33high`
+
+ - R\ :sub:`31low bits 1--0`\ (bits 7--6)
+ G\ :sub:`30low bits 5--0`\ (bits 5--0)
+
+ - G\ :sub:`32low bits 3--0`\ (bits 7--4)
+ R\ :sub:`31low bits 5--2`\ (bits 3--0)
+
+ - R\ :sub:`33low bits 5--0`\ (bits 7--2)
+ G\ :sub:`32low bits 5--4`\ (bits 1--0)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index dd7b29d..32e9e74 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -587,6 +587,11 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SGBRG14 v4l2_fourcc('G', 'B', '1', '4') /* 14 GBGB..
RGRG.. */
#define V4L2_PIX_FMT_SGRBG14 v4l2_fourcc('G', 'R', '1', '4') /* 14 GRGR..
BGBG.. */
#define V4L2_PIX_FMT_SRGGB14 v4l2_fourcc('R', 'G', '1', '4') /*
[PATCH v3 00/11] New raw bayer format definitions, fixes
Hi all, This is a third version of the new bayer format patchset. The second version of the set may be found here: http://www.spinics.net/lists/linux-media/msg101498.html> These patches fix and add new raw bayer format definitions. 12-bit packed V4L2 format definition is added as well as definitions of 14-bit media bus codes as well as unpacked and packed V4L2 formats. No driver uses them right now, yet they're common formats needed by newer devices that use higher bit depths so adding them would make sense. 16-bit pixel formats are added as well, and the 16-bit formats are now expected to have 16 bits of data. 8-bit format documentation is unified. Since v2: - Convert documentation changes to ReST - Use figures and word numerals consistently (3rd patch) - Change "colour component" -> sample. This makes more sense. (3rd patch as well as the patches adding new formats) - Unify the documentation of 8 bits per sample formats - 16 bpp formats now have 16 significant bits. The drivers that use them do not depend on the optionally lower bit depth allowed by the old definition (10th patch) Despite these changes, I've cunningly kept Hans's acks. I hope that works out well. -- Cheers, Sakari -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 03/11] doc-rst: Clean up raw bayer pixel format definitions
- Explicitly state that the most significant n bits are zeroed on 10 and 12 bpp formats. - Remove extra comma from the last entry of the format list - Add a missing colon before a list - Use figures versus word numerals consistently Signed-off-by: Sakari Ailus --- Documentation/media/uapi/v4l/pixfmt-srggb10.rst | 15 --- Documentation/media/uapi/v4l/pixfmt-srggb10p.rst | 8 Documentation/media/uapi/v4l/pixfmt-srggb12.rst | 5 +++-- 3 files changed, 15 insertions(+), 13 deletions(-) diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10.rst b/Documentation/media/uapi/v4l/pixfmt-srggb10.rst index 44a4956..deb6f19 100644 --- a/Documentation/media/uapi/v4l/pixfmt-srggb10.rst +++ b/Documentation/media/uapi/v4l/pixfmt-srggb10.rst @@ -21,15 +21,16 @@ Description === These four pixel formats are raw sRGB / Bayer formats with 10 bits per -colour. Each colour component is stored in a 16-bit word, with 6 unused -high bits filled with zeros. Each n-pixel row contains n/2 green samples -and n/2 blue or red samples, with alternating red and blue rows. Bytes -are stored in memory in little endian order. They are conventionally -described as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example -of one of these formats +sample. Each sample is stored in a 16-bit word, with 6 unused +high bits filled with zeros. Each n-pixel row contains n/2 green samples and +n/2 blue or red samples, with alternating red and blue rows. Bytes are +stored in memory in little endian order. They are conventionally described +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of +these formats: **Byte Order.** -Each cell is one byte, high 6 bits in high bytes are 0. +Each cell is one byte, the 6 most significant bits in the high bytes +are 0. diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst index 32c067c..b24f2e4 100644 --- a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst +++ b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst @@ -21,10 +21,10 @@ Description === These four pixel formats are packed raw sRGB / Bayer formats with 10 -bits per colour. Every four consecutive colour components are packed -into 5 bytes. Each of the first 4 bytes contain the 8 high order bits of -the pixels, and the fifth byte contains the two least significants bits -of each pixel, in the same order. +bits per sample. Every four consecutive samples are packed into 5 +bytes. Each of the first 4 bytes contain the 8 high order bits +of the pixels, and the 5th byte contains the 2 least significants +bits of each pixel, in the same order. Each n-pixel row contains n/2 green samples and n/2 blue or red samples, with alternating green-red and green-blue rows. They are conventionally diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb12.rst b/Documentation/media/uapi/v4l/pixfmt-srggb12.rst index b3b0709..1d217f2 100644 --- a/Documentation/media/uapi/v4l/pixfmt-srggb12.rst +++ b/Documentation/media/uapi/v4l/pixfmt-srggb12.rst @@ -27,10 +27,11 @@ high bits filled with zeros. Each n-pixel row contains n/2 green samples and n/2 blue or red samples, with alternating red and blue rows. Bytes are stored in memory in little endian order. They are conventionally described as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example -of one of these formats +of one of these formats: **Byte Order.** -Each cell is one byte, high 4 bits in high bytes are 0. +Each cell is one byte, the 4 most significant bits in the high bytes are +0. -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 06/11] media: Add 1X14 14-bit raw bayer media bus code definitions
From: Jouni Ukkonen The codes will be called: MEDIA_BUS_FMT_SBGGR14_1X14 MEDIA_BUS_FMT_SGBRG14_1X14 MEDIA_BUS_FMT_SGRBG14_1X14 MEDIA_BUS_FMT_SRGGB14_1X14 Signed-off-by: Jouni Ukkonen Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil --- Documentation/media/uapi/v4l/subdev-formats.rst | 258 +++- include/uapi/linux/media-bus-format.h | 6 +- 2 files changed, 262 insertions(+), 2 deletions(-) diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst b/Documentation/media/uapi/v4l/subdev-formats.rst index 6dbb27b..238ecfc 100644 --- a/Documentation/media/uapi/v4l/subdev-formats.rst +++ b/Documentation/media/uapi/v4l/subdev-formats.rst @@ -2782,7 +2782,7 @@ organization is given as an example for the first pixel only. - Code - - - :cspan:`11` Data organization + - :cspan:`13` Data organization - .. row 2 @@ -2790,6 +2790,10 @@ organization is given as an example for the first pixel only. - - Bit + - 13 + + - 12 + - 11 - 10 @@ -2829,6 +2833,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`7` - b\ :sub:`6` @@ -2860,6 +2868,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -2891,6 +2903,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -2922,6 +2938,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - r\ :sub:`7` - r\ :sub:`6` @@ -2953,6 +2973,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`7` - b\ :sub:`6` @@ -2984,6 +3008,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -3015,6 +3043,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -3046,6 +3078,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - r\ :sub:`7` - r\ :sub:`6` @@ -3077,6 +3113,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`7` - b\ :sub:`6` @@ -3108,6 +3148,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -3139,6 +3183,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - g\ :sub:`7` - g\ :sub:`6` @@ -3170,6 +3218,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - r\ :sub:`7` - r\ :sub:`6` @@ -3201,6 +3253,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - 0 - 0 @@ -3230,6 +3286,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`7` - b\ :sub:`6` @@ -3261,6 +3321,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`7` - b\ :sub:`6` @@ -3290,6 +3354,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - 0 - 0 @@ -3321,6 +3389,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`9` - b\ :sub:`8` @@ -3350,6 +3422,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`1` - b\ :sub:`0` @@ -3381,6 +3457,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`1` - b\ :sub:`0` @@ -3410,6 +3490,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`9` - b\ :sub:`8` @@ -3437,6 +3521,10 @@ organization is given as an example for the first pixel only. - - + - - + + - - + - b\ :sub:`9` - b\ :sub:`8` @@ -3468,6 +3556,10 @@ organization is given as an example for the first pixel only. - - + - - + + -
[PATCH v3 11/11] doc-rst: Add 16-bit raw bayer pixel format definitions
The formats added by this patch are:
V4L2_PIX_FMT_SBGGR16
V4L2_PIX_FMT_SGBRG16
V4L2_PIX_FMT_SGRBG16
V4L2_PIX_FMT_SRGGB16 already existed before the patch. Rework the
documentation to match that of the other sample depths.
Also align the description of V4L2_PIX_FMT_SRGGB16 to match with other
similar formats.
Signed-off-by: Sakari Ailus
Acked-by: Lad, Prabhakar
---
Documentation/media/uapi/v4l/pixfmt-rgb.rst | 2 +-
Documentation/media/uapi/v4l/pixfmt-sbggr16.rst | 111 --
Documentation/media/uapi/v4l/pixfmt-srggb16.rst | 120
drivers/media/v4l2-core/v4l2-ioctl.c| 5 +-
include/uapi/linux/videodev2.h | 3 +
5 files changed, 128 insertions(+), 113 deletions(-)
delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
create mode 100644 Documentation/media/uapi/v4l/pixfmt-srggb16.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
index 69f11ab..ed0ac1b 100644
--- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
@@ -12,7 +12,6 @@ RGB Formats
pixfmt-packed-rgb
pixfmt-srggb8
-pixfmt-sbggr16
pixfmt-srggb10
pixfmt-srggb10p
pixfmt-srggb10alaw8
@@ -21,3 +20,4 @@ RGB Formats
pixfmt-srggb12p
pixfmt-srggb14
pixfmt-srggb14p
+pixfmt-srggb16
diff --git a/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
b/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
deleted file mode 100644
index 7844dc3..000
--- a/Documentation/media/uapi/v4l/pixfmt-sbggr16.rst
+++ /dev/null
@@ -1,111 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _V4L2-PIX-FMT-SBGGR16:
-
-*
-V4L2_PIX_FMT_SBGGR16 ('BYR2')
-*
-
-*man V4L2_PIX_FMT_SBGGR16(2)*
-
-Bayer RGB format
-
-
-Description
-===
-
-This format is similar to
-:ref:`V4L2_PIX_FMT_SBGGR8 `, except each pixel
-has a depth of 16 bits. The least significant byte is stored at lower
-memory addresses (little-endian).
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-.. flat-table::
-:header-rows: 0
-:stub-columns: 0
-:widths: 2 1 1 1 1 1 1 1 1
-
-
-- .. row 1
-
- - start + 0:
-
- - B\ :sub:`00low`
-
- - B\ :sub:`00high`
-
- - G\ :sub:`01low`
-
- - G\ :sub:`01high`
-
- - B\ :sub:`02low`
-
- - B\ :sub:`02high`
-
- - G\ :sub:`03low`
-
- - G\ :sub:`03high`
-
-- .. row 2
-
- - start + 8:
-
- - G\ :sub:`10low`
-
- - G\ :sub:`10high`
-
- - R\ :sub:`11low`
-
- - R\ :sub:`11high`
-
- - G\ :sub:`12low`
-
- - G\ :sub:`12high`
-
- - R\ :sub:`13low`
-
- - R\ :sub:`13high`
-
-- .. row 3
-
- - start + 16:
-
- - B\ :sub:`20low`
-
- - B\ :sub:`20high`
-
- - G\ :sub:`21low`
-
- - G\ :sub:`21high`
-
- - B\ :sub:`22low`
-
- - B\ :sub:`22high`
-
- - G\ :sub:`23low`
-
- - G\ :sub:`23high`
-
-- .. row 4
-
- - start + 24:
-
- - G\ :sub:`30low`
-
- - G\ :sub:`30high`
-
- - R\ :sub:`31low`
-
- - R\ :sub:`31high`
-
- - G\ :sub:`32low`
-
- - G\ :sub:`32high`
-
- - R\ :sub:`33low`
-
- - R\ :sub:`33high`
diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb16.rst
b/Documentation/media/uapi/v4l/pixfmt-srggb16.rst
new file mode 100644
index 000..4a3e6f9
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb16.rst
@@ -0,0 +1,120 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-SRGGB16:
+.. _v4l2-pix-fmt-sbggr16:
+.. _v4l2-pix-fmt-sgbrg16:
+.. _v4l2-pix-fmt-sgrbg16:
+
+
+***
+V4L2_PIX_FMT_SRGGB16 ('RG16'), V4L2_PIX_FMT_SGRBG16 ('GR16'),
V4L2_PIX_FMT_SGBRG16 ('GB16'), V4L2_PIX_FMT_SBGGR16 ('BYR2'),
+***
+
+*man V4L2_PIX_FMT_SRGGB16(2)*
+
+V4L2_PIX_FMT_SGRBG16
+V4L2_PIX_FMT_SGBRG16
+V4L2_PIX_FMT_SBGGR16
+16-bit Bayer formats expanded to 16 bits
+
+
+Description
+===
+
+These four pixel formats are raw sRGB / Bayer formats with 16 bits per
+sample. Each sample is stored in a 16-bit word. Each n-pixel row contains
+n/2 green samples and n/2 blue or red samples, with alternating red and blue
+rows. Bytes are stored in memory in little endian order. They are
+conventionally described as GRGR... BGBG..., RGRG... GBGB..., etc. Below is
+an example of one of these formats:
+
+**Byte Order.**
+Each cell is one byte.
+
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+:widths: 2 1 1 1 1 1 1 1 1
+
+
+- .. row 1
+
+ - start + 0:
+
+ - B\ :sub:`00low`
+
+ - B\ :sub:`00high`
+
+ - G\ :sub:`01low`
+
[PATCH v3 02/11] doc-rst: Fix number of zeroed high order bits in 12-bit raw format defs
The number of high order bits in samples was documented to be 6 for 12-bit data. This is clearly wrong, fix it. Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil --- Documentation/media/uapi/v4l/pixfmt-srggb12.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb12.rst b/Documentation/media/uapi/v4l/pixfmt-srggb12.rst index f5303ab..b3b0709 100644 --- a/Documentation/media/uapi/v4l/pixfmt-srggb12.rst +++ b/Documentation/media/uapi/v4l/pixfmt-srggb12.rst @@ -30,7 +30,7 @@ described as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these formats **Byte Order.** -Each cell is one byte, high 6 bits in high bytes are 0. +Each cell is one byte, high 4 bits in high bytes are 0. -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/11] doc-rst: Unify documentation of the 8-bit bayer formats
The other raw bayer formats had a single sample depth dependent definition
whereas the 8-bit formats had one page for each. Unify the documentation
of the 8-bit formats.
Signed-off-by: Sakari Ailus
---
Documentation/media/uapi/v4l/pixfmt-rgb.rst| 3 -
Documentation/media/uapi/v4l/pixfmt-sbggr8.rst | 81 --
Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst | 81 --
Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst | 81 --
Documentation/media/uapi/v4l/pixfmt-srggb8.rst | 41 +++--
5 files changed, 23 insertions(+), 264 deletions(-)
delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sbggr8.rst
delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst
delete mode 100644 Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst
diff --git a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
index 4b3651c..9cc9808 100644
--- a/Documentation/media/uapi/v4l/pixfmt-rgb.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-rgb.rst
@@ -11,9 +11,6 @@ RGB Formats
:maxdepth: 1
pixfmt-packed-rgb
-pixfmt-sbggr8
-pixfmt-sgbrg8
-pixfmt-sgrbg8
pixfmt-srggb8
pixfmt-sbggr16
pixfmt-srggb10
diff --git a/Documentation/media/uapi/v4l/pixfmt-sbggr8.rst
b/Documentation/media/uapi/v4l/pixfmt-sbggr8.rst
deleted file mode 100644
index db4c523..000
--- a/Documentation/media/uapi/v4l/pixfmt-sbggr8.rst
+++ /dev/null
@@ -1,81 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _V4L2-PIX-FMT-SBGGR8:
-
-
-V4L2_PIX_FMT_SBGGR8 ('BA81')
-
-
-*man V4L2_PIX_FMT_SBGGR8(2)*
-
-Bayer RGB format
-
-
-Description
-===
-
-This is commonly the native format of digital cameras, reflecting the
-arrangement of sensors on the CCD device. Only one red, green or blue
-value is given for each pixel. Missing components must be interpolated
-from neighbouring pixels. From left to right the first row consists of a
-blue and green value, the second row of a green and red value. This
-scheme repeats to the right and down for every two columns and rows.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-.. flat-table::
-:header-rows: 0
-:stub-columns: 0
-:widths: 2 1 1 1 1
-
-
-- .. row 1
-
- - start + 0:
-
- - B\ :sub:`00`
-
- - G\ :sub:`01`
-
- - B\ :sub:`02`
-
- - G\ :sub:`03`
-
-- .. row 2
-
- - start + 4:
-
- - G\ :sub:`10`
-
- - R\ :sub:`11`
-
- - G\ :sub:`12`
-
- - R\ :sub:`13`
-
-- .. row 3
-
- - start + 8:
-
- - B\ :sub:`20`
-
- - G\ :sub:`21`
-
- - B\ :sub:`22`
-
- - G\ :sub:`23`
-
-- .. row 4
-
- - start + 12:
-
- - G\ :sub:`30`
-
- - R\ :sub:`31`
-
- - G\ :sub:`32`
-
- - R\ :sub:`33`
diff --git a/Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst
b/Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst
deleted file mode 100644
index 6345c24..000
--- a/Documentation/media/uapi/v4l/pixfmt-sgbrg8.rst
+++ /dev/null
@@ -1,81 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _V4L2-PIX-FMT-SGBRG8:
-
-
-V4L2_PIX_FMT_SGBRG8 ('GBRG')
-
-
-*man V4L2_PIX_FMT_SGBRG8(2)*
-
-Bayer RGB format
-
-
-Description
-===
-
-This is commonly the native format of digital cameras, reflecting the
-arrangement of sensors on the CCD device. Only one red, green or blue
-value is given for each pixel. Missing components must be interpolated
-from neighbouring pixels. From left to right the first row consists of a
-green and blue value, the second row of a red and green value. This
-scheme repeats to the right and down for every two columns and rows.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-.. flat-table::
-:header-rows: 0
-:stub-columns: 0
-:widths: 2 1 1 1 1
-
-
-- .. row 1
-
- - start + 0:
-
- - G\ :sub:`00`
-
- - B\ :sub:`01`
-
- - G\ :sub:`02`
-
- - B\ :sub:`03`
-
-- .. row 2
-
- - start + 4:
-
- - R\ :sub:`10`
-
- - G\ :sub:`11`
-
- - R\ :sub:`12`
-
- - G\ :sub:`13`
-
-- .. row 3
-
- - start + 8:
-
- - G\ :sub:`20`
-
- - B\ :sub:`21`
-
- - G\ :sub:`22`
-
- - B\ :sub:`23`
-
-- .. row 4
-
- - start + 12:
-
- - R\ :sub:`30`
-
- - G\ :sub:`31`
-
- - R\ :sub:`32`
-
- - G\ :sub:`33`
diff --git a/Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst
b/Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst
deleted file mode 100644
index 51b7b8e..000
--- a/Documentation/media/uapi/v4l/pixfmt-sgrbg8.rst
+++ /dev/null
@@ -1,81 +0,0 @@
-.. -*- coding: utf-8; mode: rst -*-
-
-.. _V4L2-PIX-FMT-SGRBG8:
-
-
-V4L2_PIX_FMT_SGRBG8 ('GRBG')
-
-
-*man V4L2_PIX_FMT_SGRBG8(2)*
-
-Bayer RGB format
-
-
-Description
-
Re: [PATCHv6] support for AD5820 camera auto-focus coil
On Friday 05 August 2016 12:26:11 Pavel Machek wrote: > > This adds support for AD5820 autofocus coil, found for example in > Nokia N900 smartphone. > > Signed-off-by: Pavel Machek Acked-by: Pali Rohár > --- > v2: simple cleanups, fix error paths, simplify probe > v3: more cleanups, remove printk, add include > v4: remove header file. > v5: switch to devm_ , style cleanups, fixes > v6: remove new userspace APIs. > > Can we finally get the patch in, please? This patch is on ML for months or years, right? Please merge it... -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv6] support for AD5820 camera auto-focus coil
This adds support for AD5820 autofocus coil, found for example in
Nokia N900 smartphone.
Signed-off-by: Pavel Machek
---
v2: simple cleanups, fix error paths, simplify probe
v3: more cleanups, remove printk, add include
v4: remove header file.
v5: switch to devm_ , style cleanups, fixes
v6: remove new userspace APIs.
Can we finally get the patch in, please?
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 993dc50..20e8e89 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -279,6 +279,13 @@ config VIDEO_ML86V7667
To compile this driver as a module, choose M here: the
module will be called ml86v7667.
+config VIDEO_AD5820
+ tristate "AD5820 lens voice coil support"
+ depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ ---help---
+ This is a driver for the AD5820 camera lens voice coil.
+ It is used for example in Nokia N900 (RX-51).
+
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 94f2c99..0216af0 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_VIDEO_SAA717X) += saa717x.o
obj-$(CONFIG_VIDEO_SAA7127) += saa7127.o
obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
+obj-$(CONFIG_VIDEO_AD5820) += ad5820.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/ad5820.c b/drivers/media/i2c/ad5820.c
new file mode 100644
index 000..62cc1f5
--- /dev/null
+++ b/drivers/media/i2c/ad5820.c
@@ -0,0 +1,380 @@
+/*
+ * drivers/media/i2c/ad5820.c
+ *
+ * AD5820 DAC driver for camera voice coil focus.
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Copyright (C) 2007 Texas Instruments
+ * Copyright (C) 2016 Pavel Machek
+ *
+ * Contact: Tuukka Toivonen
+ * Sakari Ailus
+ *
+ * Based on af_d88.c by Texas Instruments.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define AD5820_NAME"ad5820"
+
+/* Register definitions */
+#define AD5820_POWER_DOWN (1 << 15)
+#define AD5820_DAC_SHIFT 4
+#define AD5820_RAMP_MODE_LINEAR(0 << 3)
+#define AD5820_RAMP_MODE_64_16 (1 << 3)
+
+#define CODE_TO_RAMP_US(s) ((s) == 0 ? 0 : (1 << ((s) - 1)) * 50)
+#define RAMP_US_TO_CODE(c) fls(((c) + ((c)>>1)) / 50)
+
+#define to_ad5820_device(sd) container_of(sd, struct ad5820_device, subdev)
+
+struct ad5820_device {
+ struct v4l2_subdev subdev;
+ struct ad5820_platform_data *platform_data;
+ struct regulator *vana;
+
+ struct v4l2_ctrl_handler ctrls;
+ u32 focus_absolute;
+ u32 focus_ramp_time;
+ u32 focus_ramp_mode;
+
+ struct mutex power_lock;
+ int power_count;
+
+ int standby : 1;
+};
+
+static int ad5820_write(struct ad5820_device *coil, u16 data)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&coil->subdev);
+ struct i2c_msg msg;
+ int r;
+
+ if (!client->adapter)
+ return -ENODEV;
+
+ data = cpu_to_be16(data);
+ msg.addr = client->addr;
+ msg.flags = 0;
+ msg.len = 2;
+ msg.buf = (u8 *)&data;
+
+ r = i2c_transfer(client->adapter, &msg, 1);
+ if (r < 0) {
+ dev_err(&client->dev, "write failed, error %d\n", r);
+ return r;
+ }
+
+ return 0;
+}
+
+/*
+ * Calculate status word and write it to the device based on current
+ * values of V4L2 controls. It is assumed that the stored V4L2 control
+ * values are properly limited and rounded.
+ */
+static int ad5820_update_hw(struct ad5820_device *coil)
+{
+ u16 status;
+
+ status = RAMP_US_TO_CODE(coil->focus_ramp_time);
+ status |= coil->focus_ramp_mode
+ ? AD5820_RAMP_MODE_64_16 : AD5820_RAMP_MODE_LINEAR;
+ status |= coil->focus_absolute << AD5820_DAC_SHIFT;
+
+ if (coil->standby)
+ status |= AD5820_POWER_DOWN;
+
+ return ad5820_write(coil, status);
+}
+
+/*
+ * Power handling
+ */
+static int ad5820_power_off(struct ad5820_device *coil, int standby)
+{
+ int ret = 0, ret2;
+
+ /*
+* Go to standby first as real power off my be denied by the hardware
+* (single power line control for both coil and sensor).
+*/
+
Sphinx-doc: build over N processes in parallel
Am 20.07.2016 um 16:04 schrieb Mauro Carvalho Chehab : > > A completely unrelated question: it seems that Sphinx is using just > one CPU to do its builds: > > %Cpu0 : 3,0 us, 7,6 sy, 0,0 ni, 89,4 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 > st > %Cpu1 :100,0 us, 0,0 sy, 0,0 ni, 0,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 > st > %Cpu2 : 1,3 us, 2,7 sy, 0,0 ni, 95,7 id, 0,3 wa, 0,0 hi, 0,0 si, 0,0 > st > %Cpu3 : 1,0 us, 3,3 sy, 0,0 ni, 95,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 > st > KiB Mem : 15861876 total, 5809820 free, 1750528 used, 8301528 buff/cache > KiB Swap: 8200188 total, 8200188 free,0 used. 13382964 avail Mem > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > > 5660 mchehab 20 0 325256 89776 8300 R 99,7 0,6 0:22.25 > sphinx-bui+ > > Are there any way to speed it up and make it use all available CPUs? Hi Mauro, sorry for the late reply. There is a sphinx-build option "-j N" [1]. It is in a *experimental* state in Sphinx v1.2 and has been improved in v1.3. Set e.g. "-j2" to the SPHINXOPTS to use two cores. make SPHINXOPTS=-j2 htmldocs But take into account what the documentation says: """not all parts and not all builders of Sphinx can be parallelized.""". [1] http://www.sphinx-doc.org/en/stable/invocation.html#cmdoption-sphinx-build-j -- Markus To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] doc-rst: customize RTD theme, drop padding of inline literal
On 08/05/2016 11:19 AM, Markus Heiser wrote:
> From: Markus Heiser
>
> Remove the distracting (left/right) padding of inline literals. (HTML
> ). Requested and discussed in [1].
>
> [1] http://www.spinics.net/lists/linux-media/msg103991.html
>
> Signed-off-by: Markus Heiser
Acked-by: Hans Verkuil
Thank you! Thank you! Thank you!
So much better!
Regards,
Hans
> ---
> Documentation/sphinx-static/theme_overrides.css | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/sphinx-static/theme_overrides.css
> b/Documentation/sphinx-static/theme_overrides.css
> index 3a2ac4b..e88461c 100644
> --- a/Documentation/sphinx-static/theme_overrides.css
> +++ b/Documentation/sphinx-static/theme_overrides.css
> @@ -42,11 +42,12 @@
> caption a.headerlink { opacity: 0; }
> caption a.headerlink:hover { opacity: 1; }
>
> -/* inline literal: drop the borderbox and red color */
> +/* inline literal: drop the borderbox, padding and red color */
>
> code, .rst-content tt, .rst-content code {
> color: inherit;
> border: none;
> +padding: unset;
> background: inherit;
> font-size: 85%;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] doc-rst: customize RTD theme, drop padding of inline literal
From: Markus Heiser
Remove the distracting (left/right) padding of inline literals. (HTML
). Requested and discussed in [1].
[1] http://www.spinics.net/lists/linux-media/msg103991.html
Signed-off-by: Markus Heiser
---
Documentation/sphinx-static/theme_overrides.css | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/sphinx-static/theme_overrides.css
b/Documentation/sphinx-static/theme_overrides.css
index 3a2ac4b..e88461c 100644
--- a/Documentation/sphinx-static/theme_overrides.css
+++ b/Documentation/sphinx-static/theme_overrides.css
@@ -42,11 +42,12 @@
caption a.headerlink { opacity: 0; }
caption a.headerlink:hover { opacity: 1; }
-/* inline literal: drop the borderbox and red color */
+/* inline literal: drop the borderbox, padding and red color */
code, .rst-content tt, .rst-content code {
color: inherit;
border: none;
+padding: unset;
background: inherit;
font-size: 85%;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: doc-rst: too much space around ``foo`` text
Am 05.08.2016 um 09:39 schrieb Hans Verkuil : > Hi Markus, > > Did you have time to look at this yet? It is for me something that is really > distracting. I tried to track this down myself but I just don't know enough > about > html/css. > > The text ``V4L2_XFER_FUNC_709`` is translated to: > > class="pre">V4L2_XFER_FUNC_709. > > And it is the part that adds the extra spacing somewhere. > > Originally added a rectangle around the text, so I suspect that the > extra spacing > for that rectangle is still added somewhere. > > Regards. > > Hans > Hi Hans, sorry I forgot your requirement ... my TODO list is to long ;-). Yes, this is a 5pt padding (left/right) of the tag. I drop the padding and send a patch ... -- Markus -- > On 07/09/2016 10:40 AM, Markus Heiser wrote: >> Hi Hans, >> >> Am 08.07.2016 um 22:52 schrieb Hans Verkuil : >> >>> Hi Markus, >>> >>> First of all a big 'Thank you!' for working on this, very much appreciated. >>> And I also am very grateful that you could convert the CEC docs so quickly >>> for me. >> >> You are welcome :) >> >>> That said, can you take a look at this: >>> >>> https://mchehab.fedorapeople.org/media_API_book/linux_tv/media/v4l/vidioc-enum-fmt.html >>> >>> As you can see, every text written as ``foo`` in the rst file has a bit too >>> much space >>> around it. It's especially clear in the description of the 'type' field: >>> the commas >>> after each V4L2_BUF_TYPE_ constant should be right after the last >>> character, and now >>> it looks as if there is a space in front. >>> >>> It's jarring when you read it, but it is probably easy to fix for someone >>> who knows >>> this stuff. >> >> Yes, this is a good point, the layout of inline constant markup bothers me >> also. >> The Read-The-Doc (RTD) theme we use is IMHO the best on the web, since it is >> well >> maintained and supports a good layout on various viewports: >> >> http://read-the-docs.readthedocs.io/en/latest/theme.html >> >> Nevertheless I think in some details it is a bit to excessive. >> >> I will place it on my TODO list .. hopefully I find the time to solve >> it in the next days. >> >> -- Markus -- >> >>> >>> Thanks! >>> >>> Hans >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: doc-rst: too much space around ``foo`` text
Hi Markus, Did you have time to look at this yet? It is for me something that is really distracting. I tried to track this down myself but I just don't know enough about html/css. The text ``V4L2_XFER_FUNC_709`` is translated to: V4L2_XFER_FUNC_709. And it is the part that adds the extra spacing somewhere. Originally added a rectangle around the text, so I suspect that the extra spacing for that rectangle is still added somewhere. Regards. Hans On 07/09/2016 10:40 AM, Markus Heiser wrote: > Hi Hans, > > Am 08.07.2016 um 22:52 schrieb Hans Verkuil : > >> Hi Markus, >> >> First of all a big 'Thank you!' for working on this, very much appreciated. >> And I also am very grateful that you could convert the CEC docs so quickly >> for me. > > You are welcome :) > >> That said, can you take a look at this: >> >> https://mchehab.fedorapeople.org/media_API_book/linux_tv/media/v4l/vidioc-enum-fmt.html >> >> As you can see, every text written as ``foo`` in the rst file has a bit too >> much space >> around it. It's especially clear in the description of the 'type' field: the >> commas >> after each V4L2_BUF_TYPE_ constant should be right after the last character, >> and now >> it looks as if there is a space in front. >> >> It's jarring when you read it, but it is probably easy to fix for someone >> who knows >> this stuff. > > Yes, this is a good point, the layout of inline constant markup bothers me > also. > The Read-The-Doc (RTD) theme we use is IMHO the best on the web, since it is > well > maintained and supports a good layout on various viewports: > > http://read-the-docs.readthedocs.io/en/latest/theme.html > > Nevertheless I think in some details it is a bit to excessive. > > I will place it on my TODO list .. hopefully I find the time to solve > it in the next days. > > -- Markus -- > >> >> Thanks! >> >> Hans > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Functions and data structure cross references with Sphinx
Am 01.08.2016 um 13:25 schrieb Mauro Carvalho Chehab : > There's one remaining major issue I noticed after the conversion of the > media books to Sphinx: > > While sphinx complains if a cross-reference (using :ref:) points to an > undefined reference, the same doesn't happen if the reference uses > :c:func: and :c:type:. > > In practice, it means that, if we do some typo there, or if we forget to > add the function/struct prototype (or use the wrong domain, like :cpp:), > Sphinx won't generate the proper cross-reference, nor warning the user. > > That's specially bad for media, as, while we're using the c domain for > the kAPI and driver-specific books, we need to use the cpp domain on the > uAPI book - as the c domain doesn't allow multiple declarations for > syscalls, and we have multiple pages for read, write, open, close, > poll and ioctl. > > It would be good to have a way to run Sphinx on some "pedantic" > mode or have something similar to xmlint that would be complaining > about invalid c/cpp domain references. > > Thanks, > Mauro Hi Mauro, there is a nit-picky mode [1], which could be activated by setting "nitpicky=True" in the conf.py or alternative, set "-n" to the SPHINXOPTS: make SPHINXOPTS=-n htmldocs Within nit-picky mode, Sphinx will warn about **all** references. This might be more then you want. For this, in the conf.py you could assemble a "nitpick_ignore" list [2]. But I think, assemble the ignore list is quite a lot of work. [1] http://www.sphinx-doc.org/en/stable/config.html#confval-nitpicky [2] http://www.sphinx-doc.org/en/stable/config.html#confval-nitpick_ignore -- Markus To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
