Re: [PATCH] docs: Remove "could not extract kernel version" warning
On Mon, 11 Dec 2017, Randy Dunlap wrote:
> On 12/11/2017 02:24 PM, Jonathan Corbet wrote:
>> This warning will happen for every normal kernel docs build and doesn't
>> carry any useful information. Should anybody actually depend on this
>> "version" variable (which isn't clear to me), the "unknown version" value
>> will be clue enough.
>
> Yay. I looked at that last week and got nowhere with it.
The whole try block was for when sphinx-build is run directly, e.g. when
run by Read the Docs or manually on the command line. But looking at all
the Makefile sauce we've accumulated, we're probably way, *way* beyond
the point where building the docs is in any way feasible by running
sphinx-build directly.
The Makefile passes version and release on the sphinx-build command line
in our normal build, so we could just remove the try block
altogether. It's more like a fallback hack anyway.
The version shows up in the built documentation, depending on the theme.
Nothing wrong with this patch, but could go further.
BR,
Jani.
>
>> Signed-off-by: Jonathan Corbet
>> ---
>> Documentation/conf.py | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/Documentation/conf.py b/Documentation/conf.py
>> index 63857d33778c..62ac5a9f3a9f 100644
>> --- a/Documentation/conf.py
>> +++ b/Documentation/conf.py
>> @@ -88,7 +88,6 @@ finally:
>> if makefile_version and makefile_patchlevel:
>> version = release = makefile_version + '.' + makefile_patchlevel
>> else:
>> -sys.stderr.write('Warning: Could not extract kernel version\n')
>> version = release = "unknown version"
>>
>> # The language for content autogenerated by Sphinx. Refer to documentation
>>
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] arm64: v8.4: Support for new floating point multiplication instructions
ARM v8.4 extensions add new neon instructions for performing a
multiplication of each FP16 element of one vector with the corresponding
FP16 element of a second vector, and to add or subtract this without an
intermediate rounding to the corresponding FP32 element in a third vector.
This patch detects this feature and let the userspace know about it via a
HWCAP bit and MRS emulation.
Cc: Dave Martin
Cc: Suzuki K Poulose
Signed-off-by: Dongjiu Geng
---
Change since v1:
1. Address Dave and Suzuki's comments to update the commit message.
2. Address Dave's comments to update Documentation/arm64/elf_hwcaps.txt.
---
Documentation/arm64/cpu-feature-registers.txt | 4 +++-
Documentation/arm64/elf_hwcaps.txt| 4
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/include/uapi/asm/hwcap.h | 1 +
arch/arm64/kernel/cpufeature.c| 2 ++
arch/arm64/kernel/cpuinfo.c | 1 +
6 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm64/cpu-feature-registers.txt
b/Documentation/arm64/cpu-feature-registers.txt
index bd9b3fa..a70090b 100644
--- a/Documentation/arm64/cpu-feature-registers.txt
+++ b/Documentation/arm64/cpu-feature-registers.txt
@@ -110,7 +110,9 @@ infrastructure:
x--x
| Name | bits | visible |
|--|
- | RES0 | [63-48] |n|
+ | RES0 | [63-52] |n|
+ |--|
+ | FHM | [51-48] |y|
|--|
| DP | [47-44] |y|
|--|
diff --git a/Documentation/arm64/elf_hwcaps.txt
b/Documentation/arm64/elf_hwcaps.txt
index 89edba1..987c40e 100644
--- a/Documentation/arm64/elf_hwcaps.txt
+++ b/Documentation/arm64/elf_hwcaps.txt
@@ -158,3 +158,7 @@ HWCAP_SHA512
HWCAP_SVE
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
+
+HWCAP_FHM
+
+ Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 08cc885..1818077 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -419,6 +419,7 @@
#define SCTLR_EL1_CP15BEN (1 << 5)
/* id_aa64isar0 */
+#define ID_AA64ISAR0_FHM_SHIFT 48
#define ID_AA64ISAR0_DP_SHIFT 44
#define ID_AA64ISAR0_SM4_SHIFT 40
#define ID_AA64ISAR0_SM3_SHIFT 36
diff --git a/arch/arm64/include/uapi/asm/hwcap.h
b/arch/arm64/include/uapi/asm/hwcap.h
index cda76fa..f018c3d 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -43,5 +43,6 @@
#define HWCAP_ASIMDDP (1 << 20)
#define HWCAP_SHA512 (1 << 21)
#define HWCAP_SVE (1 << 22)
+#define HWCAP_ASIMDFHM (1 << 23)
#endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c5ba009..bc7e707 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -123,6 +123,7 @@ static int __init register_cpu_hwcaps_dumper(void)
* sync with the documentation of the CPU feature register ABI.
*/
static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
ID_AA64ISAR0_FHM_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
ID_AA64ISAR0_DP_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
ID_AA64ISAR0_SM4_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
ID_AA64ISAR0_SM3_SHIFT, 4, 0),
@@ -991,6 +992,7 @@ static bool has_no_fpsimd(const struct
arm64_cpu_capabilities *entry, int __unus
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED,
1, CAP_HWCAP, HWCAP_SM3),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED,
1, CAP_HWCAP, HWCAP_SM4),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1,
CAP_HWCAP, HWCAP_ASIMDDP),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED,
1, CAP_HWCAP, HWCAP_ASIMDFHM),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0,
CAP_HWCAP, HWCAP_FP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1,
CAP_HWCAP, HWCAP_FPHP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0,
CAP_HWCAP, HWCAP_ASIMD),
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 1e25545..7f94623 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -76,6 +76,7 @@
"asimddp",
"sha512",
"sve",
+ "asimdfhm",
NULL
};
--
1.9.1
-
Re: [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
On 2017/12/12 2:58, Suzuki K Poulose wrote: > Hi gengdongjiu > > Sorry for the late response. I have a similar patch to add the support for > "FHM", which I was about to post it this week. Suzuki, you are welcome. May be you can not post again to avoid the duplicate review, thanks! > > On 11/12/17 13:29, Dave Martin wrote: >> On Mon, Dec 11, 2017 at 08:47:00PM +0800, gengdongjiu wrote: >>> >>> On 2017/12/11 19:59, Dave P Martin wrote: On Sat, Dec 09, 2017 at 03:28:42PM +, Dongjiu Geng wrote: > ARM v8.4 extensions include support for new floating point > multiplication variant instructions to the AArch64 SIMD Do we have any human-readable description of what the new instructions do? Since the v8.4 spec itself only describes these as "New Floating Point Multiplication Variant", I wonder what "FHM" actually stands for. >>> Thanks for the point out. >>> In fact, this feature only adds two instructions: >>> FP16 * FP16 + FP32 >>> FP16 * FP16 - FP32 >>> >>> The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it >>> will call "FHM", I think call it "FMLXL" may be better, which can >>> stand for FMLAL/FMLSL instructions. >> >> Although "FHM" is cryptic, I think it makes sense to keep this as "FHM" >> to match the ISAR0 field name -- we've tended to follow this policy >> for other extension names unless there's a much better or more obvious >> name available. >> >> For "FMLXL", new instructions might be added in the future that match >> the same pattern, and then "FMLXL" could become ambiguous. So maybe >> this is not the best choice. > > I think the FHM stands for "FP Half precision Multiplication instructions". I > vote for keeping the feature bit in sync with the register bit definition. > i.e, FHM. agree with you > > However, my version of the patch names the HWCAP bit "asimdfml", following > the compiler name for the feature option "fp16fml", which > is not perfect either. I think FHM is the safe option here. yes, "FHM" is safe here. > >> Maybe something like "widening half-precision floating-point multiply accumulate" is acceptable wording consistent with the existing architecture, but I just made that up, so it's not official ;) >>> >>> how about something like "performing a multiplication of each FP16 >>> element of one vector with the corresponding FP16 element of a second >>> vector, and to add or subtract this without an intermediate rounding >>> to the corresponding FP32 element in a third vector."? >> >> We could have that, I guess. >> > > I agree, and that matches the feature description. Ok, thanks! > > -- 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: [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
On 2017/12/11 21:29, Dave Martin wrote: >> Thanks for the point out. >> In fact, this feature only adds two instructions: >> FP16 * FP16 + FP32 >> FP16 * FP16 - FP32 >> >> The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it >> will call "FHM", I think call it "FMLXL" may be better, which can >> stand for FMLAL/FMLSL instructions. > Although "FHM" is cryptic, I think it makes sense to keep this as "FHM" > to match the ISAR0 field name -- we've tended to follow this policy > for other extension names unless there's a much better or more obvious > name available Agree with you, I also think the "FHM" is better. > > For "FMLXL", new instructions might be added in the future that match > the same pattern, and then "FMLXL" could become ambiguous. So maybe > this is not the best choice. Ok. > >>> Maybe something like "widening half-precision floating-point multiply >>> accumulate" is acceptable wording consistent with the existing >>> architecture, but I just made that up, so it's not official ;) >> how about something like "performing a multiplication of each FP16 >> element of one vector with the corresponding FP16 element of a second >> vector, and to add or subtract this without an intermediate rounding >> to the corresponding FP32 element in a third vector."? > We could have that, I guess. Ok, thanks! > instructions set. Let the userspace know about it via a HWCAP bit and MRS emulation. -- 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 v10 00/13] Introduce framework for SLIMbus device driver
From: Srinivas Kandagatla SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used to communicate with peripheral components like audio-codec. SLIMbus uses Time-Division-Multiplexing to accommodate multiple data channels, and control channel. Control channel has messages to do device-enumeration, messages to send/receive control-data to/from SLIMbus devices, messages for port/channel management, and messages to do bandwidth allocation. Framework is introduced to support multiple instances of the bus (1 controller per bus), and multiple slave devices per controller. SPI and I2C frameworks, and comments from last time when I submitted the patches were referred-to while working on this framework. These patchsets introduce device-management, OF helpers, and messaging APIs, controller driver for Qualcomm's SLIMbus controller, and clock-pause feature for entering/exiting low-power mode for SLIMbus. Framework patches to do channel, port and bandwidth management are work-in-progress and will be sent out once these initial patches are accepted. These patchsets were tested on IFC6410 board with Qualcomm APQ8064 processor using the controller driver, and a WCD9310 codec. v9: https://lkml.org/lkml/2017/12/7/289 Changes from v9 to v10: * Added kernel-doc reference into slimbus driver api doc suggested by Jonathan Corbet Sagar Dharia (9): Documentation: Add SLIMbus summary dt-bindings: Add SLIMbus bindings slimbus: Add SLIMbus bus type slimbus: core: Add slim controllers support slimbus: Add messaging APIs to slimbus framework slimbus: Add support for 'clock-pause' feature dt-bindings: Add qcom slimbus controller bindings slimbus: qcom: Add Qualcomm Slimbus controller driver slimbus: qcom: Add runtime-pm support using clock-pause Srinivas Kandagatla (4): slimbus: core: add support to device tree helper regmap: add SLIMbus support slimbus: core: add common defines required for controllers MAINTAINERS: Add SLIMbus maintainer Documentation/devicetree/bindings/slimbus/bus.txt | 50 ++ .../devicetree/bindings/slimbus/slim-qcom-ctrl.txt | 39 ++ Documentation/driver-api/index.rst | 1 + Documentation/driver-api/slimbus.rst | 127 MAINTAINERS| 8 + drivers/Kconfig| 2 + drivers/Makefile | 1 + drivers/base/regmap/Kconfig| 4 + drivers/base/regmap/Makefile | 1 + drivers/base/regmap/regmap-slimbus.c | 80 +++ drivers/slimbus/Kconfig| 23 + drivers/slimbus/Makefile | 10 + drivers/slimbus/core.c | 480 + drivers/slimbus/messaging.c| 330 + drivers/slimbus/qcom-ctrl.c| 750 + drivers/slimbus/sched.c| 121 drivers/slimbus/slimbus.h | 261 +++ include/linux/mod_devicetable.h| 13 + include/linux/regmap.h | 18 + include/linux/slimbus.h| 164 + 20 files changed, 2483 insertions(+) create mode 100644 Documentation/devicetree/bindings/slimbus/bus.txt create mode 100644 Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt create mode 100644 Documentation/driver-api/slimbus.rst create mode 100644 drivers/base/regmap/regmap-slimbus.c create mode 100644 drivers/slimbus/Kconfig create mode 100644 drivers/slimbus/Makefile create mode 100644 drivers/slimbus/core.c create mode 100644 drivers/slimbus/messaging.c create mode 100644 drivers/slimbus/qcom-ctrl.c create mode 100644 drivers/slimbus/sched.c create mode 100644 drivers/slimbus/slimbus.h create mode 100644 include/linux/slimbus.h -- 2.15.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 02/13] dt-bindings: Add SLIMbus bindings
From: Sagar Dharia
SLIMbus (Serial Low Power Interchip Media Bus) is a specification
developed by MIPI (Mobile Industry Processor Interface) alliance.
SLIMbus is a 2-wire implementation, which is used to communicate with
peripheral components like audio-codec.
This patch adds device tree bindings for the slimbus.
Signed-off-by: Sagar Dharia
Signed-off-by: Srinivas Kandagatla
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/slimbus/bus.txt | 50 +++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/slimbus/bus.txt
diff --git a/Documentation/devicetree/bindings/slimbus/bus.txt
b/Documentation/devicetree/bindings/slimbus/bus.txt
new file mode 100644
index ..52fa6426388c
--- /dev/null
+++ b/Documentation/devicetree/bindings/slimbus/bus.txt
@@ -0,0 +1,50 @@
+SLIM(Serial Low Power Interchip Media Bus) bus
+
+SLIMbus is a 2-wire bus, and is used to communicate with peripheral
+components like audio-codec.
+
+Required property for SLIMbus controller node:
+- compatible - name of SLIMbus controller
+
+Child nodes:
+Every SLIMbus controller node can contain zero or more child nodes
+representing slave devices on the bus. Every SLIMbus slave device is
+uniquely determined by the enumeration address containing 4 fields:
+Manufacturer ID, Product code, Device index, and Instance value for
+the device.
+If child node is not present and it is instantiated after device
+discovery (slave device reporting itself present).
+
+In some cases it may be necessary to describe non-probeable device
+details such as non-standard ways of powering up a device. In
+such cases, child nodes for those devices will be present as
+slaves of the SLIMbus controller, as detailed below.
+
+Required property for SLIMbus child node if it is present:
+- reg - Should be ('Device index', 'Instance ID') from SLIMbus
+ Enumeration Address.
+ Device Index Uniquely identifies multiple Devices within
+ a single Component.
+ Instance ID Is for the cases where multiple Devices of the
+ same type or Class are attached to the bus.
+
+- compatible -"slimMID,PID". The textual representation of Manufacturer ID,
+ Product Code, shall be in lower case hexadecimal with leading
+ zeroes suppressed
+
+SLIMbus example for Qualcomm's slimbus manager component:
+
+ slim@2808 {
+ compatible = "qcom,apq8064-slim", "qcom,slim";
+ reg = <0x2808 0x2000>,
+ interrupts = <0 33 0>;
+ clocks = <&lcc SLIMBUS_SRC>, <&lcc AUDIO_SLIMBUS_CLK>;
+ clock-names = "iface", "core";
+ #address-cells = <2>;
+ #size-cell = <0>;
+
+ codec: wcd9310@1,0{
+ compatible = "slim217,60";
+ reg = <1 0>;
+ };
+ };
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 08/13] regmap: add SLIMbus support
From: Srinivas Kandagatla
This patch adds support to read/write SLIMbus value elements.
Currently it only supports byte read/write. Adding this support in
regmap would give codec drivers more flexibility when there are more
than 2 control interfaces like SLIMbus, i2c.
Without this patch each codec driver has to directly call SLIMbus value
element apis, and this could would get messy once we want to add i2c
interface to it.
Signed-off-by: Srinivas Kandagatla
---
drivers/base/regmap/Kconfig | 4 ++
drivers/base/regmap/Makefile | 1 +
drivers/base/regmap/regmap-slimbus.c | 80
include/linux/regmap.h | 18
4 files changed, 103 insertions(+)
create mode 100644 drivers/base/regmap/regmap-slimbus.c
diff --git a/drivers/base/regmap/Kconfig b/drivers/base/regmap/Kconfig
index 3a1535d812d8..cc162b48c6d7 100644
--- a/drivers/base/regmap/Kconfig
+++ b/drivers/base/regmap/Kconfig
@@ -21,6 +21,10 @@ config REGMAP_I2C
tristate
depends on I2C
+config REGMAP_SLIMBUS
+ tristate
+ depends on SLIMBUS
+
config REGMAP_SPI
tristate
depends on SPI
diff --git a/drivers/base/regmap/Makefile b/drivers/base/regmap/Makefile
index 0d298c446108..63dec9222892 100644
--- a/drivers/base/regmap/Makefile
+++ b/drivers/base/regmap/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_REGCACHE_COMPRESSED) += regcache-lzo.o
obj-$(CONFIG_DEBUG_FS) += regmap-debugfs.o
obj-$(CONFIG_REGMAP_AC97) += regmap-ac97.o
obj-$(CONFIG_REGMAP_I2C) += regmap-i2c.o
+obj-$(CONFIG_REGMAP_SLIMBUS) += regmap-slimbus.o
obj-$(CONFIG_REGMAP_SPI) += regmap-spi.o
obj-$(CONFIG_REGMAP_SPMI) += regmap-spmi.o
obj-$(CONFIG_REGMAP_MMIO) += regmap-mmio.o
diff --git a/drivers/base/regmap/regmap-slimbus.c
b/drivers/base/regmap/regmap-slimbus.c
new file mode 100644
index ..c90bee81d954
--- /dev/null
+++ b/drivers/base/regmap/regmap-slimbus.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, Linaro Ltd.
+
+#include
+#include
+#include
+
+#include "internal.h"
+
+static int regmap_slimbus_byte_reg_read(void *context, unsigned int reg,
+ unsigned int *val)
+{
+ struct slim_device *sdev = context;
+ int v;
+
+ v = slim_readb(sdev, reg);
+
+ if (v < 0)
+ return v;
+
+ *val = v;
+
+ return 0;
+}
+
+static int regmap_slimbus_byte_reg_write(void *context, unsigned int reg,
+unsigned int val)
+{
+ struct slim_device *sdev = context;
+
+ return slim_writeb(sdev, reg, val);
+}
+
+static struct regmap_bus regmap_slimbus_bus = {
+ .reg_write = regmap_slimbus_byte_reg_write,
+ .reg_read = regmap_slimbus_byte_reg_read,
+ .reg_format_endian_default = REGMAP_ENDIAN_LITTLE,
+ .val_format_endian_default = REGMAP_ENDIAN_LITTLE,
+};
+
+static const struct regmap_bus *regmap_get_slimbus(struct slim_device *slim,
+ const struct regmap_config *config)
+{
+ if (config->val_bits == 8 && config->reg_bits == 8)
+ return ®map_slimbus_bus;
+
+ return ERR_PTR(-ENOTSUPP);
+}
+
+struct regmap *__regmap_init_slimbus(struct slim_device *slimbus,
+const struct regmap_config *config,
+struct lock_class_key *lock_key,
+const char *lock_name)
+{
+ const struct regmap_bus *bus = regmap_get_slimbus(slimbus, config);
+
+ if (IS_ERR(bus))
+ return ERR_CAST(bus);
+
+ return __regmap_init(&slimbus->dev, bus, &slimbus->dev, config,
+lock_key, lock_name);
+}
+EXPORT_SYMBOL_GPL(__regmap_init_slimbus);
+
+struct regmap *__devm_regmap_init_slimbus(struct slim_device *slimbus,
+ const struct regmap_config *config,
+ struct lock_class_key *lock_key,
+ const char *lock_name)
+{
+ const struct regmap_bus *bus = regmap_get_slimbus(slimbus, config);
+
+ if (IS_ERR(bus))
+ return ERR_CAST(bus);
+
+ return __devm_regmap_init(&slimbus->dev, bus, &slimbus, config,
+ lock_key, lock_name);
+}
+EXPORT_SYMBOL_GPL(__devm_regmap_init_slimbus);
+
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 15eddc1353ba..b2207737a159 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -24,6 +24,7 @@ struct module;
struct device;
struct i2c_client;
struct irq_domain;
+struct slim_device;
struct spi_device;
struct spmi_device;
struct regmap;
@@ -499,6 +500,10 @@ struct regmap *__regmap_init_i2c(struct i2c_client *i2c,
const struct regmap_config *config,
struct lock_class_key *lock_key,
[PATCH v10 01/13] Documentation: Add SLIMbus summary
From: Sagar Dharia SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used to communicate with peripheral components like audio-codec. The summary of SLIMbus and API is documented in the 'summary' file. Signed-off-by: Sagar Dharia Signed-off-by: Srinivas Kandagatla --- Documentation/driver-api/index.rst | 1 + Documentation/driver-api/slimbus.rst | 127 +++ 2 files changed, 128 insertions(+) create mode 100644 Documentation/driver-api/slimbus.rst diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index d17a9876b473..ef7c9e0b179c 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -47,6 +47,7 @@ available subsections can be seen below. gpio misc_devices dmaengine/index + slimbus .. only:: subproject and html diff --git a/Documentation/driver-api/slimbus.rst b/Documentation/driver-api/slimbus.rst new file mode 100644 index ..7555ecd538de --- /dev/null +++ b/Documentation/driver-api/slimbus.rst @@ -0,0 +1,127 @@ + +Linux kernel SLIMbus support + + +Overview + + +What is SLIMbus? + +SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by +MIPI (Mobile Industry Processor Interface) alliance. The bus uses master/slave +configuration, and is a 2-wire multi-drop implementation (clock, and data). + +Currently, SLIMbus is used to interface between application processors of SoCs +(System-on-Chip) and peripheral components (typically codec). SLIMbus uses +Time-Division-Multiplexing to accommodate multiple data channels, and +a control channel. + +The control channel is used for various control functions such as bus +management, configuration and status updates. These messages can be unicast (e.g. +reading/writing device specific values), or multicast (e.g. data channel +reconfiguration sequence is a broadcast message announced to all devices) + +A data channel is used for data-transfer between 2 SLIMbus devices. Data +channel uses dedicated ports on the device. + +Hardware description: +- +SLIMbus specification has different types of device classifications based on +their capabilities. +A manager device is responsible for enumeration, configuration, and dynamic +channel allocation. Every bus has 1 active manager. + +A generic device is a device providing application functionality (e.g. codec). + +Framer device is responsible for clocking the bus, and transmitting frame-sync +and framing information on the bus. + +Each SLIMbus component has an interface device for monitoring physical layer. + +Typically each SoC contains SLIMbus component having 1 manager, 1 framer device, +1 generic device (for data channel support), and 1 interface device. +External peripheral SLIMbus component usually has 1 generic device (for +functionality/data channel support), and an associated interface device. +The generic device's registers are mapped as 'value elements' so that they can +be written/read using SLIMbus control channel exchanging control/status type of +information. +In case there are multiple framer devices on the same bus, manager device is +responsible to select the active-framer for clocking the bus. + +Per specification, SLIMbus uses "clock gears" to do power management based on +current frequency and bandwidth requirements. There are 10 clock gears and each +gear changes the SLIMbus frequency to be twice its previous gear. + +Each device has a 6-byte enumeration-address and the manager assigns every +device with a 1-byte logical address after the devices report presence on the +bus. + +Software description: +- +There are 2 types of SLIMbus drivers: + +slim_controller represents a 'controller' for SLIMbus. This driver should +implement duties needed by the SoC (manager device, associated +interface device for monitoring the layers and reporting errors, default +framer device). + +slim_device represents the 'generic device/component' for SLIMbus, and a +slim_driver should implement driver for that slim_device. + +Device notifications to the driver: +--- +Since SLIMbus devices have mechanisms for reporting their presence, the +framework allows drivers to bind when corresponding devices report their +presence on the bus. +However, it is possible that the driver needs to be probed +first so that it can enable corresponding SLIMbus device (e.g. power it up and/or +take it out of reset). To support that behavior, the framework allows drivers +to probe first as well (e.g. using standard DeviceTree compatibility field). +This creates the necessity for the driver to know when the device is functional +(i.e. reported present). device_up callback is used for that reason when the +devi
[PATCH v10 06/13] slimbus: Add messaging APIs to slimbus framework
From: Sagar Dharia
SLIMbus devices use value-element, and information elements to
control device parameters (e.g. value element is used to represent
gain for codec, information element is used to represent interrupt
status for codec when codec interrupt fires).
Messaging APIs are used to set/get these value and information
elements. SLIMbus specification uses 8-bit "transaction IDs" for
messages where a read-value is anticipated. Framework uses a table
of pointers to store those TIDs and responds back to the caller in
O(1).
Caller can do synchronous and asynchronous reads/writes.
Signed-off-by: Srinivas Kandagatla
---
drivers/slimbus/Makefile| 2 +-
drivers/slimbus/messaging.c | 297
drivers/slimbus/slimbus.h | 67 ++
include/linux/slimbus.h | 40 ++
4 files changed, 405 insertions(+), 1 deletion(-)
create mode 100644 drivers/slimbus/messaging.c
diff --git a/drivers/slimbus/Makefile b/drivers/slimbus/Makefile
index 506ff17d6346..568a14c7be78 100644
--- a/drivers/slimbus/Makefile
+++ b/drivers/slimbus/Makefile
@@ -3,4 +3,4 @@
# Makefile for kernel SLIMbus framework.
#
obj-$(CONFIG_SLIMBUS) += slimbus.o
-slimbus-y := core.o
+slimbus-y := core.o messaging.o
diff --git a/drivers/slimbus/messaging.c b/drivers/slimbus/messaging.c
new file mode 100644
index ..031e67648d7c
--- /dev/null
+++ b/drivers/slimbus/messaging.c
@@ -0,0 +1,297 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2011-2017, The Linux Foundation
+ */
+
+#include
+#include "slimbus.h"
+
+/**
+ * slim_msg_response() - Deliver Message response received from a device to the
+ * framework.
+ *
+ * @ctrl: Controller handle
+ * @reply: Reply received from the device
+ * @len: Length of the reply
+ * @tid: Transaction ID received with which framework can associate reply.
+ *
+ * Called by controller to inform framework about the response received.
+ * This helps in making the API asynchronous, and controller-driver doesn't
need
+ * to manage 1 more table other than the one managed by framework mapping TID
+ * with buffers
+ */
+void slim_msg_response(struct slim_controller *ctrl, u8 *reply, u8 tid, u8 len)
+{
+ struct slim_msg_txn *txn;
+ struct slim_val_inf *msg;
+ unsigned long flags;
+
+ spin_lock_irqsave(&ctrl->txn_lock, flags);
+ txn = idr_find(&ctrl->tid_idr, tid);
+ if (txn == NULL) {
+ spin_unlock_irqrestore(&ctrl->txn_lock, flags);
+ return;
+ }
+
+ msg = txn->msg;
+ if (msg == NULL || msg->rbuf == NULL) {
+ dev_err(ctrl->dev, "Got response to invalid TID:%d, len:%d\n",
+ tid, len);
+ return;
+ }
+
+ idr_remove(&ctrl->tid_idr, tid);
+ spin_unlock_irqrestore(&ctrl->txn_lock, flags);
+
+ memcpy(msg->rbuf, reply, len);
+ if (txn->comp)
+ complete(txn->comp);
+}
+EXPORT_SYMBOL_GPL(slim_msg_response);
+
+/**
+ * slim_do_transfer() - Process a SLIMbus-messaging transaction
+ *
+ * @ctrl: Controller handle
+ * @txn: Transaction to be sent over SLIMbus
+ *
+ * Called by controller to transmit messaging transactions not dealing with
+ * Interface/Value elements. (e.g. transmittting a message to assign logical
+ * address to a slave device
+ *
+ * Return: -ETIMEDOUT: If transmission of this message timed out
+ * (e.g. due to bus lines not being clocked or driven by controller)
+ */
+int slim_do_transfer(struct slim_controller *ctrl, struct slim_msg_txn *txn)
+{
+ DECLARE_COMPLETION_ONSTACK(done);
+ bool need_tid;
+ unsigned long flags;
+ int ret, tid, timeout;
+
+ need_tid = slim_tid_txn(txn->mt, txn->mc);
+
+ if (need_tid) {
+ spin_lock_irqsave(&ctrl->txn_lock, flags);
+ tid = idr_alloc(&ctrl->tid_idr, txn, 0,
+ SLIM_MAX_TIDS, GFP_KERNEL);
+ txn->tid = tid;
+
+ if (!txn->msg->comp)
+ txn->comp = &done;
+ else
+ txn->comp = txn->comp;
+
+ spin_unlock_irqrestore(&ctrl->txn_lock, flags);
+
+ if (tid < 0)
+ return tid;
+ }
+
+ ret = ctrl->xfer_msg(ctrl, txn);
+
+ if (ret && need_tid && !txn->msg->comp) {
+ unsigned long ms = txn->rl + HZ;
+
+ timeout = wait_for_completion_timeout(txn->comp,
+ msecs_to_jiffies(ms));
+ if (!timeout) {
+ ret = -ETIMEDOUT;
+ spin_lock_irqsave(&ctrl->txn_lock, flags);
+ idr_remove(&ctrl->tid_idr, tid);
+ spin_unlock_irqrestore(&ctrl->txn_lock, flags);
+ }
+ }
+
+ if (ret)
+ dev_err(ct
[PATCH v10 07/13] slimbus: Add support for 'clock-pause' feature
From: Sagar Dharia
Per SLIMbus specification, a reconfiguration sequence known as
'clock pause' needs to be broadcast over the bus while entering low-
power mode. Clock-pause is initiated by the controller driver.
To exit clock-pause, controller typically wakes up the framer device.
Since wakeup precedure is controller-specific, framework calls it via
controller's function pointer to invoke it.
Signed-off-by: Sagar Dharia
Signed-off-by: Srinivas Kandagatla
---
drivers/slimbus/Makefile| 2 +-
drivers/slimbus/core.c | 16 ++
drivers/slimbus/messaging.c | 35 -
drivers/slimbus/sched.c | 121
drivers/slimbus/slimbus.h | 53 +++
5 files changed, 225 insertions(+), 2 deletions(-)
create mode 100644 drivers/slimbus/sched.c
diff --git a/drivers/slimbus/Makefile b/drivers/slimbus/Makefile
index 568a14c7be78..cd6833ed521a 100644
--- a/drivers/slimbus/Makefile
+++ b/drivers/slimbus/Makefile
@@ -3,4 +3,4 @@
# Makefile for kernel SLIMbus framework.
#
obj-$(CONFIG_SLIMBUS) += slimbus.o
-slimbus-y := core.o messaging.o
+slimbus-y := core.o messaging.o sched.o
diff --git a/drivers/slimbus/core.c b/drivers/slimbus/core.c
index 1accb20ed5cd..4988a8f4d905 100644
--- a/drivers/slimbus/core.c
+++ b/drivers/slimbus/core.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include "slimbus.h"
@@ -218,6 +219,8 @@ int slim_register_controller(struct slim_controller *ctrl)
ida_init(&ctrl->laddr_ida);
idr_init(&ctrl->tid_idr);
mutex_init(&ctrl->lock);
+ mutex_init(&ctrl->sched.m_reconf);
+ init_completion(&ctrl->sched.pause_comp);
dev_dbg(ctrl->dev, "Bus [%s] registered:dev:%p\n",
ctrl->name, ctrl->dev);
@@ -249,6 +252,8 @@ int slim_unregister_controller(struct slim_controller *ctrl)
{
/* Remove all clients */
device_for_each_child(ctrl->dev, NULL, slim_ctrl_remove_device);
+ /* Enter Clock Pause */
+ slim_ctrl_clk_pause(ctrl, false, 0);
ida_simple_remove(&ctrl_ida, ctrl->id);
return 0;
@@ -416,6 +421,14 @@ int slim_device_report_present(struct slim_controller
*ctrl,
struct slim_device *sbdev;
int ret;
+ ret = pm_runtime_get_sync(ctrl->dev);
+
+ if (ctrl->sched.clk_state != SLIM_CLK_ACTIVE) {
+ dev_err(ctrl->dev, "slim ctrl not active,state:%d, ret:%d\n",
+ ctrl->sched.clk_state, ret);
+ goto slimbus_not_active;
+ }
+
sbdev = slim_get_device(ctrl, e_addr);
if (IS_ERR(sbdev))
return -ENODEV;
@@ -427,6 +440,9 @@ int slim_device_report_present(struct slim_controller *ctrl,
ret = slim_device_alloc_laddr(sbdev, true);
+slimbus_not_active:
+ pm_runtime_mark_last_busy(ctrl->dev);
+ pm_runtime_put_autosuspend(ctrl->dev);
return ret;
}
EXPORT_SYMBOL_GPL(slim_device_report_present);
diff --git a/drivers/slimbus/messaging.c b/drivers/slimbus/messaging.c
index 031e67648d7c..755462a4c75e 100644
--- a/drivers/slimbus/messaging.c
+++ b/drivers/slimbus/messaging.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include "slimbus.h"
/**
@@ -46,6 +47,10 @@ void slim_msg_response(struct slim_controller *ctrl, u8
*reply, u8 tid, u8 len)
memcpy(msg->rbuf, reply, len);
if (txn->comp)
complete(txn->comp);
+
+ /* Remove runtime-pm vote now that response was received for TID txn */
+ pm_runtime_mark_last_busy(ctrl->dev);
+ pm_runtime_put_autosuspend(ctrl->dev);
}
EXPORT_SYMBOL_GPL(slim_msg_response);
@@ -65,10 +70,29 @@ EXPORT_SYMBOL_GPL(slim_msg_response);
int slim_do_transfer(struct slim_controller *ctrl, struct slim_msg_txn *txn)
{
DECLARE_COMPLETION_ONSTACK(done);
- bool need_tid;
+ bool need_tid = false, clk_pause_msg = false;
unsigned long flags;
int ret, tid, timeout;
+ /*
+* do not vote for runtime-PM if the transactions are part of clock
+* pause sequence
+*/
+ if (ctrl->sched.clk_state == SLIM_CLK_ENTERING_PAUSE &&
+ (txn->mt == SLIM_MSG_MT_CORE &&
+txn->mc >= SLIM_MSG_MC_BEGIN_RECONFIGURATION &&
+txn->mc <= SLIM_MSG_MC_RECONFIGURE_NOW))
+ clk_pause_msg = true;
+
+ if (!clk_pause_msg) {
+ ret = pm_runtime_get_sync(ctrl->dev);
+ if (ctrl->sched.clk_state != SLIM_CLK_ACTIVE) {
+ dev_err(ctrl->dev, "ctrl wrong state:%d, ret:%d\n",
+ ctrl->sched.clk_state, ret);
+ goto slim_xfer_err;
+ }
+ }
+
need_tid = slim_tid_txn(txn->mt, txn->mc);
if (need_tid) {
@@ -107,6 +131,15 @@ int slim_do_transfer(struct slim_controller *ctrl, struct
slim_msg_txn *txn)
[PATCH v10 10/13] dt-bindings: Add qcom slimbus controller bindings
From: Sagar Dharia
This patch add device tree bindings for Qualcomm slimbus controller.
Signed-off-by: Sagar Dharia
Signed-off-by: Srinivas Kandagatla
Reviewed-by: Rob Herring
---
.../devicetree/bindings/slimbus/slim-qcom-ctrl.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
diff --git a/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
b/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
new file mode 100644
index ..922dcb8ff24a
--- /dev/null
+++ b/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
@@ -0,0 +1,39 @@
+Qualcomm SLIMbus controller
+This controller is used if applications processor driver controls SLIMbus
+master component.
+
+Required properties:
+
+ - #address-cells - refer to Documentation/devicetree/bindings/slimbus/bus.txt
+ - #size-cells - refer to Documentation/devicetree/bindings/slimbus/bus.txt
+
+ - reg : Offset and length of the register region(s) for the device
+ - reg-names : Register region name(s) referenced in reg above
+Required register resource entries are:
+"ctrl": Physical address of controller register blocks
+"slew": required for "qcom,apq8064-slim" SOC.
+ - compatible : should be "qcom,-slim" for SOC specific compatible
+ followed by "qcom,slim" for fallback.
+ - interrupts : Interrupt number used by this controller
+ - clocks : Interface and core clocks used by this SLIMbus controller
+ - clock-names : Required clock-name entries are:
+ "iface" : Interface clock for this controller
+ "core" : Interrupt for controller core's BAM
+
+Example:
+
+ slim@2808 {
+ compatible = "qcom,apq8064-slim", "qcom,slim";
+ reg = <0x2808 0x2000>, <0x80207C 4>;
+ reg-names = "ctrl", "slew";
+ interrupts = <0 33 0>;
+ clocks = <&lcc SLIMBUS_SRC>, <&lcc AUDIO_SLIMBUS_CLK>;
+ clock-names = "iface", "core";
+ #address-cells = <2>;
+ #size-cell = <0>;
+
+ wcd9310: audio-codec@1,0{
+ compatible = "slim217,60";
+ reg = <1 0>;
+ };
+ };
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 04/13] slimbus: core: Add slim controllers support
From: Sagar Dharia
This patch adds support to slim controllers in the slim core,
including some utility functions invoked by the controller and
slim device drivers.
Signed-off-by: Srinivas Kandagatla
---
drivers/slimbus/core.c| 306 ++
drivers/slimbus/slimbus.h | 108
include/linux/slimbus.h | 8 ++
3 files changed, 422 insertions(+)
create mode 100644 drivers/slimbus/slimbus.h
diff --git a/drivers/slimbus/core.c b/drivers/slimbus/core.c
index 02f5075a9309..ed53ae6bd1cc 100644
--- a/drivers/slimbus/core.c
+++ b/drivers/slimbus/core.c
@@ -7,7 +7,11 @@
#include
#include
#include
+#include
#include
+#include "slimbus.h"
+
+static DEFINE_IDA(ctrl_ida);
static const struct slim_device_id *slim_match(const struct slim_device_id *id,
const struct slim_device *sbdev)
@@ -92,6 +96,308 @@ void slim_driver_unregister(struct slim_driver *drv)
}
EXPORT_SYMBOL_GPL(slim_driver_unregister);
+static void slim_dev_release(struct device *dev)
+{
+ struct slim_device *sbdev = to_slim_device(dev);
+
+ kfree(sbdev);
+}
+
+static int slim_add_device(struct slim_controller *ctrl,
+ struct slim_device *sbdev,
+ struct device_node *node)
+{
+ sbdev->dev.bus = &slimbus_bus;
+ sbdev->dev.parent = ctrl->dev;
+ sbdev->dev.release = slim_dev_release;
+ sbdev->dev.driver = NULL;
+ sbdev->ctrl = ctrl;
+
+ dev_set_name(&sbdev->dev, "%x:%x:%x:%x",
+ sbdev->e_addr.manf_id,
+ sbdev->e_addr.prod_code,
+ sbdev->e_addr.dev_index,
+ sbdev->e_addr.instance);
+
+ return device_register(&sbdev->dev);
+}
+
+static struct slim_device *slim_alloc_device(struct slim_controller *ctrl,
+struct slim_eaddr *eaddr,
+struct device_node *node)
+{
+ struct slim_device *sbdev;
+ int ret;
+
+ sbdev = kzalloc(sizeof(*sbdev), GFP_KERNEL);
+ if (!sbdev)
+ return NULL;
+
+ sbdev->e_addr = *eaddr;
+ ret = slim_add_device(ctrl, sbdev, node);
+ if (ret) {
+ kfree(sbdev);
+ return NULL;
+ }
+
+ return sbdev;
+}
+
+/*
+ * slim_register_controller() - Controller bring-up and registration.
+ *
+ * @ctrl: Controller to be registered.
+ *
+ * A controller is registered with the framework using this API.
+ * If devices on a controller were registered before controller,
+ * this will make sure that they get probed when controller is up
+ */
+int slim_register_controller(struct slim_controller *ctrl)
+{
+ int id;
+
+ id = ida_simple_get(&ctrl_ida, 0, 0, GFP_KERNEL);
+ if (id < 0)
+ return id;
+
+ ctrl->id = id;
+
+ if (!ctrl->min_cg)
+ ctrl->min_cg = SLIM_MIN_CLK_GEAR;
+ if (!ctrl->max_cg)
+ ctrl->max_cg = SLIM_MAX_CLK_GEAR;
+
+ ida_init(&ctrl->laddr_ida);
+ idr_init(&ctrl->tid_idr);
+ mutex_init(&ctrl->lock);
+
+ dev_dbg(ctrl->dev, "Bus [%s] registered:dev:%p\n",
+ ctrl->name, ctrl->dev);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(slim_register_controller);
+
+/* slim_remove_device: Remove the effect of slim_add_device() */
+static void slim_remove_device(struct slim_device *sbdev)
+{
+ device_unregister(&sbdev->dev);
+}
+
+static int slim_ctrl_remove_device(struct device *dev, void *null)
+{
+ slim_remove_device(to_slim_device(dev));
+ return 0;
+}
+
+/**
+ * slim_unregister_controller() - Controller tear-down.
+ *
+ * @ctrl: Controller to tear-down.
+ */
+int slim_unregister_controller(struct slim_controller *ctrl)
+{
+ /* Remove all clients */
+ device_for_each_child(ctrl->dev, NULL, slim_ctrl_remove_device);
+ ida_simple_remove(&ctrl_ida, ctrl->id);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(slim_unregister_controller);
+
+static void slim_device_update_status(struct slim_device *sbdev,
+ enum slim_device_status status)
+{
+ struct slim_driver *sbdrv;
+
+ if (sbdev->status == status)
+ return;
+
+ sbdev->status = status;
+ if (!sbdev->dev.driver)
+ return;
+
+ sbdrv = to_slim_driver(sbdev->dev.driver);
+ if (sbdrv->device_status)
+ sbdrv->device_status(sbdev, sbdev->status);
+}
+
+/**
+ * slim_report_absent() - Controller calls this function when a device
+ * reports absent, OR when the device cannot be communicated with
+ *
+ * @sbdev: Device that cannot be reached, or sent report absent
+ */
+void slim_report_absent(struct slim_device *sbdev)
+{
+ struct slim_controller *ctrl = sbdev->ctrl;
+
+ if (!ctrl)
+ return;
+
+ /* invalidate
[PATCH v10 05/13] slimbus: core: add support to device tree helper
From: Srinivas Kandagatla
This patch adds support to parse slim devices from device tree.
Signed-off-by: Srinivas Kandagatla
---
drivers/slimbus/core.c | 50 ++
1 file changed, 50 insertions(+)
diff --git a/drivers/slimbus/core.c b/drivers/slimbus/core.c
index ed53ae6bd1cc..1accb20ed5cd 100644
--- a/drivers/slimbus/core.c
+++ b/drivers/slimbus/core.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include "slimbus.h"
@@ -113,6 +114,9 @@ static int slim_add_device(struct slim_controller *ctrl,
sbdev->dev.driver = NULL;
sbdev->ctrl = ctrl;
+ if (node)
+ sbdev->dev.of_node = of_node_get(node);
+
dev_set_name(&sbdev->dev, "%x:%x:%x:%x",
sbdev->e_addr.manf_id,
sbdev->e_addr.prod_code,
@@ -143,6 +147,50 @@ static struct slim_device *slim_alloc_device(struct
slim_controller *ctrl,
return sbdev;
}
+static void of_register_slim_devices(struct slim_controller *ctrl)
+{
+ struct device *dev = ctrl->dev;
+ struct device_node *node;
+
+ if (!ctrl->dev->of_node)
+ return;
+
+ for_each_child_of_node(ctrl->dev->of_node, node) {
+ struct slim_device *sbdev;
+ struct slim_eaddr e_addr;
+ const char *compat = NULL;
+ int reg[2], ret;
+ int manf_id, prod_code;
+
+ compat = of_get_property(node, "compatible", NULL);
+ if (!compat)
+ continue;
+
+ ret = sscanf(compat, "slim%x,%x", &manf_id, &prod_code);
+ if (ret != 2) {
+ dev_err(dev, "Manf ID & Product code not found %s\n",
+ compat);
+ continue;
+ }
+
+ ret = of_property_read_u32_array(node, "reg", reg, 2);
+ if (ret) {
+ dev_err(dev, "Device and Instance id not found:%d\n",
+ ret);
+ continue;
+ }
+
+ e_addr.dev_index = reg[0];
+ e_addr.instance = reg[1];
+ e_addr.manf_id = manf_id;
+ e_addr.prod_code = prod_code;
+
+ sbdev = slim_alloc_device(ctrl, &e_addr, node);
+ if (!sbdev)
+ continue;
+ }
+}
+
/*
* slim_register_controller() - Controller bring-up and registration.
*
@@ -174,6 +222,8 @@ int slim_register_controller(struct slim_controller *ctrl)
dev_dbg(ctrl->dev, "Bus [%s] registered:dev:%p\n",
ctrl->name, ctrl->dev);
+ of_register_slim_devices(ctrl);
+
return 0;
}
EXPORT_SYMBOL_GPL(slim_register_controller);
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 09/13] slimbus: core: add common defines required for controllers
From: Srinivas Kandagatla
This patch adds some common constant defines which are required
for qcom slim controller driver.
Signed-off-by: Srinivas Kandagatla
---
drivers/slimbus/slimbus.h | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/slimbus/slimbus.h b/drivers/slimbus/slimbus.h
index db089134f673..79f8e05d92dd 100644
--- a/drivers/slimbus/slimbus.h
+++ b/drivers/slimbus/slimbus.h
@@ -11,9 +11,38 @@
#include
#include
+/* Standard values per SLIMbus spec needed by controllers and devices */
+#define SLIM_CL_PER_SUPERFRAME 6144
+#define SLIM_CL_PER_SUPERFRAME_DIV8(SLIM_CL_PER_SUPERFRAME >> 3)
+
/* SLIMbus message types. Related to interpretation of message code. */
#define SLIM_MSG_MT_CORE 0x0
+/*
+ * SLIM Broadcast header format
+ * BYTE 0: MT[7:5] RL[4:0]
+ * BYTE 1: RSVD[7] MC[6:0]
+ * BYTE 2: RSVD[7:6] DT[5:4] PI[3:0]
+ */
+#define SLIM_MSG_MT_MASK GENMASK(2, 0)
+#define SLIM_MSG_MT_SHIFT 5
+#define SLIM_MSG_RL_MASK GENMASK(4, 0)
+#define SLIM_MSG_RL_SHIFT 0
+#define SLIM_MSG_MC_MASK GENMASK(6, 0)
+#define SLIM_MSG_MC_SHIFT 0
+#define SLIM_MSG_DT_MASK GENMASK(1, 0)
+#define SLIM_MSG_DT_SHIFT 4
+
+#define SLIM_HEADER_GET_MT(b) ((b >> SLIM_MSG_MT_SHIFT) & SLIM_MSG_MT_MASK)
+#define SLIM_HEADER_GET_RL(b) ((b >> SLIM_MSG_RL_SHIFT) & SLIM_MSG_RL_MASK)
+#define SLIM_HEADER_GET_MC(b) ((b >> SLIM_MSG_MC_SHIFT) & SLIM_MSG_MC_MASK)
+#define SLIM_HEADER_GET_DT(b) ((b >> SLIM_MSG_DT_SHIFT) & SLIM_MSG_DT_MASK)
+
+/* Device management messages used by this framework */
+#define SLIM_MSG_MC_REPORT_PRESENT 0x1
+#define SLIM_MSG_MC_ASSIGN_LOGICAL_ADDRESS 0x2
+#define SLIM_MSG_MC_REPORT_ABSENT0xF
+
/* Clock pause Reconfiguration messages */
#define SLIM_MSG_MC_BEGIN_RECONFIGURATION0x40
#define SLIM_MSG_MC_NEXT_PAUSE_CLOCK 0x4A
@@ -94,6 +123,10 @@ struct slim_msg_txn {
#define DEFINE_SLIM_BCAST_TXN(name, mc, rl, la, msg) \
struct slim_msg_txn name = { rl, 0, mc, SLIM_MSG_DEST_BROADCAST, 0,\
0, la, msg, }
+
+#define DEFINE_SLIM_EDEST_TXN(name, mc, rl, la, msg) \
+ struct slim_msg_txn name = { rl, 0, mc, SLIM_MSG_DEST_ENUMADDR, 0,\
+ 0, la, msg, }
/**
* enum slim_clk_state: SLIMbus controller's clock state used internally for
* maintaining current clock state.
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 11/13] slimbus: qcom: Add Qualcomm Slimbus controller driver
From: Sagar Dharia
This controller driver programs manager, interface, and framer
devices for Qualcomm's slimbus HW block.
Manager component currently implements logical address setting,
and messaging interface.
Interface device reports bus synchronization information, and framer
device clocks the bus from the time it's woken up, until clock-pause
is executed by the manager device.
Signed-off-by: Sagar Dharia
Signed-off-by: Srinivas Kandagatla
---
drivers/slimbus/Kconfig | 6 +
drivers/slimbus/Makefile| 4 +
drivers/slimbus/qcom-ctrl.c | 655
3 files changed, 665 insertions(+)
create mode 100644 drivers/slimbus/qcom-ctrl.c
diff --git a/drivers/slimbus/Kconfig b/drivers/slimbus/Kconfig
index 9b6bb84d66ed..78bdd4808282 100644
--- a/drivers/slimbus/Kconfig
+++ b/drivers/slimbus/Kconfig
@@ -13,5 +13,11 @@ menuconfig SLIMBUS
if SLIMBUS
# SLIMbus controllers
+config SLIM_QCOM_CTRL
+ tristate "Qualcomm SLIMbus Manager Component"
+ depends on SLIMBUS
+ help
+ Select driver if Qualcomm's SLIMbus Manager Component is
+ programmed using Linux kernel.
endif
diff --git a/drivers/slimbus/Makefile b/drivers/slimbus/Makefile
index cd6833ed521a..a35a3da4eb78 100644
--- a/drivers/slimbus/Makefile
+++ b/drivers/slimbus/Makefile
@@ -4,3 +4,7 @@
#
obj-$(CONFIG_SLIMBUS) += slimbus.o
slimbus-y := core.o messaging.o sched.o
+
+#Controllers
+obj-$(CONFIG_SLIM_QCOM_CTRL) += slim-qcom-ctrl.o
+slim-qcom-ctrl-y := qcom-ctrl.o
diff --git a/drivers/slimbus/qcom-ctrl.c b/drivers/slimbus/qcom-ctrl.c
new file mode 100644
index ..ace85ce3de90
--- /dev/null
+++ b/drivers/slimbus/qcom-ctrl.c
@@ -0,0 +1,655 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2011-2017, The Linux Foundation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "slimbus.h"
+
+/* Manager registers */
+#defineMGR_CFG 0x200
+#defineMGR_STATUS 0x204
+#defineMGR_INT_EN 0x210
+#defineMGR_INT_STAT0x214
+#defineMGR_INT_CLR 0x218
+#defineMGR_TX_MSG 0x230
+#defineMGR_RX_MSG 0x270
+#defineMGR_IE_STAT 0x2F0
+#defineMGR_VE_STAT 0x300
+#defineMGR_CFG_ENABLE 1
+
+/* Framer registers */
+#defineFRM_CFG 0x400
+#defineFRM_STAT0x404
+#defineFRM_INT_EN 0x410
+#defineFRM_INT_STAT0x414
+#defineFRM_INT_CLR 0x418
+#defineFRM_WAKEUP 0x41C
+#defineFRM_CLKCTL_DONE 0x420
+#defineFRM_IE_STAT 0x430
+#defineFRM_VE_STAT 0x440
+
+/* Interface registers */
+#defineINTF_CFG0x600
+#defineINTF_STAT 0x604
+#defineINTF_INT_EN 0x610
+#defineINTF_INT_STAT 0x614
+#defineINTF_INT_CLR0x618
+#defineINTF_IE_STAT0x630
+#defineINTF_VE_STAT0x640
+
+/* Interrupt status bits */
+#defineMGR_INT_TX_NACKED_2 BIT(25)
+#defineMGR_INT_MSG_BUF_CONTE BIT(26)
+#defineMGR_INT_RX_MSG_RCVD BIT(30)
+#defineMGR_INT_TX_MSG_SENT BIT(31)
+
+/* Framer config register settings */
+#defineFRM_ACTIVE 1
+#defineCLK_GEAR7
+#defineROOT_FREQ 11
+#defineREF_CLK_GEAR15
+#defineINTR_WAKE 19
+
+#define SLIM_MSG_ASM_FIRST_WORD(l, mt, mc, dt, ad) \
+ ((l) | ((mt) << 5) | ((mc) << 8) | ((dt) << 15) | ((ad) << 16))
+
+#define SLIM_ROOT_FREQ 24576000
+
+/* MAX message size over control channel */
+#define SLIM_MSGQ_BUF_LEN 40
+#define QCOM_TX_MSGS 2
+#define QCOM_RX_MSGS 8
+#define QCOM_BUF_ALLOC_RETRIES 10
+
+#define CFG_PORT(r, v) ((v) ? CFG_PORT_V2(r) : CFG_PORT_V1(r))
+
+/* V2 Component registers */
+#define CFG_PORT_V2(r) ((r ## _V2))
+#defineCOMP_CFG_V2 4
+#defineCOMP_TRUST_CFG_V2 0x3000
+
+/* V1 Component registers */
+#define CFG_PORT_V1(r) ((r ## _V1))
+#defineCOMP_CFG_V1 0
+#defineCOMP_TRUST_CFG_V1 0x14
+
+/* Resource group info for manager, and non-ported generic device-components */
+#define EE_MGR_RSC_GRP (1 << 10)
+#define EE_NGD_2 (2 << 6)
+#define EE_NGD_1 0
+
+struct slim_ctrl_buf {
+ void*base;
+ phys_addr_t phy;
+ spinlock_t lock;
+ int head;
+ int tail;
+ int sl_sz;
+ int n;
+};
+
+struct qcom_slim_ctrl {
+ struct slim_controller ctrl;
+ struct slim_framer framer;
+ struct device *dev;
+ void __iomem*base;
+ void __iomem*slew_reg;
+
+ struct slim_ctrl_bufrx;
+ struct slim_ctrl_buftx;
+
+ struct completi
[PATCH v10 03/13] slimbus: Add SLIMbus bus type
From: Sagar Dharia
SLIMbus (Serial Low Power Interchip Media Bus) is a specification
developed by MIPI (Mobile Industry Processor Interface) alliance.
SLIMbus is a 2-wire implementation, which is used to communicate with
peripheral components like audio-codec.
SLIMbus uses Time-Division-Multiplexing to accommodate multiple data
channels, and control channel. Control channel has messages to do
device-enumeration, messages to send/receive control-data to/from
SLIMbus devices, messages for port/channel management, and messages to
do bandwidth allocation.
The framework supports multiple instances of the bus (1 controller per
bus), and multiple slave devices per controller.
This patch adds support to basic silmbus core which includes support to
SLIMbus type, slimbus device registeration and some basic data structures.
Signed-off-by: Sagar Dharia
Signed-off-by: Srinivas Kandagatla
---
drivers/Kconfig | 2 +
drivers/Makefile| 1 +
drivers/slimbus/Kconfig | 17 ++
drivers/slimbus/Makefile| 6 +++
drivers/slimbus/core.c | 108 +
include/linux/mod_devicetable.h | 13 +
include/linux/slimbus.h | 116
7 files changed, 263 insertions(+)
create mode 100644 drivers/slimbus/Kconfig
create mode 100644 drivers/slimbus/Makefile
create mode 100644 drivers/slimbus/core.c
create mode 100644 include/linux/slimbus.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 152744c5ef0f..c8e1d1c3f426 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -211,4 +211,6 @@ source "drivers/mux/Kconfig"
source "drivers/opp/Kconfig"
+source "drivers/slimbus/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 1d034b680431..d233a95b3b24 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_MTD) += mtd/
obj-$(CONFIG_SPI) += spi/
obj-$(CONFIG_SPMI) += spmi/
obj-$(CONFIG_HSI) += hsi/
+obj-$(CONFIG_SLIMBUS) += slimbus/
obj-y += net/
obj-$(CONFIG_ATM) += atm/
obj-$(CONFIG_FUSION) += message/
diff --git a/drivers/slimbus/Kconfig b/drivers/slimbus/Kconfig
new file mode 100644
index ..9b6bb84d66ed
--- /dev/null
+++ b/drivers/slimbus/Kconfig
@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# SLIMbus driver configuration
+#
+menuconfig SLIMBUS
+ tristate "SLIMbus support"
+ help
+ SLIMbus is standard interface between System-on-Chip and audio codec,
+ and other peripheral components in typical embedded systems.
+
+ If unsure, choose N.
+
+if SLIMBUS
+
+# SLIMbus controllers
+
+endif
diff --git a/drivers/slimbus/Makefile b/drivers/slimbus/Makefile
new file mode 100644
index ..506ff17d6346
--- /dev/null
+++ b/drivers/slimbus/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for kernel SLIMbus framework.
+#
+obj-$(CONFIG_SLIMBUS) += slimbus.o
+slimbus-y := core.o
diff --git a/drivers/slimbus/core.c b/drivers/slimbus/core.c
new file mode 100644
index ..02f5075a9309
--- /dev/null
+++ b/drivers/slimbus/core.c
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2011-2017, The Linux Foundation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static const struct slim_device_id *slim_match(const struct slim_device_id *id,
+ const struct slim_device *sbdev)
+{
+ while (id->manf_id != 0 || id->prod_code != 0) {
+ if (id->manf_id == sbdev->e_addr.manf_id &&
+ id->prod_code == sbdev->e_addr.prod_code)
+ return id;
+ id++;
+ }
+ return NULL;
+}
+
+static int slim_device_match(struct device *dev, struct device_driver *drv)
+{
+ struct slim_device *sbdev = to_slim_device(dev);
+ struct slim_driver *sbdrv = to_slim_driver(drv);
+
+ return !!slim_match(sbdrv->id_table, sbdev);
+}
+
+static int slim_device_probe(struct device *dev)
+{
+ struct slim_device *sbdev = to_slim_device(dev);
+ struct slim_driver *sbdrv = to_slim_driver(dev->driver);
+
+ return sbdrv->probe(sbdev);
+}
+
+static int slim_device_remove(struct device *dev)
+{
+ struct slim_device *sbdev = to_slim_device(dev);
+ struct slim_driver *sbdrv;
+
+ if (dev->driver) {
+ sbdrv = to_slim_driver(dev->driver);
+ if (sbdrv->remove)
+ sbdrv->remove(sbdev);
+ }
+
+ return 0;
+}
+
+struct bus_type slimbus_bus = {
+ .name = "slimbus",
+ .match = slim_device_match,
+ .probe = slim_device_probe,
+ .remove = slim_device_remove,
+};
+EXPORT_SYMBOL_GPL(slimbus_bus);
+
+/*
+ * __slim_driv
[PATCH v10 13/13] MAINTAINERS: Add SLIMbus maintainer
From: Srinivas Kandagatla Add myself as maintainer for slimbus. Signed-off-by: Srinivas Kandagatla Acked-by: Bjorn Andersson --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index aa71ab52fd76..f26bf2707709 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12500,6 +12500,14 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git F: include/linux/srcu.h F: kernel/rcu/srcu.c +SERIAL LOW-POWER INTER-CHIP MEDIA BUS (SLIMbus) +M: Srinivas Kandagatla +L: alsa-de...@alsa-project.org (moderated for non-subscribers) +S: Maintained +F: drivers/slimbus/ +F: Documentation/devicetree/bindings/slimbus/ +F: include/linux/slimbus.h + SMACK SECURITY MODULE M: Casey Schaufler L: linux-security-mod...@vger.kernel.org -- 2.15.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 12/13] slimbus: qcom: Add runtime-pm support using clock-pause
From: Sagar Dharia
Slimbus HW mandates that clock-pause sequence has to be executed
before disabling relevant interface and core clocks.
Runtime-PM's autosuspend feature is used here to enter/exit low
power mode for Qualcomm's Slimbus controller. Autosuspend feature
enables driver to avoid changing power-modes too frequently since
entering clock-pause is an expensive sequence
Signed-off-by: Sagar Dharia
Signed-off-by: Srinivas Kandagatla
---
drivers/slimbus/qcom-ctrl.c | 101 ++--
1 file changed, 98 insertions(+), 3 deletions(-)
diff --git a/drivers/slimbus/qcom-ctrl.c b/drivers/slimbus/qcom-ctrl.c
index ace85ce3de90..35ad70dbfe3a 100644
--- a/drivers/slimbus/qcom-ctrl.c
+++ b/drivers/slimbus/qcom-ctrl.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "slimbus.h"
/* Manager registers */
@@ -65,6 +66,7 @@
((l) | ((mt) << 5) | ((mc) << 8) | ((dt) << 15) | ((ad) << 16))
#define SLIM_ROOT_FREQ 24576000
+#define QCOM_SLIM_AUTOSUSPEND 1000
/* MAX message size over control channel */
#define SLIM_MSGQ_BUF_LEN 40
@@ -275,6 +277,30 @@ static irqreturn_t qcom_slim_interrupt(int irq, void *d)
return ret;
}
+static int qcom_clk_pause_wakeup(struct slim_controller *sctrl)
+{
+ struct qcom_slim_ctrl *ctrl = dev_get_drvdata(sctrl->dev);
+
+ clk_prepare_enable(ctrl->hclk);
+ clk_prepare_enable(ctrl->rclk);
+ enable_irq(ctrl->irq);
+
+ writel_relaxed(1, ctrl->base + FRM_WAKEUP);
+ /* Make sure framer wakeup write goes through before ISR fires */
+ mb();
+ /*
+* HW Workaround: Currently, slave is reporting lost-sync messages
+* after SLIMbus comes out of clock pause.
+* Transaction with slave fail before slave reports that message
+* Give some time for that report to come
+* SLIMbus wakes up in clock gear 10 at 24.576MHz. With each superframe
+* being 250 usecs, we wait for 5-10 superframes here to ensure
+* we get the message
+*/
+ usleep_range(1250, 2500);
+ return 0;
+}
+
void *slim_alloc_txbuf(struct qcom_slim_ctrl *ctrl, struct slim_msg_txn *txn,
struct completion *done)
{
@@ -511,6 +537,7 @@ static int qcom_slim_probe(struct platform_device *pdev)
sctrl->set_laddr = qcom_set_laddr;
sctrl->xfer_msg = qcom_xfer_msg;
+ sctrl->wakeup = qcom_clk_pause_wakeup;
ctrl->tx.n = QCOM_TX_MSGS;
ctrl->tx.sl_sz = SLIM_MSGQ_BUF_LEN;
ctrl->rx.n = QCOM_RX_MSGS;
@@ -618,14 +645,81 @@ static int qcom_slim_remove(struct platform_device *pdev)
{
struct qcom_slim_ctrl *ctrl = platform_get_drvdata(pdev);
- disable_irq(ctrl->irq);
- clk_disable_unprepare(ctrl->hclk);
- clk_disable_unprepare(ctrl->rclk);
+ pm_runtime_disable(&pdev->dev);
slim_unregister_controller(&ctrl->ctrl);
destroy_workqueue(ctrl->rxwq);
return 0;
}
+/*
+ * If PM_RUNTIME is not defined, these 2 functions become helper
+ * functions to be called from system suspend/resume.
+ */
+#ifdef CONFIG_PM
+static int qcom_slim_runtime_suspend(struct device *device)
+{
+ struct platform_device *pdev = to_platform_device(device);
+ struct qcom_slim_ctrl *ctrl = platform_get_drvdata(pdev);
+ int ret;
+
+ dev_dbg(device, "pm_runtime: suspending...\n");
+ ret = slim_ctrl_clk_pause(&ctrl->ctrl, false, SLIM_CLK_UNSPECIFIED);
+ if (ret) {
+ dev_err(device, "clk pause not entered:%d", ret);
+ } else {
+ disable_irq(ctrl->irq);
+ clk_disable_unprepare(ctrl->hclk);
+ clk_disable_unprepare(ctrl->rclk);
+ }
+ return ret;
+}
+
+static int qcom_slim_runtime_resume(struct device *device)
+{
+ struct platform_device *pdev = to_platform_device(device);
+ struct qcom_slim_ctrl *ctrl = platform_get_drvdata(pdev);
+ int ret = 0;
+
+ dev_dbg(device, "pm_runtime: resuming...\n");
+ ret = slim_ctrl_clk_pause(&ctrl->ctrl, true, 0);
+ if (ret)
+ dev_err(device, "clk pause not exited:%d", ret);
+ return ret;
+}
+#endif
+
+#ifdef CONFIG_PM_SLEEP
+static int qcom_slim_suspend(struct device *dev)
+{
+ int ret = 0;
+
+ if (!pm_runtime_enabled(dev) ||
+ (!pm_runtime_suspended(dev))) {
+ dev_dbg(dev, "system suspend");
+ ret = qcom_slim_runtime_suspend(dev);
+ }
+
+ return ret;
+}
+
+static int qcom_slim_resume(struct device *dev)
+{
+ if (!pm_runtime_enabled(dev) || !pm_runtime_suspended(dev)) {
+ int ret;
+
+ dev_dbg(dev, "system resume");
+ ret = qcom_slim_runtime_resume(dev);
+ if (!ret) {
+ pm_runtime_mark_last_busy(dev);
+ pm_request_autosuspend(dev);
+ }
+ return ret;
+
+ }
+
Re: [PATCH v9 01/13] Documentation: Add SLIMbus summary
On Thu, 7 Dec 2017 23:22:51 + Srinivas Kandagatla wrote: > > It seems you have kerneldoc comments for your data structures and at least > > some of your exported symbols. If you really want to document this stuff > > well, I'd suggest finishing out those comments, then pulling them into the > > documentation in the appropriate places. > Am sure all the exported symbols have kernel doc, I will pull them into > relevant sub sections. > > Do you think something like this http://paste.ubuntu.com/26135862/ makes > sense? At a first glance it looks good to me. 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] i2c: update i2c-dev.h warning in documentation
On Sat, 9 Dec 2017 23:10:58 +0300
Cengiz Can wrote:
> `dev-interface` document gives examples for accessing i2c from
> userspace.
>
> There's a note warning developers about the different `i2c-dev.h` header
> files which were shipped with the kernel and i2c-tools separately.
>
> However, these commits in i2c-tools repository suggests that the header
> files are now identical (in functionality) and `i2c_*` 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
So this seems like a worthwhile change, but the patch contains a number of
unrelated changes, mostly white-space stuff it seems. Can you clean that
up and resend?
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: Remove "could not extract kernel version" warning
On 12/11/2017 02:24 PM, Jonathan Corbet wrote:
> This warning will happen for every normal kernel docs build and doesn't
> carry any useful information. Should anybody actually depend on this
> "version" variable (which isn't clear to me), the "unknown version" value
> will be clue enough.
Yay. I looked at that last week and got nowhere with it.
> Signed-off-by: Jonathan Corbet
> ---
> Documentation/conf.py | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index 63857d33778c..62ac5a9f3a9f 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -88,7 +88,6 @@ finally:
> if makefile_version and makefile_patchlevel:
> version = release = makefile_version + '.' + makefile_patchlevel
> else:
> -sys.stderr.write('Warning: Could not extract kernel version\n')
> version = release = "unknown version"
>
> # The language for content autogenerated by Sphinx. Refer to documentation
>
--
~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
[PATCH] docs: Remove "could not extract kernel version" warning
This warning will happen for every normal kernel docs build and doesn't
carry any useful information. Should anybody actually depend on this
"version" variable (which isn't clear to me), the "unknown version" value
will be clue enough.
Signed-off-by: Jonathan Corbet
---
Documentation/conf.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 63857d33778c..62ac5a9f3a9f 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -88,7 +88,6 @@ finally:
if makefile_version and makefile_patchlevel:
version = release = makefile_version + '.' + makefile_patchlevel
else:
-sys.stderr.write('Warning: Could not extract kernel version\n')
version = release = "unknown version"
# The language for content autogenerated by Sphinx. Refer to documentation
--
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
Re: [PATCH] docs: refcount_t documentation
On Mon, Dec 11, 2017 at 1:42 PM, Jonathan Corbet wrote: > On Tue, 5 Dec 2017 12:46:35 +0200 > Elena Reshetova wrote: > >> Some functions from refcount_t API provide different >> memory ordering guarantees that their atomic counterparts. >> This adds a document outlining these differences ( >> Documentation/core-api/refcount-vs-atomic.rst) as well as >> some other minor improvements. > > I've applied this, thanks, it looks good. > > One thing I noticed, though, is that this landed in the core-api manual, > while the refcount_t documentation is in the driver-api manual. The > cross-references work just fine and such, but this still doesn't seem quite > right. Probably what should be done is to have all the refcount_t > material in core-api; I may do that if I get a moment. I did notice that, yeah. It seemed like a bunch of kernel-doc was living in the driver-api manual, where it should be in core. Since atomics were already there, I put refcount_t there... -Kees -- Kees Cook Pixel Security -- 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/2] Documentation: Add guidance on CONFIG default value
On Mon, 20 Nov 2017 14:39:32 -0800 Darren Hart wrote: > Document the preference for "default n" in kconfig-language.txt, and reference > that in the submit-checklist.rst. I've (finally) applied the pair 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 2/2 v2] Documentation: add UUID/GUID to kernel-api
On Wed, 29 Nov 2017 12:32:42 -0800 Randy Dunlap wrote: > From: Randy Dunlap > > Update kernel-doc notation in lib/uuid.c and then add UUID/GUID > function interfaces to kernel-api. > > Signed-off-by: Randy Dunlap Applied to the docs tree. While I was at it... > + * uuid_is_valid - checks if UUID string valid > + * @uuid:UUID string to check > + * I made that "checks if *a* UUID string *is* valid". 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 1/2 v2] Documentation: add Sorting section to kernel-api
On Wed, 29 Nov 2017 12:32:38 -0800 Randy Dunlap wrote: > Add sort() and list_sort() to the kernel API documentation in a > new "Sorting" section. > > Signed-off-by: Randy Dunlap 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/2] mux: add overview and add to driver-api docs
On Mon, 11 Dec 2017 09:29:41 +0100 Peter Rosin wrote: > Don't know if this is worth adding, but it might answer at least a few > questions. > > It looks ok when I view the htmldocs output, but I'm not all that certain > this is good to go? Almost, but I have one request: the new mux.rst file is rather unenlightening for somebody who reads it directly in the docs tree. If you want to keep the bulk of the text in the source I can live with that, but can mux.rst at least get an introductory paragraph saying what it covers (what *is* the mux subsystem?) and why readers might want to go find the rest? Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs: refcount_t documentation
On Tue, 5 Dec 2017 12:46:35 +0200 Elena Reshetova wrote: > Some functions from refcount_t API provide different > memory ordering guarantees that their atomic counterparts. > This adds a document outlining these differences ( > Documentation/core-api/refcount-vs-atomic.rst) as well as > some other minor improvements. I've applied this, thanks, it looks good. One thing I noticed, though, is that this landed in the core-api manual, while the refcount_t documentation is in the driver-api manual. The cross-references work just fine and such, but this still doesn't seem quite right. Probably what should be done is to have all the refcount_t material in core-api; I may do that if I get a moment. 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] Documentation/driver-api/usb: Replace dead link
On Fri, 8 Dec 2017 01:12:09 +0100 Stefan Tatschner wrote: > This link is dead: > > $ curl -vI http://usb.cs.tum.edu/usbdoc > * Could not resolve host: usb.cs.tum.edu > * Closing connection 0 > curl: (6) Could not resolve host: usb.cs.tum.edu > > I found the document somewhere else. Let's replace it. Working URLs are better than dead ones, so I've applied this. But that document was written 17 years ago and probably doesn't relate all that closely to the current state of affairs...one has to wonder if it's worth keeping the link at all. 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] kernel-doc: parse DECLARE_KFIFO and DECLARE_KFIFO_PTR()
On Fri, 8 Dec 2017 09:05:12 -0500 Mauro Carvalho Chehab wrote: > So, teach kernel-doc how to parse DECLARE_KFIFO() and DECLARE_KFIFO_PTR(). > > While here, relax at the past DECLARE_foo() macros, accepting a random > number of spaces after comma. 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] Documentation: kernel-hacking: corrected a typo
On Fri, 8 Dec 2017 19:10:54 +0100 Marco Donato Torsello wrote: > Corrected a typo. > > Signed-off-by: Marco Donato Torsello > --- > Documentation/kernel-hacking/hacking.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) 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] Documentation: mono: Update links and s/CVS/Git/
On Sat, 9 Dec 2017 17:21:04 +0100 Jonathan Neuschäfer wrote: > The URLs in mono.rst redirect to pages on www.mono-project.com, so let's > update them. I took the liberty to update the compilation instructions > to the Linux-specific version, because readers of the kernel > documentation will most likely use Linux. Applied to the docs tree, thanks. I do wonder if anybody actually does this, though... 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: [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
Hi gengdongjiu Sorry for the late response. I have a similar patch to add the support for "FHM", which I was about to post it this week. On 11/12/17 13:29, Dave Martin wrote: On Mon, Dec 11, 2017 at 08:47:00PM +0800, gengdongjiu wrote: On 2017/12/11 19:59, Dave P Martin wrote: On Sat, Dec 09, 2017 at 03:28:42PM +, Dongjiu Geng wrote: ARM v8.4 extensions include support for new floating point multiplication variant instructions to the AArch64 SIMD Do we have any human-readable description of what the new instructions do? Since the v8.4 spec itself only describes these as "New Floating Point Multiplication Variant", I wonder what "FHM" actually stands for. Thanks for the point out. In fact, this feature only adds two instructions: FP16 * FP16 + FP32 FP16 * FP16 - FP32 The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it will call "FHM", I think call it "FMLXL" may be better, which can stand for FMLAL/FMLSL instructions. Although "FHM" is cryptic, I think it makes sense to keep this as "FHM" to match the ISAR0 field name -- we've tended to follow this policy for other extension names unless there's a much better or more obvious name available. For "FMLXL", new instructions might be added in the future that match the same pattern, and then "FMLXL" could become ambiguous. So maybe this is not the best choice. I think the FHM stands for "FP Half precision Multiplication instructions". I vote for keeping the feature bit in sync with the register bit definition. i.e, FHM. However, my version of the patch names the HWCAP bit "asimdfml", following the compiler name for the feature option "fp16fml", which is not perfect either. I think FHM is the safe option here. Maybe something like "widening half-precision floating-point multiply accumulate" is acceptable wording consistent with the existing architecture, but I just made that up, so it's not official ;) how about something like "performing a multiplication of each FP16 element of one vector with the corresponding FP16 element of a second vector, and to add or subtract this without an intermediate rounding to the corresponding FP32 element in a third vector."? We could have that, I guess. I agree, and that matches the feature description. -- 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] doc: convert printk-formats.txt to rst
On 12/08/2017 10:33 PM, Tobin C. Harding wrote: [Adding Laura] On Fri, Dec 08, 2017 at 06:18:45PM -0800, Joe Perches wrote: On Sat, 2017-12-09 at 12:27 +1100, Tobin C. Harding wrote: On Fri, Dec 08, 2017 at 01:22:37PM -0800, Joe Perches wrote: Outside of the documentation, what could be useful is for someone to add a tool to verify %p extension to the typeof address actually passed as an argument. This sounds interesting to work no. At first glance I have no idea how one would go about this. Some form of static analysis would be a good place to start, right? I'd like to allocate some cycles to this, any pointers most appreciated. A gcc-plugin would likely work best. What's the learning curve like in your opinion to do a gcc-plugin. I recall reading someplace 'deep understanding of how the compiler works' or some such thing. I suppose reading the Dragon book would be a good place to start? The hardest part of doing a gcc-plugin is understanding the gccisms. There isn't much documentation and most of what there is ends up being "here's how you hook into the compiler at point X" without showing how you do anything with it. The Dragon book (also known as "Compilers: Principles, Techniques, and Tools" for those who haven't heard of it before) is a great resource for general compiler concepts but it's not helpful for gcc-specific work. Writing about some of my experiments on my gcc-plugins has been on my TODO list for a while. 2018 resolution on actually finishing it perhaps. We could also catch pointers being cast to longs and printed with %x (and %u) or so I would guess. There was some discussion about such a thing here: http://www.openwall.com/lists/kernel-hardening/2017/02/14/38 Did you make much progress with this Laura? Not particularly. I wanted to re-use the kernel's print functionality in the plugin to automatically check new formats but I went down a rathole trying to make it work and got side tracked with other things and never picked it up again. I vaguely recall someone else doing a broader use tool which I believe was not smatch, but my google-fu isn't finding it. It might have been coccinelle based. thanks, Tobin. Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] acpi, x86: Use SPCR table for earlycon on x86
The ACPI SPCR code has been used to define an earlycon console for ARM64
and can be used for x86.
Modify the ACPI SPCR parsing code to account for console behaviour
differences between ARM64 and x86. Initialize the SPCR code from
x86 ACPI initialization code.
Signed-off-by: Prarit Bhargava
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-ser...@vger.kernel.org
Cc: Bhupesh Sharma
Cc: Lv Zheng
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Jonathan Corbet
Cc: Catalin Marinas
Cc: Will Deacon
Cc: "Rafael J. Wysocki"
Cc: Timur Tabi
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
arch/arm64/kernel/acpi.c| 2 +-
arch/x86/kernel/acpi/boot.c | 4
drivers/acpi/Kconfig| 2 +-
drivers/acpi/spcr.c | 7 +--
include/linux/acpi.h| 7 +--
6 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 0d173289c67e..c7cc890a0e81 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -918,6 +918,9 @@
stdout-path property in device tree's chosen node,
or determined by the ACPI SPCR table.
+ [X86] When used with no options the early console is
+ determined by the ACPI SPCR table.
+
cdns,[,options]
Start an early, polled-mode console on a Cadence
(xuartps) serial port at the specified address. Only
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index b3e33bbdf3b7..aaee4864b63e 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -355,7 +355,7 @@ void __init acpi_boot_table_init(void)
early_init_dt_scan_chosen_stdout();
} else {
/* Always enable the ACPI SPCR console */
- acpi_parse_spcr(console_acpi_spcr_enable);
+ acpi_parse_spcr(console_acpi_spcr_enable, true);
if (IS_ENABLED(CONFIG_ACPI_BGRT))
acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
}
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index f4c463df8b08..f01a03643cff 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1626,6 +1627,9 @@ int __init acpi_boot_init(void)
if (!acpi_noirq)
x86_init.pci.init = pci_acpi_init;
+ /* Do not enable ACPI SPCR console by default */
+ acpi_parse_spcr(console_acpi_spcr_enable, console_acpi_spcr_enable);
+
return 0;
}
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 9ae98eeada76..2d4e841e0682 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -80,7 +80,7 @@ endif
config ACPI_SPCR_TABLE
bool "ACPI Serial Port Console Redirection Support"
- default y if ARM64
+ default y if (X86 || ARM64)
help
Enable support for Serial Port Console Redirection (SPCR) Table.
This table provides information about the configuration of the
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index f4bb8110e404..c9469b488527 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -39,7 +39,7 @@ bool console_acpi_spcr_enable __initdata;
* from arch initialization code as soon as the DT/ACPI decision is made.
*
*/
-int __init acpi_parse_spcr(bool earlycon)
+int __init acpi_parse_spcr(bool earlycon, bool enable_console)
{
static char opts[ACPI_SPCR_OPTS_SIZE];
static char uart[ACPI_SPCR_BUF_SIZE];
@@ -112,7 +112,10 @@ int __init acpi_parse_spcr(bool earlycon)
if (earlycon)
setup_earlycon(opts);
- err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
+ if (enable_console)
+ err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
+ else
+ err = 0;
done:
acpi_put_table((struct acpi_table_header *)table);
return err;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 875d7327d91c..4c2d449bab9b 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1248,10 +1248,13 @@ extern bool console_acpi_spcr_enable __initdata;
extern int acpi_arch_setup_console(struct acpi_table_spcr *table,
char *opts, char *uart, char *iotype,
int baud_rate, bool earlycon);
-int acpi_parse_spcr(bool earlycon);
+int acpi_parse_spcr(bool earlycon, bool enable_console);
#else
static const bool console_acpi_spcr
[PATCH v2 0/2] acpi, x86: Add SPCR table support
The SPCR (Serial Port Console Redirection) Table provides information about the configuration of the serial port. This information can be used to configure the early console. SPCR support was added for ARM64 and is made available across all arches in this patchset. The first patch adds a weak per-arch configuration function and moves the SPCR code into ACPI. The second patch adds support to x86. The existing behaviour on ARM64 is maintained. If the SPCR exists the earlycon and console are automatically configured. The existing default behaviour on x86 is also maintained. If no console or earlycon parameter is defined and the SPCR exists, the serial port is not configured. If the earlycon parameter is used both the early console and the console are configured using the data from the SPCR. Additional testing (requested by Timur): On Gigabyte (no quirks), Qualcomm Amberwing systems to test Qualcomm quirks, HPE Mantis system to test xgene quirks. Tested several x86 systems with and without a SPCR to confirm no changes in default behaviour. [v2]: See 1/2 for code changes. Signed-off-by: Prarit Bhargava Cc: linux-doc@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux-ser...@vger.kernel.org Cc: Bhupesh Sharma Cc: Lv Zheng Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Jonathan Corbet Cc: Catalin Marinas Cc: Will Deacon Cc: "Rafael J. Wysocki" Cc: Timur Tabi Prarit Bhargava (2): acpi, spcr: Make SPCR avialable to other architectures acpi, x86: Use SPCR table for earlycon on x86 Documentation/admin-guide/kernel-parameters.txt | 9 +- arch/arm64/kernel/acpi.c| 128 - arch/x86/kernel/acpi/boot.c | 4 + drivers/acpi/Kconfig| 7 +- drivers/acpi/spcr.c | 180 ++-- drivers/tty/serial/earlycon.c | 15 +- include/linux/acpi.h| 14 +- include/linux/serial_core.h | 2 - 8 files changed, 198 insertions(+), 161 deletions(-) -- 2.15.0.rc0.39.g2f0e14e64 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
Other architectures can use SPCR to setup an early console or console
but the current code is ARM64 specific.
Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak
function acpi_arch_setup_console() that can be used for arch-specific
setup. Move flags into ACPI code. Update the Documention on the use of
the SPCR.
[v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
Keep ACPI_SPCR_TABLE selected for ARM64. Fix 8-bit port access width
mmio value. Move baud rate check earlier.
Signed-off-by: Prarit Bhargava
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-ser...@vger.kernel.org
Cc: Bhupesh Sharma
Cc: Lv Zheng
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Jonathan Corbet
Cc: Catalin Marinas
Cc: Will Deacon
Cc: "Rafael J. Wysocki"
Cc: Timur Tabi
---
Documentation/admin-guide/kernel-parameters.txt | 6 +-
arch/arm64/kernel/acpi.c| 128 -
drivers/acpi/Kconfig| 7 +-
drivers/acpi/spcr.c | 175 ++--
drivers/tty/serial/earlycon.c | 15 +-
include/linux/acpi.h| 11 +-
include/linux/serial_core.h | 2 -
7 files changed, 184 insertions(+), 160 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 6571fbfdb2a1..0d173289c67e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -914,9 +914,9 @@
earlycon= [KNL] Output early console device and options.
- When used with no options, the early console is
- determined by the stdout-path property in device
- tree's chosen node.
+ [ARM64] The early console is determined by the
+ stdout-path property in device tree's chosen node,
+ or determined by the ACPI SPCR table.
cdns,[,options]
Start an early, polled-mode console on a Cadence
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index b3162715ed78..b3e33bbdf3b7 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include
@@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
return ret;
}
+/*
+ * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
+ * occasionally getting stuck as 1. To avoid the potential for a hang, check
+ * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
+ * implementations, so only do so if an affected platform is detected in
+ * acpi_parse_spcr().
+ */
+bool qdf2400_e44_present;
+EXPORT_SYMBOL(qdf2400_e44_present);
+
+/*
+ * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
+ * Detect them by examining the OEM fields in the SPCR header, similar to PCI
+ * quirk detection in pci_mcfg.c.
+ */
+static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
+{
+ if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
+ return false;
+
+ if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
+ return true;
+
+ if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
+ h->oem_revision == 1)
+ return true;
+
+ return false;
+}
+
+/*
+ * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
+ * register aligned to 32-bit. In addition, the BIOS also encoded the
+ * access width to be 8 bits. This function detects this errata condition.
+ */
+static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
+{
+ bool xgene_8250 = false;
+
+ if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
+ return false;
+
+ if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
+ memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
+ return false;
+
+ if (!memcmp(tb->header.oem_table_id, "XGENESPC",
+ ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
+ xgene_8250 = true;
+
+ if (!memcmp(tb->header.oem_table_id, "ProLiant",
+ ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
+ xgene_8250 = true;
+
+ return xgene_8250;
+}
+
+int acpi_arch_setup_console(struct acpi_table_spcr *table,
+ char *opts, char *uart, char *iotype,
+ int baud_rate, bool earlycon)
+{
+ if (table->header.revision < 2) {
+ pr_err("wrong table version\n");
+ return -ENOENT;
+ }
+
+
Re: [PATCH 0/2] acpi, x86: Add SPCR table support
* Prarit Bhargava wrote: > If I disable "Serial Port Console Debug" in my BIOS I still see the SPCR > configured: > > [root@prarit-lab ~]# dmesg | grep SPCR > [0.00] ACPI: SPCR 0x69031000 50 (v01 > ) > > AFAICT the SPCR is always enabled on some systems. Fair enough. > > If so then we should pick up that serial console configuration and activate > > it, > > regardless of any kernel boot options! > > I'm worried about someone who doesn't want a console on ttyS0 suddenly ending > up > with one. The SPCR could contain incorrect data, etc. Yeah, that's not good. Thanks, Ingo -- 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: [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
On Mon, Dec 11, 2017 at 08:47:00PM +0800, gengdongjiu wrote: > > On 2017/12/11 19:59, Dave P Martin wrote: > > On Sat, Dec 09, 2017 at 03:28:42PM +, Dongjiu Geng wrote: > >> ARM v8.4 extensions include support for new floating point > >> multiplication variant instructions to the AArch64 SIMD > > > > Do we have any human-readable description of what the new instructions > > do? > > > > Since the v8.4 spec itself only describes these as "New Floating > > Point Multiplication Variant", I wonder what "FHM" actually stands > > for. > Thanks for the point out. > In fact, this feature only adds two instructions: > FP16 * FP16 + FP32 > FP16 * FP16 - FP32 > > The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it > will call "FHM", I think call it "FMLXL" may be better, which can > stand for FMLAL/FMLSL instructions. Although "FHM" is cryptic, I think it makes sense to keep this as "FHM" to match the ISAR0 field name -- we've tended to follow this policy for other extension names unless there's a much better or more obvious name available. For "FMLXL", new instructions might be added in the future that match the same pattern, and then "FMLXL" could become ambiguous. So maybe this is not the best choice. > > Maybe something like "widening half-precision floating-point multiply > > accumulate" is acceptable wording consistent with the existing > > architecture, but I just made that up, so it's not official ;) > > how about something like "performing a multiplication of each FP16 > element of one vector with the corresponding FP16 element of a second > vector, and to add or subtract this without an intermediate rounding > to the corresponding FP32 element in a third vector."? We could have that, I guess. > > > >> instructions set. Let the userspace know about it via a > >> HWCAP bit and MRS emulation. > >> > >> Cc: Suzuki K Poulose > >> Signed-off-by: Dongjiu Geng > >> --- > >> My platform supports this feature, so I need to add it. > >> --- > >> Documentation/arm64/cpu-feature-registers.txt | 4 +++- > >> arch/arm64/include/asm/sysreg.h | 1 + > >> arch/arm64/include/uapi/asm/hwcap.h | 1 + > >> arch/arm64/kernel/cpufeature.c| 2 ++ > >> arch/arm64/kernel/cpuinfo.c | 1 + > >> 5 files changed, 8 insertions(+), 1 deletion(-) > >> > >> diff --git a/Documentation/arm64/cpu-feature-registers.txt > >> b/Documentation/arm64/cpu-feature-registers.txt > >> index bd9b3fa..a70090b 100644 > >> --- a/Documentation/arm64/cpu-feature-registers.txt > >> +++ b/Documentation/arm64/cpu-feature-registers.txt > >> @@ -110,7 +110,9 @@ infrastructure: > >> x--x > >> | Name | bits | visible | > >> |--| > >> - | RES0 | [63-48] |n| > >> + | RES0 | [63-52] |n| > >> + |--| > >> + | FHM | [51-48] |y| > > > > You also need to update Documentation/arm64/elf_hwcaps.txt. > I will update it, thanks for the point out > > > > > Otherwise, looks OK. > Appreciate for your review. [...] Cheers ---Dave -- 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 v8 00/20] ILP32 for ARM64
On Mon, Dec 11, 2017 at 10:32:30AM +, Catalin Marinas wrote: > Hi Yury, > > On Thu, Nov 16, 2017 at 02:11:30PM +0300, Yury Norov wrote: > > This is ILP32 patches on top of 4.14 kernel: > > https://github.com/norov/linux/commits/ilp32-4.14 > > > > I tested the series with LTP lite built by Linaro toolchain, and no > > regressions found. > > Thanks. I gave it a try as well with LTP and pushed a staging/ilp32-4.14 > branch to the arm64 tree on git.kernel.org. BTW, you've added two random > patches on top of this branch (which I removed). Ah, it was accidentally. Removed them and force-updated the repo. Thanks for pointing that. > > By the way, do you have plans to upstream arch subseries? > > https://lkml.org/lkml/2017/9/25/574 > > I was hoping Arnd would pick them up since they are rather UAPI specific > than arm64. > > BTW, I wonder whether the nds32 patches actually follow the proposed > defaults in your patches like force_o_largefile() and get/setrlimit: > > https://lkml.org/lkml/2017/11/27/474 > > (I haven't reviewed the nds32 patches in detail though) I pulled that patches, and there's no my series. Arnd, could you pick that? Or if you see any problems, let me know and I'll fix them. Yury -- 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: [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
On 2017/12/11 19:59, Dave P Martin wrote:
> On Sat, Dec 09, 2017 at 03:28:42PM +, Dongjiu Geng wrote:
>> ARM v8.4 extensions include support for new floating point
>> multiplication variant instructions to the AArch64 SIMD
>
> Do we have any human-readable description of what the new instructions
> do?
>
> Since the v8.4 spec itself only describes these as "New Floating
> Point Multiplication Variant", I wonder what "FHM" actually stands
> for.Thanks for the point out.
In fact, this feature only adds two instructions:
FP16 * FP16 + FP32
FP16 * FP16 - FP32
The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it will call
"FHM", I think call it "FMLXL" may be better, which can stand for FMLAL/FMLSL
instructions.
>
> Maybe something like "widening half-precision floating-point multiply
> accumulate" is acceptable wording consistent with the existing
> architecture, but I just made that up, so it's not official ;)
how about something like "performing a multiplication of each FP16 element of
one
vector with the corresponding FP16 element of a second vector, and to
add or subtract this without an intermediate rounding to the
corresponding FP32 element in a third vector."?
>
>> instructions set. Let the userspace know about it via a
>> HWCAP bit and MRS emulation.
>>
>> Cc: Suzuki K Poulose
>> Signed-off-by: Dongjiu Geng
>> ---
>> My platform supports this feature, so I need to add it.
>> ---
>> Documentation/arm64/cpu-feature-registers.txt | 4 +++-
>> arch/arm64/include/asm/sysreg.h | 1 +
>> arch/arm64/include/uapi/asm/hwcap.h | 1 +
>> arch/arm64/kernel/cpufeature.c| 2 ++
>> arch/arm64/kernel/cpuinfo.c | 1 +
>> 5 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/arm64/cpu-feature-registers.txt
>> b/Documentation/arm64/cpu-feature-registers.txt
>> index bd9b3fa..a70090b 100644
>> --- a/Documentation/arm64/cpu-feature-registers.txt
>> +++ b/Documentation/arm64/cpu-feature-registers.txt
>> @@ -110,7 +110,9 @@ infrastructure:
>> x--x
>> | Name | bits | visible |
>> |--|
>> - | RES0 | [63-48] |n|
>> + | RES0 | [63-52] |n|
>> + |--|
>> + | FHM | [51-48] |y|
>
> You also need to update Documentation/arm64/elf_hwcaps.txt.
I will update it, thanks for the point out
>
> Otherwise, looks OK.
Appreciate for your review.
>
> Cheers
> ---Dave
>
>> |--|
>> | DP | [47-44] |y|
>> |--|
>> diff --git a/arch/arm64/include/asm/sysreg.h
>> b/arch/arm64/include/asm/sysreg.h
>> index 08cc885..1818077 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -419,6 +419,7 @@
>> #define SCTLR_EL1_CP15BEN(1 << 5)
>>
>> /* id_aa64isar0 */
>> +#define ID_AA64ISAR0_FHM_SHIFT 48
>> #define ID_AA64ISAR0_DP_SHIFT44
>> #define ID_AA64ISAR0_SM4_SHIFT 40
>> #define ID_AA64ISAR0_SM3_SHIFT 36
>> diff --git a/arch/arm64/include/uapi/asm/hwcap.h
>> b/arch/arm64/include/uapi/asm/hwcap.h
>> index cda76fa..f018c3d 100644
>> --- a/arch/arm64/include/uapi/asm/hwcap.h
>> +++ b/arch/arm64/include/uapi/asm/hwcap.h
>> @@ -43,5 +43,6 @@
>> #define HWCAP_ASIMDDP(1 << 20)
>> #define HWCAP_SHA512 (1 << 21)
>> #define HWCAP_SVE(1 << 22)
>> +#define HWCAP_ASIMDFHM (1 << 23)
>>
>> #endif /* _UAPI__ASM_HWCAP_H */
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index c5ba009..bc7e707 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -123,6 +123,7 @@ static int __init register_cpu_hwcaps_dumper(void)
>> * sync with the documentation of the CPU feature register ABI.
>> */
>> static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
>> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>> ID_AA64ISAR0_FHM_SHIFT, 4, 0),
>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>> ID_AA64ISAR0_DP_SHIFT, 4, 0),
>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>> ID_AA64ISAR0_SM4_SHIFT, 4, 0),
>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>> ID_AA64ISAR0_SM3_SHIFT, 4, 0),
>> @@ -991,6 +992,7 @@ static bool has_no_fpsimd(const struct
>> arm64_cpu_capabilities *entry, int __unus
>> HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED,
>> 1, CAP_HWCAP, HWCAP_SM3),
>> HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED,
>> 1, CAP_HWCAP, HWCAP_SM4),
>> HWCAP_CAP(SY
Re: [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
On Sat, Dec 09, 2017 at 03:28:42PM +, Dongjiu Geng wrote:
> ARM v8.4 extensions include support for new floating point
> multiplication variant instructions to the AArch64 SIMD
Do we have any human-readable description of what the new instructions
do?
Since the v8.4 spec itself only describes these as "New Floating
Point Multiplication Variant", I wonder what "FHM" actually stands
for.
Maybe something like "widening half-precision floating-point multiply
accumulate" is acceptable wording consistent with the existing
architecture, but I just made that up, so it's not official ;)
> instructions set. Let the userspace know about it via a
> HWCAP bit and MRS emulation.
>
> Cc: Suzuki K Poulose
> Signed-off-by: Dongjiu Geng
> ---
> My platform supports this feature, so I need to add it.
> ---
> Documentation/arm64/cpu-feature-registers.txt | 4 +++-
> arch/arm64/include/asm/sysreg.h | 1 +
> arch/arm64/include/uapi/asm/hwcap.h | 1 +
> arch/arm64/kernel/cpufeature.c| 2 ++
> arch/arm64/kernel/cpuinfo.c | 1 +
> 5 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/arm64/cpu-feature-registers.txt
> b/Documentation/arm64/cpu-feature-registers.txt
> index bd9b3fa..a70090b 100644
> --- a/Documentation/arm64/cpu-feature-registers.txt
> +++ b/Documentation/arm64/cpu-feature-registers.txt
> @@ -110,7 +110,9 @@ infrastructure:
> x--x
> | Name | bits | visible |
> |--|
> - | RES0 | [63-48] |n|
> + | RES0 | [63-52] |n|
> + |--|
> + | FHM | [51-48] |y|
You also need to update Documentation/arm64/elf_hwcaps.txt.
Otherwise, looks OK.
Cheers
---Dave
> |--|
> | DP | [47-44] |y|
> |--|
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 08cc885..1818077 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -419,6 +419,7 @@
> #define SCTLR_EL1_CP15BEN(1 << 5)
>
> /* id_aa64isar0 */
> +#define ID_AA64ISAR0_FHM_SHIFT 48
> #define ID_AA64ISAR0_DP_SHIFT44
> #define ID_AA64ISAR0_SM4_SHIFT 40
> #define ID_AA64ISAR0_SM3_SHIFT 36
> diff --git a/arch/arm64/include/uapi/asm/hwcap.h
> b/arch/arm64/include/uapi/asm/hwcap.h
> index cda76fa..f018c3d 100644
> --- a/arch/arm64/include/uapi/asm/hwcap.h
> +++ b/arch/arm64/include/uapi/asm/hwcap.h
> @@ -43,5 +43,6 @@
> #define HWCAP_ASIMDDP(1 << 20)
> #define HWCAP_SHA512 (1 << 21)
> #define HWCAP_SVE(1 << 22)
> +#define HWCAP_ASIMDFHM (1 << 23)
>
> #endif /* _UAPI__ASM_HWCAP_H */
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index c5ba009..bc7e707 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -123,6 +123,7 @@ static int __init register_cpu_hwcaps_dumper(void)
> * sync with the documentation of the CPU feature register ABI.
> */
> static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64ISAR0_FHM_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64ISAR0_DP_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64ISAR0_SM4_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
> ID_AA64ISAR0_SM3_SHIFT, 4, 0),
> @@ -991,6 +992,7 @@ static bool has_no_fpsimd(const struct
> arm64_cpu_capabilities *entry, int __unus
> HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED,
> 1, CAP_HWCAP, HWCAP_SM3),
> HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED,
> 1, CAP_HWCAP, HWCAP_SM4),
> HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1,
> CAP_HWCAP, HWCAP_ASIMDDP),
> + HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED,
> 1, CAP_HWCAP, HWCAP_ASIMDFHM),
> HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0,
> CAP_HWCAP, HWCAP_FP),
> HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1,
> CAP_HWCAP, HWCAP_FPHP),
> HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0,
> CAP_HWCAP, HWCAP_ASIMD),
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 1e25545..7f94623 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -76,6 +76,7 @@
> "asimddp",
> "sha512",
> "sve",
> + "asimdfhm",
> NUL
Re: [PATCH v8 00/20] ILP32 for ARM64
Hi Yury, On Thu, Nov 16, 2017 at 02:11:30PM +0300, Yury Norov wrote: > This is ILP32 patches on top of 4.14 kernel: > https://github.com/norov/linux/commits/ilp32-4.14 > > I tested the series with LTP lite built by Linaro toolchain, and no > regressions found. Thanks. I gave it a try as well with LTP and pushed a staging/ilp32-4.14 branch to the arm64 tree on git.kernel.org. BTW, you've added two random patches on top of this branch (which I removed). > By the way, do you have plans to upstream arch subseries? > https://lkml.org/lkml/2017/9/25/574 I was hoping Arnd would pick them up since they are rather UAPI specific than arm64. BTW, I wonder whether the nds32 patches actually follow the proposed defaults in your patches like force_o_largefile() and get/setrlimit: https://lkml.org/lkml/2017/11/27/474 (I haven't reviewed the nds32 patches in detail though) -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] mux: core: add a brief overview of the subsystem
Preparation for adding the mux subsystem to the driver-api documenation. Signed-off-by: Peter Rosin --- drivers/mux/core.c | 37 + 1 file changed, 37 insertions(+) diff --git a/drivers/mux/core.c b/drivers/mux/core.c index d1271c1ee23c..ccb5479f8a39 100644 --- a/drivers/mux/core.c +++ b/drivers/mux/core.c @@ -7,6 +7,43 @@ * Author: Peter Rosin */ +/** + * DOC: overview + * + * The multiplexer subsystem uses the following naming: + * + * - Multiplexer controller: the piece of hardware that changes the + * state of a hardware multiplexer (or indeed, several parallel + * multiplexers). + * + * - Multiplexer chip: a collection of multiplexer controllers, in a chip. + * + * - Multiplexer driver: the device driver that interacts with and handles the + * above hardware. The driver has structures representing a mux chip and mux + * controllers. + * + * - Multiplexer consumer: the driver that needs to manipulate the hardware + * multiplexer. + * + * The mux subsystem provides a framework for multiplexer drivers that can + * be used by other consumer drivers. It has two primary purposes. + * + * First, when a consumer driver can be used with one of several multiplexers, + * depending on hardware configuration, the actual multiplexer is abstracted + * away in the mux drivers. The multiplexer consumer driver can be neater + * this way. + * + * Second, when two consumers -- possibly from different subsystems -- compete + * for the same mux controller, i.e. when one mux controller muxes more than + * one signal, the mux framework provides locking. + * + * If the mux driver is so special that it will only ever have a single + * consumer, and that consumer can really only work with that one mux driver, + * the mux framework is not really providing much benefit. It might be a better + * idea to simply manipulate the mux hardware directly from the consumer + * driver. + */ + #define pr_fmt(fmt) "mux-core: " fmt #include -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] docs: add mux docs to the driver-api docs
Include both the overview and the more detailed api docs. Signed-off-by: Peter Rosin --- Documentation/driver-api/index.rst | 1 + Documentation/driver-api/mux.rst | 17 + 2 files changed, 18 insertions(+) create mode 100644 Documentation/driver-api/mux.rst diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index d17a9876b473..d10b01b2b429 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -47,6 +47,7 @@ available subsections can be seen below. gpio misc_devices dmaengine/index + mux .. only:: subproject and html diff --git a/Documentation/driver-api/mux.rst b/Documentation/driver-api/mux.rst new file mode 100644 index ..d26d7518e9c9 --- /dev/null +++ b/Documentation/driver-api/mux.rst @@ -0,0 +1,17 @@ +Multiplexer Subsystem += + +Overview + + +.. kernel-doc:: drivers/mux/core.c + :doc: overview + +Details +--- + +.. kernel-doc:: include/linux/mux/driver.h + :internal: + +.. kernel-doc:: drivers/mux/core.c + :export: -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] mux: add overview and add to driver-api docs
Hi! Don't know if this is worth adding, but it might answer at least a few questions. It looks ok when I view the htmldocs output, but I'm not all that certain this is good to go? Cheers, Peter Peter Rosin (2): mux: core: add a brief overview of the subsystem docs: add mux docs to the driver-api docs Documentation/driver-api/index.rst | 1 + Documentation/driver-api/mux.rst | 17 + drivers/mux/core.c | 37 + 3 files changed, 55 insertions(+) create mode 100644 Documentation/driver-api/mux.rst -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
