Re: [PATCH v2] tracing/kprobes: expose maxactive for kretprobe in kprobe_events
On Fri, 31 Mar 2017 10:08:39 -0400 Steven Rostedt wrote: > On Fri, 31 Mar 2017 15:20:24 +0200 > Alban Crequy wrote: > > > When a kretprobe is installed on a kernel function, there is a maximum > > limit of how many calls in parallel it can catch (aka "maxactive"). A > > kernel module could call register_kretprobe() and initialize maxactive > > (see example in samples/kprobes/kretprobe_example.c). > > > > But that is not exposed to userspace and it is currently not possible to > > choose maxactive when writing to /sys/kernel/debug/tracing/kprobe_events > > > > The default maxactive can be as low as 1 on single-core with a > > non-preemptive kernel. This is too low and we need to increase it not > > only for recursive functions, but for functions that sleep or resched. > > > > This patch updates the format of the command that can be written to > > kprobe_events so that maxactive can be optionally specified. > > > > I need this for a bpf program attached to the kretprobe of > > inet_csk_accept, which can sleep for a long time. > > > > This patch includes a basic selftest: > > > > > # ./ftracetest -v test.d/kprobe/ > > > === Ftrace unit tests === > > > [1] Kprobe dynamic event - adding and removing[PASS] > > > [2] Kprobe dynamic event - busy event check [PASS] > > > [3] Kprobe dynamic event with arguments [PASS] > > > [4] Kprobes event arguments with types[PASS] > > > [5] Kprobe dynamic event with function tracer [PASS] > > > [6] Kretprobe dynamic event with arguments[PASS] > > > [7] Kretprobe dynamic event with maxactive[PASS] > > > > > > # of passed: 7 > > > # of failed: 0 > > > # of unresolved: 0 > > > # of untested: 0 > > > # of unsupported: 0 > > > # of xfailed: 0 > > > # of undefined(test bug): 0 > > > > BugLink: https://github.com/iovisor/bcc/issues/1072 > > Signed-off-by: Alban Crequy > > > > --- > > > > Changes since v1: > > - Remove "(*)" from documentation. (Review from Masami Hiramatsu) > > - Fix support for "r100" without the event name (Review from Masami > > Hiramatsu) > > - Get rid of magic numbers within the code. (Review from Steven Rostedt) > > Note that I didn't use KRETPROBE_MAXACTIVE_ALLOC since that patch is not > > merged. > > - Return -E2BIG when maxactive is too big. > > - Add basic selftest > > --- > > Documentation/trace/kprobetrace.txt| 4 ++- > > kernel/trace/trace_kprobe.c| 39 > > ++ > > .../ftrace/test.d/kprobe/kretprobe_maxactive.tc| 39 > > ++ > > 3 files changed, 75 insertions(+), 7 deletions(-) > > create mode 100644 > > tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_maxactive.tc > > > > diff --git a/Documentation/trace/kprobetrace.txt > > b/Documentation/trace/kprobetrace.txt > > index 41ef9d8..7051a20 100644 > > --- a/Documentation/trace/kprobetrace.txt > > +++ b/Documentation/trace/kprobetrace.txt > > @@ -23,7 +23,7 @@ current_tracer. Instead of that, add probe points via > > Synopsis of kprobe_events > > - > >p[:[GRP/]EVENT] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS] : Set a probe > > - r[:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS]: Set a return > > probe > > + r[MAXACTIVE][:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS] : Set a return > > probe > >-:[GRP/]EVENT: Clear a probe > > > > GRP : Group name. If omitted, use "kprobes" for it. > > @@ -32,6 +32,8 @@ Synopsis of kprobe_events > > MOD : Module name which has given SYM. > > SYM[+offs]: Symbol+offset where the probe is inserted. > > MEMADDR : Address where the probe is inserted. > > + MAXACTIVE : Maximum number of instances of the specified function that > > + can be probed simultaneously, or 0 for the default. > > BTW, to me, 0 means none (no instances can probe). This should have a > better description of what "0" actually means. default value is defined in Documentation/kprobes.txt sction 1.3.1, so you'll just need to refer that. Thank you, > > -- Steve > > > > > > FETCHARGS : Arguments. Each probe can have up to 128 args. > >%REG : Fetch register REG -- Masami Hiramatsu -- 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
[PATCH] docs-rst: core_api: move driver-specific stuff to drivers_api
There are several stuff there that are actually driver-specific. Move those to the driver_api book. Signed-off-by: Mauro Carvalho Chehab --- Documentation/core-api/kernel-api.rst | 72 -- Documentation/driver-api/firmware/index.rst| 1 + .../driver-api/firmware/other_interfaces.rst | 15 + Documentation/driver-api/index.rst | 2 + Documentation/driver-api/misc_devices.rst | 5 ++ Documentation/driver-api/pci.rst | 50 +++ 6 files changed, 73 insertions(+), 72 deletions(-) create mode 100644 Documentation/driver-api/firmware/other_interfaces.rst create mode 100644 Documentation/driver-api/misc_devices.rst create mode 100644 Documentation/driver-api/pci.rst diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 9a3d3597a6b7..9ec8488319dc 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -228,72 +228,6 @@ MTRR Handling .. kernel-doc:: arch/x86/kernel/cpu/mtrr/main.c :export: -PCI Support Library - -.. kernel-doc:: drivers/pci/pci.c - :export: - -.. kernel-doc:: drivers/pci/pci-driver.c - :export: - -.. kernel-doc:: drivers/pci/remove.c - :export: - -.. kernel-doc:: drivers/pci/search.c - :export: - -.. kernel-doc:: drivers/pci/msi.c - :export: - -.. kernel-doc:: drivers/pci/bus.c - :export: - -.. kernel-doc:: drivers/pci/access.c - :export: - -.. kernel-doc:: drivers/pci/irq.c - :export: - -.. kernel-doc:: drivers/pci/htirq.c - :export: - -.. kernel-doc:: drivers/pci/probe.c - :export: - -.. kernel-doc:: drivers/pci/slot.c - :export: - -.. kernel-doc:: drivers/pci/rom.c - :export: - -.. kernel-doc:: drivers/pci/iov.c - :export: - -.. kernel-doc:: drivers/pci/pci-sysfs.c - :internal: - -PCI Hotplug Support Library - -.. kernel-doc:: drivers/pci/hotplug/pci_hotplug_core.c - :export: - -Firmware Interfaces -=== - -DMI Interfaces --- - -.. kernel-doc:: drivers/firmware/dmi_scan.c - :export: - -EDD Interfaces --- - -.. kernel-doc:: drivers/firmware/edd.c - :internal: - Security Framework == @@ -372,12 +306,6 @@ Char devices .. kernel-doc:: fs/char_dev.c :export: -Miscellaneous Devices -= - -.. kernel-doc:: drivers/char/misc.c - :export: - Clock Framework === diff --git a/Documentation/driver-api/firmware/index.rst b/Documentation/driver-api/firmware/index.rst index 1abe01793031..29da39ec4b8a 100644 --- a/Documentation/driver-api/firmware/index.rst +++ b/Documentation/driver-api/firmware/index.rst @@ -7,6 +7,7 @@ Linux Firmware API introduction core request_firmware + other_interfaces .. only:: subproject and html diff --git a/Documentation/driver-api/firmware/other_interfaces.rst b/Documentation/driver-api/firmware/other_interfaces.rst new file mode 100644 index ..36c47b1e9824 --- /dev/null +++ b/Documentation/driver-api/firmware/other_interfaces.rst @@ -0,0 +1,15 @@ +Other Firmware Interfaces += + +DMI Interfaces +-- + +.. kernel-doc:: drivers/firmware/dmi_scan.c + :export: + +EDD Interfaces +-- + +.. kernel-doc:: drivers/firmware/edd.c + :internal: + diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 90e742577dfc..8058a87c1c74 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -27,6 +27,7 @@ available subsections can be seen below. iio/index input usb/index + pci spi i2c hsi @@ -36,6 +37,7 @@ available subsections can be seen below. 80211/index uio-howto firmware/index + misc_devices .. only:: subproject and html diff --git a/Documentation/driver-api/misc_devices.rst b/Documentation/driver-api/misc_devices.rst new file mode 100644 index ..c7ee7b02ba88 --- /dev/null +++ b/Documentation/driver-api/misc_devices.rst @@ -0,0 +1,5 @@ +Miscellaneous Devices += + +.. kernel-doc:: drivers/char/misc.c + :export: diff --git a/Documentation/driver-api/pci.rst b/Documentation/driver-api/pci.rst new file mode 100644 index ..01a6c8b7d3a7 --- /dev/null +++ b/Documentation/driver-api/pci.rst @@ -0,0 +1,50 @@ +PCI Support Library +--- + +.. kernel-doc:: drivers/pci/pci.c + :export: + +.. kernel-doc:: drivers/pci/pci-driver.c + :export: + +.. kernel-doc:: drivers/pci/remove.c + :export: + +.. kernel-doc:: drivers/pci/search.c + :export: + +.. kernel-doc:: drivers/pci/msi.c + :export: + +.. kernel-doc:: drivers/pci/bus.c + :export: + +.. kernel-doc:: drivers/pci/access.c + :export: + +.. kernel-doc:: drivers/pci/irq.c + :export: + +.. kernel-doc:: drivers/pci/htirq.c + :export: + +.. kernel-doc:: drivers/pci/probe.c + :export: + +.. kernel-doc:
Re: [PATCH v5 16/24] dt-bindings: PCI: dra7xx: Add dt bindings to enable unaligned access
On Mon, Mar 27, 2017 at 03:15:12PM +0530, Kishon Vijay Abraham I wrote: > Update device tree binding documentation of TI's dra7xx PCI > controller to include property for enabling unaligned mem access. > > Signed-off-by: Kishon Vijay Abraham I > --- > Documentation/devicetree/bindings/pci/ti-pci.txt | 5 + > 1 file changed, 5 insertions(+) Acked-by: Rob Herring -- 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
Re: [PATCH v5 14/24] dt-bindings: mfd: syscon: Add documentation for #syscon-cells property
On Fri, Mar 31, 2017 at 01:58:52PM -0500, Rob Herring wrote: > On Mon, Mar 27, 2017 at 03:15:10PM +0530, Kishon Vijay Abraham I wrote: > > Add documentation for the optional #syscon-cells property to determine > > the number of cells that should be given in the phandle while > > referencing the syscon-node. > > > > Suggested-by: Rob Herring > > I did? When? > > I'm not remembering why we need this. Generally, phandles to a syscon > are for a single defined purpose. When do we need a list of them? Ah, I remember now the context. I suggested using standard parsing function rather than open coding. I wasn't suggesting changing the binding. Instead of of_parse_phandle_with_args, can't of_parse_phandle_with_fixed_args work? Rob -- 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
Re: [PATCH v5 14/24] dt-bindings: mfd: syscon: Add documentation for #syscon-cells property
On Mon, Mar 27, 2017 at 03:15:10PM +0530, Kishon Vijay Abraham I wrote:
> Add documentation for the optional #syscon-cells property to determine
> the number of cells that should be given in the phandle while
> referencing the syscon-node.
>
> Suggested-by: Rob Herring
I did? When?
I'm not remembering why we need this. Generally, phandles to a syscon
are for a single defined purpose. When do we need a list of them?
Rob
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Documentation/devicetree/bindings/mfd/syscon.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt
> b/Documentation/devicetree/bindings/mfd/syscon.txt
> index 408f768686f1..446b47e8fb71 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> @@ -16,6 +16,8 @@ Required properties:
> Optional property:
> - reg-io-width: the size (in bytes) of the IO accesses that should be
>performed on the device.
> +- #syscon-cells: determine the number of cells that should be given in the
> + phandle while referencing this syscon-node.
>
> Examples:
> gpr: iomuxc-gpr@020e {
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] kernel-api.tmpl: convert it to ReST
Em Fri, 31 Mar 2017 09:05:37 -0600 Jonathan Corbet escreveu: > On Thu, 30 Mar 2017 17:11:32 -0300 > Mauro Carvalho Chehab wrote: > > > Brainless conversion of genericirq.tmpl book to ReST, via > > Documentation/sphinx/tmplcvt > > This one kind of showcases why I'm nervous about bulk conversions. It's > a bit of a dumping-ground document, with a bit of everything, and I think > we can do better. And, in particular, this one contains a bunch of stuff > that belongs in the driver-api manual instead. So, at a minimum, I would > really like to see this template split across those two manuals. Yeah, I was in doubt if it should be either at driver-api or core-api manuals. > If you promise me a followup patch doing that, maybe I can go ahead and > merge this series now :) Surely I can do a patch moving things around. > (That's mildly complicated by the fact that you didn't send me parts 6, > 8, and 9; I really would rather get the whole series in cases like this.) Sorry. Just forwarded those missing parts to your e-mail. They basically fix some kernel-doc headers that are not properly parsed by Sphinx. Thanks, Mauro -- 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
Re: [PATCH 3/9] genericirq.tmpl: convert it to ReST
Em Fri, 31 Mar 2017 08:57:11 -0600 Jonathan Corbet escreveu: > On Thu, 30 Mar 2017 17:11:30 -0300 > Mauro Carvalho Chehab wrote: > > [Reordering things a bit] > > > +== > > +Linux generic IRQ handling > > +== > > + > > +:Copyright: |copy| 2005-2010: Thomas Gleixner > > +:Copyright: |copy| 2005-2006: Ingo Molnar > > It seems maybe they should have been CC'd on this one? Adding them now > (and leaving the full patch for their amusement). > > > Brainless conversion of genericirq.tmpl book to ReST, via > > Documentation/sphinx/tmplcvt > > In general this seems good, but I have to wonder how current this material > is at this point? The last substantive change was in 2013 (3.11), and I've > seen a certain amount of IRQ work going by since then. I'm not opposed to > this move at all, but perhaps if it's outdated we should add a note to that > effect? Looking on the amount of c:func: references that got solved: http://www.infradead.org/~mchehab/kernel_docs/core-api/genericirq.html I'd say that it doesn't seem outdated. It mentions a __do_IRQ() function, with I was unable to found, but I was able to find arch-dependent do_IRQ() functions, with seems to match the concepts explained at the doc. I almost did a s/__do_IRQ/do_IRQ/ but, as I wasn't 100% sure, I opted to keep it as-is for others to touch. It also mentions a request_irq() function, with is there, just without kernel-doc markups. Finally, it includes several core-api files with kernel-doc markups. So, IMHO, it is worth merging it. Yet, it would be great if the ones working on that part of the core could review and update it. Regards, Mauro -- 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
Re: [PATCH 3/9] genericirq.tmpl: convert it to ReST
On Fri, 31 Mar 2017, Jonathan Corbet wrote: > On Thu, 30 Mar 2017 17:11:30 -0300 > Mauro Carvalho Chehab wrote: > > [Reordering things a bit] > > > +== > > +Linux generic IRQ handling > > +== > > + > > +:Copyright: |copy| 2005-2010: Thomas Gleixner > > +:Copyright: |copy| 2005-2006: Ingo Molnar > > It seems maybe they should have been CC'd on this one? Adding them now > (and leaving the full patch for their amusement). > > > Brainless conversion of genericirq.tmpl book to ReST, via > > Documentation/sphinx/tmplcvt > > In general this seems good, but I have to wonder how current this material > is at this point? The last substantive change was in 2013 (3.11), and I've > seen a certain amount of IRQ work going by since then. I'm not opposed to > this move at all, but perhaps if it's outdated we should add a note to that > effect? We should take the opportunity and rewrite it proper. I might have an intern available in the next couple of weeks, but I need to check with the folks who are tasked to entertain him :) Thanks, tglx -- 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
Re: [PATCH v2] Use sphinx.version_info directly instead of parsing
On Fri, 31 Mar 2017 09:49:55 +0200 Remy Leone wrote: > Did this patch got applied? Yup, it did, it's in docs-next now. Sorry for the delay. jon -- 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
Re: [PATCH] sparse doc: fix reference path
On Fri, 24 Mar 2017 17:03:17 +0800 Cao jin wrote: > Documentation/sparse.txt has been moved to > Documentation/dev-tools/sparse.rst > > Signed-off-by: Cao jin > --- > Documentation/translations/zh_CN/sparse.txt | 4 ++-- > Makefile| 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) Applied to the docs tree, thanks. jon -- 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
Re: [PATCH 5/9] kernel-api.tmpl: convert it to ReST
On Thu, 30 Mar 2017 17:11:32 -0300 Mauro Carvalho Chehab wrote: > Brainless conversion of genericirq.tmpl book to ReST, via > Documentation/sphinx/tmplcvt This one kind of showcases why I'm nervous about bulk conversions. It's a bit of a dumping-ground document, with a bit of everything, and I think we can do better. And, in particular, this one contains a bunch of stuff that belongs in the driver-api manual instead. So, at a minimum, I would really like to see this template split across those two manuals. If you promise me a followup patch doing that, maybe I can go ahead and merge this series now :) (That's mildly complicated by the fact that you didn't send me parts 6, 8, and 9; I really would rather get the whole series in cases like this.) Thanks, jon -- 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
Re: [PATCH 3/9] genericirq.tmpl: convert it to ReST
On Thu, 30 Mar 2017 17:11:30 -0300 Mauro Carvalho Chehab wrote: [Reordering things a bit] > +== > +Linux generic IRQ handling > +== > + > +:Copyright: |copy| 2005-2010: Thomas Gleixner > +:Copyright: |copy| 2005-2006: Ingo Molnar It seems maybe they should have been CC'd on this one? Adding them now (and leaving the full patch for their amusement). > Brainless conversion of genericirq.tmpl book to ReST, via > Documentation/sphinx/tmplcvt In general this seems good, but I have to wonder how current this material is at this point? The last substantive change was in 2013 (3.11), and I've seen a certain amount of IRQ work going by since then. I'm not opposed to this move at all, but perhaps if it's outdated we should add a note to that effect? Thanks, jon > Copyright information inserted manually. > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/DocBook/Makefile| 2 +- > Documentation/DocBook/genericirq.tmpl | 520 > -- > Documentation/core-api/genericirq.rst | 445 + > Documentation/core-api/index.rst | 1 + > 4 files changed, 447 insertions(+), 521 deletions(-) > delete mode 100644 Documentation/DocBook/genericirq.tmpl > create mode 100644 Documentation/core-api/genericirq.rst > > diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile > index 7d94db2b53cd..e0c13655f770 100644 > --- a/Documentation/DocBook/Makefile > +++ b/Documentation/DocBook/Makefile > @@ -11,7 +11,7 @@ DOCBOOKS := z8530book.xml \ > networking.xml \ > kernel-api.xml filesystems.xml lsm.xml kgdb.xml \ > libata.xml mtdnand.xml librs.xml rapidio.xml \ > - genericirq.xml s390-drivers.xml scsi.xml \ > + s390-drivers.xml scsi.xml \ > sh.xml w1.xml > > ifeq ($(DOCBOOKS),) > diff --git a/Documentation/DocBook/genericirq.tmpl > b/Documentation/DocBook/genericirq.tmpl > deleted file mode 100644 > index 59fb5c077541.. > --- a/Documentation/DocBook/genericirq.tmpl > +++ /dev/null > @@ -1,520 +0,0 @@ > - > - - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []> > - > - > - > - Linux generic IRQ handling > - > - > - > -Thomas > -Gleixner > - > - > - t...@linutronix.de > - > - > - > - > -Ingo > -Molnar > - > - > - mi...@elte.hu > - > - > - > - > - > - > - 2005-2010 > - Thomas Gleixner > - > - > - 2005-2006 > - Ingo Molnar > - > - > - > - > - This documentation 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. > - > - > - > - You should have received a copy of the GNU General Public > - License along with this program; if not, write to the Free > - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, > - MA 02111-1307 USA > - > - > - > - For more details see the file COPYING in the source > - distribution of Linux. > - > - > - > - > - > - > - > -Introduction > - > - The generic interrupt handling layer is designed to provide a > - complete abstraction of interrupt handling for device drivers. > - It is able to handle all the different types of interrupt controller > - hardware. Device drivers use generic API functions to request, enable, > - disable and free interrupts. The drivers do not have to know anything > - about interrupt hardware details, so they can be used on different > - platforms without code changes. > - > - > - This documentation is provided to developers who want to implement > - an interrupt subsystem based for their architecture, with the help > - of the generic IRQ handling layer. > - > - > - > - > -Rationale > - > - The original implementation of interrupt handling in Linux uses > - the __do_IRQ() super-handler, which is able to deal with every > - type of interrupt logic. > - > - > - Originally, Russell King identified different types of handlers to > - build a quite universal set for the ARM interrupt handler > - implementation in Linux 2.5/2.6. He distinguished between: > - > - Level type > - Edge type > - Simple type > - > - During the implementation we identified another type: > - > - Fast EOI type > - > - In the SMP world of the __do_IRQ() super-handler another type > - was identified: > - > - Per CPU type > - > - >
Re: [PATCH 02/22] docs-rst: convert usb docbooks to ReST
On Thu, 30 Mar 2017 11:20:14 +0200 Markus Heiser wrote: > @Jon: what do you think about a bulk conversion? I'm a bit leery of it, to tell the truth. We're trying to create a better set of kernel docs, and I'm far from convinced that dumping a bunch of unloved stuff there in a mechanical way will get us there. Each of those docs needs to be looked at, and, first of all, we need to decide whether it's worth keeping or not. Nobody wants to delete docs, but old and unmaintained stuff doesn't help our users, IMO. For the stuff we want to keep, we need to look at how it fits into the new scheme, probably split it up, etc. It's a lot slower, but we've been getting rid of 3-6 template files in each of the last few cycles, so we are getting there. I don't think we need to just give up on the rest. Thanks, jon -- 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
[PATCH v5.1 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings
Some display pipelines can only provide non-RBG input pixels to the HDMI TX
Controller, this patch takes the pixel format from the plat_data if provided.
Reviewed-by: Jose Abreu
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 326 +-
include/drm/bridge/dw_hdmi.h | 63 ++
2 files changed, 294 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ff1fae3..16d5fff3 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -30,18 +30,15 @@
#include
#include
+#include
+#include
+
#include "dw-hdmi.h"
#include "dw-hdmi-audio.h"
#define DDC_SEGMENT_ADDR 0x30
#define HDMI_EDID_LEN 512
-#define RGB0
-#define YCBCR444 1
-#define YCBCR422_16BITS2
-#define YCBCR422_8BITS 3
-#define XVYCC444 4
-
enum hdmi_datamap {
RGB444_8B = 0x01,
RGB444_10B = 0x03,
@@ -95,10 +92,10 @@ struct hdmi_vmode {
};
struct hdmi_data_info {
- unsigned int enc_in_format;
- unsigned int enc_out_format;
- unsigned int enc_color_depth;
- unsigned int colorimetry;
+ unsigned int enc_in_bus_format;
+ unsigned int enc_out_bus_format;
+ unsigned int enc_in_encoding;
+ unsigned int enc_out_encoding;
unsigned int pix_repet_factor;
unsigned int hdcp_enable;
struct hdmi_vmode video_mode;
@@ -567,6 +564,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
}
EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
+static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
+{
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_RGB101010_1X30:
+ case MEDIA_BUS_FMT_RGB121212_1X36:
+ case MEDIA_BUS_FMT_RGB161616_1X48:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
+static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
+{
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_YUV8_1X24:
+ case MEDIA_BUS_FMT_YUV10_1X30:
+ case MEDIA_BUS_FMT_YUV12_1X36:
+ case MEDIA_BUS_FMT_YUV16_1X48:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
+static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
+{
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_UYVY8_1X16:
+ case MEDIA_BUS_FMT_UYVY10_1X20:
+ case MEDIA_BUS_FMT_UYVY12_1X24:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
+static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
+{
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
+ case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
+ case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
+ case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
+static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
+{
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_YUV8_1X24:
+ case MEDIA_BUS_FMT_UYVY8_1X16:
+ case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
+ return 8;
+
+ case MEDIA_BUS_FMT_RGB101010_1X30:
+ case MEDIA_BUS_FMT_YUV10_1X30:
+ case MEDIA_BUS_FMT_UYVY10_1X20:
+ case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
+ return 10;
+
+ case MEDIA_BUS_FMT_RGB121212_1X36:
+ case MEDIA_BUS_FMT_YUV12_1X36:
+ case MEDIA_BUS_FMT_UYVY12_1X24:
+ case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
+ return 12;
+
+ case MEDIA_BUS_FMT_RGB161616_1X48:
+ case MEDIA_BUS_FMT_YUV16_1X48:
+ case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
+ return 16;
+
+ default:
+ return 0;
+ }
+}
+
/*
* this submodule is responsible for the video data synchronization.
* for example, for RGB 4:4:4 input, the data map is defined as
@@ -579,37 +662,49 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
int color_format = 0;
u8 val;
- if (hdmi->hdmi_data.enc_in_format == RGB) {
- if (hdmi->hdmi_data.enc_color_depth == 8)
- color_format = 0x01;
- else if (hdmi->hdmi_data.enc_color_depth == 10)
- color_format = 0x03;
- else if (hdmi->hdmi_data.enc_color_depth == 12)
- color_format = 0x05;
- else if (hdmi->hdmi_data.enc_color_depth == 16)
- color_format = 0x07;
- else
- return;
- } else if (hdmi->hdmi_data.enc_in_format == YCBCR444) {
- if (hdmi->hdmi_data.enc_color_depth == 8)
- color_format = 0x09;
- else if (hdmi->hdmi_data.enc_color_depth == 10)
- color_format =
[PATCH v5.1 5/6] drm: bridge: dw-hdmi: Add Documentation on supported input formats
This patch adds a new DRM documentation entry and links to the input format table added in the dw_hdmi header. Signed-off-by: Neil Armstrong --- Documentation/gpu/bridge/dw-hdmi.rst | 15 +++ Documentation/gpu/index.rst | 1 + 2 files changed, 16 insertions(+) create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst diff --git a/Documentation/gpu/bridge/dw-hdmi.rst b/Documentation/gpu/bridge/dw-hdmi.rst new file mode 100644 index 000..486faad --- /dev/null +++ b/Documentation/gpu/bridge/dw-hdmi.rst @@ -0,0 +1,15 @@ +=== + drm/bridge/dw-hdmi Synopsys DesignWare HDMI Controller +=== + +Synopsys DesignWare HDMI Controller +=== + +This section covers everything related to the Synopsys DesignWare HDMI +Controller implemented as a DRM bridge. + +Supported Input Formats and Encodings +- + +.. kernel-doc:: include/drm/bridge/dw_hdmi.h + :doc: Supported input formats and encodings diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index e998ee0..d81c6ff 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -15,6 +15,7 @@ Linux GPU Driver Developer's Guide vc4 vga-switcheroo vgaarbiter + bridge/dw-hdmi todo .. only:: subproject and html -- 1.9.1 -- 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
[PATCH v5.1 3/6] documentation: media: Add documentation for new RGB and YUV bus formats
Add documentation for added Bus Formats to describe RGB and YUV formats used
as input to the Synopsys DesignWare HDMI TX Controller.
Acked-by: Hans Verkuil
Signed-off-by: Neil Armstrong
---
Documentation/media/uapi/v4l/subdev-formats.rst | 874 +++-
1 file changed, 859 insertions(+), 15 deletions(-)
diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst
b/Documentation/media/uapi/v4l/subdev-formats.rst
index d6152c9..371f6eb 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -1258,6 +1258,281 @@ The following tables list existing packed RGB formats.
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
+* .. _MEDIA-BUS-FMT-RGB101010-1X30:
+
+ - MEDIA_BUS_FMT_RGB101010_1X30
+ - 0x1018
+ -
+ - 0
+ - 0
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - 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.
+
+.. tabularcolumns::
|p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+.. _v4l2-mbus-pixelcode-rgb-36:
+
+.. raw:: latex
+
+\begingroup
+\tiny
+\setlength{\tabcolsep}{2pt}
+
+.. flat-table:: 36bit RGB formats
+:header-rows: 2
+:stub-columns: 0
+:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2
+
+* - Identifier
+ - Code
+ -
+ - :cspan:`35` Data organization
+* -
+ -
+ - Bit
+ - 35
+ - 34
+ - 33
+ - 32
+ - 31
+ - 30
+ - 29
+ - 28
+ - 27
+ - 26
+ - 25
+ - 24
+ - 23
+ - 22
+ - 21
+ - 20
+ - 19
+ - 18
+ - 17
+ - 16
+ - 15
+ - 14
+ - 13
+ - 12
+ - 11
+ - 10
+ - 9
+ - 8
+ - 7
+ - 6
+ - 5
+ - 4
+ - 3
+ - 2
+ - 1
+ - 0
+* .. _MEDIA-BUS-FMT-RGB121212-1X36:
+
+ - MEDIA_BUS_FMT_RGB121212_1X36
+ - 0x1019
+ -
+ - r\ :sub:`11`
+ - r\ :sub:`10`
+ - r\ :sub:`9`
+ - r\ :sub:`8`
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - g\ :sub:`11`
+ - g\ :sub:`10`
+ - g\ :sub:`9`
+ - g\ :sub:`8`
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - b\ :sub:`11`
+ - b\ :sub:`10`
+ - b\ :sub:`9`
+ - b\ :sub:`8`
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+
+.. raw:: latex
+
+\endgroup
+
+
+The following table list existing packed 48bit wide RGB formats.
+
+.. tabularcolumns::
|p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
+
+.. _v4l2-mbus-pixelcode-rgb-48:
+
+.. raw:: latex
+
+\begingroup
+\tiny
+\setlength{\tabcolsep}{2pt}
+
+.. flat-table:: 48bit RGB formats
+:header-rows: 2
+:stub-columns: 0
+:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
+
+* - Identifier
+ - Code
+ -
+ - :cspan:`47` Data organization
+* -
+ -
+ - Bit
+ - 47
+ - 46
+ - 45
+ - 44
+ - 43
+ - 42
+ - 41
+ - 40
+ - 39
+ - 38
+ - 37
+ - 36
+ - 35
+ - 34
+ - 33
+ - 32
+ - 31
+ - 30
+ - 29
+ - 28
[PATCH v5.1 6/6] drm: bridge: dw-hdmi: Move HPD handling to PHY operations
The HDMI TX controller support HPD and RXSENSE signaling from the PHY
via it's STAT0 PHY interface, but some vendor PHYs can manage these
signals independently from the controller, thus these STAT0 handling
should be moved to PHY specific operations and become optional.
The existing STAT0 HPD and RXSENSE handling code is refactored into
a supplementaty set of default PHY operations that are used automatically
when the platform glue doesn't provide its own operations.
Reviewed-by: Jose Abreu
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 135 ++
include/drm/bridge/dw_hdmi.h | 5 ++
2 files changed, 86 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 16d5fff3..84cc949 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1229,10 +1229,46 @@ static enum drm_connector_status
dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
connector_status_connected : connector_status_disconnected;
}
+static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+ bool force, bool disabled, bool rxsense)
+{
+ u8 old_mask = hdmi->phy_mask;
+
+ if (force || disabled || !rxsense)
+ hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
+ else
+ hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
+
+ if (old_mask != hdmi->phy_mask)
+ hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+}
+
+static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+{
+ /*
+* Configure the PHY RX SENSE and HPD interrupts polarities and clear
+* any pending interrupt.
+*/
+ hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
+ hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+ HDMI_IH_PHY_STAT0);
+
+ /* Enable cable hot plug irq. */
+ hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+
+ /* Clear and unmute interrupts. */
+ hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+ HDMI_IH_PHY_STAT0);
+ hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
+ HDMI_IH_MUTE_PHY_STAT0);
+}
+
static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
.init = dw_hdmi_phy_init,
.disable = dw_hdmi_phy_disable,
.read_hpd = dw_hdmi_phy_read_hpd,
+ .update_hpd = dw_hdmi_phy_update_hpd,
+ .setup_hpd = dw_hdmi_phy_setup_hpd,
};
/*
-
@@ -1808,35 +1844,10 @@ static void dw_hdmi_update_power(struct dw_hdmi *hdmi)
*/
static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
{
- u8 old_mask = hdmi->phy_mask;
-
- if (hdmi->force || hdmi->disabled || !hdmi->rxsense)
- hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
- else
- hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
-
- if (old_mask != hdmi->phy_mask)
- hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-}
-
-static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi)
-{
- /*
-* Configure the PHY RX SENSE and HPD interrupts polarities and clear
-* any pending interrupt.
-*/
- hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
- hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
- HDMI_IH_PHY_STAT0);
-
- /* Enable cable hot plug irq. */
- hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-
- /* Clear and unmute interrupts. */
- hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
- HDMI_IH_PHY_STAT0);
- hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
- HDMI_IH_MUTE_PHY_STAT0);
+ if (hdmi->phy.ops->update_hpd)
+ hdmi->phy.ops->update_hpd(hdmi, hdmi->phy.data,
+ hdmi->force, hdmi->disabled,
+ hdmi->rxsense);
}
static enum drm_connector_status
@@ -2028,6 +2039,41 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
return ret;
}
+void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
+{
+ mutex_lock(&hdmi->mutex);
+
+ if (!hdmi->force) {
+ /*
+* If the RX sense status indicates we're disconnected,
+* clear the software rxsense status.
+*/
+ if (!rx_sense)
+ hdmi->rxsense = false;
+
+ /*
+* Only set the software rxsense status when both
+* rxsense and hpd indicates we're connected.
+* This avoids what seems to be bad behaviour in
+
[PATCH v5.1 0/6] drm: bridge: dw-hdmi: Add support for Custom PHYs
The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller in combination with a very custom PHY. Thanks to Laurent Pinchart's changes, the HW report the following : Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy) The following differs from common PHY integration as managed in the current driver : - Amlogic PHY is not configured through the internal I2C link - Amlogic PHY do not use the ENTMDS, SVSRET, PDDQ, ... signals from the controller - Amlogic PHY do not export HPD ands RxSense signals to the controller And finally, concerning the controller integration : - the Controller registers are not flat memory-mapped, and uses an addr+read/write register pair to write all registers. - Inputs only YUV444 pixel data Most of these uses case are implemented in Laurent Pinchart v5.1 patchset merged in drm-misc-next branch. This is why the following patchset implements : - Configure the Input format from the plat_data - Add PHY callback to handle HPD and RxSense out of the dw-hdmi driver To implement the input format handling, the Synopsys HDMIT TX Controller input V4L bus formats are used and missing formats + documentation are added. This patchset makes the Amlogic GX SoCs HDMI output successfully work, and is also tested on the RK3288 ACT8846 EVB Board. Changes since v5 at [6] : - Small addition in V4L YUV bus formats documentation Changes since v4 at [5] : - Rebased on drm-misc-next at bd283d2f66c2 - Fix 4:2:0 bus formats naming - Renamed function fd_registered to i2c_init in dw-hdmi.c Changes since v3 at [4] : - Fix 4:2:0 bus formats naming - Add separate 36bit and 48bit tables for bus formats documentation - Added 4:2:0 bus config in hdmi_video_sample - Moved dw_hdmi documentation in a "bridge" subdir - Rebase on drm-misc-next at 62c58af32c93 Changes since v2 at [3] : - Rebase on laurent patch "Extract PHY interrupt setup to a function" - Reduce phy operations - Switch the V4L bus formats and encodings instead of custom enum Changes since v1 at [2] : - Drop patches submitted by laurent Changes since RFC at [1] : - Regmap fixup for 4bytes register access, tested on RK3288 SoC - Move phy callbacks to phy_ops and move Synopsys PHY calls into default ops - Move HDMI link data into shared header - Move Pixel Encoding enum to shared header [1] http://lkml.kernel.org/r/1484656294-6140-1-git-send-email-narmstr...@baylibre.com [2] http://lkml.kernel.org/r/1485774318-21916-1-git-send-email-narmstr...@baylibre.com [3] http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com [4] http://lkml.kernel.org/r/1488904944-14285-1-git-send-email-narmstr...@baylibre.com [5] http://lkml.kernel.org/r/1490109161-20529-1-git-send-email-narmstr...@baylibre.com [6] http://lkml.kernel.org/r/1490864675-17336-1-git-send-email-narmstr...@baylibre.com Laurent Pinchart (1): drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function Neil Armstrong (5): media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX Controller documentation: media: Add documentation for new RGB and YUV bus formats drm: bridge: dw-hdmi: Switch to V4L bus format and encodings drm: bridge: dw-hdmi: Add Documentation on supported input formats drm: bridge: dw-hdmi: Move HPD handling to PHY operations Documentation/gpu/bridge/dw-hdmi.rst| 15 + Documentation/gpu/index.rst | 1 + Documentation/media/uapi/v4l/subdev-formats.rst | 874 +++- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 470 - include/drm/bridge/dw_hdmi.h| 68 ++ include/uapi/linux/media-bus-format.h | 13 +- 6 files changed, 1268 insertions(+), 173 deletions(-) create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst -- 1.9.1 -- 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
Re: [PATCH 22/22] usb: document that URB transfer_buffer should be aligned
On Thu, 30 Mar 2017, Oliver Neukum wrote: > Am Donnerstag, den 30.03.2017, 11:55 -0400 schrieb Alan Stern: > > > > I'm pretty sure that usb-storage does not do this, at least, not when > > operating in its normal Bulk-Only-Transport mode. It never tries to > > read the results of an earlier transfer after carrying out a later > > transfer to any part of the same buffer. > > The storage driver takes buffers as the block layer (or sg) provide > them, does it not? Yes. But it does not read the data from an earlier transfer after carrying out a later transfer on the same buffer. The only possible example would be if the sense buffer for a command occupied part of the same block as the data buffer. But this can't happen, because the sense buffer is allocated separately by its own kzalloc_node() call in scsi_init_request(). Alan Stern -- 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
Re: [PATCH v2] tracing/kprobes: expose maxactive for kretprobe in kprobe_events
On Fri, 31 Mar 2017 15:20:24 +0200 Alban Crequy wrote: > When a kretprobe is installed on a kernel function, there is a maximum > limit of how many calls in parallel it can catch (aka "maxactive"). A > kernel module could call register_kretprobe() and initialize maxactive > (see example in samples/kprobes/kretprobe_example.c). > > But that is not exposed to userspace and it is currently not possible to > choose maxactive when writing to /sys/kernel/debug/tracing/kprobe_events > > The default maxactive can be as low as 1 on single-core with a > non-preemptive kernel. This is too low and we need to increase it not > only for recursive functions, but for functions that sleep or resched. > > This patch updates the format of the command that can be written to > kprobe_events so that maxactive can be optionally specified. > > I need this for a bpf program attached to the kretprobe of > inet_csk_accept, which can sleep for a long time. > > This patch includes a basic selftest: > > > # ./ftracetest -v test.d/kprobe/ > > === Ftrace unit tests === > > [1] Kprobe dynamic event - adding and removing [PASS] > > [2] Kprobe dynamic event - busy event check [PASS] > > [3] Kprobe dynamic event with arguments [PASS] > > [4] Kprobes event arguments with types [PASS] > > [5] Kprobe dynamic event with function tracer [PASS] > > [6] Kretprobe dynamic event with arguments [PASS] > > [7] Kretprobe dynamic event with maxactive [PASS] > > > > # of passed: 7 > > # of failed: 0 > > # of unresolved: 0 > > # of untested: 0 > > # of unsupported: 0 > > # of xfailed: 0 > > # of undefined(test bug): 0 > > BugLink: https://github.com/iovisor/bcc/issues/1072 > Signed-off-by: Alban Crequy > > --- > > Changes since v1: > - Remove "(*)" from documentation. (Review from Masami Hiramatsu) > - Fix support for "r100" without the event name (Review from Masami Hiramatsu) > - Get rid of magic numbers within the code. (Review from Steven Rostedt) > Note that I didn't use KRETPROBE_MAXACTIVE_ALLOC since that patch is not > merged. > - Return -E2BIG when maxactive is too big. > - Add basic selftest > --- > Documentation/trace/kprobetrace.txt| 4 ++- > kernel/trace/trace_kprobe.c| 39 > ++ > .../ftrace/test.d/kprobe/kretprobe_maxactive.tc| 39 > ++ > 3 files changed, 75 insertions(+), 7 deletions(-) > create mode 100644 > tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_maxactive.tc > > diff --git a/Documentation/trace/kprobetrace.txt > b/Documentation/trace/kprobetrace.txt > index 41ef9d8..7051a20 100644 > --- a/Documentation/trace/kprobetrace.txt > +++ b/Documentation/trace/kprobetrace.txt > @@ -23,7 +23,7 @@ current_tracer. Instead of that, add probe points via > Synopsis of kprobe_events > - >p[:[GRP/]EVENT] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS] : Set a probe > - r[:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS] : Set a return probe > + r[MAXACTIVE][:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS] : Set a return > probe >-:[GRP/]EVENT : Clear a probe > > GRP : Group name. If omitted, use "kprobes" for it. > @@ -32,6 +32,8 @@ Synopsis of kprobe_events > MOD : Module name which has given SYM. > SYM[+offs] : Symbol+offset where the probe is inserted. > MEMADDR : Address where the probe is inserted. > + MAXACTIVE : Maximum number of instances of the specified function that > + can be probed simultaneously, or 0 for the default. BTW, to me, 0 means none (no instances can probe). This should have a better description of what "0" actually means. -- Steve > > FETCHARGS : Arguments. Each probe can have up to 128 args. >%REG : Fetch register REG -- 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
Re: [PATCH v5 3/6] documentation: media: Add documentation for new RGB and YUV bus formats
On 03/31/2017 03:14 PM, Hans Verkuil wrote: > On 30/03/17 11:04, Neil Armstrong wrote: >> Add documentation for added Bus Formats to describe RGB and YUV formats used >> as input to the Synopsys DesignWare HDMI TX Controller. >> >> Signed-off-by: Neil Armstrong >> --- >> Documentation/media/uapi/v4l/subdev-formats.rst | 871 >> +++- >> 1 file changed, 857 insertions(+), 14 deletions(-) > > This looks good, but the "Packed YUV Formats" documentation should be updated. > > Currently this says: > > - The number of bus samples per pixel. Pixels that are wider than the >bus width must be transferred in multiple samples. Common values are >1, 1.5 (encoded as 1_5) and 2. > > I propose this change: > > - The number of bus samples per pixel. Pixels that are wider than the >bus width must be transferred in multiple samples. Common values are >0.5 (encoded as 0_5; in this case two pixels are transferred per bus >sample), 1, 1.5 (encoded as 1_5) and 2. > > With that additional change you can add my: > > Acked-by: Hans Verkuil > > Regards, > > Hans > Hi Hans, Thanks for the hint, I will change this and post a v5.1 with your acks. Neil -- 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
[PATCH v2] tracing/kprobes: expose maxactive for kretprobe in kprobe_events
When a kretprobe is installed on a kernel function, there is a maximum
limit of how many calls in parallel it can catch (aka "maxactive"). A
kernel module could call register_kretprobe() and initialize maxactive
(see example in samples/kprobes/kretprobe_example.c).
But that is not exposed to userspace and it is currently not possible to
choose maxactive when writing to /sys/kernel/debug/tracing/kprobe_events
The default maxactive can be as low as 1 on single-core with a
non-preemptive kernel. This is too low and we need to increase it not
only for recursive functions, but for functions that sleep or resched.
This patch updates the format of the command that can be written to
kprobe_events so that maxactive can be optionally specified.
I need this for a bpf program attached to the kretprobe of
inet_csk_accept, which can sleep for a long time.
This patch includes a basic selftest:
> # ./ftracetest -v test.d/kprobe/
> === Ftrace unit tests ===
> [1] Kprobe dynamic event - adding and removing[PASS]
> [2] Kprobe dynamic event - busy event check [PASS]
> [3] Kprobe dynamic event with arguments [PASS]
> [4] Kprobes event arguments with types[PASS]
> [5] Kprobe dynamic event with function tracer [PASS]
> [6] Kretprobe dynamic event with arguments[PASS]
> [7] Kretprobe dynamic event with maxactive[PASS]
>
> # of passed: 7
> # of failed: 0
> # of unresolved: 0
> # of untested: 0
> # of unsupported: 0
> # of xfailed: 0
> # of undefined(test bug): 0
BugLink: https://github.com/iovisor/bcc/issues/1072
Signed-off-by: Alban Crequy
---
Changes since v1:
- Remove "(*)" from documentation. (Review from Masami Hiramatsu)
- Fix support for "r100" without the event name (Review from Masami Hiramatsu)
- Get rid of magic numbers within the code. (Review from Steven Rostedt)
Note that I didn't use KRETPROBE_MAXACTIVE_ALLOC since that patch is not
merged.
- Return -E2BIG when maxactive is too big.
- Add basic selftest
---
Documentation/trace/kprobetrace.txt| 4 ++-
kernel/trace/trace_kprobe.c| 39 ++
.../ftrace/test.d/kprobe/kretprobe_maxactive.tc| 39 ++
3 files changed, 75 insertions(+), 7 deletions(-)
create mode 100644
tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_maxactive.tc
diff --git a/Documentation/trace/kprobetrace.txt
b/Documentation/trace/kprobetrace.txt
index 41ef9d8..7051a20 100644
--- a/Documentation/trace/kprobetrace.txt
+++ b/Documentation/trace/kprobetrace.txt
@@ -23,7 +23,7 @@ current_tracer. Instead of that, add probe points via
Synopsis of kprobe_events
-
p[:[GRP/]EVENT] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS] : Set a probe
- r[:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS]: Set a return probe
+ r[MAXACTIVE][:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS] : Set a return probe
-:[GRP/]EVENT: Clear a probe
GRP : Group name. If omitted, use "kprobes" for it.
@@ -32,6 +32,8 @@ Synopsis of kprobe_events
MOD : Module name which has given SYM.
SYM[+offs]: Symbol+offset where the probe is inserted.
MEMADDR : Address where the probe is inserted.
+ MAXACTIVE : Maximum number of instances of the specified function that
+ can be probed simultaneously, or 0 for the default.
FETCHARGS : Arguments. Each probe can have up to 128 args.
%REG : Fetch register REG
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index c5089c7..ae81f3c 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -25,6 +25,7 @@
#include "trace_probe.h"
#define KPROBE_EVENT_SYSTEM "kprobes"
+#define KRETPROBE_MAXACTIVE_MAX 4096
/**
* Kprobe event core functions
@@ -282,6 +283,7 @@ static struct trace_kprobe *alloc_trace_kprobe(const char
*group,
void *addr,
const char *symbol,
unsigned long offs,
+int maxactive,
int nargs, bool is_return)
{
struct trace_kprobe *tk;
@@ -309,6 +311,8 @@ static struct trace_kprobe *alloc_trace_kprobe(const char
*group,
else
tk->rp.kp.pre_handler = kprobe_dispatcher;
+ tk->rp.maxactive = maxactive;
+
if (!event || !is_good_name(event)) {
ret = -EINVAL;
goto error;
@@ -598,8 +602,10 @@ static int create_trace_kprobe(int argc, char **argv)
{
/*
* Argument syntax:
-* - Add kprobe: p[:[GRP/]EVENT] [MOD:]KSYM[+OFFS]|KADDR [FETCHARGS]
-* - Add kretprobe: r[:[GRP/]EVENT] [MOD:]KSYM[+0] [FETCHARGS]
+* - Add kprobe:
+* p[:[GRP/]EVENT] [MOD:]KSYM[+OFFS]|KADDR [FETCHARGS]
+* - Add kretprobe:
+* r[MAXA
Re: [PATCH v5 3/6] documentation: media: Add documentation for new RGB and YUV bus formats
On 30/03/17 11:04, Neil Armstrong wrote: > Add documentation for added Bus Formats to describe RGB and YUV formats used > as input to the Synopsys DesignWare HDMI TX Controller. > > Signed-off-by: Neil Armstrong > --- > Documentation/media/uapi/v4l/subdev-formats.rst | 871 > +++- > 1 file changed, 857 insertions(+), 14 deletions(-) This looks good, but the "Packed YUV Formats" documentation should be updated. Currently this says: - The number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1, 1.5 (encoded as 1_5) and 2. I propose this change: - The number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 0.5 (encoded as 0_5; in this case two pixels are transferred per bus sample), 1, 1.5 (encoded as 1_5) and 2. With that additional change you can add my: Acked-by: Hans Verkuil Regards, Hans -- 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
Re: [PATCH 1/2] Documentation/sphinx: kerneldoc: add "unused-functions"
On Fri, 31 Mar 2017, Johannes Berg wrote:
> From: Johannes Berg
>
> When adding functions one by one into documentation, in order to
> order/group things properly, it's easy to miss things. Allow use
> of the kernel-doc directive with "unused-functions" like this
>
> .. kernel-doc::
>:unused-functions:
I'm sure the parameter name could be improved to capture what you mean
better; alas I don't have a suggestion.
>
> to output anything previously unused from that file. This allows
> grouping things but still making sure that the documentation has
> all the functions.
>
> Internally this works by collecting (per-file) those functions
> (and enums, structs, doc sections...) that are explicitly used,
> and invoking the kernel-doc script with "-nofunction" later.
A quick thought that I don't have the time to check now, but should be
checked before merging: Is the order of directive extension execution
deterministic if the Sphinx run is parallelized (sphinx-build -j)? Is it
deterministic within an rst file? Surely it's not deterministic when
called from several rst files? The latter is, perhaps, acceptable, but
the former not.
BR,
Jani.
>
> Signed-off-by: Johannes Berg
> ---
> Documentation/sphinx/kerneldoc.py | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/sphinx/kerneldoc.py
> b/Documentation/sphinx/kerneldoc.py
> index d15e07f36881..79fc1491348a 100644
> --- a/Documentation/sphinx/kerneldoc.py
> +++ b/Documentation/sphinx/kerneldoc.py
> @@ -41,6 +41,9 @@ from sphinx.ext.autodoc import AutodocReporter
>
> __version__ = '1.0'
>
> +# per-file list
> +_used_fns = {}
> +
> class KernelDocDirective(Directive):
> """Extract kernel-doc comments from the specified file"""
> required_argument = 1
> @@ -50,6 +53,7 @@ class KernelDocDirective(Directive):
> 'functions': directives.unchanged_required,
> 'export': directives.unchanged,
> 'internal': directives.unchanged,
> +'unused-functions': directives.unchanged,
> }
> has_content = False
>
> @@ -60,6 +64,10 @@ class KernelDocDirective(Directive):
> filename = env.config.kerneldoc_srctree + '/' + self.arguments[0]
> export_file_patterns = []
>
> +if not filename in _used_fns:
> +_used_fns[filename] = []
> +_used_fns_this_file = _used_fns[filename]
> +
> # Tell sphinx of the dependency
> env.note_dependency(os.path.abspath(filename))
>
> @@ -73,10 +81,16 @@ class KernelDocDirective(Directive):
> cmd += ['-internal']
> export_file_patterns = str(self.options.get('internal')).split()
> elif 'doc' in self.options:
> -cmd += ['-function', str(self.options.get('doc'))]
> +f = str(self.options.get('doc'))
> +cmd += ['-function', f]
> +_used_fns_this_file.append(f)
> +elif 'unused-functions' in self.options:
> +for f in _used_fns_this_file:
> +cmd += ['-nofunction', f]
> elif 'functions' in self.options:
> for f in str(self.options.get('functions')).split():
> cmd += ['-function', f]
> +_used_fns_this_file.append(f)
>
> for pattern in export_file_patterns:
> for f in glob.glob(env.config.kerneldoc_srctree + '/' + pattern):
--
Jani Nikula, Intel Open Source Technology Center
--
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
Re: [RFC PATCH tip/master 1/3] trace: kprobes: Show sum of probe/retprobe nmissed count
On Wed, Mar 29, 2017 at 7:22 AM, Masami Hiramatsu wrote: > Show sum of probe and retprobe nmissed count in > kprobe_profile, since retprobe can be missed even > if the kprobe itself succeeeded. > This explains user why their return probe didn't hit > sometimes. > > Signed-off-by: Masami Hiramatsu I tested this patch with my kretprobe on "inet_csk_accept" when there are many processes waiting in the accept() syscall. I can now successfully see the nmissed counter in /sys/kernel/debug/tracing/kprobe_profile being incremented when the kretprobe is missed. Tested-by: Alban Crequy > --- > kernel/trace/trace_kprobe.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c > index 013f4e7..bbdc3de 100644 > --- a/kernel/trace/trace_kprobe.c > +++ b/kernel/trace/trace_kprobe.c > @@ -896,7 +896,7 @@ static int probes_profile_seq_show(struct seq_file *m, > void *v) > seq_printf(m, " %-44s %15lu %15lu\n", >trace_event_name(&tk->tp.call), >trace_kprobe_nhit(tk), > - tk->rp.kp.nmissed); > + tk->rp.kp.nmissed + tk->rp.nmissed); > > return 0; > } > -- 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
Re: [PATCH v5 1/9] coresight: bindings for CPU debug module
On 25/03/17 18:23, Leo Yan wrote: According to ARMv8 architecture reference manual (ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate debug module and it can support self-hosted debug and external debug. Especially for supporting self-hosted debug, this means the program can access the debug module from mmio region; and usually the mmio region is integrated with coresight. So add document for binding debug component, includes binding to APB clock; and also need specify the CPU node which the debug module is dedicated to specific CPU. Suggested-by: Mike Leach Reviewed-by: Mathieu Poirier Signed-off-by: Leo Yan Reviewed-by: Suzuki K Poulose -- 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
Re: [PATCH v5 4/9] coresight: refactor with function of_coresight_get_cpu
On 25/03/17 18:23, Leo Yan wrote:
This is refactor to add function of_coresight_get_cpu(), so it's used to
retrieve CPU id for coresight component. Finally can use it as a common
function for multiple places.
Suggested-by: Mathieu Poirier
Signed-off-by: Leo Yan
Reviewed-by: Suzuki K Poulose
- if (found)
- break;
- }
- of_node_put(dn);
-
- /* Affinity to CPU0 if no cpu nodes are found */
- pdata->cpu = found ? cpu : 0;
+ pdata->cpu = of_coresight_get_cpu(node);
return pdata;
}
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 2a5982c..bf96678 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -263,9 +263,11 @@ static inline int coresight_timeout(void __iomem *addr,
u32 offset,
#endif
#ifdef CONFIG_OF
+extern int of_coresight_get_cpu(struct device_node *node);
extern struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, struct device_node *node);
#else
+static inline int of_coresight_get_cpu(struct device_node *node) { return 0; }
static inline struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, struct device_node *node) { return NULL; }
#endif
--
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
Re: [PATCH 1/2] Documentation/sphinx: kerneldoc: add "unused-functions"
> Do we really need such generic stuff? ... IMO explicit is better than > implicit. Why not getting an error when a function, which is referred > from a reST-document disappears in the source? Those errors help > to maintain the consistency of documentation with source-code. That's a totally different problem. > I know, there are also use-cases where generic is very helpful (e.g. > create a complete API description from the header file, with just > one line in reST). And I know, that we have already generic e.g. the > "export" option of the kernel-doc directive. Exactly. But now you can either * use "export" or "internal" to get *everything* * list every single function, and get no warning when there's a function you didn't list This serves to help get a mixture of the two, to be able to group things but also document everything that got missed as a fall-back. johannes -- 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
Re: [PATCH 1/2] Documentation/sphinx: kerneldoc: add "unused-functions"
Am 31.03.2017 um 09:16 schrieb Johannes Berg : > From: Johannes Berg > > When adding functions one by one into documentation, in order to > order/group things properly, it's easy to miss things. Allow use > of the kernel-doc directive with "unused-functions" like this > > .. kernel-doc:: > :unused-functions: > > to output anything previously unused from that file. This allows > grouping things but still making sure that the documentation has > all the functions. Do we really need such generic stuff? ... IMO explicit is better than implicit. Why not getting an error when a function, which is referred from a reST-document disappears in the source? Those errors help to maintain the consistency of documentation with source-code. In the past (DocBook) we had such generic stuff and IMO it was not helpful to serve consistency. Take a look at the old DocBook stuff, most of it is outdated and some object in the source-code, which are referred in the past from DocBooks, are no longer existing ... but no errors when compiling the DocBooks, because these are all generic includes. I know, there are also use-cases where generic is very helpful (e.g. create a complete API description from the header file, with just one line in reST). And I know, that we have already generic e.g. the "export" option of the kernel-doc directive. I'am not totally against generic, but I think every decision in this direction should be well considered. These are only my 2cent. -- Markus -- -- 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
Re: doc build requirements
Hi Johannes, Am 31.03.2017 um 08:26 schrieb Johannes Berg : > Hi, > > I notice that now - since > > commit ec868e4ee2bcebb9e4c03979d90e0ac0b79fe05a > Author: Mauro Carvalho Chehab > Date: Wed Nov 30 08:00:17 2016 -0200 > >docs-rst: media: build SVG from graphviz files > > was merged, it is strictly necessary to have `dot' installed to build > documentation - there isn't even any fallback. > > Now, it's not hard to install, so I have no major objection against it, > but I wanted to take the opportunity to point out that this seems a bit > arbitrary - last I tried adding new functionality and *didn't* even > make it a build requirement (logging only a warning if not installed) I > was told I can't add such a thing. > > Does this mean something has changed and I can try again? :) no ;) yes, you are right and we have improved it; since .. -- doc-4.11-images db6ccf23e8ba40fc2e8914ec9c0eb950df71d9fe Author: Markus Heiser AuthorDate: Mon Mar 6 14:09:27 2017 +0100 docs-rst: automatically convert Graphviz and SVG images -- the situation is much better: for HTML, dot installation is optional and other requirements are listed in Documentation/process/changes.rst (see chapter "Kernel documentation"). Mauro also patched his media tree to get rid of the 'dot' and 'convert' usage in the media/Makefile, see: -- 8fa1bb506fc9b5b0f7b5e42cee4f8213325a98ee Author: Mauro Carvalho Chehab AuthorDate: Thu Mar 9 15:14:52 2017 -0300 docs-rst: Don't use explicit Makefile rules to build SVG and DOT files -- -- Markus -- -- 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
Re: [PATCH v2] Use sphinx.version_info directly instead of parsing
Hello,
Did this patch got applied?
Best regards
Rémy
Le 20/03/2017 à 16:37, Remy Leone a écrit :
From: Rémy Léone
Using the development version of sphinx caused the parsing of the
version to fail.
Signed-off-by: Rémy Léone
---
Documentation/conf.py | 4 ++--
Documentation/sphinx/cdomain.py | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 7fadb3b..da139b5 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -17,7 +17,7 @@ import os
import sphinx
# Get Sphinx version
-major, minor, patch = map(int, sphinx.__version__.split("."))
+major, minor, patch = sphinx.version_info[:3]
# If extensions (or modules to document with autodoc) are in another directory,
@@ -29,7 +29,7 @@ from load_config import loadConfig
# -- General configuration
# If your documentation needs a minimal Sphinx version, state it here.
-#needs_sphinx = '1.0'
+needs_sphinx = '1.2'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py
index df0419c..cf13ff3 100644
--- a/Documentation/sphinx/cdomain.py
+++ b/Documentation/sphinx/cdomain.py
@@ -44,7 +44,7 @@ from sphinx.domains.c import CDomain as Base_CDomain
__version__ = '1.0'
# Get Sphinx version
-major, minor, patch = map(int, sphinx.__version__.split("."))
+major, minor, patch = sphinx.version_info[:3]
def setup(app):
--
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
[PATCH 2/2] cfg80211: add remaining functions/etc. to documentation
From: Johannes Berg A lot (likely most!) enums, structs and functions aren't explicitly listed in the documentation. For now, just add everything to the documentation in a new section so at least the references to those functions can be resolved. Signed-off-by: Johannes Berg --- Documentation/driver-api/80211/cfg80211.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/driver-api/80211/cfg80211.rst b/Documentation/driver-api/80211/cfg80211.rst index 8ffac57e1f5b..52caec2c9ff9 100644 --- a/Documentation/driver-api/80211/cfg80211.rst +++ b/Documentation/driver-api/80211/cfg80211.rst @@ -355,3 +355,8 @@ Test mode .. kernel-doc:: include/net/cfg80211.h :functions: cfg80211_testmode_event + +Remaining functions +=== +.. kernel-doc:: include/net/cfg80211.h + :unused-functions: -- 2.11.0 -- 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
[PATCH 1/2] Documentation/sphinx: kerneldoc: add "unused-functions"
From: Johannes Berg
When adding functions one by one into documentation, in order to
order/group things properly, it's easy to miss things. Allow use
of the kernel-doc directive with "unused-functions" like this
.. kernel-doc::
:unused-functions:
to output anything previously unused from that file. This allows
grouping things but still making sure that the documentation has
all the functions.
Internally this works by collecting (per-file) those functions
(and enums, structs, doc sections...) that are explicitly used,
and invoking the kernel-doc script with "-nofunction" later.
Signed-off-by: Johannes Berg
---
Documentation/sphinx/kerneldoc.py | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/sphinx/kerneldoc.py
b/Documentation/sphinx/kerneldoc.py
index d15e07f36881..79fc1491348a 100644
--- a/Documentation/sphinx/kerneldoc.py
+++ b/Documentation/sphinx/kerneldoc.py
@@ -41,6 +41,9 @@ from sphinx.ext.autodoc import AutodocReporter
__version__ = '1.0'
+# per-file list
+_used_fns = {}
+
class KernelDocDirective(Directive):
"""Extract kernel-doc comments from the specified file"""
required_argument = 1
@@ -50,6 +53,7 @@ class KernelDocDirective(Directive):
'functions': directives.unchanged_required,
'export': directives.unchanged,
'internal': directives.unchanged,
+'unused-functions': directives.unchanged,
}
has_content = False
@@ -60,6 +64,10 @@ class KernelDocDirective(Directive):
filename = env.config.kerneldoc_srctree + '/' + self.arguments[0]
export_file_patterns = []
+if not filename in _used_fns:
+_used_fns[filename] = []
+_used_fns_this_file = _used_fns[filename]
+
# Tell sphinx of the dependency
env.note_dependency(os.path.abspath(filename))
@@ -73,10 +81,16 @@ class KernelDocDirective(Directive):
cmd += ['-internal']
export_file_patterns = str(self.options.get('internal')).split()
elif 'doc' in self.options:
-cmd += ['-function', str(self.options.get('doc'))]
+f = str(self.options.get('doc'))
+cmd += ['-function', f]
+_used_fns_this_file.append(f)
+elif 'unused-functions' in self.options:
+for f in _used_fns_this_file:
+cmd += ['-nofunction', f]
elif 'functions' in self.options:
for f in str(self.options.get('functions')).split():
cmd += ['-function', f]
+_used_fns_this_file.append(f)
for pattern in export_file_patterns:
for f in glob.glob(env.config.kerneldoc_srctree + '/' + pattern):
--
2.11.0
--
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
