[PATCH v3 1/6] doc: Add Coresight documentation directory
For easily management and friendly adding more Coresight related documentations, this commit creates one dedicated directory: Documentation/trace/coresight. It moves Coresight related docs into this new directory and updates MAINTAINERS file to reflect docs movement. Signed-off-by: Leo Yan --- Documentation/trace/coresight-cpu-debug.txt| 187 Documentation/trace/coresight.txt | 332 - .../trace/coresight/coresight-cpu-debug.txt| 187 Documentation/trace/coresight/coresight.txt| 332 + MAINTAINERS| 4 +- 5 files changed, 521 insertions(+), 521 deletions(-) delete mode 100644 Documentation/trace/coresight-cpu-debug.txt delete mode 100644 Documentation/trace/coresight.txt create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt create mode 100644 Documentation/trace/coresight/coresight.txt diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight-cpu-debug.txt deleted file mode 100644 index 2b9b51c..000 --- a/Documentation/trace/coresight-cpu-debug.txt +++ /dev/null @@ -1,187 +0,0 @@ - Coresight CPU Debug Module - == - - Author: Leo Yan - Date: April 5th, 2017 - -Introduction - - -Coresight CPU debug module is defined in ARMv8-a architecture reference manual -(ARM DDI 0487A.k) Chapter 'Part H: External debug', the CPU can integrate -debug module and it is mainly used for two modes: self-hosted debug and -external debug. Usually the external debug mode is well known as the external -debugger connects with SoC from JTAG port; on the other hand the program can -explore debugging method which rely on self-hosted debug mode, this document -is to focus on this part. - -The debug module provides sample-based profiling extension, which can be used -to sample CPU program counter, secure state and exception level, etc; usually -every CPU has one dedicated debug module to be connected. Based on self-hosted -debug mechanism, Linux kernel can access these related registers from mmio -region when the kernel panic happens. The callback notifier for kernel panic -will dump related registers for every CPU; finally this is good for assistant -analysis for panic. - - -Implementation --- - -- During driver registration, it uses EDDEVID and EDDEVID1 - two device ID - registers to decide if sample-based profiling is implemented or not. On some - platforms this hardware feature is fully or partially implemented; and if - this feature is not supported then registration will fail. - -- At the time this documentation was written, the debug driver mainly relies on - information gathered by the kernel panic callback notifier from three - sampling registers: EDPCSR, EDVIDSR and EDCIDSR: from EDPCSR we can get - program counter; EDVIDSR has information for secure state, exception level, - bit width, etc; EDCIDSR is context ID value which contains the sampled value - of CONTEXTIDR_EL1. - -- The driver supports a CPU running in either AArch64 or AArch32 mode. The - registers naming convention is a bit different between them, AArch64 uses - 'ED' for register prefix (ARM DDI 0487A.k, chapter H9.1) and AArch32 uses - 'DBG' as prefix (ARM DDI 0487A.k, chapter G5.1). The driver is unified to - use AArch64 naming convention. - -- ARMv8-a (ARM DDI 0487A.k) and ARMv7-a (ARM DDI 0406C.b) have different - register bits definition. So the driver consolidates two difference: - - If PCSROffset=0b, on ARMv8-a the feature of EDPCSR is not implemented; - but ARMv7-a defines "PCSR samples are offset by a value that depends on the - instruction set state". For ARMv7-a, the driver checks furthermore if CPU - runs with ARM or thumb instruction set and calibrate PCSR value, the - detailed description for offset is in ARMv7-a ARM (ARM DDI 0406C.b) chapter - C11.11.34 "DBGPCSR, Program Counter Sampling Register". - - If PCSROffset=0b0010, ARMv8-a defines "EDPCSR implemented, and samples have - no offset applied and do not sample the instruction set state in AArch32 - state". So on ARMv8 if EDDEVID1.PCSROffset is 0b0010 and the CPU operates - in AArch32 state, EDPCSR is not sampled; when the CPU operates in AArch64 - state EDPCSR is sampled and no offset are applied. - - -Clock and power domain --- - -Before accessing debug registers, we should ensure the clock and power domain -have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1 -Debug registers', the debug registers are spread into two domains: the debug -domain and the CPU domain. - -+---+ -| | -| | - +--+--+| -dbg_clock -->| |**||<-- cpu_clock -
[PATCH v3 0/6] Coresight: support panic kdump
This patch set is to explore Coresight trace data for postmortem debugging. When kernel panic happens, the Coresight panic kdump can help save on-chip trace data and tracer metadata into DRAM, later relies on kdump and crash/perf for "offline" analysis. The documentation is important to understand the purpose of Coresight panic kdump, the implementation and usage. Patches 0001/0002 are used to relocate and add related documenation. Patch 0003 introduces the simple panic kdump framework which can be easily used by Coresight devices. Patches 0004/0005 support panic kdump for ETB; Patch 0006 supports the dump for ETMv4. As Mathieu suggested, patch 0006 distinguish two different tracer enabling mode: sysFS interface and perf mode. This patch set have been verified on 96boards Hikey with tracer enabling by sysFS interface. Changes from v2: * Add the two patches for documentation. * Following Mathieu suggestion, reworked the panic kdump framework, removed the useless flag "PRE_PANIC". * According to comment, changed to add and delete kdump node operations in sink enable/disable functions; * According to Mathieu suggestion, handle kdump node addition/deletion/updating separately for sysFS interface and perf method. Changes from v1: * Add support to dump ETMv4 meta data. * Wrote 'crash' extension csdump.so so rely on it to generate 'perf' format compatible file. * Refactored panic dump driver to support pre & post panic dump. Changes from RFC: * Follow Mathieu's suggestion, use general framework to support dump functionality. * Changed to use perf to analyse trace data. Leo Yan (6): doc: Add Coresight documentation directory doc: Add documentation for Coresight panic kdump coresight: Support panic kdump functionality coresight: tmc: Hook callback for panic kdump coresight: Add and delete sink callback for panic kdump list coresight: etm4x: Support panic kdump Documentation/trace/coresight-cpu-debug.txt| 187 Documentation/trace/coresight.txt | 332 - .../trace/coresight/coresight-cpu-debug.txt| 187 .../trace/coresight/coresight-panic-kdump.txt | 91 ++ Documentation/trace/coresight/coresight.txt| 332 + MAINTAINERS| 5 +- drivers/hwtracing/coresight/Kconfig| 9 + drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +- drivers/hwtracing/coresight/coresight-etm4x.c | 23 ++ drivers/hwtracing/coresight/coresight-etm4x.h | 15 + .../hwtracing/coresight/coresight-panic-kdump.c| 154 ++ drivers/hwtracing/coresight/coresight-priv.h | 13 + drivers/hwtracing/coresight/coresight-tmc-etf.c| 29 ++ drivers/hwtracing/coresight/coresight.c| 12 + include/linux/coresight.h | 7 + 16 files changed, 887 insertions(+), 522 deletions(-) delete mode 100644 Documentation/trace/coresight-cpu-debug.txt delete mode 100644 Documentation/trace/coresight.txt create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt create mode 100644 Documentation/trace/coresight/coresight.txt create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c -- 2.7.4 -- 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 v3 5/6] coresight: Add and delete sink callback for panic kdump list
If the sink device has panic kdump callback, this means the sink device
wants to save tracing data for panic happening.
This commit adds node into panic kdump list when the sink device is
enabled, and delete node when the sink device is disabled.
Signed-off-by: Leo Yan
---
drivers/hwtracing/coresight/coresight.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight.c
b/drivers/hwtracing/coresight/coresight.c
index 389c4ba..56798b1 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -146,6 +146,14 @@ static int coresight_enable_sink(struct coresight_device
*csdev, u32 mode)
if (ret)
return ret;
}
+
+ /* Add into panic kdump list */
+ if (sink_ops(csdev)->panic_cb) {
+ ret = coresight_kdump_add(csdev, 0);
+ if (ret)
+ return ret;
+ }
+
csdev->enable = true;
}
@@ -157,6 +165,10 @@ static int coresight_enable_sink(struct coresight_device
*csdev, u32 mode)
static void coresight_disable_sink(struct coresight_device *csdev)
{
if (atomic_dec_return(csdev->refcnt) == 0) {
+ /* Delete from panic kdump list */
+ if (sink_ops(csdev)->panic_cb)
+ coresight_kdump_del(csdev);
+
if (sink_ops(csdev)->disable) {
sink_ops(csdev)->disable(csdev);
csdev->enable = false;
--
2.7.4
--
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 v3 3/6] coresight: Support panic kdump functionality
After kernel panic happens, coresight has many useful info can be used
for analysis. For example, the trace info from ETB RAM can be used to
check the CPU execution flows before crash. So we can save the tracing
data from sink devices, and rely on kdump to save DDR content and uses
"crash" tool to extract coresight dumping from vmcore file.
This patch is to add a simple framework to support panic dump
functionality; it registers panic notifier, and provide the general APIs
{coresight_kdump_add|coresight_kdump_del} as helper functions so any
coresight device can add itself into dump list or delete as needed.
This driver provides helper function coresight_kdump_update() to update
the dump buffer base address and buffer size. This function can be used
by coresight driver, e.g. it can be used to save ETM meta data info at
runtime and these info can be prepared pre panic happening.
When kernel panic happens, the notifier iterates dump list and calls
callback function to dump device specific info. The panic dump is
mainly used to dump trace data so we can get to know the execution flow
before the panic happens.
Signed-off-by: Leo Yan
---
drivers/hwtracing/coresight/Kconfig| 9 ++
drivers/hwtracing/coresight/Makefile | 1 +
.../hwtracing/coresight/coresight-panic-kdump.c| 154 +
drivers/hwtracing/coresight/coresight-priv.h | 13 ++
include/linux/coresight.h | 7 +
5 files changed, 184 insertions(+)
create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
diff --git a/drivers/hwtracing/coresight/Kconfig
b/drivers/hwtracing/coresight/Kconfig
index ef9cb3c..4812529 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -103,4 +103,13 @@ config CORESIGHT_CPU_DEBUG
properly, please refer Documentation/trace/coresight-cpu-debug.txt
for detailed description and the example for usage.
+config CORESIGHT_PANIC_KDUMP
+ bool "CoreSight Panic Kdump driver"
+ depends on ARM || ARM64
+ help
+ This driver provides panic kdump functionality for CoreSight
+ devices. When a kernel panic happen a device supplied callback
function
+ is used to save trace data to memory. From there we rely on kdump to
extract
+ the trace data from kernel dump file.
+
endif
diff --git a/drivers/hwtracing/coresight/Makefile
b/drivers/hwtracing/coresight/Makefile
index 61db9dd..946fe19 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
obj-$(CONFIG_CORESIGHT_DYNAMIC_REPLICATOR) += coresight-dynamic-replicator.o
obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
+obj-$(CONFIG_CORESIGHT_PANIC_KDUMP) += coresight-panic-kdump.o
diff --git a/drivers/hwtracing/coresight/coresight-panic-kdump.c
b/drivers/hwtracing/coresight/coresight-panic-kdump.c
new file mode 100644
index 000..c21d20b
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-panic-kdump.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017 Linaro Limited.
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "coresight-priv.h"
+
+typedef void (*coresight_cb_t)(void *data);
+
+/**
+ * struct coresight_kdump_node - Node information for dump
+ * @cpu: The cpu this node is affined to.
+ * @csdev: Handler for coresight device.
+ * @buf: Pointer for dump buffer.
+ * @buf_size: Length of dump buffer.
+ * @list: Hook to the list.
+ */
+struct coresight_kdump_node {
+ int cpu;
+ struct coresight_device *csdev;
+ char *buf;
+ unsigned int buf_size;
+ struct list_head list;
+};
+
+static DEFINE_SPINLOCK(coresight_kdump_lock);
+static LIST_HEAD(coresight_kdump_list);
+static struct notifier_block coresight_kdump_nb;
+
+int coresight_kdump_update(struct coresight_device *csdev, char *buf,
+ unsigned int buf_size)
+{
+ struct coresight_kdump_node *node = csdev->dump_node;
+
+ if (!node) {
+ dev_err(&csdev->dev, "Failed to update dump node.\n");
+ return -EINVAL;
+ }
+
+ node->buf = buf;
+ node->buf_size = buf_size;
+ return 0;
+}
+
+int coresight_kdump_add(struct coresight_device *csdev, int cpu)
+{
+ struct coresight_kdump_node *node;
+ unsigned long flags;
+
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (!node)
+ return -ENOMEM;
+
+ csdev->dump_node = (void *)node;
+ node->cpu = cpu;
+ node->csdev = csdev;
+
+ spin_lock_irqsave(&coresight_kdump_lock, flags);
+ list_add_tail(&node->list, &coresight_kdump_list);
+ spin_unlock_irqrestore(&coresight_kdump_lock, flags);
+ return 0;
+}
+
[PATCH v3 6/6] coresight: etm4x: Support panic kdump
ETMv4 hardware information and configuration needs to be saved as
metadata; these metadata should be compatible with tool 'perf' and
can be used for tracing data analysis. ETMv4 usually works as tracer
per CPU, we cannot wait to gather ETM info after the CPU has been panic
and cannot execute dump operations for itself; so should gather
metadata when the corresponding CPU is alive.
Since values in TRCIDR{0, 1, 2, 8} and TRCAUTHSTATUS are read-only and
won't change at the runtime. Those registers value are filled when
tracers are instantiated.
The configuration and control registers TRCCONFIGR and TRCTRACEIDR are
dynamically configured, we record their value when enabling coresight
path. When operating from sysFS tracer these two registers are recorded
in etm4_enable_sysfs() and add kdump node into list, and remove the
kdump node in etm4_disable_sysfs(). When operating from perf,
etm_setup_aux() adds all tracers to the dump list and etm4_enable_perf()
is used to record configuration registers and update dump buffer info,
this can avoid unnecessary list addition and deletion operations.
Removal of the tracers from the dump list is done in function
free_event_data().
Suggested-by: Mathieu Poirier
Signed-off-by: Leo Yan
---
drivers/hwtracing/coresight/coresight-etm-perf.c | 12 +++-
drivers/hwtracing/coresight/coresight-etm4x.c| 23 +++
drivers/hwtracing/coresight/coresight-etm4x.h| 15 +++
3 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 8a0ad77..fec779b 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -137,6 +137,12 @@ static void free_event_data(struct work_struct *work)
}
for_each_cpu(cpu, mask) {
+ struct coresight_device *csdev;
+
+ csdev = per_cpu(csdev_src, cpu);
+ if (csdev)
+ coresight_kdump_del(csdev);
+
if (!(IS_ERR_OR_NULL(event_data->path[cpu])))
coresight_release_path(event_data->path[cpu]);
}
@@ -195,7 +201,7 @@ static void etm_free_aux(void *data)
static void *etm_setup_aux(int event_cpu, void **pages,
int nr_pages, bool overwrite)
{
- int cpu;
+ int cpu, ret;
cpumask_t *mask;
struct coresight_device *sink;
struct etm_event_data *event_data = NULL;
@@ -238,6 +244,10 @@ static void *etm_setup_aux(int event_cpu, void **pages,
event_data->path[cpu] = coresight_build_path(csdev, sink);
if (IS_ERR(event_data->path[cpu]))
goto err;
+
+ ret = coresight_kdump_add(csdev, cpu);
+ if (ret)
+ goto err;
}
if (!sink_ops(sink)->alloc_buffer)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c
b/drivers/hwtracing/coresight/coresight-etm4x.c
index cf364a5..cbde398 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -258,10 +258,19 @@ static int etm4_enable_perf(struct coresight_device
*csdev,
static int etm4_enable_sysfs(struct coresight_device *csdev)
{
struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ struct etmv4_config *config = &drvdata->config;
+ struct etmv4_metadata *metadata = &drvdata->metadata;
int ret;
spin_lock(&drvdata->spinlock);
+ /* Update meta data and add into kdump list */
+ metadata->trcconfigr = config->cfg;
+ metadata->trctraceidr = drvdata->trcid;
+
+ coresight_kdump_add(csdev, drvdata->cpu);
+ coresight_kdump_update(csdev, (char *)metadata, sizeof(*metadata));
+
/*
* Executing etm4_enable_hw on the cpu whose ETM is being enabled
* ensures that register writes occur when cpu is powered.
@@ -384,6 +393,9 @@ static void etm4_disable_sysfs(struct coresight_device
*csdev)
*/
smp_call_function_single(drvdata->cpu, etm4_disable_hw, drvdata, 1);
+ /* Delete from kdump list */
+ coresight_kdump_del(csdev);
+
spin_unlock(&drvdata->spinlock);
cpus_read_unlock();
@@ -438,6 +450,7 @@ static void etm4_init_arch_data(void *info)
u32 etmidr4;
u32 etmidr5;
struct etmv4_drvdata *drvdata = info;
+ struct etmv4_metadata *metadata = &drvdata->metadata;
/* Make sure all registers are accessible */
etm4_os_unlock(drvdata);
@@ -590,6 +603,16 @@ static void etm4_init_arch_data(void *info)
drvdata->nrseqstate = BMVAL(etmidr5, 25, 27);
/* NUMCNTR, bits[30:28] number of counters available for tracing */
drvdata->nr_cntr = BMVAL(etmidr5, 28, 30);
+
+ /* Update metadata */
+ metadata->magic = ETM4_METADATA_MAGIC;
+ metadata->cpu = drvd
[PATCH v3 4/6] coresight: tmc: Hook callback for panic kdump
Since the panic kdump functionality has been ready, this patch is to
hook panic callback function for ETB/ETF. Since the driver data
structure has allocated buffer when the session started, so simply save
ETB/ETF trace data into the buffer when panic happens and update
related info into dump node.
Signed-off-by: Leo Yan
---
drivers/hwtracing/coresight/coresight-tmc-etf.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c
b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index e2513b7..f823464 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -504,6 +504,34 @@ static void tmc_update_etf_buffer(struct coresight_device
*csdev,
CS_LOCK(drvdata->base);
}
+static void tmc_panic_cb(void *data)
+{
+ struct coresight_device *csdev = (struct coresight_device *)data;
+ struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+ unsigned long flags;
+
+ if (WARN_ON_ONCE(drvdata->config_type != TMC_CONFIG_TYPE_ETB &&
+drvdata->config_type != TMC_CONFIG_TYPE_ETF))
+ return;
+
+ if (drvdata->mode == CS_MODE_DISABLED)
+ return;
+
+ spin_lock_irqsave(&drvdata->spinlock, flags);
+
+ CS_UNLOCK(drvdata->base);
+
+ tmc_flush_and_stop(drvdata);
+ tmc_etb_dump_hw(drvdata);
+
+ CS_LOCK(drvdata->base);
+
+ /* Update buffer info for panic dump */
+ coresight_kdump_update(csdev, drvdata->buf, drvdata->len);
+
+ spin_unlock_irqrestore(&drvdata->spinlock, flags);
+}
+
static const struct coresight_ops_sink tmc_etf_sink_ops = {
.enable = tmc_enable_etf_sink,
.disable= tmc_disable_etf_sink,
@@ -512,6 +540,7 @@ static const struct coresight_ops_sink tmc_etf_sink_ops = {
.set_buffer = tmc_set_etf_buffer,
.reset_buffer = tmc_reset_etf_buffer,
.update_buffer = tmc_update_etf_buffer,
+ .panic_cb = tmc_panic_cb,
};
static const struct coresight_ops_link tmc_etf_link_ops = {
--
2.7.4
--
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 v3 2/6] doc: Add documentation for Coresight panic kdump
Add detailed documentation for Coresight panic kdump, which contains
the idea for why need this and introduce the framework implementation
and usage.
Signed-off-by: Leo Yan
---
.../trace/coresight/coresight-panic-kdump.txt | 91 ++
MAINTAINERS| 1 +
2 files changed, 92 insertions(+)
create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt
diff --git a/Documentation/trace/coresight/coresight-panic-kdump.txt
b/Documentation/trace/coresight/coresight-panic-kdump.txt
new file mode 100644
index 000..6bf9cac
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-panic-kdump.txt
@@ -0,0 +1,91 @@
+ Coresight Panic Kdump
+ =
+
+ Author: Leo Yan
+ Date: Dec 21th, 2017
+
+Introduction
+
+
+Coresight has different sinks for trace data, the trace data is quite useful
+for postmortem debugging. Embedded Trace Buffer (ETB) is one type sink which
+provides on-chip storage of trace data, usually uses SRAM as buffer with
+several KBs size; if the SoC designs to support 'Local ETF' (ARM DDI 0461B,
+chapter 1.2.7), every CPU has one local ETB buffer so the per CPU trace data
+can avoid to be overwritted by other CPUs. Trace Memory Controller (TMC) is
+another kind sink designed as a successor to the CoreSight ETB to capture trace
+into DRAM.
+
+After Linux kernel trigger panic, the trace data keeps the last execution flow
+before issues happen. We could consider the trace data is quite useful for
+postmortem debugging, especially when we can record trace data into DRAM and
rely
+on kdump to save them into vmcore file; at the end we can retrieve trace data
+from vmcore file and "offline" to analyze the execution flow.
+
+
+Implementation
+--
+
+Coresight panic kdump is a simple framework to support dump functionality,
+it maintains dump list with every node recording the dump buffer base address
+and buffer size. Coresight panic kdump provides the general APIs
+{coresight_kdump_add|coresight_kdump_del} as helper functions so any coresight
+device can add itself into dump list or delete as needed.
+
+Generally coresight device set its 'panic_cb' in the ops structure, the panic
+notifier iterates dump list and invokes callback function to dump device
specific
+info.
+
+For easily used by offline analysis, we also record tracer metadata so can
+retrieve tracer IDs and configuration, in this case the node records CPU
number so
+can create connection between the metadata and specific CPU. The tracer
+driver uses helper function coresight_kdump_update() to update the dump
+buffer base address and buffer size; so the tracer can save metadata at runtime
+and these info can be prepared well pre panic happening.
+
+
+Usage
+-
+
+Build Linux kernel with enabling 'CONFIG_CORESIGHT_PANIC_KDUMP' configuration.
+
+After system booting up, we need firstly prepare dump-capture kernel, this can
+refer doc [1] chapter 'Load the Dump-capture Kernel' for detailed steps. Then
+we need enable the coresight tracer, this can use either perf framework method
+or sysFS interface, please refer doc [2] chapter 'How to use the tracer
modules'
+for detailed steps.
+
+When kernel panic happens, the panic kdump records trace data and launches
+dump-capture kernel, we can utilize the dump-capture kernel to save kernel dump
+file, this can refer doc [1] chapter 'Write Out the Dump File'.
+
+After get kernel dump file, we can use 'crash' tool + csdump.so extension to
+extract trace data and generate 'perf.data' file:
+
+ ./crash vmcore vmlinux
+ crash> extend csdump.so
+ crash> csdump output_dir
+
+ We can see in the 'output_dir' there will generate out three files:
+ output_dir/
+ ├── cstrace.bin -> trace raw data
+ ├── metadata.bin -> meta data
+ └── perf.data -> 'perf' format compatible file
+
+Finally use 'perf' tool for offline analysis:
+
+ ./perf script -v -F cpu,event,ip,sym,symoff -i perf.data -k vmlinux
--kallsyms /proc/kallsyms
+ [001] instructions: 08559ad0 pl011_console_write+0x90
+ [001] instructions: 08559230 pl011_read+0x0
+ [001] instructions: 0855924c pl011_read+0x1c
+ [001] instructions: 08559ae0 pl011_console_write+0xa0
+ [001] instructions: 08559ad0 pl011_console_write+0x90
+ [001] instructions: 08559230 pl011_read+0x0
+ [001] instructions: 0855924c pl011_read+0x1c
+ [001] instructions: 08559ae0 pl011_console_write+0xa0
+ [001] instructions: 08559ad0 pl011_console_write+0x90
+ [001] instructions: 08559230 pl011_read+0x0
+ [001] instructions: 0855924c pl011_read+0x1c
+
+[1] Documentation/kdump/kdump.txt
+[2] Documentation/trace/coresight/coresight.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index d7a6fc7..26276e0 100644
--- a/MA
Re: [PATCH v4 16/18] scripts: kernel-doc: improve nested logic to handle multiple identifiers
Hi Mauro, I love your patch! Perhaps something to improve: [auto build test WARNING on lwn/docs-next] [also build test WARNING on v4.15-rc4 next-20171221] [cannot apply to linus/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/kernel-doc-add-supported-to-document-nested-structs/20171221-055609 base: git://git.lwn.net/linux-2.6 docs-next reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/crypto/hash.h:89: warning: duplicate section name 'Note' include/crypto/hash.h:95: warning: duplicate section name 'Note' include/crypto/hash.h:102: warning: duplicate section name 'Note' include/crypto/hash.h:89: warning: duplicate section name 'Note' include/crypto/hash.h:95: warning: duplicate section name 'Note' include/crypto/hash.h:102: warning: duplicate section name 'Note' include/crypto/hash.h:89: warning: duplicate section name 'Note' include/crypto/hash.h:95: warning: duplicate section name 'Note' include/crypto/hash.h:102: warning: duplicate section name 'Note' include/crypto/hash.h:89: warning: duplicate section name 'Note' include/crypto/hash.h:95: warning: duplicate section name 'Note' include/crypto/hash.h:102: warning: duplicate section name 'Note' include/crypto/hash.h:89: warning: duplicate section name 'Note' include/crypto/hash.h:95: warning: duplicate section name 'Note' include/crypto/hash.h:102: warning: duplicate section name 'Note' include/crypto/hash.h:89: warning: duplicate section name 'Note' include/crypto/hash.h:95: warning: duplicate section name 'Note' include/crypto/hash.h:102: warning: duplicate section name 'Note' include/crypto/hash.h:89: warning: duplicate section name 'Note' include/crypto/hash.h:95: warning: duplicate section name 'Note' include/crypto/hash.h:102: warning: duplicate section name 'Note' include/crypto/hash.h:89: warning: duplicate section name 'Note' include/crypto/hash.h:95: warning: duplicate section name 'Note' include/crypto/hash.h:102: warning: duplicate section name 'Note' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.ablkcipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.blkcipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.cipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.compress' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.ablkcipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.blkcipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.cipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.compress' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.ablkcipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.blkcipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.cipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.compress' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.ablkcipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.blkcipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.cipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.compress' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.ablkcipher' not described in 'crypto_alg' include/linux/crypto.h:469: warning: Function parameter or member 'cra_u.blkcipher' not described in
Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
On Wed, 20 Dec 2017 12:06:45 -0600
Rob Herring wrote:
> On Sat, Dec 16, 2017 at 07:35:37PM +0100, Boris Brezillon wrote:
> > On Sat, 16 Dec 2017 11:20:40 -0600
> > Rob Herring wrote:
> >
> > > On Thu, Dec 14, 2017 at 04:16:08PM +0100, Boris Brezillon wrote:
> > > > A new I3C subsystem has been added and a generic description has been
> > > > created to represent the I3C bus and the devices connected on it.
> > > >
> > > > Document this generic representation.
>
> [...]
>
> > > So please define the node
> > > name to be "i3c-controller". That's more inline with other node names
> > > than i3c-master that you used below.
> >
> > Hm, not sure i3c-controller is appropriate though, because you can have
> > slave controllers. Maybe i3c-host, but I'd prefer to keep the term
> > master since it's employed everywhere in the spec. I can also be
> > i3c-master-controller if you prefer.
>
> Okay, i3c-master is fine. Just make it explicit.
Okay.
>
> > > > +I3C devices
> > > > +===
> > > > +
> > > > +All I3C devices are supposed to support DAA (Dynamic Address
> > > > Assignment), and
> > > > +are thus discoverable. So, by default, I3C devices do not have to be
> > > > described
> > > > +in the device tree.
> > > > +This being said, one might want to attach extra resources to these
> > > > devices,
> > > > +and those resources may have to be described in the device tree, which
> > > > in turn
> > > > +means we have to describe I3C devices.
> > > > +
> > > > +Another use case for describing an I3C device in the device tree is
> > > > when this
> > > > +I3C device has a static address and we want to assign it a specific
> > > > dynamic
> > > > +address before the DAA takes place (so that other devices on the bus
> > > > can't
> > > > +take this dynamic address).
> > > > +
> > > > +Required properties
> > > > +---
> > > > +- i3c-pid: PID (Provisional ID). 64-bit property which is used to
> > > > match a
> > > > + device discovered during DAA with its device tree
> > > > definition. The
> > > > + PID is supposed to be unique on a given bus, which
> > > > guarantees a 1:1
> > > > + match. This property becomes optional if a reg property is
> > > > defined,
> > > > + meaning that the device has a static address.
> > >
> > > What determines this number?
> >
> > Part of it is fixed (manufacturer and part id) and the last few bits
> > represent the device instance on the bus (so you can have several
> > identical devices on the same bus). The manufacturer and part ids
> > should be statically assigned during production, instance id is usually
> > configurable through extra pins that you drive high or low at reset
> > time.
>
> Sounds like an I2C address at least for the pin strapping part...
The address space of this instance-id is smaller (4bits) than the I2C
one (7bits), and more importantly, the instance-id is not required to
be unique, it's the aggregation of the vendor-id, part-id and
instance-id that has to be unique. So, if you were thinking about using
this id to uniquely identify the device on the bus it's not a good idea.
>
> > > > +
> > > > +Optional properties
> > > > +---
> > > > +- reg: static address. Only valid is the device has a static address.
> > > > +- i3c-dynamic-address: dynamic address to be assigned to this device.
> > > > This
> > > > + property depends on the reg property.
> > >
> > > Perhaps "assigned-address" property would be appropriate. I'm not all
> > > that familiar with it though.
> >
> > Again, the spec use the term "dynamic address" everywhere, and I'd like
> > to stay as close as possible to the spec.
>
> I looked at assigned-addresses a bit more and that won't really fit
> because it should be the same format as reg. So I think reg should
> always be the PID as that is fixed and always present. Then the DAA
> address is separate and can be the i3c-dynamic-address property.
>
> However, there's still part I don't understand...
>
> > > > + /* I3C device with a static address. */
> > > > + thermal_sensor: sensor@68 {
> > > > + reg = <0x68>;
> > > > + i3c-dynamic-address = <0xa>;
>
> I'm confused as to how/why you have both reg and dynamic address?
Some I3C devices have an I2C address (also called static or legacy
address in a few places). The static/I2C/legacy address is used until
the I3C device is assigned a dynamic address by the master. The whole
point of specifying both an I2C address (through the reg property) and
a dynamic address (through the i3c-dynamic-address) is to tell the
controller that a specific dynamic address should be assigned to this
device using the SETSADA (Set Dynamic Address from Static Address)
command before a DAA (Dynamic Address Assignment) procedure is started.
This way, the device will not participate to the DAA (because it
alr
Re: Distress Call Please don't ignore
Good Day, Forgive my indignation if this message comes to you as a surprise and may offend your personality for contacting you without your prior consent and writing through this channel. I came across your name and contact on the course of my personal searching when i was searching for a foreign reliable partner. I was assured of your capability and reliability after going true your profile. I'm (Miss. Sandra) from Benghazi libya, My father of blessed memory by name late General Abdel Fattah Younes who was shot death by Islamist-linked militia within the anti-Gaddafi forces on 28th July, 2011 and after two days later my mother with my two brothers was killed one early morning by the rebels as result of civil war that is going on in my country Libya, then after the burial of my parents, my uncles conspired and sold my father's properties and left nothing for me. On a faithful morning, I opened my father's briefcase and discover a document which he has deposited ($6.250M USD) in a bank in a Turkish Bank which has a small branch in Canada with my name as the legitimate/next of kin. Meanwhile i have located the bank,and have also discussed the possiblity of transfering the fund. My father left a clause to the bank that i must introduce a trusted foreign partner who would be my trustee to help me invest this fund; hence the need for your assistance,i request that you be my t rustee and assist me in e You will also be responsible for the investment and management of the fund for me and also you will help me get a good school where i will further my education. I agreed to give you 40% of the $6.250M once the transfer is done. this is my true life story, I will be glad to receive your respond soonest for more details to enable us start and champion the transfer less than 14 banking days as i was informed by the bank manager. Thanks for giving me your attention, Yours sincerely, Miss. Sandra Younes -- 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] mm: memcontrol: memory+swap accounting for cgroup-v2
Hello, Shakeel. On Wed, Dec 20, 2017 at 05:15:41PM -0800, Shakeel Butt wrote: > Let's say we have a job that allocates 100 MiB memory and suppose 80 > MiB is anon and 20 MiB is non-anon (file & kmem). > > [With memsw] Scheduler sets the memsw limit of the job to 100 MiB and > memory to max. Now suppose the job tries to allocates memory more than > 100 MiB, it will hit the memsw limit and will try to reclaim non-anon > memory. The memcg OOM behavior will only depend on the reclaim of > non-anon memory and will be independent of the underlying swap device. Sure, the direct reclaim on memsw limit won't reclaim anon pages, but think about how the state at that point would have formed. You're claiming that memsw makes memory allocation and balancing behavior an invariant against the performance of the swap device that the machine has. It's simply not possible. On top of that, what's the point? 1. As I wrote earlier, given the current OOM killer implementation, whether OOM kicks in or not is not even that relevant in determining the health of the workload. There are frequent failure modes where OOM killer fails to kick in while the workload isn't making any meaningful forward progress. 2. On hitting memsw limit, the OOM decision is dependent on the performance of the file backing devices. Why is that necessarily better than being dependent on swap or both, which would increase the reclaim efficiency anyway? You can't avoid being affected by the underlying hardware one way or the other. 3. The only thing memsw does is that memsw direct reclaim will only consider file backed pages, which I think is more of an accident (in an attemp to avoid lower swap setting meaning higher actual memory usage) than the intended outcome. This is obviously suboptimal and an implementation detail. I don't think it's something we want to expose to userland as a feature. Thanks. -- tejun -- 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] mm: memcontrol: memory+swap accounting for cgroup-v2
On Thu, Dec 21, 2017 at 5:37 AM, Tejun Heo wrote: > Hello, Shakeel. > > On Wed, Dec 20, 2017 at 05:15:41PM -0800, Shakeel Butt wrote: >> Let's say we have a job that allocates 100 MiB memory and suppose 80 >> MiB is anon and 20 MiB is non-anon (file & kmem). >> >> [With memsw] Scheduler sets the memsw limit of the job to 100 MiB and >> memory to max. Now suppose the job tries to allocates memory more than >> 100 MiB, it will hit the memsw limit and will try to reclaim non-anon >> memory. The memcg OOM behavior will only depend on the reclaim of >> non-anon memory and will be independent of the underlying swap device. > > Sure, the direct reclaim on memsw limit won't reclaim anon pages, but > think about how the state at that point would have formed. You're > claiming that memsw makes memory allocation and balancing behavior an > invariant against the performance of the swap device that the machine > has. It's simply not possible. > I am claiming memory allocations under global pressure will be affected by the performance of the underlying swap device. However memory allocations under memcg memory pressure, with memsw, will not be affected by the performance of the underlying swap device. A job having 100 MiB limit running on a machine without global memory pressure will never see swap on hitting 100 MiB memsw limit. > On top of that, what's the point? > > 1. As I wrote earlier, given the current OOM killer implementation, >whether OOM kicks in or not is not even that relevant in >determining the health of the workload. There are frequent failure >modes where OOM killer fails to kick in while the workload isn't >making any meaningful forward progress. > Deterministic oom-killer is not the point. The point is to "consistently limit the anon memory" allocated by the job which only memsw can provide. A job owner who has requested 100 MiB for a job sees some instances of the job suffer at 100 MiB and other instances suffer at 150 MiB, is an inconsistent behavior. > 2. On hitting memsw limit, the OOM decision is dependent on the >performance of the file backing devices. Why is that necessarily >better than being dependent on swap or both, which would increase >the reclaim efficiency anyway? You can't avoid being affected by >the underlying hardware one way or the other. > This is a separate discussion but still the amount of file backed pages is known and controlled by the job owner and they have the option to use a storage service, providing a consistent performance across different data centers, instead of the physical disks of the system where the job is running and thus isolating the job's performance from the speed of the local disk. This is not possible with swap. The swap (and its performance) is and should be transparent to the job owners. -- 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] mm: memcontrol: memory+swap accounting for cgroup-v2
> The swap (and its performance) is and should be transparent > to the job owners. Please ignore this statement, I didn't mean to claim on the independence of job performance and underlying swap performance, sorry about that. I meant to say that the amount of anon memory a job can allocate should be independent to the underlying swap. -- 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 00/11] dvb: add support for memory mapped I/O
This patch series is based on a work made by Samsung in 2015 meant
to add memory-mapped I/O to the Linux media, in order to improve
performance. The preparation patches were merged on that time, but
we didn't have time to test and finish the final patch.
Fortunately, Satendra helped us doing such port. On my tests, even
on USB drivers, where we need to do DMA at URB buffers, the
performance gains seem considerable.
On the tests I did today, with perf stat, the gains were expressive:
- the number of task clocks reduced by 3,5 times;
- the number of context switches reduced by about 4,5 times;
- the number of CPU cycles reduced by almost 3,5 times;
- the number of executed instructions reduced almost 2 times;
- the number of cache references reduced by almost 8 times;
- the number of cache misses reduced more than 4,5 times.
The patches are at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb_mmap
An userspace test patchset is at:
https://git.linuxtv.org/mchehab/experimental-v4l-utils.git/log/?h=dvb_mmap
More details about my tests can be found on my comments to the
original Satendra's patch:
https://patchwork.linuxtv.org/patch/46101/
Mauro Carvalho Chehab (9):
media: vb2-core: add pr_fmt() macro
media: vb2-core: add a new warning about pending buffers
media: dvb_vb2: fix a warning about streamoff logic
media: move videobuf2 to drivers/media/common
media: dvb uAPI docs: document demux mmap/munmap syscalls
media: dvb uAPI docs: document mmap-related ioctls
media: dvb-core: get rid of mmap reserved field
fs: compat_ioctl: add new DVB demux ioctls
media: dvb_vb2: add SPDX headers
Satendra Singh Thakur (2):
media: vb2-core: Fix a bug about unnecessary calls to queue cancel and
free
media: videobuf2: Add new uAPI for DVB streaming I/O
Documentation/media/uapi/dvb/dmx-expbuf.rst| 88 +
Documentation/media/uapi/dvb/dmx-mmap.rst | 116 ++
Documentation/media/uapi/dvb/dmx-munmap.rst| 54 +++
Documentation/media/uapi/dvb/dmx-qbuf.rst | 83
Documentation/media/uapi/dvb/dmx-querybuf.rst | 63 +++
Documentation/media/uapi/dvb/dmx-reqbufs.rst | 74
Documentation/media/uapi/dvb/dmx_fcalls.rst| 6 +
drivers/media/common/Kconfig | 1 +
drivers/media/common/Makefile | 2 +-
drivers/media/common/videobuf/Kconfig | 31 ++
drivers/media/common/videobuf/Makefile | 7 +
.../videobuf}/videobuf2-core.c | 38 +-
.../videobuf}/videobuf2-dma-contig.c | 0
.../videobuf}/videobuf2-dma-sg.c | 0
.../{v4l2-core => common/videobuf}/videobuf2-dvb.c | 0
.../videobuf}/videobuf2-memops.c | 0
.../videobuf}/videobuf2-v4l2.c | 0
.../videobuf}/videobuf2-vmalloc.c | 0
drivers/media/dvb-core/Makefile| 2 +-
drivers/media/dvb-core/dmxdev.c| 196 --
drivers/media/dvb-core/dmxdev.h| 4 +
drivers/media/dvb-core/dvb_vb2.c | 430 +
drivers/media/dvb-core/dvb_vb2.h | 74
drivers/media/v4l2-core/Kconfig| 32 --
drivers/media/v4l2-core/Makefile | 7 -
fs/compat_ioctl.c | 5 +
include/uapi/linux/dvb/dmx.h | 63 ++-
27 files changed, 1290 insertions(+), 86 deletions(-)
create mode 100644 Documentation/media/uapi/dvb/dmx-expbuf.rst
create mode 100644 Documentation/media/uapi/dvb/dmx-mmap.rst
create mode 100644 Documentation/media/uapi/dvb/dmx-munmap.rst
create mode 100644 Documentation/media/uapi/dvb/dmx-qbuf.rst
create mode 100644 Documentation/media/uapi/dvb/dmx-querybuf.rst
create mode 100644 Documentation/media/uapi/dvb/dmx-reqbufs.rst
create mode 100644 drivers/media/common/videobuf/Kconfig
create mode 100644 drivers/media/common/videobuf/Makefile
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-core.c (98%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-dma-contig.c
(100%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-dma-sg.c (100%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-dvb.c (100%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-memops.c (100%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-v4l2.c (100%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-vmalloc.c (100%)
create mode 100644 drivers/media/dvb-core/dvb_vb2.c
create mode 100644 drivers/media/dvb-core/dvb_vb2.h
--
2.14.3
--
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 01/11] media: vb2-core: Fix a bug about unnecessary calls to queue cancel and free
From: Satendra Singh Thakur
When the func vb2_core_reqbufs is called first time after
vb2_core_queue_init(), the condition q->memory != memory always gets
satisfied, since q->memory was set to 0 at vb2_core_queue_init().
After the condition is true, unnecessary calls to __vb2_queue_cancel()
and __vb2_queue_free() are done. in such case, *count is non-zero,
q->num_buffers is zero and q->memory is 0, which is not equal to
memory field *count=N, q->num_buffers=0, q->memory != memory.
[mche...@s-opensource.com: fix checkpatch issues]
Signed-off-by: Satendra Singh Thakur
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/v4l2-core/videobuf2-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index cb115ba6a1d2..21017b478a34 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -662,7 +662,8 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory
memory,
return -EBUSY;
}
- if (*count == 0 || q->num_buffers != 0 || q->memory != memory) {
+ if (*count == 0 || q->num_buffers != 0 ||
+ (q->memory && q->memory != memory)) {
/*
* We already have buffers allocated, so first check if they
* are not in use and can be freed.
--
2.14.3
--
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 08/11] media: dvb uAPI docs: document mmap-related ioctls
5 new ioctls were added to the DVB demux API, in order to
handle memory maped I/O. Add documentation for them.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/media/uapi/dvb/dmx-expbuf.rst | 90 +++
Documentation/media/uapi/dvb/dmx-qbuf.rst | 85 +
Documentation/media/uapi/dvb/dmx-querybuf.rst | 65 +++
Documentation/media/uapi/dvb/dmx-reqbufs.rst | 76 ++
Documentation/media/uapi/dvb/dmx_fcalls.rst | 4 ++
5 files changed, 320 insertions(+)
create mode 100644 Documentation/media/uapi/dvb/dmx-expbuf.rst
create mode 100644 Documentation/media/uapi/dvb/dmx-qbuf.rst
create mode 100644 Documentation/media/uapi/dvb/dmx-querybuf.rst
create mode 100644 Documentation/media/uapi/dvb/dmx-reqbufs.rst
diff --git a/Documentation/media/uapi/dvb/dmx-expbuf.rst
b/Documentation/media/uapi/dvb/dmx-expbuf.rst
new file mode 100644
index ..51df34c6fb59
--- /dev/null
+++ b/Documentation/media/uapi/dvb/dmx-expbuf.rst
@@ -0,0 +1,90 @@
+.. _DMX_EXPBUF:
+
+
+ioctl DMX_EXPBUF
+
+
+Name
+
+
+DMX_EXPBUF - Export a buffer as a DMABUF file descriptor.
+
+.. warning:: this API is still experimental
+
+
+Synopsis
+
+
+.. c:function:: int ioctl( int fd, DMX_EXPBUF, struct dmx_exportbuffer *argp )
+:name: DMX_EXPBUF
+
+
+Arguments
+=
+
+``fd``
+File descriptor returned by :ref:`open() `.
+
+``argp``
+Pointer to struct :c:type:`dmx_exportbuffer`.
+
+
+Description
+===
+
+This ioctl is an extension to the memory mapping I/O method.
+It can be used to export a buffer as a DMABUF file at any time after
+buffers have been allocated with the :ref:`DMX_REQBUFS` ioctl.
+
+The ``reserved`` array must be zeroed before calling it.
+
+To export a buffer, applications fill struct :c:type:`dmx_exportbuffer`.
+Applications must set the ``index`` field. Valid index numbers
+range from zero to the number of buffers allocated with :ref:`DMX_REQBUFS`
+(struct :c:type:`dmx_requestbuffers` ``count``) minus one.
+Additional flags may be posted in the ``flags`` field. Refer to a manual
+for open() for details. Currently only O_CLOEXEC, O_RDONLY, O_WRONLY,
+and O_RDWR are supported.
+All other fields must be set to zero. In the
+case of multi-planar API, every plane is exported separately using
+multiple :ref:`DMX_EXPBUF` calls.
+
+After calling :ref:`DMX_EXPBUF` the ``fd`` field will be set by a
+driver, on success. This is a DMABUF file descriptor. The application may
+pass it to other DMABUF-aware devices. It is recommended to close a DMABUF
+file when it is no longer used to allow the associated memory to be reclaimed.
+
+
+Examples
+
+
+
+.. code-block:: c
+
+int buffer_export(int v4lfd, enum dmx_buf_type bt, int index, int *dmafd)
+{
+ struct dmx_exportbuffer expbuf;
+
+ memset(&expbuf, 0, sizeof(expbuf));
+ expbuf.type = bt;
+ expbuf.index = index;
+ if (ioctl(v4lfd, DMX_EXPBUF, &expbuf) == -1) {
+ perror("DMX_EXPBUF");
+ return -1;
+ }
+
+ *dmafd = expbuf.fd;
+
+ return 0;
+}
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
+
+EINVAL
+A queue is not in MMAP mode or DMABUF exporting is not supported or
+``flags`` or ``index`` fields are invalid.
diff --git a/Documentation/media/uapi/dvb/dmx-qbuf.rst
b/Documentation/media/uapi/dvb/dmx-qbuf.rst
new file mode 100644
index ..b20b8153d48d
--- /dev/null
+++ b/Documentation/media/uapi/dvb/dmx-qbuf.rst
@@ -0,0 +1,85 @@
+.. _DMX_QBUF:
+
+*
+ioctl DMX_QBUF, DMX_DQBUF
+*
+
+Name
+
+
+DMX_QBUF - DMX_DQBUF - Exchange a buffer with the driver
+
+.. warning:: this API is still experimental
+
+
+Synopsis
+
+
+.. c:function:: int ioctl( int fd, DMX_QBUF, struct dmx_buffer *argp )
+:name: DMX_QBUF
+
+.. c:function:: int ioctl( int fd, DMX_DQBUF, struct dmx_buffer *argp )
+:name: DMX_DQBUF
+
+
+Arguments
+=
+
+``fd``
+File descriptor returned by :ref:`open() `.
+
+``argp``
+Pointer to struct :c:type:`dmx_buffer`.
+
+
+Description
+===
+
+Applications call the ``DMX_QBUF`` ioctl to enqueue an empty
+(capturing) or filled (output) buffer in the driver's incoming queue.
+The semantics depend on the selected I/O method.
+
+To enqueue a buffer applications set the ``index`` field. Valid index
+numbers range from zero to the number of buffers allocated with
+:ref:`DMX_REQBUFS` (struct :c:type:`dmx_requestbuffers` ``count``) minus
+one. The contents of the struct :c:type:`dmx_buffer` returned
+by a :ref:`DMX_QUERYBUF` ioctl will do as well.
+
+The and ``reserved`` field must be set to 0.
+
+When ``DMX_QBUF`` is called with a pointer to this structure, it locks the
+memory pages of the buffer i
[PATCH 11/11] media: dvb_vb2: add SPDX headers
This code is released under GPL. Add the corresponding SPDX headers. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/dvb-core/dvb_vb2.c | 1 + drivers/media/dvb-core/dvb_vb2.h | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/media/dvb-core/dvb_vb2.c b/drivers/media/dvb-core/dvb_vb2.c index 7b1663f64e84..10d8f627af3a 100644 --- a/drivers/media/dvb-core/dvb_vb2.c +++ b/drivers/media/dvb-core/dvb_vb2.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL /* * dvb-vb2.c - dvb-vb2 * diff --git a/drivers/media/dvb-core/dvb_vb2.h b/drivers/media/dvb-core/dvb_vb2.h index d68653926d91..a5164effee16 100644 --- a/drivers/media/dvb-core/dvb_vb2.h +++ b/drivers/media/dvb-core/dvb_vb2.h @@ -1,4 +1,6 @@ /* + * SPDX-License-Identifier: GPL + * * dvb-vb2.h - DVB driver helper framework for streaming I/O * * Copyright (C) 2015 Samsung Electronics -- 2.14.3 -- 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 03/11] media: vb2-core: add pr_fmt() macro
Simplify the pr_foo() macros by adding a pr_fmt() macro.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/v4l2-core/videobuf2-core.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 21017b478a34..319ab8bf220f 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -14,6 +14,8 @@
* the Free Software Foundation.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -32,10 +34,10 @@
static int debug;
module_param(debug, int, 0644);
-#define dprintk(level, fmt, arg...) \
- do { \
- if (debug >= level) \
- pr_info("vb2-core: %s: " fmt, __func__, ## arg); \
+#define dprintk(level, fmt, arg...)\
+ do {\
+ if (debug >= level) \
+ pr_info("%s: " fmt, __func__, ## arg); \
} while (0)
#ifdef CONFIG_VIDEO_ADV_DEBUG
@@ -460,12 +462,12 @@ static int __vb2_queue_free(struct vb2_queue *q, unsigned
int buffers)
q->cnt_wait_prepare != q->cnt_wait_finish;
if (unbalanced || debug) {
- pr_info("vb2: counters for queue %p:%s\n", q,
+ pr_info("counters for queue %p:%s\n", q,
unbalanced ? " UNBALANCED!" : "");
- pr_info("vb2: setup: %u start_streaming: %u
stop_streaming: %u\n",
+ pr_info(" setup: %u start_streaming: %u
stop_streaming: %u\n",
q->cnt_queue_setup, q->cnt_start_streaming,
q->cnt_stop_streaming);
- pr_info("vb2: wait_prepare: %u wait_finish: %u\n",
+ pr_info(" wait_prepare: %u wait_finish: %u\n",
q->cnt_wait_prepare, q->cnt_wait_finish);
}
q->cnt_queue_setup = 0;
@@ -486,23 +488,23 @@ static int __vb2_queue_free(struct vb2_queue *q, unsigned
int buffers)
vb->cnt_buf_init != vb->cnt_buf_cleanup;
if (unbalanced || debug) {
- pr_info("vb2: counters for queue %p, buffer %d:%s\n",
+ pr_info(" counters for queue %p, buffer %d:%s\n",
q, buffer, unbalanced ? " UNBALANCED!" : "");
- pr_info("vb2: buf_init: %u buf_cleanup: %u
buf_prepare: %u buf_finish: %u\n",
+ pr_info(" buf_init: %u buf_cleanup: %u buf_prepare:
%u buf_finish: %u\n",
vb->cnt_buf_init, vb->cnt_buf_cleanup,
vb->cnt_buf_prepare, vb->cnt_buf_finish);
- pr_info("vb2: buf_queue: %u buf_done: %u\n",
+ pr_info(" buf_queue: %u buf_done: %u\n",
vb->cnt_buf_queue, vb->cnt_buf_done);
- pr_info("vb2: alloc: %u put: %u prepare: %u finish:
%u mmap: %u\n",
+ pr_info(" alloc: %u put: %u prepare: %u finish: %u
mmap: %u\n",
vb->cnt_mem_alloc, vb->cnt_mem_put,
vb->cnt_mem_prepare, vb->cnt_mem_finish,
vb->cnt_mem_mmap);
- pr_info("vb2: get_userptr: %u put_userptr: %u\n",
+ pr_info(" get_userptr: %u put_userptr: %u\n",
vb->cnt_mem_get_userptr,
vb->cnt_mem_put_userptr);
- pr_info("vb2: attach_dmabuf: %u detach_dmabuf: %u
map_dmabuf: %u unmap_dmabuf: %u\n",
+ pr_info(" attach_dmabuf: %u detach_dmabuf: %u
map_dmabuf: %u unmap_dmabuf: %u\n",
vb->cnt_mem_attach_dmabuf,
vb->cnt_mem_detach_dmabuf,
vb->cnt_mem_map_dmabuf,
vb->cnt_mem_unmap_dmabuf);
- pr_info("vb2: get_dmabuf: %u num_users: %u vaddr:
%u cookie: %u\n",
+ pr_info(" get_dmabuf: %u num_users: %u vaddr: %u
cookie: %u\n",
vb->cnt_mem_get_dmabuf,
vb->cnt_mem_num_users,
vb->cnt_mem_vaddr,
--
2.14.3
--
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 10/11] fs: compat_ioctl: add new DVB demux ioctls
Use trivial handling for the new DVB demux ioctls, as none of them passes a pointer inside their structures. Signed-off-by: Mauro Carvalho Chehab --- fs/compat_ioctl.c | 5 + 1 file changed, 5 insertions(+) diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index bd5d91e119ca..cc71c3676ce2 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -1333,6 +1333,11 @@ COMPATIBLE_IOCTL(DMX_SET_PES_FILTER) COMPATIBLE_IOCTL(DMX_SET_BUFFER_SIZE) COMPATIBLE_IOCTL(DMX_GET_PES_PIDS) COMPATIBLE_IOCTL(DMX_GET_STC) +COMPATIBLE_IOCTL(DMX_REQBUFS) +COMPATIBLE_IOCTL(DMX_QUERYBUF) +COMPATIBLE_IOCTL(DMX_EXPBUF) +COMPATIBLE_IOCTL(DMX_QBUF) +COMPATIBLE_IOCTL(DMX_DQBUF) COMPATIBLE_IOCTL(FE_GET_INFO) COMPATIBLE_IOCTL(FE_DISEQC_RESET_OVERLOAD) COMPATIBLE_IOCTL(FE_DISEQC_SEND_MASTER_CMD) -- 2.14.3 -- 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 05/11] media: dvb_vb2: fix a warning about streamoff logic
The streamoff logic is causing those warnings:
WARNING: CPU: 3 PID: 3382 at drivers/media/v4l2-core/videobuf2-core.c:1652
__vb2_queue_cancel+0x177/0x250 [videobuf2_core]
Modules linked in: bnep fuse xt_CHECKSUM iptable_mangle tun ebtable_filter
ebtables ip6table_filter ip6_tables xt_physdev br_netfilter bluetooth bridge
rfkill ecdh_generic stp llc nf_log_ipv4 nf_log_common xt_LOG xt_conntrack
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c sunrpc vfat fat
snd_hda_codec_hdmi rc_dib0700_nec i915 rc_pinnacle_pctv_hd em28xx_rc a8293
ts2020 m88ds3103 i2c_mux em28xx_dvb dib8000 dvb_usb_dib0700 dib0070 dib7000m
dib0090 dvb_usb dvb_core uvcvideo snd_usb_audio videobuf2_v4l2 dib3000mc
videobuf2_vmalloc videobuf2_memops dibx000_common videobuf2_core rc_core
snd_usbmidi_lib snd_rawmidi em28xx tveeprom v4l2_common videodev media
intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel
kvm_intel snd_hda_codec kvm snd_hwdep snd_hda_core snd_seq irqbypass
crct10dif_pclmul crc32_pclmul i2c_algo_bit ghash_clmulni_intel snd_seq_device
drm_kms_helper snd_pcm intel_cstate intel_uncore snd_timer tpm_tis drm mei_wdt
iTCO_wdt iTCO_vendor_support tpm_tis_core snd intel_rapl_perf mei_me mei tpm
i2c_i801 soundcore lpc_ich video binfmt_misc hid_logitech_hidpp hid_logitech_dj
e1000e crc32c_intel ptp pps_core analog gameport joydev
CPU: 3 PID: 3382 Comm: lt-dvbv5-zap Not tainted 4.14.0+ #3
Hardware name: /D53427RKE, BIOS
RKPPT10H.86A.0048.2017.0506.1545 05/06/2017
task: 94b93bbe1e40 task.stack: b7a98320c000
RIP: 0010:__vb2_queue_cancel+0x177/0x250 [videobuf2_core]
RSP: 0018:b7a98320fd40 EFLAGS: 00010202
RAX: 0001 RBX: 94b92ff72428 RCX:
RDX: 0001 RSI: 0001 RDI: 94b92ff72428
RBP: b7a98320fd68 R08: 94b92ff725d8 R09: b7a98320fcc8
R10: 94b978003d98 R11: 94b92ff72428 R12: 94b92ff72428
R13: 0282 R14: 94b92059ae20 R15: dead0100
FS: () GS:94b99e38() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 555953007d70 CR3: 00012be09004 CR4: 001606e0
Call Trace:
vb2_core_streamoff+0x28/0x90 [videobuf2_core]
dvb_vb2_stream_off+0xd1/0x150 [dvb_core]
dvb_dvr_release+0x114/0x120 [dvb_core]
__fput+0xdf/0x1e0
fput+0xe/0x10
task_work_run+0x94/0xc0
do_exit+0x2dc/0xba0
do_group_exit+0x47/0xb0
SyS_exit_group+0x14/0x20
entry_SYSCALL_64_fastpath+0x1a/0xa5
RIP: 0033:0x7f775e931ed8
RSP: 002b:7fff07019d68 EFLAGS: 0246 ORIG_RAX: 00e7
RAX: ffda RBX: 01d02690 RCX: 7f775e931ed8
RDX: 0001 RSI: 003c RDI: 0001
RBP: 7fff0701a500 R08: 00e7 R09: ff70
R10: 7f775e854dd8 R11: 0246 R12:
R13: 035fa000 R14: 000a R15: 000a
Code: 00 00 04 74 1c 44 89 e8 49 83 c5 01 41 39 84 24 88 01 00 00 77 8a 5b 41
5c 41 5d 41 5e 41 5f 5d c3 48 89 df e8 bb fd ff ff eb da <0f> ff 41 8b b4 24 88
01 00 00 85 f6 74 34 bb 01 00 00 00 eb 10
There are actually two issues here:
1) list_del() should be called when changing the buffer state;
2) The logic with marks the buffers as done is at the wrong place.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-core/dvb_vb2.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_vb2.c b/drivers/media/dvb-core/dvb_vb2.c
index 34193a4acc47..277d33b83089 100644
--- a/drivers/media/dvb-core/dvb_vb2.c
+++ b/drivers/media/dvb-core/dvb_vb2.c
@@ -89,8 +89,19 @@ static int _start_streaming(struct vb2_queue *vq, unsigned
int count)
static void _stop_streaming(struct vb2_queue *vq)
{
struct dvb_vb2_ctx *ctx = vb2_get_drv_priv(vq);
+ struct dvb_buffer *buf;
+ unsigned long flags = 0;
dprintk(3, "[%s]\n", ctx->name);
+
+ spin_lock_irqsave(&ctx->slock, flags);
+ while (!list_empty(&ctx->dvb_q)) {
+ buf = list_entry(ctx->dvb_q.next,
+struct dvb_buffer, list);
+ vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
+ list_del(&buf->list);
+ }
+ spin_unlock_irqrestore(&ctx->slock, flags);
}
static void _dmxdev_lock(struct vb2_queue *vq)
@@ -224,21 +235,8 @@ int dvb_vb2_stream_off(struct dvb_vb2_ctx *ctx)
{
struct vb2_queue *q = (struct vb2_queue *)&ctx->vb_q;
int ret;
- unsigned long flags = 0;
ctx->state &= ~DVB_VB2_STATE_STREAMON;
- spin_lock_irqsave(&ctx->slock, flags);
- while (!list_empty(&ctx->dvb_q)) {
- struct dvb_buffer *buf;
-
- buf = list_entry(ctx->dvb_q.next,
-struct dvb_buffer, list);
- l
[PATCH 04/11] media: vb2-core: add a new warning about pending buffers
There's a logic at the VB2 core that produces a WARN_ON if
there are still buffers waiting to be filled. However, it doesn't
indicate what buffers are still opened, with makes harder to
identify issues inside caller drivers.
So, add a new pr_warn() pointing to such buffers. That, together
with debug instrumentation inside the drivers can make easier to
identify where the problem is.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/v4l2-core/videobuf2-core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 319ab8bf220f..064d3c6f1e74 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1653,8 +1653,11 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
*/
if (WARN_ON(atomic_read(&q->owned_by_drv_count))) {
for (i = 0; i < q->num_buffers; ++i)
- if (q->bufs[i]->state == VB2_BUF_STATE_ACTIVE)
+ if (q->bufs[i]->state == VB2_BUF_STATE_ACTIVE) {
+ pr_warn("driver bug: stop_streaming operation
is leaving buf %p in active state\n",
+ q->bufs[i]);
vb2_buffer_done(q->bufs[i],
VB2_BUF_STATE_ERROR);
+ }
/* Must be zero now */
WARN_ON(atomic_read(&q->owned_by_drv_count));
}
--
2.14.3
--
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 09/11] media: dvb-core: get rid of mmap reserved field
The "reserved" field was a way, used at V4L2 API, to add new
data to existing structs without breaking userspace. However,
there are now clever ways of doing that, without needing to add
an uneeded overhead. So, get rid of them.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/media/uapi/dvb/dmx-expbuf.rst | 2 --
Documentation/media/uapi/dvb/dmx-qbuf.rst | 2 --
Documentation/media/uapi/dvb/dmx-querybuf.rst | 2 --
Documentation/media/uapi/dvb/dmx-reqbufs.rst | 2 --
drivers/media/dvb-core/dvb_vb2.c | 1 -
include/uapi/linux/dvb/dmx.h | 3 ---
6 files changed, 12 deletions(-)
diff --git a/Documentation/media/uapi/dvb/dmx-expbuf.rst
b/Documentation/media/uapi/dvb/dmx-expbuf.rst
index 51df34c6fb59..2d96cfe891df 100644
--- a/Documentation/media/uapi/dvb/dmx-expbuf.rst
+++ b/Documentation/media/uapi/dvb/dmx-expbuf.rst
@@ -36,8 +36,6 @@ This ioctl is an extension to the memory mapping I/O method.
It can be used to export a buffer as a DMABUF file at any time after
buffers have been allocated with the :ref:`DMX_REQBUFS` ioctl.
-The ``reserved`` array must be zeroed before calling it.
-
To export a buffer, applications fill struct :c:type:`dmx_exportbuffer`.
Applications must set the ``index`` field. Valid index numbers
range from zero to the number of buffers allocated with :ref:`DMX_REQBUFS`
diff --git a/Documentation/media/uapi/dvb/dmx-qbuf.rst
b/Documentation/media/uapi/dvb/dmx-qbuf.rst
index b20b8153d48d..b48c4931658e 100644
--- a/Documentation/media/uapi/dvb/dmx-qbuf.rst
+++ b/Documentation/media/uapi/dvb/dmx-qbuf.rst
@@ -45,8 +45,6 @@ numbers range from zero to the number of buffers allocated
with
one. The contents of the struct :c:type:`dmx_buffer` returned
by a :ref:`DMX_QUERYBUF` ioctl will do as well.
-The and ``reserved`` field must be set to 0.
-
When ``DMX_QBUF`` is called with a pointer to this structure, it locks the
memory pages of the buffer in physical memory, so they cannot be swapped
out to disk. Buffers remain locked until dequeued, until the
diff --git a/Documentation/media/uapi/dvb/dmx-querybuf.rst
b/Documentation/media/uapi/dvb/dmx-querybuf.rst
index 46a50f191b10..89481e24bb86 100644
--- a/Documentation/media/uapi/dvb/dmx-querybuf.rst
+++ b/Documentation/media/uapi/dvb/dmx-querybuf.rst
@@ -36,8 +36,6 @@ This ioctl is part of the mmap streaming I/O method. It can
be used to query the status of a buffer at any time after buffers have
been allocated with the :ref:`DMX_REQBUFS` ioctl.
-The ``reserved`` array must be zeroed before calling it.
-
Applications set the ``index`` field. Valid index numbers range from zero
to the number of buffers allocated with :ref:`DMX_REQBUFS`
(struct :c:type:`dvb_requestbuffers` ``count``) minus one.
diff --git a/Documentation/media/uapi/dvb/dmx-reqbufs.rst
b/Documentation/media/uapi/dvb/dmx-reqbufs.rst
index 0749623d9d83..14b80d60bf35 100644
--- a/Documentation/media/uapi/dvb/dmx-reqbufs.rst
+++ b/Documentation/media/uapi/dvb/dmx-reqbufs.rst
@@ -42,8 +42,6 @@ allocated by applications through a device driver, and this
ioctl only
configures the driver into DMABUF I/O mode without performing any direct
allocation.
-The ``reserved`` array must be zeroed before calling it.
-
To allocate device buffers applications initialize all fields of the
struct :c:type:`dmx_requestbuffers` structure. They set the ``count`` field
to the desired number of buffers, and ``size`` to the size of each
diff --git a/drivers/media/dvb-core/dvb_vb2.c b/drivers/media/dvb-core/dvb_vb2.c
index 277d33b83089..7b1663f64e84 100644
--- a/drivers/media/dvb-core/dvb_vb2.c
+++ b/drivers/media/dvb-core/dvb_vb2.c
@@ -140,7 +140,6 @@ static void _fill_dmx_buffer(struct vb2_buffer *vb, void
*pb)
b->length = vb->planes[0].length;
b->bytesused = vb->planes[0].bytesused;
b->offset = vb->planes[0].m.offset;
- memset(b->reserved, 0, sizeof(b->reserved));
dprintk(3, "[%s]\n", ctx->name);
}
diff --git a/include/uapi/linux/dvb/dmx.h b/include/uapi/linux/dvb/dmx.h
index e212aa18ad78..5f3c5a918f00 100644
--- a/include/uapi/linux/dvb/dmx.h
+++ b/include/uapi/linux/dvb/dmx.h
@@ -229,7 +229,6 @@ struct dmx_buffer {
__u32 bytesused;
__u32 offset;
__u32 length;
- __u32 reserved[4];
};
/**
@@ -244,7 +243,6 @@ struct dmx_buffer {
struct dmx_requestbuffers {
__u32 count;
__u32 size;
- __u32 reserved[2];
};
/**
@@ -266,7 +264,6 @@ struct dmx_exportbuffer {
__u32 index;
__u32 flags;
__s32 fd;
- __u32 reserved[5];
};
#define DMX_START_IO('o', 41)
--
2.14.3
--
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.or
[PATCH 07/11] media: dvb uAPI docs: document demux mmap/munmap syscalls
With the new dmx mmap interface, those two syscalls are now handled by the subsystem. Document them. This patch is based on the V4L2 text for those ioctls. Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/dvb/dmx-mmap.rst | 116 Documentation/media/uapi/dvb/dmx-munmap.rst | 54 + Documentation/media/uapi/dvb/dmx_fcalls.rst | 2 + 3 files changed, 172 insertions(+) create mode 100644 Documentation/media/uapi/dvb/dmx-mmap.rst create mode 100644 Documentation/media/uapi/dvb/dmx-munmap.rst diff --git a/Documentation/media/uapi/dvb/dmx-mmap.rst b/Documentation/media/uapi/dvb/dmx-mmap.rst new file mode 100644 index ..15d107348b9f --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-mmap.rst @@ -0,0 +1,116 @@ +.. _dmx-mmap: + +* +Digital TV mmap() +* + +Name + + +dmx-mmap - Map device memory into application address space + +.. warning:: this API is still experimental + +Synopsis + + +.. code-block:: c + +#include +#include + + +.. c:function:: void *mmap( void *start, size_t length, int prot, int flags, int fd, off_t offset ) +:name: dmx-mmap + +Arguments += + +``start`` +Map the buffer to this address in the application's address space. +When the ``MAP_FIXED`` flag is specified, ``start`` must be a +multiple of the pagesize and mmap will fail when the specified +address cannot be used. Use of this option is discouraged; +applications should just specify a ``NULL`` pointer here. + +``length`` +Length of the memory area to map. This must be a multiple of the +DVB packet length (188, on most drivers). + +``prot`` +The ``prot`` argument describes the desired memory protection. +Regardless of the device type and the direction of data exchange it +should be set to ``PROT_READ`` | ``PROT_WRITE``, permitting read +and write access to image buffers. Drivers should support at least +this combination of flags. + +``flags`` +The ``flags`` parameter specifies the type of the mapped object, +mapping options and whether modifications made to the mapped copy of +the page are private to the process or are to be shared with other +references. + +``MAP_FIXED`` requests that the driver selects no other address than +the one specified. If the specified address cannot be used, +:ref:`mmap() ` will fail. If ``MAP_FIXED`` is specified, +``start`` must be a multiple of the pagesize. Use of this option is +discouraged. + +One of the ``MAP_SHARED`` or ``MAP_PRIVATE`` flags must be set. +``MAP_SHARED`` allows applications to share the mapped memory with +other (e. g. child-) processes. + +.. note:: + + The Linux Digital TV applications should not set the + ``MAP_PRIVATE``, ``MAP_DENYWRITE``, ``MAP_EXECUTABLE`` or ``MAP_ANON`` + flags. + +``fd`` +File descriptor returned by :ref:`open() `. + +``offset`` +Offset of the buffer in device memory, as returned by +:ref:`DMX_QUERYBUF` ioctl. + + +Description +=== + +The :ref:`mmap() ` function asks to map ``length`` bytes starting at +``offset`` in the memory of the device specified by ``fd`` into the +application address space, preferably at address ``start``. This latter +address is a hint only, and is usually specified as 0. + +Suitable length and offset parameters are queried with the +:ref:`DMX_QUERYBUF` ioctl. Buffers must be allocated with the +:ref:`DMX_REQBUFS` ioctl before they can be queried. + +To unmap buffers the :ref:`munmap() ` function is used. + + +Return Value + + +On success :ref:`mmap() ` returns a pointer to the mapped buffer. On +error ``MAP_FAILED`` (-1) is returned, and the ``errno`` variable is set +appropriately. Possible error codes are: + +EBADF +``fd`` is not a valid file descriptor. + +EACCES +``fd`` is not open for reading and writing. + +EINVAL +The ``start`` or ``length`` or ``offset`` are not suitable. (E. g. +they are too large, or not aligned on a ``PAGESIZE`` boundary.) + +The ``flags`` or ``prot`` value is not supported. + +No buffers have been allocated with the +:ref:`DMX_REQBUFS` ioctl. + +ENOMEM +Not enough physical or virtual memory was available to complete the +request. diff --git a/Documentation/media/uapi/dvb/dmx-munmap.rst b/Documentation/media/uapi/dvb/dmx-munmap.rst new file mode 100644 index ..d77218732bb6 --- /dev/null +++ b/Documentation/media/uapi/dvb/dmx-munmap.rst @@ -0,0 +1,54 @@ +.. _dmx-munmap: + + +DVB munmap() + + +Name + + +dmx-munmap - Unmap device memory + +.. warning:: This API is still experimental. + + +Synopsis + + +.. code-block:: c + +#include +#include + + +.. c:function:: int munmap( void *start, size_t length ) +:name: dmx-munmap + +Arguments += + +``start`` +Address of the mapped buffer as returned by the +:ref:`mma
[PATCH 02/11] media: videobuf2: Add new uAPI for DVB streaming I/O
From: Satendra Singh Thakur
Adds a new uAPI for DVB to use streaming I/O which is implemented
based on videobuf2, using those new ioctls:
- DMX_REQBUFS: Request kernel to allocate buffers which count and size
are dedicated by user.
- DMX_QUERYBUF: Get the buffer information like a memory offset which
will mmap() and be shared with user-space.
- DMX_EXPBUF: Just for testing whether buffer-exporting success or not.
- DMX_QBUF: Pass the buffer to kernel-space.
- DMX_DQBUF:Get back the buffer which may contain TS data.
Originally developed by: Junghak Sung , as
seen at:
https://patchwork.linuxtv.org/patch/31613/
https://patchwork.kernel.org/patch/7334301/
The original patch was written before merging VB2-core functionalities
upstream. When such series was added, several adjustments were made,
fixing some issues with V4L2, causing the original patch to be
non-trivially rebased.
After rebased, a few bugs in the patch were fixed. The patch was
also enhanced it and polling functionality got added.
The main changes over the original patch are:
dvb_vb2_fill_buffer():
- Set the size of the outgoing buffer after while loop using
vb2_set_plane_payload;
- Added NULL check for source buffer as per normal convention
of demux driver, this is called twice, first time with valid
buffer second time with NULL pointer, if its not handled,
it will result in crash
- Restricted spinlock for only list_* operations
dvb_vb2_init():
- Restricted q->io_modes to only VB2_MMAP as its the only
supported mode
dvb_vb2_release():
- Replaced the && in if condiion with &, because otherwise
it was always getting satisfied.
dvb_vb2_stream_off():
- Added list_del code for enqueud buffers upon stream off
dvb_vb2_poll():
- Added this new function in order to support polling
dvb_demux_poll() and dvb_dvr_poll()
- dvb_vb2_poll() is now called from these functions
- Ported this patch and latest videobuf2 to lower kernel versions and
tested auto scan.
[mche...@s-opensource.com: checkpatch fixes]
Co-developed-by: Junghak Sung
Signed-off-by: Junghak Sung
Signed-off-by: Geunyoung Kim
Acked-by: Seung-Woo Kim
Acked-by: Inki Dae
Signed-off-by: Satendra Singh Thakur
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-core/Makefile | 2 +-
drivers/media/dvb-core/dmxdev.c | 196 +++---
drivers/media/dvb-core/dmxdev.h | 4 +
drivers/media/dvb-core/dvb_vb2.c | 423 +++
drivers/media/dvb-core/dvb_vb2.h | 72 +++
include/uapi/linux/dvb/dmx.h | 66 +-
6 files changed, 733 insertions(+), 30 deletions(-)
create mode 100644 drivers/media/dvb-core/dvb_vb2.c
create mode 100644 drivers/media/dvb-core/dvb_vb2.h
diff --git a/drivers/media/dvb-core/Makefile b/drivers/media/dvb-core/Makefile
index 47e2e391bfb8..bbc65dfa0a8e 100644
--- a/drivers/media/dvb-core/Makefile
+++ b/drivers/media/dvb-core/Makefile
@@ -7,6 +7,6 @@ dvb-net-$(CONFIG_DVB_NET) := dvb_net.o
dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o \
dvb_ca_en50221.o dvb_frontend.o\
-$(dvb-net-y) dvb_ringbuffer.o dvb_math.o
+$(dvb-net-y) dvb_ringbuffer.o dvb_vb2.o dvb_math.o
obj-$(CONFIG_DVB_CORE) += dvb-core.o
diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
index 18e4230865be..4cbb9003a1ed 100644
--- a/drivers/media/dvb-core/dmxdev.c
+++ b/drivers/media/dvb-core/dmxdev.c
@@ -28,6 +28,7 @@
#include
#include
#include "dmxdev.h"
+#include "dvb_vb2.h"
static int debug;
@@ -138,14 +139,8 @@ static int dvb_dvr_open(struct inode *inode, struct file
*file)
return -ENODEV;
}
- if ((file->f_flags & O_ACCMODE) == O_RDWR) {
- if (!(dmxdev->capabilities & DMXDEV_CAP_DUPLEX)) {
- mutex_unlock(&dmxdev->mutex);
- return -EOPNOTSUPP;
- }
- }
-
- if ((file->f_flags & O_ACCMODE) == O_RDONLY) {
+ if (((file->f_flags & O_ACCMODE) == O_RDONLY) ||
+ ((file->f_flags & O_ACCMODE) == O_RDWR)) {
void *mem;
if (!dvbdev->readers) {
@@ -158,6 +153,8 @@ static int dvb_dvr_open(struct inode *inode, struct file
*file)
return -ENOMEM;
}
dvb_ringbuffer_init(&dmxdev->dvr_buffer, mem, DVR_BUFFER_SIZE);
+ dvb_vb2_init(&dmxdev->dvr_vb2_ctx, "dvr",
+file->f_flags & O_NONBLOCK);
dvbdev->readers--;
}
@@ -195,7 +192,11 @@ static int dvb_dvr_release(struct inode *inode, struct
file *file)
dmxdev->demux->connect_frontend(dmxdev->demux,
dmxdev->dvr_orig_fe);
}
- if ((file->f_flags & O_ACCMO
[PATCH 06/11] media: move videobuf2 to drivers/media/common
Now that VB2 is used by both V4L2 and DVB core, move it to
the common part of the subsystem.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/common/Kconfig | 1 +
drivers/media/common/Makefile | 2 +-
drivers/media/common/videobuf/Kconfig | 31 +
drivers/media/common/videobuf/Makefile | 7 +
.../videobuf}/videobuf2-core.c | 0
.../videobuf}/videobuf2-dma-contig.c | 0
.../videobuf}/videobuf2-dma-sg.c | 0
.../{v4l2-core => common/videobuf}/videobuf2-dvb.c | 0
.../videobuf}/videobuf2-memops.c | 0
.../videobuf}/videobuf2-v4l2.c | 0
.../videobuf}/videobuf2-vmalloc.c | 0
drivers/media/v4l2-core/Kconfig| 32 --
drivers/media/v4l2-core/Makefile | 7 -
13 files changed, 40 insertions(+), 40 deletions(-)
create mode 100644 drivers/media/common/videobuf/Kconfig
create mode 100644 drivers/media/common/videobuf/Makefile
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-core.c (100%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-dma-contig.c
(100%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-dma-sg.c (100%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-dvb.c (100%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-memops.c (100%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-v4l2.c (100%)
rename drivers/media/{v4l2-core => common/videobuf}/videobuf2-vmalloc.c (100%)
diff --git a/drivers/media/common/Kconfig b/drivers/media/common/Kconfig
index 326df0ad75c0..cdfc905967dc 100644
--- a/drivers/media/common/Kconfig
+++ b/drivers/media/common/Kconfig
@@ -16,6 +16,7 @@ config CYPRESS_FIRMWARE
tristate "Cypress firmware helper routines"
depends on USB
+source "drivers/media/common/videobuf/Kconfig"
source "drivers/media/common/b2c2/Kconfig"
source "drivers/media/common/saa7146/Kconfig"
source "drivers/media/common/siano/Kconfig"
diff --git a/drivers/media/common/Makefile b/drivers/media/common/Makefile
index 2d1b0a025084..f24b5ed39982 100644
--- a/drivers/media/common/Makefile
+++ b/drivers/media/common/Makefile
@@ -1,4 +1,4 @@
-obj-y += b2c2/ saa7146/ siano/ v4l2-tpg/
+obj-y += b2c2/ saa7146/ siano/ v4l2-tpg/ videobuf/
obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_CYPRESS_FIRMWARE) += cypress_firmware.o
diff --git a/drivers/media/common/videobuf/Kconfig
b/drivers/media/common/videobuf/Kconfig
new file mode 100644
index ..5df05250de94
--- /dev/null
+++ b/drivers/media/common/videobuf/Kconfig
@@ -0,0 +1,31 @@
+# Used by drivers that need Videobuf2 modules
+config VIDEOBUF2_CORE
+ select DMA_SHARED_BUFFER
+ tristate
+
+config VIDEOBUF2_MEMOPS
+ tristate
+ select FRAME_VECTOR
+
+config VIDEOBUF2_DMA_CONTIG
+ tristate
+ depends on HAS_DMA
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ select DMA_SHARED_BUFFER
+
+config VIDEOBUF2_VMALLOC
+ tristate
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ select DMA_SHARED_BUFFER
+
+config VIDEOBUF2_DMA_SG
+ tristate
+ depends on HAS_DMA
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+
+config VIDEOBUF2_DVB
+ tristate
+ select VIDEOBUF2_CORE
diff --git a/drivers/media/common/videobuf/Makefile
b/drivers/media/common/videobuf/Makefile
new file mode 100644
index ..19de5ccda20b
--- /dev/null
+++ b/drivers/media/common/videobuf/Makefile
@@ -0,0 +1,7 @@
+
+obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o videobuf2-v4l2.o
+obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
+obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
+obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
+obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
+obj-$(CONFIG_VIDEOBUF2_DVB) += videobuf2-dvb.o
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/common/videobuf/videobuf2-core.c
similarity index 100%
rename from drivers/media/v4l2-core/videobuf2-core.c
rename to drivers/media/common/videobuf/videobuf2-core.c
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/common/videobuf/videobuf2-dma-contig.c
similarity index 100%
rename from drivers/media/v4l2-core/videobuf2-dma-contig.c
rename to drivers/media/common/videobuf/videobuf2-dma-contig.c
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/common/videobuf/videobuf2-dma-sg.c
similarity index 100%
rename from drivers/media/v4l2-core/videobuf2-dma-sg.c
rename to drivers/media/common/videobuf/videobuf2-dma-sg.c
diff --git a/drivers/media/v4l2-core/videobuf2-dvb.c
b/drivers/media/common/videobuf/videobuf2-dvb.c
similarity index 100%
rename from drivers/media/v4l2-core/videobuf2-dvb.c
renam
Re: [PATCH v10 11/13] slimbus: qcom: Add Qualcomm Slimbus controller driver
> +
> + ctrl->tx.base = dmam_alloc_coherent(&pdev->dev,
> + (ctrl->tx.sl_sz * ctrl->tx.n),
> + &ctrl->tx.phy, GFP_KERNEL);
> + if (!ctrl->tx.base) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + ctrl->rx.base = dmam_alloc_coherent(&pdev->dev,
> + (ctrl->rx.sl_sz * ctrl->rx.n),
> + &ctrl->rx.phy, GFP_KERNEL);
I got another one of
/git/arm-soc/drivers/slimbus/qcom-ctrl.c: In function 'qcom_slim_probe':
/git/arm-soc/drivers/slimbus/qcom-ctrl.c:584:9: error: passing
argument 3 of 'dmam_alloc_coherent' from incompatible pointer type
[-Werror=incompatible-pointer-types]
&ctrl->tx.phy, GFP_KERNEL);
^
In file included from /git/arm-soc/drivers/slimbus/qcom-ctrl.c:16:0:
/git/arm-soc/include/linux/dma-mapping.h:760:14: note: expected
'dma_addr_t * {aka unsigned int *}' but argument is of type
'phys_addr_t * {aka long long unsigned int *}'
extern void *dmam_alloc_coherent(struct device *dev, size_t size,
^~~
/git/arm-soc/drivers/slimbus/qcom-ctrl.c:592:9: error: passing
argument 3 of 'dmam_alloc_coherent' from incompatible pointer type
[-Werror=incompatible-pointer-types]
&ctrl->rx.phy, GFP_KERNEL);
^
In file included from /git/arm-soc/drivers/slimbus/qcom-ctrl.c:16:0:
/git/arm-soc/include/linux/dma-mapping.h:760:14: note: expected
'dma_addr_t * {aka unsigned int *}' but argument is of type
'phys_addr_t * {aka long long unsigned int *}'
extern void *dmam_alloc_coherent(struct device *dev, size_t size,
I don't have time to analyze this further, but I guess this is the
same confusion
that happened in a few other qualcomm drivers, which all used dma_alloc_*
to get a buffer that gets passed into firmware.This is always wrong.
Arnd
--
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] mm: memcontrol: memory+swap accounting for cgroup-v2
Hello, Shakeel. On Thu, Dec 21, 2017 at 07:22:20AM -0800, Shakeel Butt wrote: > I am claiming memory allocations under global pressure will be > affected by the performance of the underlying swap device. However > memory allocations under memcg memory pressure, with memsw, will not > be affected by the performance of the underlying swap device. A job > having 100 MiB limit running on a machine without global memory > pressure will never see swap on hitting 100 MiB memsw limit. But, without global memory pressure, the swap wouldn't be making any difference to begin with. Also, when multiple cgroups are hitting memsw limits, they'd behave as if swappiness is zero increasing load on the filesystems, which then then of course will affect everyone under memory pressure whether memsw or not. > > On top of that, what's the point? > > > > 1. As I wrote earlier, given the current OOM killer implementation, > >whether OOM kicks in or not is not even that relevant in > >determining the health of the workload. There are frequent failure > >modes where OOM killer fails to kick in while the workload isn't > >making any meaningful forward progress. > > > > Deterministic oom-killer is not the point. The point is to > "consistently limit the anon memory" allocated by the job which only > memsw can provide. A job owner who has requested 100 MiB for a job > sees some instances of the job suffer at 100 MiB and other instances > suffer at 150 MiB, is an inconsistent behavior. So, the first part, I get. memsw happens to be be able to limit the amount of anon memory. I really don't think that was the intention but more of a byproduct that some people might find useful. The example you listed tho doesn't make much sense to me. Given two systems with differing level of memory pressures, two instances can see wildly different performance regardless of memsw. > > 2. On hitting memsw limit, the OOM decision is dependent on the > >performance of the file backing devices. Why is that necessarily > >better than being dependent on swap or both, which would increase > >the reclaim efficiency anyway? You can't avoid being affected by > >the underlying hardware one way or the other. > > This is a separate discussion but still the amount of file backed > pages is known and controlled by the job owner and they have the > option to use a storage service, providing a consistent performance > across different data centers, instead of the physical disks of the > system where the job is running and thus isolating the job's > performance from the speed of the local disk. This is not possible > with swap. The swap (and its performance) is and should be transparent > to the job owners. And, for your use case, there is a noticeable difference between file backed and anonymous memories and that's why you want to limit anonymous memory independently from file backed memory. It looks like what you actually want is limiting the amount of anonymous memory independently from file-backed consumptions because, in your setup, while swap is always on local disk the file storages are over network and more configurable / flexible. Assuming I'm not misunderstanding you, here are my thoughts. * I'm not sure that distinguishing anon and file backed memories like that is the direction we want to head. In fact, the more uniform we can behave across them, the more efficient we'd be as we wouldn't have that artificial barrier. It is true that we don't have the same level of control for swap tho. * Even if we want an independent anon limit, memsw isn't the solution. It's too conflated. If you want to have anon limit, the right thing to do would be pushing for an independent anon limit, not memsw. Thanks. -- tejun -- 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 v4 0/3] doc: update printk documentation
On Wed, 20 Dec 2017 08:17:14 +1100 "Tobin C. Harding" wrote: > This set converts printk-formats.txt -> core-api/printk-formats.rst > > We also update the documentation around printing kernel addresses. > > This is my first documentation conversion. Please do be hard on this > patch series. I'd like to get it _really_ correct so that future > conversions will require less review effort. Also if there are any > peculiarities to patching docs (as apposed to C files) please say so. > > Thank you for the time already given to reviewing previous versions. So I spent a while thinking hard about how I could make Tobin do another round or two on these patches. But then I figure that it's the holidays, and I should just apply them. So that's done. Thanks for all of your work on this! That said... - I don't quite understand why you capitalize "kernel" everywhere. I vaguely recall some sort of discussion on that. To me it looks strange...oh well. - There's a dangling reference to printk-formats.txt in lib/vsprintf.c that we'll want to fix up. - The vsprintf kerneldoc currently gets pulled into the big "kernel API" dumpster. Someday, it would be nice to turn printk-formats.rst into a "how to output data from the kernel" section, with documentation on vnsprintf, printk, trace_printk, and format strings all in one place. What a fine day that would be... Thanks again, 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] Documentation/filesystems/vfat.txt: fix a remark that implies UCS2
On Mon, 18 Dec 2017 20:47:27 +0100 Adam Borowski wrote: > All non-historic operating systems support the full range of Unicode here, > thus you can make filenames for example in Gothic (𐌼𐌴𐍉𐍅), the other Gothic > (𝓂ℯℴ𝓌) or the third Gothic (𝗆𝖾𝗈𝗐), or declare something as 💩. > > Characters above U+ are encoded on four bytes. > > Signed-off-by: Adam Borowski 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 0/3] Documentation: more names to the enforcement statement
On Wed, 13 Dec 2017 13:52:52 +0100 Greg Kroah-Hartman wrote: > Here are 3 patches for the kernel-enforcement-statement file that came > in after the file was originally added to the kernel tree. Applied all three, 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 v4 0/3] doc: update printk documentation
On 12/21/2017 11:21 AM, Jonathan Corbet wrote: > On Wed, 20 Dec 2017 08:17:14 +1100 > "Tobin C. Harding" wrote: > >> This set converts printk-formats.txt -> core-api/printk-formats.rst >> >> We also update the documentation around printing kernel addresses. >> >> This is my first documentation conversion. Please do be hard on this >> patch series. I'd like to get it _really_ correct so that future >> conversions will require less review effort. Also if there are any >> peculiarities to patching docs (as apposed to C files) please say so. >> >> Thank you for the time already given to reviewing previous versions. > > So I spent a while thinking hard about how I could make Tobin do another > round or two on these patches. But then I figure that it's the holidays, > and I should just apply them. So that's done. Thanks for all of your > work on this! > > That said... > > - I don't quite understand why you capitalize "kernel" everywhere. I >vaguely recall some sort of discussion on that. To me it looks >strange...oh well. Mauro explained that he capitalizes Kernel when it is being used as a shortened version of "the Linux kernel," i.e., as a proper name, so I think that Tobin appropriated that style. It would be OK to undo that IMO. > - There's a dangling reference to printk-formats.txt in lib/vsprintf.c >that we'll want to fix up. > > - The vsprintf kerneldoc currently gets pulled into the big "kernel API" >dumpster. Someday, it would be nice to turn printk-formats.rst into a >"how to output data from the kernel" section, with documentation on >vnsprintf, printk, trace_printk, and format strings all in one place. >What a fine day that would be... -- ~Randy -- 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 v4 0/3] doc: update printk documentation
On Thu, 2017-12-21 at 12:21 -0700, Jonathan Corbet wrote: > On Wed, 20 Dec 2017 08:17:14 +1100 > "Tobin C. Harding" wrote: > > > This set converts printk-formats.txt -> core-api/printk-formats.rst > > > > We also update the documentation around printing kernel addresses. [] > > - There's a dangling reference to printk-formats.txt in lib/vsprintf.c >that we'll want to fix up. patch 1/3 updates that reference. -- 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/1] usb: doc: Update document for USB3 debug port usage
On Wed, 13 Dec 2017 13:07:44 +0800 Lu Baolu wrote: > Update Documentation/driver-api/usb/usb3-debug-port.rst. This update > includes the guide for using xHCI debug capability based TTY serial > link. > > Cc: Mathias Nyman > Cc: Greg Kroah-Hartman > Signed-off-by: Lu Baolu 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 v4 0/3] doc: update printk documentation
On Thu, 21 Dec 2017 11:30:57 -0800 Joe Perches wrote: > > > - There's a dangling reference to printk-formats.txt in lib/vsprintf.c > >that we'll want to fix up. > > patch 1/3 updates that reference. It updates one of them - there were two, one of which remains. I'll just toss in a patch to do that one too. 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 v2] i2c: update i2c-dev.h warning in documentation
On Tue, 12 Dec 2017 19:43:09 +0300
"Cengiz C." wrote:
> `Documentation/i2c/dev-interface` gives examples for accessing i2c from
> userspace.
>
> There's a note that warns developers about the two `i2c-dev.h` header
> files which were shipped with the kernel and i2c-tools separately.
>
> However, following i2c-tools commits suggest that the header files are now
> identical (in functionality) and `i2c_*` helper functions are now defined
> in a separate header called `i2c/smbus.h`, which is distributed with
> i2c-tools:
>
> commit 652619121974 ("Minimize differences with kernel flavor")
> commit 93caf007f4cb ("Move SMBus helper functions to include/i2c/smbus.h")
>
> Thus, I've converted the warning paragraph into a historical note and
> updated the suggested header files.
>
> Signed-off-by: Cengiz Can
Applied to the docs tree, thanks. Note that the patch was wrapped by your
mailer and I had to fix it up; that would be nice to avoid in the future.
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] docs: ftrace-uses.rst fix varios code-block directives
On Tue, 12 Dec 2017 11:22:25 +0100 Markus Heiser wrote: > ftrace-uses.rst is not yet included into any toctree, but since it is > a .rst file, it is parsed by the Sphinx build. Thats, why we see some > WARNINGS: > > - trace/ftrace-uses.rst:53: WARNING: Definition list ends without a blank > line; unexpected unindent. > - trace/ftrace-uses.rst:89: WARNING: Inline emphasis start-string without > end-string. > - trace/ftrace-uses.rst:89: WARNING: Inline emphasis start-string without > end-strin > > Fixing the code-block directives results in a less noisy build, but the 'not > included' WARNING will be stay: > > - trace/ftrace-uses.rst: WARNING: document isn't included in any toctree Applied with Steve's ack, thanks. Maybe it *should* be in the toctree...perhaps as part of that nice RST tracing manual that we know is coming any day now...:) 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] docs: fix process/submit-checklist.rst Sphinx warning
On Tue, 12 Dec 2017 11:46:51 +0100 Markus Heiser wrote: > add missing indent whitespace to list item, fixes the warning: > > - process/submit-checklist.rst:41: WARNING: Enumerated list ends without a > blank > line; unexpected unindent. > > Signed-off-by: Markus Heiser Applied, 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 v2] i2c: update i2c-dev.h warning in documentation
> Applied to the docs tree, thanks. Note that the patch was wrapped by your > mailer and I had to fix it up; that would be nice to avoid in the future. Thank you! I've ditched claws-mail and will use git send-mail instead. -- Cengiz Can -- 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] i2c: update i2c-dev.h warning in documentation
On Thu, 21 Dec 2017 23:49:16 +0300 Cengiz Can wrote: > I've ditched claws-mail and will use git send-mail instead. FWIW, I use claws for patch mailing and more. It can be made to work, you just need to tweak the options a bit. The trick is to send patches to yourself and keep at it until what you receive still applies. 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 v4 00/18] kernel-doc: add supported to document nested structs
On Mon, 18 Dec 2017 10:30:01 -0200 Mauro Carvalho Chehab wrote: > This is a rebased version of my patch series that add support for > nested structs on kernel-doc. With this version, it won't produce anymore > hundreds of identical warnings, as patch 17 removes the warning > duplication. > > Excluding warnings about duplicated Note: section at hash.h, before > this series, it reports 166 kernel-doc warnings. After this patch series, > it reports 123 kernel-doc warnings, being 51 from DVB. I have already a patch > series that will cleanup those new DVB warnings due to nested structs. > > So, the net result is that the number of warnings is reduced with > this version. This seems like a great set of improvements overall, and I love getting rid of all that old kernel-doc code. I will note that it makes a full htmldocs build take 20-30 seconds longer, which is not entirely welcome, but so be it. Someday, I guess, $SOMEBODY should see if there's some low-hanging optimization fruit there. Applied, 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 v2 0/2] mux: add overview and add to driver-api docs
On Tue, 12 Dec 2017 09:46:31 +0100 Peter Rosin wrote: > Changes since v1: > - added a short introductory paragraph to mux.rst > - added an entry in MAINTAINERS. > > I forgot to mention that this applies on top of linux-next, I suspect > there will be a trivial conflict with an SPDX conversion in mux/core.c > on Linus upstream. Sorry, I've had this just sitting here for a bit. Did you want me to take both patches through 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 v4 00/18] kernel-doc: add supported to document nested structs
Em Thu, 21 Dec 2017 14:08:43 -0700 Jonathan Corbet escreveu: > On Mon, 18 Dec 2017 10:30:01 -0200 > Mauro Carvalho Chehab wrote: > > > This is a rebased version of my patch series that add support for > > nested structs on kernel-doc. With this version, it won't produce anymore > > hundreds of identical warnings, as patch 17 removes the warning > > duplication. > > > > Excluding warnings about duplicated Note: section at hash.h, before > > this series, it reports 166 kernel-doc warnings. After this patch series, > > it reports 123 kernel-doc warnings, being 51 from DVB. I have already a > > patch > > series that will cleanup those new DVB warnings due to nested structs. > > > > So, the net result is that the number of warnings is reduced with > > this version. > > This seems like a great set of improvements overall, and I love getting > rid of all that old kernel-doc code. > I will note that it makes a full > htmldocs build take 20-30 seconds longer, which is not entirely > welcome, but so be it. Someday, I guess, $SOMEBODY should see if there's > some low-hanging optimization fruit there. Yeah. Well, I used a recursive algorithm, with can be painfull if there are mang things to parse. Anyway, I didn't notice it, because there was a major performance regression that happened recently that it is affecting all my sphinx builds: trying to compile stuff in parallel with SPHINXOPTS=-j5 is crashing with: # Loaded extensions: # kfigure (1.0.0) from /devel/v4l/patchwork/Documentation/sphinx/kfigure.py # kernel_include (1.0) from /devel/v4l/patchwork/Documentation/sphinx/kernel_include.py # rstFlatTable (1.0) from /devel/v4l/patchwork/Documentation/sphinx/rstFlatTable.py # cdomain (1.0) from /devel/v4l/patchwork/Documentation/sphinx/cdomain.py # kerneldoc (1.0) from /devel/v4l/patchwork/Documentation/sphinx/kerneldoc.py # alabaster (0.7.10) from /devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/alabaster/__init__.pyc # sphinx.ext.imgmath (1.4.9) from /devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/ext/imgmath.pyc Traceback (most recent call last): File "/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/cmdline.py", line 244, in main app.build(opts.force_all, filenames) File "/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/application.py", line 297, in build self.builder.build_update() File "/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 251, in build_update 'out of date' % len(to_build)) File "/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 265, in build self.doctreedir, self.app)) File "/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/environment.py", line 567, in update self._read_parallel(docnames, app, nproc=app.parallel) File "/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/environment.py", line 625, in _read_parallel tasks.join() File "/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/util/parallel.py", line 92, in join self._join_one() File "/devel/v4l/docs/sphinx_1.4/lib/python2.7/site-packages/sphinx/util/parallel.py", line 97, in _join_one exc, result = pipe.recv() EOFError I had to change my build scripts to remove parallel build, with increased *a lot* the building time. So, right now, I just go out to take a coffee or two when building documentation, as, without -j (even without this patch series), is really slow. If someone wants to look into it, the breakage happened by the time I upgraded to Fedora 27 and Kernel 4.14 was released. Yet, I'm using pip for Sphinx. So, I dunno what's the culprit. I didn't have time yet to investigate. > Applied, thanks. Thank you! 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 v4 0/3] doc: update printk documentation
On Thu, Dec 21, 2017 at 11:26:22AM -0800, Randy Dunlap wrote: > On 12/21/2017 11:21 AM, Jonathan Corbet wrote: > > On Wed, 20 Dec 2017 08:17:14 +1100 > > "Tobin C. Harding" wrote: > > > >> This set converts printk-formats.txt -> core-api/printk-formats.rst > >> > >> We also update the documentation around printing kernel addresses. > >> > >> This is my first documentation conversion. Please do be hard on this > >> patch series. I'd like to get it _really_ correct so that future > >> conversions will require less review effort. Also if there are any > >> peculiarities to patching docs (as apposed to C files) please say so. > >> > >> Thank you for the time already given to reviewing previous versions. > > > > So I spent a while thinking hard about how I could make Tobin do another > > round or two on these patches. But then I figure that it's the holidays, > > and I should just apply them. So that's done. Thanks for all of your > > work on this! > > > > That said... > > > > - I don't quite understand why you capitalize "kernel" everywhere. I > >vaguely recall some sort of discussion on that. To me it looks > >strange...oh well. > > Mauro explained that he capitalizes Kernel when it is being used as a > shortened version of "the Linux kernel," i.e., as a proper name, > so I think that Tobin appropriated that style. > > It would be OK to undo that IMO. I'm happy to write it however, if everyone is happy with 'kernel' everywhere then that is good (and easier). I think Mauro is correct but I also think Jon is correct, it does look funny. Code language doesn't always follow English grammar rules after all. thanks, Tobin. -- 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 v4 0/3] doc: update printk documentation
On Thu, Dec 21, 2017 at 12:21:41PM -0700, Jonathan Corbet wrote: > On Wed, 20 Dec 2017 08:17:14 +1100 > "Tobin C. Harding" wrote: > > > This set converts printk-formats.txt -> core-api/printk-formats.rst > > > > We also update the documentation around printing kernel addresses. > > > > This is my first documentation conversion. Please do be hard on this > > patch series. I'd like to get it _really_ correct so that future > > conversions will require less review effort. Also if there are any > > peculiarities to patching docs (as apposed to C files) please say so. > > > > Thank you for the time already given to reviewing previous versions. > > So I spent a while thinking hard about how I could make Tobin do another > round or two on these patches. But then I figure that it's the holidays, > and I should just apply them. So that's done. Thanks for all of your > work on this! Oh ok, I would have been happy to drag it over the holiday period and get it super correct. I'm always chasing perfection (even if seemingly a long way from it ;) so please never feel you have to rush things through. I'm happy to learn how to do it correctly and that will save everyone time in the future. > That said... I am happy also to patch on top of what was applied after Christmas break :) I don't want to create any extra work for anyone else. > - I don't quite understand why you capitalize "kernel" everywhere. I >vaguely recall some sort of discussion on that. To me it looks >strange...oh well. Ok, I'm going to go with 'kernel' everywhere from now on. Despite having two degrees I am particularly crap at English [grammar]. Please do pick me up on any mistakes no matter how trivial. That is the only way to learn IMO. > - There's a dangling reference to printk-formats.txt in lib/vsprintf.c >that we'll want to fix up. Bad Tobin, no biscuit. > - The vsprintf kerneldoc currently gets pulled into the big "kernel API" >dumpster. Someday, it would be nice to turn printk-formats.rst into a >"how to output data from the kernel" section, with documentation on >vnsprintf, printk, trace_printk, and format strings all in one place. >What a fine day that would be... I don't quite understand this yet. (I added to my kernel list of things to learn and work on ;) thanks Jon. Merry Christmas, Tobin. -- 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 0/2] mux: add overview and add to driver-api docs
On 2017-12-21 22:35, Jonathan Corbet wrote: > On Tue, 12 Dec 2017 09:46:31 +0100 > Peter Rosin wrote: > >> Changes since v1: >> - added a short introductory paragraph to mux.rst >> - added an entry in MAINTAINERS. >> >> I forgot to mention that this applies on top of linux-next, I suspect >> there will be a trivial conflict with an SPDX conversion in mux/core.c >> on Linus upstream. > > Sorry, I've had this just sitting here for a bit. Did you want me to take > both patches through the docs tree? I think that's going to be easiest, thanks! Let me know if you want me to rebase them to something w/o the SPDX change. Cheers, Peter -- 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
