c-guide/sphinx.rst| 90 ++-
> Documentation/doc-guide/svg_image.svg | 10 +
> Documentation/process/changes.rst | 7 +-
> Documentation/sphinx/kfigure.py | 442 ++
> 6 files changed, 548 insertions(+), 6 deletions(-)
> create mode 100
Hi Daniel,
On Thursday 02 Mar 2017 14:54:32 Daniel Vetter wrote:
> On Thu, Mar 2, 2017 at 1:26 PM, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > Thank you for the patch.
> >
> > With this applied, I get
> >
> > make[1]: Entering dir
Hi Daniel,
Thank you for the patch.
On Tuesday 28 Feb 2017 18:13:16 Daniel Vetter wrote:
> Oh, the shiny and pretties!
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
Overall this looks good to me, please see below for a few minor issues.
> ---
> Documen
a ok-ish start for
> better atomic overview.
>
> v2: Spelling and clarifications (Eric).
>
> v3: Implement suggestion from Gabriel to fix the graph.
>
> Cc: Gabriel Krisman Bertazi
> Acked-by: Eric Anholt
> Cc: Eric Anholt
> Cc: Laurent Pinchart
> Cc: Harr
rt, otherwise debugging issues with
> the diagrams is impossible.
>
> v3: Only sphinx 1.4 (released in Mar 2016) has patches.Figure.
> Implement Markus suggestion for backwards compatability with earlier
> releases. Laurent reported this, running sphinx 1.3. Solution entirely
&g
Hi Daniel and Markus,
On Thursday 02 Mar 2017 16:11:08 Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 03:58:36PM +0100, Markus Heiser wrote:
> > Am 02.03.2017 um 15:14 schrieb Laurent Pinchart:
> > > On Thursday 02 Mar 2017 14:54:32 Daniel Vetter wrote:
> > >>
Hi Daniel,
Thank you for the patch.
On Wednesday 01 Mar 2017 09:27:14 Daniel Vetter wrote:
> Resulted in confusion a few times in the past.
>
> v2: Spelling fix (Eric).
>
> Cc: Eric Anholt
> Acked-by: Eric Anholt
> Cc: Laurent Pinchart
> Cc: Manasi Navare
> S
ord alignment condition is normally ensured if the buffer is
> + * allocated with kmalloc(), but this may not be the case if the driver
> + * allocates a bigger buffer and point to a random place inside it.
> + *
Couldn't we avoid three copies of the same text ? The chance they will get
out-of-sync is quite high.
> * Initialization:
> *
> * All URBs submitted must initialize the dev, pipe, transfer_flags (may be
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Oliver,
On Thursday 30 Mar 2017 10:11:31 Oliver Neukum wrote:
> Am Donnerstag, den 30.03.2017, 01:15 +0300 schrieb Laurent Pinchart:
> > > + may also override PAD bytes at the end of the ``transfer_buffer``,
> > > up to the
> > > + size of the CPU word.
>
Hi Mauro,
On Wednesday 29 Mar 2017 22:06:33 Mauro Carvalho Chehab wrote:
> Em Thu, 30 Mar 2017 01:15:27 +0300 Laurent Pinchart escreveu:
> > On Wednesday 29 Mar 2017 15:54:21 Mauro Carvalho Chehab wrote:
> > > Several host controllers, commonly found on ARM, like dwc2,
> >
Hi Mauro,
On Thursday 30 Mar 2017 07:28:00 Mauro Carvalho Chehab wrote:
> Em Thu, 30 Mar 2017 12:34:32 +0300 Laurent Pinchart escreveu:
> > On Thursday 30 Mar 2017 10:11:31 Oliver Neukum wrote:
> >> Am Donnerstag, den 30.03.2017, 01:15 +0300 schrieb Laurent Pinchart:
> >&
ding a 16-bits word (0x5678),
> > it will actually read 32 bits, with 16-bits with some random value,
> >
> > causing a buffer overflow. E. g. buffer content will now be:
> > buf = { 0x12, x34, 0xde, 0xad }
> >
> > In other words, the second transfer c
> + - b\ :sub:`3`
> + - b\ :sub:`2`
> + - b\ :sub:`1`
> + - b\ :sub:`0`
> +
> +.. raw:: latex
> +
> +\endgroup
> +
> +
> +The following table list existing packed 36bit wide RGB formats.
s/list/lists/
Same comment for the other tables. Apar
;
> +/**
> + * DOC: Supported input formats and encodings
> + *
> + * Depending on the Hardware configuration of the Controller IP, it
> supports
> + * a subset of the following input formats and encodings on it's internal
> + * 48bit bus.
> + *
s/it's/its/
[s
Hi Neil,
Thank you for the patch.
On Monday 03 Apr 2017 16:42:37 Neil Armstrong wrote:
> This patch adds a new DRM documentation entry and links to the input
> format table added in the dw_hdmi header.
>
> Reviewed-by: Archit Taneja
> Signed-off-by: Neil Armstrong
Acked-by: L
s own operations.
>
> Reviewed-by: Jose Abreu
> Reviewed-by: Archit Taneja
> Signed-off-by: Neil Armstrong
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 135 +++
> include/drm/bridge/dw_hdmi.h |
e related to, say, a video node is a pain
> >> without MC.
> >
> > I disagree with the above sentence: just video nodes are enough for
> > almost all non-embedded hardware. We implemented MC there only in order to
>
> How would you find a sub-device node somehow related to a video node
> without MC?
>
> > solve a conflict when certain sub-devices are busy because they're used by
> > a DVB pipeline while someone tries to stream V4L2 on.
>
> This matter certainly was as you say, but nowadays e.g. some Intel Core
> SoCs do have IPUs (ISPs) and CSI-2 receivers in them. These chips could be
> used on a regular PC. From software point of view they're not different
> from typical embedded systems.
>
> If this doesn't mean that there will be universally more need for MC, it
> does still mean that the need for MC is no longer related to embedded
> systems only.
>
> >> Less variance in interface availability is better for the user
> >> space, and unlike between video node centric vs. MC-centric, there are
> >> hardly technical reasons (or at least I can't remember one) for doing
> >> this.
> >>
> >> I remember we had a few of these drivers and the agreement was to add MC
> >> interface to those.
> >
> > Sorry, I'm completely lost what you meant here, as it seems that you're
> > contradicting yourself :-)
> >
> > Do you want to allow non-mc-centric devices to expose subdev API or not?
> >
> > If not, we need to add a notice forbidding it (but noticing that it
> > might change in the future, if we ever need it for whatever reason).
>
> I meant to say that we should constrain ourselves to providing as little
> variance in user space interfaces between different drivers as possible,
> still without limiting ourselves to supporting only a subset of hardware
> features.
>
> In this case there is no technical reason I'm aware of for providing
> sub-device nodes without Media controller.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
devices that together make a larger user-facing functional
device (for instance the SoC ISP IP cores and external camera sensors together
make a camera device)
We need different terms for those different concepts, and we need to be very
consistent in our usage of those terms. I believe we shou
green light to such implementations
until we have to, and I also prefer discussing this topic separately. It will
require a fair amount of work to document (and thus first agree on), and
there's no need to block the rest of this patch until we complete that work.
For those reasons I woul
>> * - ``V4L2_CAP_DEVICE_CAPS``
> >>- 0x8000
> >>- The driver fills the ``device_caps`` field. This capability can
> >>
> >> diff --git a/include/uapi/linux/videodev2.h
> >> b/include/uapi/linux/videodev2.h index 45cf7359822
Hi Mauro,
On Friday, 25 August 2017 16:38:23 EEST Mauro Carvalho Chehab wrote:
> Em Fri, 25 Aug 2017 16:11:15 +0300 Laurent Pinchart escreveu:
> > On Friday, 25 August 2017 12:40:05 EEST Mauro Carvalho Chehab wrote:
> >> From: "mche...@s-opensource.com"
> >>
const struct v4l2_discrete_probe *probe,
> - s32 width, s32 height);
> +const struct v4l2_frmsize_discrete
> +*v4l2_find_nearest_format(const struct v4l2_frmsize_discrete *sizes,
> + const size_t num_sizes,
No need for a const keyword.
> + s32 width, s32 height);
>
> void v4l2_get_timestamp(struct timeval *tv);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ struct v4l2_priv_tun_config {
>
> #define VIDIOC_INT_RESET _IOW ('d', 102, u32)
>
> -struct v4l2_routing {
> - u32 input;
> - u32 output;
> -};
> -
> /*
> ---------
> */
>
handle userspace sizes, I
wouldn't mention userspace here.
> + */
> const struct v4l2_frmsize_discrete
> *v4l2_find_nearest_format(const struct v4l2_frmsize_discrete *sizes,
> const size_t num_sizes,
> s32 width, s32 height);
>
> +/**
> + * v4l2_get_timestamp - ancillary routine to get a timestamp to be used
> when
> + * filling streaming metadata. Internally, it uses ktime_get_ts(), +
> * with is the recommended way to get it.
s/with/which/
> + *
> + * @tv: pointer to &stuct timeval to be filled.
> + */
> void v4l2_get_timestamp(struct timeval *tv);
>
> #endif /* V4L2_COMMON_H_ */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Each element there groups a set of callbacks functions.
> + * @f: callback function that will be called if @cond matches.
> + * The callback functions are defined in groups, according to
> + * each element at &struct v4l2_subdev_ops.
> */
> #define v4l2_device_has_op(v4l2_dev, grpid, o, f)\
> ({ \
> @@ -331,9 +492,18 @@ static inline void v4l2_subdev_notify(struct
> v4l2_subdev *sd, __result;
> \
> })
>
> -/*
> - * Does any subdev with matching grpmsk (or all if grpmsk == 0) has the
> given
> - * op?
> +/**
> + * v4l2_device_mask_has_op - checks if any subdev with matching group
> + * mask has a given ops.
> + *
> + * @v4l2_dev: pointer to &struct v4l2_device
> + * @grpmsk: bitmask to be checked against &struct v4l2_subdev->grp_id
> + * group ID to be matched. Use 0 to match them all.
> + * @o: name of the element at &struct v4l2_subdev_ops that contains @f.
> + * Each element there groups a set of callbacks functions.
> + * @f: callback function that will be called if @cond matches.
> + * The callback functions are defined in groups, according to
> + * each element at &struct v4l2_subdev_ops.
> */
> #define v4l2_device_mask_has_op(v4l2_dev, grpmsk, o, f)
> \
> ({ \
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2 (vsync == 8) is true.
> + * - For CEA861 timings: if %V4L2_DV_FL_CAN_REDUCE_FPS flag is true.
> */
> static inline bool can_reduce_fps(struct v4l2_bt_timings *bt)
> {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ll syscalls.
> + */
> +enum v4l2_debug_flags {
> + V4L2_DEV_DEBUG_IOCTL= 0x01,
> + V4L2_DEV_DEBUG_IOCTL_ARG= 0x02,
> + V4L2_DEV_DEBUG_FOP = 0x04,
> + V4L2_DEV_DEBUG_STREAMING= 0x08,
> + V4L2_DEV_DEBUG_POLL = 0x10,
> +};
>
f the bus is Mobile Industry Processor
> + * Interface's Camera Serial Interface version 2
> + * (MIPI CSI2).
These are not pointers.
> * @link_frequencies: array of supported link frequencies
> * @nr_of_link_frequencies: number of elements in link_frequencc
> + * probed, to a notifier->waiting list.
> + * Not to be used by drivers.
> */
> struct v4l2_async_subdev {
> enum v4l2_async_match_type match_type;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
+ * @cur.val: The control's current value, if the @type is represented via
> + * a u32 integer (see &enum v4l2_ctrl_type).
> * @val: The control's new s32 value.
> * @priv:The control's private pointer. For use by the driver. It is
> *
Hi Mauro,
On Monday, 18 December 2017 17:13:26 EET Mauro Carvalho Chehab wrote:
> Em Fri, 13 Oct 2017 15:38:11 +0300 Laurent Pinchart escreveu:
> > On Thursday, 28 September 2017 00:46:51 EEST Mauro Carvalho Chehab wrote:
> >> Currently, there's no way to document #defin
e way Sphinx works, the PDF images should be
> generated inside the Kernel source tree, as otherwise Sphinx
> won't find it, not obeying what's specified by "O=" makefile
> parameter.
Can't we fix that ?
> Signed-off-by: Mauro Carvalho Chehab
--
Regards,
L
read for previous versions ?
--
Regards,
Laurent Pinchart
letter, and the submitter should push
and provide a link to a branch that contains the series on top of the
appropriate base (or just a link to the base). This won't help the bots
much though, if they just look at the base tag. Is there a way, or can
we standardize on a way, to indicate where the base can be found ?
> Reviewed-by: Kees Cook
--
Regards,
Laurent Pinchart
"qcom,tsens-v2";
> + reg = <0x0 0x0c271000 0x0 0x1000>,
> + <0x0 0x0c222000 0x0 0x1000>;
> + };
> +
> +Organizing DTSI and DTS
> +---
> +
> +The DTSI and DTS files shall be organized in a way repres
Hi Krzysztof,
On Sun, Nov 26, 2023 at 11:32:17AM +0100, Krzysztof Kozlowski wrote:
> On 25/11/2023 20:37, Laurent Pinchart wrote:
> > On Sat, Nov 25, 2023 at 07:44:22PM +0100, Krzysztof Kozlowski wrote:
> >> Document preferred coding style for Devicetree sources (DTS and DT
ompatible', bytes(compat))
> +
> +with open(fname, 'rb') as inf:
> +compressed = compress_data(inf, compress)
> +fsw.property('data', compressed)
> +return model, compat
> +
> +
> +def build_fit(args):
> +"""Build the FIT from the provided files and arguments
> +
> +Args:
> +args (Namespace): Program arguments
> +
> +Returns:
> +tuple:
> +bytes: FIT data
> +int: Number of configurations generated
> +size: Total uncompressed size of data
> +"""
> +fsw = libfdt.FdtSw()
> +setup_fit(fsw, args.name)
> +seq = 0
> +size = 0
> +entries = []
> +
> +# Handle the kernel
> +with open(args.kernel, 'rb') as inf:
> +comp_data = compress_data(inf, args.compress)
> +size += os.path.getsize(args.kernel)
> +write_kernel(fsw, comp_data, args)
> +
> +for path in args.srcdir:
> +# Handle devicetree files
> +if os.path.isdir(path):
> +for dirpath, _, fnames in os.walk(path):
> +for fname in fnames:
> +if os.path.splitext(fname)[1] != '.dtb':
> +continue
> +pathname = os.path.join(dirpath, fname)
> +seq += 1
> +size += os.path.getsize(pathname)
> +model, compat = output_dtb(fsw, seq, pathname,
> + args.arch, args.compress)
> +entries.append([model, compat])
> +
> +finish_fit(fsw, entries)
> +
> +# Include the kernel itself in the returned file count
> +return fsw.as_fdt().as_bytearray(), seq + 1, size
> +
> +
> +def run_make_fit():
> +"""Run the tool's main logic"""
> +args = parse_args()
> +
> +out_data, count, size = build_fit(args)
> +with open(args.fit, 'wb') as outf:
> +outf.write(out_data)
> +
> +ext_fit_size = None
> +if args.external:
> +mkimage = os.environ.get('MKIMAGE', 'mkimage')
> +subprocess.check_call([mkimage, '-E', '-F', args.fit],
> + stdout=subprocess.DEVNULL)
> +
> +with open(args.fit, 'rb') as inf:
> +data = inf.read()
> +ext_fit = libfdt.FdtRo(data)
> +ext_fit_size = ext_fit.totalsize()
> +
> +comp_size = len(out_data)
> +print(f'FIT size {comp_size:#x}/{comp_size / 1024 / 1024:.1f} MB',
> end='')
> +if ext_fit_size:
> +print(f', header {ext_fit_size:#x}/{ext_fit_size / 1024:.1f} KB',
> end='')
> +print(f', {count} files, uncompressed {size / 1024 / 1024:.1f} MB')
> +
> +
> +if __name__ == "__main__":
> +sys.exit(run_make_fit())
--
Regards,
Laurent Pinchart
On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > Hi Simon,
> >
> > Thank you for the patch.
> >
> > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > >
On Thu, Dec 07, 2023 at 01:52:53PM -0700, Simon Glass wrote:
> On Thu, 7 Dec 2023 at 07:38, Laurent Pinchart wrote:
> > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > Hi Si
On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> wrote:
> >
> > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinch
g-deprecated APIs that we were getting close to
removing for instance. dev_warn() wouldn't have had the same effect.
>
> Use BUILD_BUG_ON() for compile-time assertions
> **
--
Regards,
Laurent Pinchart
Hi Greg,
On Mon, Apr 15, 2024 at 07:21:37AM +0200, Greg KH wrote:
> On Sun, Apr 14, 2024 at 10:48:35PM +0300, Laurent Pinchart wrote:
> > On Sun, Apr 14, 2024 at 12:08:50PM -0500, Alex Elder wrote:
> > > Several times recently Greg KH has admonished that variants of WARN()
&
On Mon, Apr 15, 2024 at 10:33:42AM +0200, Greg KH wrote:
> On Mon, Apr 15, 2024 at 11:25:29AM +0300, Laurent Pinchart wrote:
> > On Mon, Apr 15, 2024 at 07:21:37AM +0200, Greg KH wrote:
> > > On Sun, Apr 14, 2024 at 10:48:35PM +0300, Laurent Pinchart wrote:
> > > >
information
we need without requiring many clicks (or actually any click at all). How can
we keep that feature ?
By the way, the "Video for Linux API" section (and the other sibling sections)
are child nodes of the "Introduction" section. That feels quite odd.
Hi Mauro,
On Wednesday 13 Jul 2016 11:11:43 Mauro Carvalho Chehab wrote:
> Em Sat, 09 Jul 2016 20:10:21 +0300 Laurent Pinchart escreveu:
> > The other one is related, the table of contents in the main page of each
> > section
> > (https://mchehab.fedorapeople.org/media_API_bo
Hi Mauro,
Thank you for the patch.
On Thursday 08 Sep 2016 09:03:44 Mauro Carvalho Chehab wrote:
> The "struct" were inside the reference, causing it to break.
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Laurent Pinchart
> ---
> Documentation/media/kapi/v4l2
evelopers are often
better than patches originating from within a company. External
contributors are more used to follow proper upstream review processes.
> That not to mention that company will almost always prioritize new
> product support over maintaining existing products.
>
> No do/don't kind of document will change that.
>
> A change like that should come top/down, so it has to be addressed
> via other strategies, like documents underlining the benefits of
> upstream first, and tutorials/speeches aimed at companies management
> staff.
--
Regards,
Laurent Pinchart
ing lists, and patches are then of
course reviewed and further discussed in public. Is this a behaviour you
want to discourage, or is this considered fine ?
> +
> Selecting the maintainer
>
>
--
Regards,
Laurent Pinchart
48 matches
Mail list logo
