* [PATCH v2 5/5] Input: msg2638 - Add support for msg2138 key events
From: Vincent Knecht @ 2022-01-24 21:33 UTC (permalink / raw)
To: dmitry.torokhov, stephan
Cc: linux-input, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Vincent Knecht
In-Reply-To: <20220124212611.752603-1-vincent.knecht@mailoo.org>
Some devices with msg2138 have back/menu/home keys.
Add support for them.
Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org>
---
v2:
- no change
---
drivers/input/touchscreen/msg2638.c | 53 +++++++++++++++++++++++++----
1 file changed, 47 insertions(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/msg2638.c b/drivers/input/touchscreen/msg2638.c
index 73e1b4d550fb..36069b30ab9b 100644
--- a/drivers/input/touchscreen/msg2638.c
+++ b/drivers/input/touchscreen/msg2638.c
@@ -29,6 +29,8 @@
#define MSG2138_MAX_FINGERS 2
#define MSG2638_MAX_FINGERS 5
+#define MAX_BUTTONS 4
+
#define CHIP_ON_DELAY_MS 15
#define FIRMWARE_ON_DELAY_MS 50
#define RESET_DELAY_MIN_US 10000
@@ -72,6 +74,8 @@ struct msg2638_ts_data {
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpiod;
int max_fingers;
+ u32 keycodes[MAX_BUTTONS];
+ int num_keycodes;
};
static u8 msg2638_checksum(u8 *data, u32 length)
@@ -85,6 +89,19 @@ static u8 msg2638_checksum(u8 *data, u32 length)
return (u8)((-sum) & 0xFF);
}
+static void msg2138_report_keys(struct msg2638_ts_data *msg2638, u8 keys)
+{
+ int i;
+
+ /* keys can be 0x00 or 0xff when all keys have been released */
+ if (keys == 0xff)
+ keys = 0;
+
+ for (i = 0; i < msg2638->num_keycodes; ++i)
+ input_report_key(msg2638->input_dev, msg2638->keycodes[i],
+ !!(keys & BIT(i)));
+}
+
static irqreturn_t msg2138_ts_irq_handler(int irq, void *msg2638_handler)
{
struct msg2638_ts_data *msg2638 = msg2638_handler;
@@ -121,9 +138,12 @@ static irqreturn_t msg2138_ts_irq_handler(int irq, void *msg2638_handler)
p0 = &touch_event.pkt[0];
p1 = &touch_event.pkt[1];
- /* Ignore non-pressed finger data */
- if (p0->xy_hi == 0xFF && p0->x_low == 0xFF && p0->y_low == 0xFF)
+ /* Ignore non-pressed finger data, but check for key code */
+ if (p0->xy_hi == 0xFF && p0->x_low == 0xFF && p0->y_low == 0xFF) {
+ if (p1->xy_hi == 0xFF && p1->y_low == 0xFF)
+ msg2138_report_keys(msg2638, p1->x_low);
goto report;
+ }
x = (((p0->xy_hi & 0xF0) << 4) | p0->x_low);
y = (((p0->xy_hi & 0x0F) << 8) | p0->y_low);
@@ -283,6 +303,7 @@ static int msg2638_init_input_dev(struct msg2638_ts_data *msg2638)
struct device *dev = &msg2638->client->dev;
struct input_dev *input_dev;
int error;
+ int i;
input_dev = devm_input_allocate_device(dev);
if (!input_dev) {
@@ -299,6 +320,14 @@ static int msg2638_init_input_dev(struct msg2638_ts_data *msg2638)
input_dev->open = msg2638_input_open;
input_dev->close = msg2638_input_close;
+ if (msg2638->num_keycodes) {
+ input_dev->keycode = msg2638->keycodes;
+ input_dev->keycodemax = msg2638->num_keycodes;
+ input_dev->keycodesize = sizeof(msg2638->keycodes[0]);
+ for (i = 0; i < msg2638->num_keycodes; i++)
+ input_set_capability(input_dev, EV_KEY, msg2638->keycodes[i]);
+ }
+
input_set_capability(input_dev, EV_ABS, ABS_MT_POSITION_X);
input_set_capability(input_dev, EV_ABS, ABS_MT_POSITION_Y);
@@ -367,10 +396,16 @@ static int msg2638_ts_probe(struct i2c_client *client)
return error;
}
- error = msg2638_init_input_dev(msg2638);
- if (error) {
- dev_err(dev, "Failed to initialize input device: %d\n", error);
- return error;
+ msg2638->num_keycodes =
+ of_property_read_variable_u32_array(dev->of_node, "linux,keycodes",
+ msg2638->keycodes, 0,
+ ARRAY_SIZE(msg2638->keycodes));
+ if (msg2638->num_keycodes == -EINVAL) {
+ msg2638->num_keycodes = 0;
+ } else if (msg2638->num_keycodes < 0) {
+ dev_err(dev, "Unable to parse linux,keycodes property: %d\n",
+ msg2638->num_keycodes);
+ return msg2638->num_keycodes;
}
error = devm_request_threaded_irq(dev, client->irq,
@@ -382,6 +417,12 @@ static int msg2638_ts_probe(struct i2c_client *client)
return error;
}
+ error = msg2638_init_input_dev(msg2638);
+ if (error) {
+ dev_err(dev, "Failed to initialize input device: %d\n", error);
+ return error;
+ }
+
return 0;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v1] arm64: dts: qcom: sc7280: Add lpasscore & lpassaudio clock controllers
From: Stephen Boyd @ 2022-01-24 20:36 UTC (permalink / raw)
To: Doug Anderson, Taniya Das
Cc: Rob Herring, Bjorn Andersson, Andy Gross, devicetree,
linux-arm-msm, LKML
In-Reply-To: <CAD=FV=X3+MDOMEidLbdgvcHVSObO=_x3KSLe31hr-TP6B2jCEg@mail.gmail.com>
Quoting Doug Anderson (2022-01-24 12:33:06)
> Hi,
>
> On Mon, Jan 24, 2022 at 8:58 AM Taniya Das <tdas@codeaurora.org> wrote:
> >
> > Add the low pass audio clock controller device nodes.
> >
> > Signed-off-by: Taniya Das <tdas@codeaurora.org>
> > ---
> > Dependent onLPASS clock controller change: https://lkml.org/lkml/2022/1/24/772
> >
> > arch/arm64/boot/dts/qcom/sc7280.dtsi | 43 ++++++++++++++++++++++++++++
> > 1 file changed, 43 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > index 937c2e0e93eb..0aa834ce6b61 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > @@ -8,6 +8,8 @@
> > #include <dt-bindings/clock/qcom,dispcc-sc7280.h>
> > #include <dt-bindings/clock/qcom,gcc-sc7280.h>
> > #include <dt-bindings/clock/qcom,gpucc-sc7280.h>
> > +#include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
> > +#include <dt-bindings/clock/qcom,lpasscorecc-sc7280.h>
>
> Presumably using these two include files means a dependency on things
> landing in the clk tree [1]. Unless Stephen and Bjorn want to work
> something out, I'd guess you'll need to re-post with just hardcoded
> numbers for now?
>
Bjorn will apply both patches so the dts patch can live atop the clk
one.
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: sc7280: Add lpasscore & lpassaudio clock controllers
From: Doug Anderson @ 2022-01-24 20:33 UTC (permalink / raw)
To: Taniya Das
Cc: Rob Herring, Bjorn Andersson, Stephen Boyd, Andy Gross,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-msm, LKML
In-Reply-To: <20220124165745.16277-1-tdas@codeaurora.org>
Hi,
On Mon, Jan 24, 2022 at 8:58 AM Taniya Das <tdas@codeaurora.org> wrote:
>
> Add the low pass audio clock controller device nodes.
>
> Signed-off-by: Taniya Das <tdas@codeaurora.org>
> ---
> Dependent onLPASS clock controller change: https://lkml.org/lkml/2022/1/24/772
>
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 43 ++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 937c2e0e93eb..0aa834ce6b61 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -8,6 +8,8 @@
> #include <dt-bindings/clock/qcom,dispcc-sc7280.h>
> #include <dt-bindings/clock/qcom,gcc-sc7280.h>
> #include <dt-bindings/clock/qcom,gpucc-sc7280.h>
> +#include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
> +#include <dt-bindings/clock/qcom,lpasscorecc-sc7280.h>
Presumably using these two include files means a dependency on things
landing in the clk tree [1]. Unless Stephen and Bjorn want to work
something out, I'd guess you'll need to re-post with just hardcoded
numbers for now?
[1] https://lore.kernel.org/r/20220124162442.29497-2-tdas@codeaurora.org/
^ permalink raw reply
* Re: [PATCH v2 0/7] usb: dwc3: Calculate REFCLKPER et. al. from reference clock
From: Thinh Nguyen @ 2022-01-24 23:01 UTC (permalink / raw)
To: Kathiravan Thirumoorthy, Baruch Siach, Kathiravan T
Cc: Sean Anderson, Greg Kroah-Hartman, linux-usb@vger.kernel.org,
Felipe Balbi, Thinh Nguyen, Balaji Prakash J,
linux-kernel@vger.kernel.org, Robert Hancock, Andy Gross,
Bjorn Andersson, Michal Simek, Rob Herring,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org
In-Reply-To: <e1309c23-530b-c698-b7ba-4f1a5226fe8c@quicinc.com>
Kathiravan Thirumoorthy wrote:
> Hi Baruch,
>
> On 1/20/2022 3:59 PM, Baruch Siach wrote:
>> Hi Kathiravan,
>>
>> On Thu, Jan 20 2022, Kathiravan T wrote:
>>> On 2022-01-19 23:44, Baruch Siach wrote:
>>>> Hi Sean,
>>>> On Tue, Jan 18 2022, Sean Anderson wrote:
>>>>> This is a rework of patches 3-5 of [1]. It attempts to correctly
>>>>> program
>>>>> REFCLKPER and REFCLK_FLADJ based on the reference clock frequency.
>>>>> Since
>>>>> we no longer need a special property duplicating this configuration,
>>>>> snps,ref-clock-period-ns is deprecated.
>>>>> Please test this! Patches 3/4 in this series have the effect of
>>>>> programming REFCLKPER and REFCLK_FLADJ on boards which already
>>>>> configure
>>>>> the "ref" clock. I have build tested, but not much else.
>>>> Tested here on IPQ6010 based system. USB still works. But the with
>>>> "ref"
>>>> clock at 24MHz, period is calculated as 0x29. Previous
>>>> snps,ref-clock-period-ns value used to be 0x32.
>>>> Is that expected?
>>> Yes, it is 0x29 for IPQ60xx based SoCs. In downstream it was wrongly
>>> mentioned
>>> as 0x32, which was corrected recently.
>> Thanks for the update. This needs fixing in upstream kernel. I'll send a
>> patch.
>>
>> For some reason USB appears to work here with both values. Is it because
>> I only use USB2 signals? If this is the case them I can not actually
>> test this series on my system.
The controller uses the GUCTL.REFCLKPER under specific conditions and
settings, and the conditions are different between host mode and device
mode. For example, if you're running as device-mode and not operating in
low power, and or not using periodic endpoints, you're not probably
testing this.
BR,
Thinh
>
> I could recollect we did see some issue on USB2.0 port as well, but it
> wasn't fatal one. Anyways it is better to test it.
>
> Thanks,
>
> Kathiravan T.
>
>>
>> Thanks,
>> baruch
>>
>>>>> [1]
>>>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-usb/20220114044230.2677283-1-robert.hancock@calian.com/__;!!A4F2R9G_pg!MCqqTGYTR42-4_LUHhrSJjkUOkDZKb795I8lB3PY4dB-kVCBnR9YKucgzrwhlj0tZZm5$
>>>>> Changes in v2:
>>>>> - Document clock members
>>>>> - Also program GFLADJ.240MHZDECR
>>>>> - Don't program GFLADJ if the version is < 2.50a
>>>>> - Add snps,ref-clock-frequency-hz property for ACPI
>>>>> Sean Anderson (7):
>>>>> dt-bindings: usb: dwc3: Deprecate snps,ref-clock-period-ns
>>>>> usb: dwc3: Get clocks individually
>>>>> usb: dwc3: Calculate REFCLKPER based on reference clock
>>>>> usb: dwc3: Program GFLADJ
>>>>> usb: dwc3: Add snps,ref-clock-frequency-hz property for ACPI
>>>>> arm64: dts: zynqmp: Move USB clocks to dwc3 node
>>>>> arm64: dts: ipq6018: Use reference clock to set dwc3 period
>>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 7 +-
>>>>> arch/arm64/boot/dts/qcom/ipq6018.dtsi | 3 +-
>>>>> .../arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 4 +-
>>>>> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 +-
>>>>> drivers/usb/dwc3/core.c | 112
>>>>> +++++++++++++++---
>>>>> drivers/usb/dwc3/core.h | 17 ++-
>>>>> 6 files changed, 120 insertions(+), 27 deletions(-)
>>
^ permalink raw reply
* Re: [PATCH] dt-bindings: Improve phandle-array schemas
From: Rob Herring @ 2022-01-24 20:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-kernel, Mark Brown, alsa-devel,
Sylwester Nawrocki
In-Reply-To: <CA+Eumj4HjM8SPoOUo7_eLBOHFYXTPPPgmx_YDYdEXDyaT67Rrg@mail.gmail.com>
On Mon, Jan 24, 2022 at 10:55 AM Krzysztof Kozlowski
<krzysztof.kozlowski@canonical.com> wrote:
>
> On Wed, 19 Jan 2022 at 02:50, Rob Herring <robh@kernel.org> wrote:
> >
> > The 'phandle-array' type is a bit ambiguous. It can be either just an
> > array of phandles or an array of phandles plus args. Many schemas for
> > phandle-array properties aren't clear in the schema which case applies
> > though the description usually describes it.
> >
>
> Hi Rob,
>
> I have few questions below.
>
> (...)
>
> > diff --git a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml
> > index 095775c598fa..3a4df2ce1728 100644
> > --- a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml
> > +++ b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml
> > @@ -21,8 +21,7 @@ properties:
> > type: object
> > properties:
> > sound-dai:
> > - $ref: /schemas/types.yaml#/definitions/phandle-array
> > - maxItems: 1
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > description: phandle to the I2S controller
> > required:
> > - sound-dai
>
> This passes the example only because the example was simplified to
> hide dtschema errors.
>
> The cpu dai node is like:
> cpu {
> sound-dai = <&i2s0 0>;
> };
>
> and this fails with errors missing phandle tag in 0.
>
> I am converting rest of Samsung audio bindings to dtschema and have
> trouble expressing this. How schema should express such cpu node?
The above hunk should be reverted. I'll drop that hunk.
Rob
^ permalink raw reply
* Re: [PATCH v3 4/5] drivers: bus: add driver for initializing the SSC bus on (some) qcom SoCs
From: Saravana Kannan @ 2022-01-24 21:16 UTC (permalink / raw)
To: michael.srba
Cc: Andy Gross, Bjorn Andersson, Rob Herring, Stephen Boyd,
Philipp Zabel, Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, linux-arm-msm, devicetree
In-Reply-To: <20220124121853.23600-4-michael.srba@seznam.cz>
On Mon, Jan 24, 2022 at 4:21 AM <michael.srba@seznam.cz> wrote:
>
> From: Michael Srba <Michael.Srba@seznam.cz>
>
> This patch adds bindings for the AHB bus which exposes the SCC block in
> the global address space. This bus (and the SSC block itself) is present
> on certain qcom SoCs.
>
> In typical configuration, this bus (as some of the clocks and registers
> that we need to manipulate) is not accessible to Linux, and the resources
> on this bus are indirectly accessed by communicating with a hexagon CPU
> core residing in the SSC block. In this configuration, the hypervisor is
> the one performing the bus initialization for the purposes of bringing
> the haxagon CPU core out of reset.
>
> However, it is possible to change the configuration, in which case this
> driver will initialize the bus.
>
> In combination with drivers for resources on the SSC bus, this driver can
> aid in debugging, and for example with a TLMM driver can be used to
> directly access SSC-dedicated GPIO pins, removing the need to commit
> to a particular usecase during hw design.
>
> Finally, until open firmware for the hexagon core is available, this
> approach allows for using sensors hooked up to SSC-dedicated GPIO pins
> on mainline Linux simply by utilizing the existing in-tree drivers for
> these sensors.
>
> Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
> ---
> CHANGES:
> - v2: none
> - v3: fix clang warning
> ---
> drivers/bus/Kconfig | 6 +
> drivers/bus/Makefile | 1 +
> drivers/bus/qcom-ssc-block-bus.c | 365 +++++++++++++++++++++++++++++++
> 3 files changed, 372 insertions(+)
> create mode 100644 drivers/bus/qcom-ssc-block-bus.c
>
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index 3c68e174a113..f2b2e3098491 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -173,6 +173,12 @@ config SUNXI_RSB
> with various RSB based devices, such as AXP223, AXP8XX PMICs,
> and AC100/AC200 ICs.
>
> +config QCOM_SSC_BLOCK_BUS
> + bool "Qualcomm SSC Block Bus Init Driver"
> + help
> + Say y here to enable support for initializing the bus that connects the SSC block's internal
> + bus to the cNoC on (some) qcom SoCs
> +
> config TEGRA_ACONNECT
> tristate "Tegra ACONNECT Bus Driver"
> depends on ARCH_TEGRA_210_SOC
> diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
> index 52c2f35a26a9..e6756e83a9c4 100644
> --- a/drivers/bus/Makefile
> +++ b/drivers/bus/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_OMAP_INTERCONNECT) += omap_l3_smx.o omap_l3_noc.o
>
> obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
> obj-$(CONFIG_QCOM_EBI2) += qcom-ebi2.o
> +obj-$(CONFIG_QCOM_SSC_BLOCK_BUS) += qcom-ssc-block-bus.o
> obj-$(CONFIG_SUN50I_DE2_BUS) += sun50i-de2.o
> obj-$(CONFIG_SUNXI_RSB) += sunxi-rsb.o
> obj-$(CONFIG_OF) += simple-pm-bus.o
> diff --git a/drivers/bus/qcom-ssc-block-bus.c b/drivers/bus/qcom-ssc-block-bus.c
> new file mode 100644
> index 000000000000..a93c7350a231
> --- /dev/null
> +++ b/drivers/bus/qcom-ssc-block-bus.c
> @@ -0,0 +1,365 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright (c) 2021, Michael Srba
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_clock.h>
> +#include <linux/pm_domain.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +
> +/* AXI Halt Register Offsets */
> +#define AXI_HALTREQ_REG 0x0
> +#define AXI_HALTACK_REG 0x4
> +#define AXI_IDLE_REG 0x8
> +
> +static const char *qcom_ssc_block_pd_names[] = {
> + "ssc_cx",
> + "ssc_mx"
> +};
> +
> +struct qcom_ssc_block_bus_data {
> + int num_pds;
> + const char **pd_names;
> + struct device *pds[ARRAY_SIZE(qcom_ssc_block_pd_names)];
> + char __iomem *reg_mpm_sscaon_config0; // MPM - msm power manager; AON - always-on
> + char __iomem *reg_mpm_sscaon_config1; // that's as much as we know about these
> + struct regmap *halt_map;
> + u32 ssc_axi_halt;
> + struct clk *xo_clk;
> + struct clk *aggre2_clk;
> + struct clk *gcc_im_sleep_clk;
> + struct clk *aggre2_north_clk;
> + struct clk *ssc_xo_clk;
> + struct clk *ssc_ahbs_clk;
> + struct reset_control *ssc_bcr;
> + struct reset_control *ssc_reset;
> +};
> +
> +static void reg32_set_bits(char __iomem *reg, u32 value)
> +{
> + u32 tmp = ioread32(reg);
> +
> + iowrite32(tmp | value, reg);
> +}
> +
> +static void reg32_clear_bits(char __iomem *reg, u32 value)
> +{
> + u32 tmp = ioread32(reg);
> +
> + iowrite32(tmp & (~value), reg);
> +}
> +
> +
> +static int qcom_ssc_block_bus_init(struct device *dev)
> +{
> + int ret;
> +
> + struct qcom_ssc_block_bus_data *data = dev_get_drvdata(dev);
> +
> + clk_prepare_enable(data->xo_clk);
> + clk_prepare_enable(data->aggre2_clk);
> +
> + clk_prepare_enable(data->gcc_im_sleep_clk);
> +
> + reg32_clear_bits(data->reg_mpm_sscaon_config0, BIT(4) | BIT(5));
> + reg32_clear_bits(data->reg_mpm_sscaon_config1, BIT(31));
> +
> + clk_disable(data->aggre2_north_clk);
> +
> + ret = reset_control_deassert(data->ssc_reset);
> + if (ret) {
> + dev_err(dev, "error deasserting ssc_reset: %d\n", ret);
> + return ret;
> + }
> +
> + clk_prepare_enable(data->aggre2_north_clk);
> +
> + ret = reset_control_deassert(data->ssc_bcr);
> + if (ret) {
> + dev_err(dev, "error deasserting ssc_bcr: %d\n", ret);
> + return ret;
> + }
> +
> + regmap_write(data->halt_map, data->ssc_axi_halt + AXI_HALTREQ_REG, 0);
> +
> + clk_prepare_enable(data->ssc_xo_clk);
> +
> + clk_prepare_enable(data->ssc_ahbs_clk);
> +
> + return 0;
> +}
> +
> +static int qcom_ssc_block_bus_deinit(struct device *dev)
> +{
> + int ret;
> +
> + struct qcom_ssc_block_bus_data *data = dev_get_drvdata(dev);
> +
> + clk_disable(data->ssc_xo_clk);
> + clk_disable(data->ssc_ahbs_clk);
> +
> + ret = reset_control_assert(data->ssc_bcr);
> + if (ret) {
> + dev_err(dev, "error asserting ssc_bcr: %d\n", ret);
> + return ret;
> + }
> +
> + regmap_write(data->halt_map, data->ssc_axi_halt + AXI_HALTREQ_REG, 1);
> +
> + reg32_set_bits(data->reg_mpm_sscaon_config1, BIT(31));
> + reg32_set_bits(data->reg_mpm_sscaon_config0, BIT(4) | BIT(5));
> +
> + ret = reset_control_assert(data->ssc_reset);
> + if (ret) {
> + dev_err(dev, "error asserting ssc_reset: %d\n", ret);
> + return ret;
> + }
> +
> + clk_disable(data->gcc_im_sleep_clk);
> +
> + clk_disable(data->aggre2_north_clk);
> +
> + clk_disable(data->aggre2_clk);
> + clk_disable(data->xo_clk);
> +
> + return 0;
> +}
> +
> +
> +static int qcom_ssc_block_bus_pds_attach(struct device *dev, struct device **pds,
> + const char **pd_names, size_t num_pds)
> +{
> + int ret;
> + int i;
> +
> + for (i = 0; i < num_pds; i++) {
> + pds[i] = dev_pm_domain_attach_by_name(dev, pd_names[i]);
> + if (IS_ERR_OR_NULL(pds[i])) {
> + ret = PTR_ERR(pds[i]) ? : -ENODATA;
> + goto unroll_attach;
> + }
> + }
> +
> + return num_pds;
> +
> +unroll_attach:
> + for (i--; i >= 0; i--)
> + dev_pm_domain_detach(pds[i], false);
> +
> + return ret;
> +};
> +
> +static void qcom_ssc_block_bus_pds_detach(struct device *dev, struct device **pds, size_t num_pds)
> +{
> + int i;
> +
> + for (i = 0; i < num_pds; i++)
> + dev_pm_domain_detach(pds[i], false);
> +}
> +
> +static int qcom_ssc_block_bus_pds_enable(struct device **pds, size_t num_pds)
> +{
> + int ret;
> + int i;
> +
> + for (i = 0; i < num_pds; i++) {
> + dev_pm_genpd_set_performance_state(pds[i], INT_MAX);
> + ret = pm_runtime_get_sync(pds[i]);
> + if (ret < 0)
> + goto unroll_pd_votes;
> + }
> +
> + return 0;
> +
> +unroll_pd_votes:
> + for (i--; i >= 0; i--) {
> + dev_pm_genpd_set_performance_state(pds[i], 0);
> + pm_runtime_put(pds[i]);
> + }
> +
> + return ret;
> +};
> +
> +static void qcom_ssc_block_bus_pds_disable(struct device **pds, size_t num_pds)
> +{
> + int i;
> +
> + for (i = 0; i < num_pds; i++) {
> + dev_pm_genpd_set_performance_state(pds[i], 0);
> + pm_runtime_put(pds[i]);
> + }
> +}
> +
> +static int qcom_ssc_block_bus_probe(struct platform_device *pdev)
> +{
> + struct qcom_ssc_block_bus_data *data;
> + struct device_node *np = pdev->dev.of_node;
> + struct of_phandle_args halt_args;
> + struct resource *res;
> + int ret;
> +
> + if (np)
> + of_platform_populate(np, NULL, NULL, &pdev->dev);
This is something that needs to be done all the way at the end. If you
fail to probe this device, how does it make sense to have its child
devices populated/available?
-Saravana
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, data);
> +
> + data->pd_names = qcom_ssc_block_pd_names;
> + data->num_pds = ARRAY_SIZE(qcom_ssc_block_pd_names);
> +
> + ret = qcom_ssc_block_bus_pds_attach(&pdev->dev, data->pds, data->pd_names, data->num_pds);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "error when attaching power domains: %d\n", ret);
> + return ret;
> + }
> +
> + ret = qcom_ssc_block_bus_pds_enable(data->pds, data->num_pds);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "error when enabling power domains: %d\n", ret);
> + return ret;
> + }
> +
> + // the meaning of the bits in these two registers is sadly not documented,
> + // the set/clear operations are just copying what qcom does
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpm_sscaon_config0");
> + data->reg_mpm_sscaon_config0 = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(data->reg_mpm_sscaon_config0)) {
> + ret = PTR_ERR(data->reg_mpm_sscaon_config0);
> + dev_err(&pdev->dev, "failed to ioremap mpm_sscaon_config0 (err: %d)\n", ret);
> + return ret;
> + }
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpm_sscaon_config0");
> + data->reg_mpm_sscaon_config1 = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(data->reg_mpm_sscaon_config1)) {
> + ret = PTR_ERR(data->reg_mpm_sscaon_config1);
> + dev_err(&pdev->dev, "failed to ioremap mpm_sscaon_config1 (err: %d)\n", ret);
> + return ret;
> + }
> +
> + data->ssc_bcr = devm_reset_control_get_exclusive(&pdev->dev, "ssc_bcr");
> + if (IS_ERR(data->ssc_bcr)) {
> + ret = PTR_ERR(data->ssc_bcr);
> + dev_err(&pdev->dev, "failed to acquire reset: scc_bcr (err: %d)\n", ret);
> + return ret;
> + }
> + data->ssc_reset = devm_reset_control_get_exclusive(&pdev->dev, "ssc_reset");
> + if (IS_ERR(data->ssc_reset)) {
> + ret = PTR_ERR(data->ssc_reset);
> + dev_err(&pdev->dev, "failed to acquire reset: ssc_reset: (err: %d)\n", ret);
> + return ret;
> + }
> +
> + data->xo_clk = devm_clk_get(&pdev->dev, "xo");
> + if (IS_ERR(data->xo_clk)) {
> + ret = PTR_ERR(data->xo_clk);
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to get clock: xo (err: %d)\n", ret);
> + return ret;
> + }
> +
> + data->aggre2_clk = devm_clk_get(&pdev->dev, "aggre2");
> + if (IS_ERR(data->aggre2_clk)) {
> + ret = PTR_ERR(data->aggre2_clk);
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to get clock: aggre2 (err: %d)\n", ret);
> + return ret;
> + }
> +
> + data->gcc_im_sleep_clk = devm_clk_get(&pdev->dev, "gcc_im_sleep");
> + if (IS_ERR(data->gcc_im_sleep_clk)) {
> + ret = PTR_ERR(data->gcc_im_sleep_clk);
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to get clock: gcc_im_sleep (err: %d)\n", ret);
> + return ret;
> + }
> +
> + data->aggre2_north_clk = devm_clk_get(&pdev->dev, "aggre2_north");
> + if (IS_ERR(data->aggre2_north_clk)) {
> + ret = PTR_ERR(data->aggre2_north_clk);
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to get clock: aggre2_north (err: %d)\n", ret);
> + return ret;
> + }
> +
> + data->ssc_xo_clk = devm_clk_get(&pdev->dev, "ssc_xo");
> + if (IS_ERR(data->ssc_xo_clk)) {
> + ret = PTR_ERR(data->ssc_xo_clk);
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to get clock: ssc_xo (err: %d)\n", ret);
> + return ret;
> + }
> +
> + data->ssc_ahbs_clk = devm_clk_get(&pdev->dev, "ssc_ahbs");
> + if (IS_ERR(data->ssc_ahbs_clk)) {
> + ret = PTR_ERR(data->ssc_ahbs_clk);
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to get clock: ssc_ahbs (err: %d)\n", ret);
> + return ret;
> + }
> +
> + ret = of_parse_phandle_with_fixed_args(pdev->dev.of_node, "qcom,halt-regs", 1, 0,
> + &halt_args);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to parse qcom,halt-regs\n");
> + return -EINVAL;
> + }
> +
> + data->halt_map = syscon_node_to_regmap(halt_args.np);
> + of_node_put(halt_args.np);
> + if (IS_ERR(data->halt_map))
> + return PTR_ERR(data->halt_map);
> +
> + data->ssc_axi_halt = halt_args.args[0];
> +
> + qcom_ssc_block_bus_init(&pdev->dev);
> +
> + return 0;
> +}
> +
> +static int qcom_ssc_block_bus_remove(struct platform_device *pdev)
> +{
> + struct qcom_ssc_block_bus_data *data = platform_get_drvdata(pdev);
> +
> + qcom_ssc_block_bus_deinit(&pdev->dev);
> +
> + iounmap(data->reg_mpm_sscaon_config0);
> + iounmap(data->reg_mpm_sscaon_config1);
> +
> + qcom_ssc_block_bus_pds_disable(data->pds, data->num_pds);
> + qcom_ssc_block_bus_pds_detach(&pdev->dev, data->pds, data->num_pds);
> + pm_runtime_disable(&pdev->dev);
> + pm_clk_destroy(&pdev->dev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id qcom_ssc_block_bus_of_match[] = {
> + { .compatible = "qcom,ssc-block-bus", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, qcom_ssc_block_bus_of_match);
> +
> +static struct platform_driver qcom_ssc_block_bus_driver = {
> + .probe = qcom_ssc_block_bus_probe,
> + .remove = qcom_ssc_block_bus_remove,
> + .driver = {
> + .name = "qcom-ssc-block-bus",
> + .of_match_table = qcom_ssc_block_bus_of_match,
> + },
> +};
> +
> +module_platform_driver(qcom_ssc_block_bus_driver);
> +
> +MODULE_DESCRIPTION("A driver for handling the init sequence needed for accessing the SSC block on (some) qcom SoCs over AHB");
> +MODULE_AUTHOR("Michael Srba <Michael.Srba@seznam.cz>");
> +MODULE_LICENSE("GPL v2");
> --
> 2.34.1
>
^ permalink raw reply
* [RESEND PATCH 1/2] dt-bindings: firmware: arm,scmi: define support for name based regulators
From: David Collins @ 2022-01-24 23:20 UTC (permalink / raw)
To: Rob Herring, Sudeep Holla, devicetree
Cc: David Collins, Mark Brown, Liam Girdwood, Cristian Marussi,
linux-arm-kernel, linux-kernel, linux-arm-msm,
Subbaraman Narayanamurthy
In-Reply-To: <cover.1639099631.git.quic_collinsd@quicinc.com>
Allow SCMI regulator subnodes to be specified either by ID using
the "reg" property or by name using the "regulator-name" property.
Name based SCMI regulator specification helps ensure that an SCMI
agent doesn't need to be aware of the numbering scheme used for
Voltage Domains by the SCMI platform. It also ensures that the
correct Voltage Domain is selected for a given physical regulator.
This cannot be guaranteed with numeric Voltage Domain IDs alone.
Signed-off-by: David Collins <quic_collinsd@quicinc.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/firmware/arm,scmi.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 5c4c6782e052..bc4a84fe25d2 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -155,7 +155,7 @@ properties:
The list of all regulators provided by this SCMI controller.
patternProperties:
- '^regulators@[0-9a-f]+$':
+ '^regulator.+$':
type: object
$ref: "../regulator/regulator.yaml#"
@@ -164,8 +164,13 @@ properties:
maxItems: 1
description: Identifier for the voltage regulator.
- required:
- - reg
+ regulator-name: true
+
+ anyOf:
+ - required:
+ - reg
+ - required:
+ - regulator-name
additionalProperties: false
--
2.17.1
^ permalink raw reply related
* [PATCH 5.16 0502/1039] of: fdt: Aggregate the processing of "linux,usable-memory-range"
From: Greg Kroah-Hartman @ 2022-01-24 18:38 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-efi
Cc: Greg Kroah-Hartman, stable, Rob Herring, Zhen Lei, Pingfan Liu,
Dave Kleikamp, John Donnelly, Catalin Marinas, Will Deacon,
linux-arm-kernel, Sasha Levin
In-Reply-To: <20220124184125.121143506@linuxfoundation.org>
From: Zhen Lei <thunder.leizhen@huawei.com>
[ Upstream commit 8347b41748c3019157312fbe7f8a6792ae396eb7 ]
Currently, we parse the "linux,usable-memory-range" property in
early_init_dt_scan_chosen(), to obtain the specified memory range of the
crash kernel. We then reserve the required memory after
early_init_dt_scan_memory() has identified all available physical memory.
Because the two pieces of code are separated far, the readability and
maintainability are reduced. So bring them together.
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
(change the prototype of early_init_dt_check_for_usable_mem_range(), in
order to use it outside)
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Acked-by: John Donnelly <john.p.donnelly@oracle.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
To: devicetree@vger.kernel.org
To: linux-efi@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/of/fdt.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index bdca35284cebd..5a238a933eb29 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -965,18 +965,22 @@ static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
elfcorehdr_addr, elfcorehdr_size);
}
-static phys_addr_t cap_mem_addr;
-static phys_addr_t cap_mem_size;
+static unsigned long chosen_node_offset = -FDT_ERR_NOTFOUND;
/**
* early_init_dt_check_for_usable_mem_range - Decode usable memory range
* location from flat tree
- * @node: reference to node containing usable memory range location ('chosen')
*/
-static void __init early_init_dt_check_for_usable_mem_range(unsigned long node)
+static void __init early_init_dt_check_for_usable_mem_range(void)
{
const __be32 *prop;
int len;
+ phys_addr_t cap_mem_addr;
+ phys_addr_t cap_mem_size;
+ unsigned long node = chosen_node_offset;
+
+ if ((long)node < 0)
+ return;
pr_debug("Looking for usable-memory-range property... ");
@@ -989,6 +993,8 @@ static void __init early_init_dt_check_for_usable_mem_range(unsigned long node)
pr_debug("cap_mem_start=%pa cap_mem_size=%pa\n", &cap_mem_addr,
&cap_mem_size);
+
+ memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
}
#ifdef CONFIG_SERIAL_EARLYCON
@@ -1137,9 +1143,10 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
(strcmp(uname, "chosen") != 0 && strcmp(uname, "chosen@0") != 0))
return 0;
+ chosen_node_offset = node;
+
early_init_dt_check_for_initrd(node);
early_init_dt_check_for_elfcorehdr(node);
- early_init_dt_check_for_usable_mem_range(node);
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", &l);
@@ -1275,7 +1282,7 @@ void __init early_init_dt_scan_nodes(void)
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
/* Handle linux,usable-memory-range property */
- memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
+ early_init_dt_check_for_usable_mem_range();
}
bool __init early_init_dt_scan(void *params)
--
2.34.1
^ permalink raw reply related
* [RESEND PATCH 0/2] regulator: scmi: add support for registering SCMI regulators by name
From: David Collins @ 2022-01-24 23:20 UTC (permalink / raw)
To: Rob Herring, Sudeep Holla, Mark Brown, Liam Girdwood, devicetree
Cc: David Collins, Cristian Marussi, linux-arm-kernel, linux-kernel,
linux-arm-msm, Subbaraman Narayanamurthy
Add support to register SCMI regulator subnodes based on an SCMI
Voltage Domain name specified via the 'regulator-name' device tree
property. In doing so, make the 'reg' property optional with the
constraint that at least one of 'reg' or 'regulator-name' must be
specified. If both are specified, then both must match the
Voltage Domain data exposed by the SCMI platform.
Name based SCMI regulator registration helps ensure that an SCMI
agent doesn't need to be aware of the numbering scheme used for
Voltage Domains by the SCMI platform. It also ensures that the
correct Voltage Domain is selected for a given physical regulator.
This cannot be guaranteed with numeric Voltage Domain IDs alone.
David Collins (2):
dt-bindings: firmware: arm,scmi: define support for name based
regulators
regulator: scmi: add support for registering SCMI regulators by name
.../bindings/firmware/arm,scmi.yaml | 11 +++-
drivers/regulator/scmi-regulator.c | 57 ++++++++++++++++++-
2 files changed, 62 insertions(+), 6 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH v3 3/5] dt-bindings: bus: add device tree bindings for qcom,ssc-block-bus
From: Rob Herring @ 2022-01-24 23:43 UTC (permalink / raw)
To: michael.srba
Cc: Andy Gross, Bjorn Andersson, Stephen Boyd, Philipp Zabel,
Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, devicetree
In-Reply-To: <20220124121853.23600-3-michael.srba@seznam.cz>
On Mon, Jan 24, 2022 at 01:18:51PM +0100, michael.srba@seznam.cz wrote:
> From: Michael Srba <Michael.Srba@seznam.cz>
>
> This patch adds bindings for the AHB bus which exposes the SCC block in
> the global address space. This bus (and the SSC block itself) is present
> on certain qcom SoCs.
>
> In typical configuration, this bus (as some of the clocks and registers
> that we need to manipulate) is not accessible to the OS, and the
> resources on this bus are indirectly accessed by communicating with a
> hexagon CPU core residing in the SSC block. In this configuration, the
> hypervisor is the one performing the bus initialization for the purposes
> of bringing the haxagon CPU core out of reset.
>
> However, it is possible to change the configuration, in which case this
> binding serves to allow the OS to initialize the bus.
>
> Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
> ---
> CHANGES:
> - v2: fix issues caught by by dt-schema
> - v3: none
> ---
> Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml | 159 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
You should adjust your git setup for this long line.
> 1 file changed, 159 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml
>
> diff --git a/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml b/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml
> new file mode 100644
> index 000000000000..f3f4a991337b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml
> @@ -0,0 +1,159 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bus/qcom,ssc-block-bus.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: The AHB Bus Providing a Global View of the SSC Block on (some) qcom SoCs
> +
> +maintainers:
> + - Michael Srba <Michael.Srba@seznam.cz>
> +
> +description: |
> + This binding describes the dependencies (clocks, resets, power domains) which
> + need to be turned on in a sequence before communication over the AHB bus
> + becomes possible.
> +
> + Additionally, the reg property is used to pass to the driver the location of
> + two sadly undocumented registers which need to be poked as part of the sequence.
> +
> + Currently, this binding is known to apply to msm8998. If the binding applies
> + in it's current form, the compatible should contain "qcom,ssc-block-bus-v1".
> + If the binding needs tweaking in order to apply to another SoC, this binding
> + shall be extended.
Rather than explaining this, follow normal practice for
> +
> +
> +properties:
> + compatible:
> + contains:
Drop contains.
> + items:
> + - enum: [ qcom,ssc-block-bus-v1 ]
qcom,msm8998-ssc-block-bus
And IMO, that should be the only compatible for now. If some other
identical implementation appears, then it can use
'qcom,msm8998-ssc-block-bus' too. That seems doubtful given there's a
bunch of both older and new QCom SoCs already out there and this doesn't
really seem like something reused unchanged.
> + - const: qcom,ssc-block-bus
> + description:
> + Shall contain "qcom,ssc-block-bus"
Don't repeat what the schema says in free form text.
> +
> + reg:
> + description: |
> + Shall contain the addresses of the SSCAON_CONFIG0 and SSCAON_CONFIG1
> + registers
> + minItems: 2
> + maxItems: 2
> +
> + reg-names:
> + items:
> + - const: mpm_sscaon_config0
> + - const: mpm_sscaon_config1
> +
> + '#address-cells':
> + enum: [ 1, 2 ]
> +
> + '#size-cells':
> + enum: [ 1, 2 ]
> +
> + ranges: true
> +
> + clocks:
> + description: |
> + Clock phandles for the xo, aggre2, gcc_im_sleep, aggre2_north,
> + ssc_xo and ssc_ahbs clocks
Again, don't repeat.
> + minItems: 6
> + maxItems: 6
> +
> + clock-names:
> + items:
> + - const: xo
> + - const: aggre2
> + - const: gcc_im_sleep
> + - const: aggre2_north
> + - const: ssc_xo
> + - const: ssc_ahbs
> +
> + power-domains:
> + description: Power domain phandles for the ssc_cx and ssc_mx power domains
> + minItems: 2
> + maxItems: 2
> +
> + power-domain-names:
> + items:
> + - const: ssc_cx
> + - const: ssc_mx
> +
> + resets:
> + description: |
> + Reset phandles for the ssc_reset and ssc_bcr resets (note: ssc_bcr is the
> + branch control register associated with the ssc_xo and ssc_ahbs clocks)
> + minItems: 2
> + maxItems: 2
> +
> + reset-names:
> + items:
> + - const: ssc_reset
> + - const: ssc_bcr
> +
> + qcom,halt-regs:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + description:
> + Phandle reference to a syscon representing TCSR followed by the
> + offset within syscon for the ssc AXI halt register.
This can be a bit stricter:
items:
- items:
- description: Phandle reference to a syscon representing TCSR
- description: offset for the ssc AXI halt register
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - '#address-cells'
> + - '#size-cells'
> + - ranges
> + - clocks
> + - clock-names
> + - power-domains
> + - power-domain-names
> + - resets
> + - reset-names
> + - qcom,halt-regs
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/qcom,gcc-msm8998.h>
> + #include <dt-bindings/clock/qcom,rpmcc.h>
> + #include <dt-bindings/power/qcom-rpmpd.h>
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + ssc_ahb_slave: bus@10ac008 { // devices under this node are physically located in the SSC block, connected to an ssc-internal bus;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + compatible = "qcom,ssc-block-bus";
> + reg = <0x10ac008 0x4>, <0x10ac010 0x4>;
> + reg-names = "mpm_sscaon_config0", "mpm_sscaon_config1";
> +
> + clocks = <&xo>,
> + <&rpmcc RPM_SMD_AGGR2_NOC_CLK>,
> + <&gcc GCC_IM_SLEEP>,
> + <&gcc AGGRE2_SNOC_NORTH_AXI>,
> + <&gcc SSC_XO>,
> + <&gcc SSC_CNOC_AHBS_CLK>;
> + clock-names = "xo", "aggre2", "gcc_im_sleep", "aggre2_north", "ssc_xo", "ssc_ahbs";
> +
> + resets = <&gcc GCC_SSC_RESET>, <&gcc GCC_SSC_BCR>;
> + reset-names = "ssc_reset", "ssc_bcr";
> +
> + power-domains = <&rpmpd MSM8998_SSCCX>, <&rpmpd MSM8998_SSCMX>;
> + power-domain-names = "ssc_cx", "ssc_mx";
> +
> + qcom,halt-regs = <&tcsr_mutex_regs 0x26000>;
> +
> + ssc_tlmm: pinctrl@5e10000 {
> + compatible = "qcom,msm8998-ssc-tlmm-pinctrl";
> + reg = <0x5E10000 0x10000>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&ssc_tlmm 0 0 20>;
> + };
> + };
> + };
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: input: Add bindings for Azoteq IQS7222A/B/C
From: Rob Herring @ 2022-01-24 23:27 UTC (permalink / raw)
To: Jeff LaBundy; +Cc: dmitry.torokhov, linux-input, devicetree
In-Reply-To: <20220123194232.85288-2-jeff@labundy.com>
On Sun, Jan 23, 2022 at 01:42:31PM -0600, Jeff LaBundy wrote:
> This patch adds bindings for the Azoteq IQS7222A/B/C family of
> capacitive touch controllers.
Overall, wow, that's a lot of properties. It leaves me wondering why
does this h/w need so many and others don't?
>
> Signed-off-by: Jeff LaBundy <jeff@labundy.com>
> ---
> .../devicetree/bindings/input/iqs7222.yaml | 967 ++++++++++++++++++
azoteq,iqs7222.yaml
> 1 file changed, 967 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/iqs7222.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/iqs7222.yaml b/Documentation/devicetree/bindings/input/iqs7222.yaml
> new file mode 100644
> index 000000000000..0c23d1d49ebd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/iqs7222.yaml
> @@ -0,0 +1,967 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/iqs7222.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Azoteq IQS7222A/B/C Capacitive Touch Controller
> +
> +maintainers:
> + - Jeff LaBundy <jeff@labundy.com>
> +
> +description: |
> + The Azoteq IQS7222A, IQS7222B and IQS7222C are multichannel capacitive touch
> + controllers that feature additional sensing capabilities.
> +
> + Link to datasheets: https://www.azoteq.com/
> +
> +properties:
> + compatible:
> + enum:
> + - azoteq,iqs7222a
> + - azoteq,iqs7222b
> + - azoteq,iqs7222c
> +
> + reg:
> + maxItems: 1
> +
> + irq-gpios:
Use 'interrupts'. Interrupt capable GPIO lines are also interrupt
providers.
> + maxItems: 1
> + description:
> + Specifies the GPIO connected to the device's active-low RDY output.
> +
> + reset-gpios:
> + maxItems: 1
> + description:
> + Specifies the GPIO connected to the device's active-low MCLR input. The
> + device is temporarily held in hardware reset prior to initialization if
> + this property is present.
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + azoteq,rf-filt-enable:
> + type: boolean
> + description: Enables the device's internal RF filter.
> +
> + azoteq,max-counts:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3]
> + description: |
> + Specifies the maximum counts as follows:
Counts of what?
> + 0: 1023
> + 1: 2047
> + 2: 4095
> + 3: 16384
> +
> + azoteq,auto-mode:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3]
> + description: |
> + Specifies the number of conversions to occur before an interrupt is
> + generated as follows:
> + 0: 4
> + 1: 8
> + 2: 16
> + 3: 32
> +
> + azoteq,ati-frac-div-fine:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 31
> + description: Specifies the preloaded ATI fine fractional divider.
> +
> + azoteq,ati-frac-div-coarse:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 31
> + description: Specifies the preloaded ATI coarse fractional divider.
> +
> + azoteq,ati-comp-select:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 1023
> + description: Specifies the preloaded ATI compensation selection.
> +
> + azoteq,lta-beta-lp:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description:
> + Specifies the long-term average filter damping factor to be applied during
> + low-power mode.
> +
> + azoteq,lta-beta-np:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description:
> + Specifies the long-term average filter damping factor to be applied during
> + normal-power mode.
> +
> + azoteq,counts-beta-lp:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description:
> + Specifies the counts filter damping factor to be applied during low-power
> + mode.
> +
> + azoteq,counts-beta-np:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description:
> + Specifies the counts filter damping factor to be applied during normal-
> + power mode.
> +
> + azoteq,lta-fast-beta-lp:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description:
> + Specifies the long-term average filter fast damping factor to be applied
> + during low-power mode.
> +
> + azoteq,lta-fast-beta-np:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description:
> + Specifies the long-term average filter fast damping factor to be applied
> + during normal-power mode.
> +
> + azoteq,timeout-ati-ms:
> + multipleOf: 500
> + minimum: 0
> + maximum: 32767500
> + description:
> + Specifies the delay (in ms) before ATI is retried following an ATI error.
> +
> + azoteq,rate-ati-ms:
> + minimum: 0
> + maximum: 65535
> + description: Specifies the rate (in ms) at which ATI status is evaluated.
> +
> + azoteq,timeout-np-ms:
> + minimum: 0
> + maximum: 65535
> + description:
> + Specifies the length of time (in ms) to wait for an event before moving
> + from normal-power mode to low-power mode.
> +
> + azoteq,rate-np-ms:
> + minimum: 0
> + maximum: 3000
> + description: Specifies the report rate (in ms) during normal-power mode.
> +
> + azoteq,timeout-lp-ms:
> + minimum: 0
> + maximum: 65535
> + description:
> + Specifies the length of time (in ms) to wait for an event before moving
> + from low-power mode to ultra-low-power mode.
> +
> + azoteq,rate-lp-ms:
> + minimum: 0
> + maximum: 3000
> + description: Specifies the report rate (in ms) during low-power mode.
> +
> + azoteq,timeout-ulp-ms:
> + minimum: 0
> + maximum: 65535
> + description:
> + Specifies the rate (in ms) at which channels not regularly sampled during
> + ultra-low-power mode are updated.
> +
> + azoteq,rate-ulp-ms:
> + minimum: 0
> + maximum: 3000
> + description: Specifies the report rate (in ms) during ultra-low-power mode.
> +
> +patternProperties:
> + "^cycle-[0-9]$":
> + type: object
> + description: Represents a conversion cycle serving two sensing channels.
> +
> + properties:
> + azoteq,conv-period:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 255
> + description: Specifies the cycle's conversion period.
> +
> + azoteq,conv-frac:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 255
> + description: Specifies the cycle's conversion frequency fraction.
> +
> + azoteq,tx-enable:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 9
> + items:
> + minimum: 0
> + maximum: 8
> + description: Specifies the CTx pin(s) associated with the cycle.
> +
> + azoteq,rx-float-inactive:
> + type: boolean
> + description: Floats any inactive CRx pins instead of grounding them.
> +
> + azoteq,dead-time-enable:
> + type: boolean
> + description:
> + Increases the denominator of the conversion frequency formula by one.
> +
> + azoteq,tx-freq-fosc:
> + type: boolean
> + description:
> + Fixes the conversion frequency to that of the device's core clock.
> +
> + azoteq,vbias-enable:
> + type: boolean
> + description: Enables the bias voltage for use during inductive sensing.
> +
> + azoteq,sense-mode:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3]
> + description: |
> + Specifies the cycle's sensing mode as follows:
> + 0: None
> + 1: Self capacitive
> + 2: Mutual capacitive
> + 3: Inductive
> +
> + Note that in the case of IQS7222A, cycles 5 and 6 are restricted to
> + Hall-effect sensing.
> +
> + azoteq,iref-enable:
> + type: boolean
> + description:
> + Enables the current reference for use during various sensing modes.
> +
> + azoteq,iref-level:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description: Specifies the cycle's current reference level.
> +
> + azoteq,iref-trim:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description: Specifies the cycle's current reference trim.
> +
> + dependencies:
> + azoteq,iref-level: ["azoteq,iref-enable"]
> + azoteq,iref-trim: ["azoteq,iref-enable"]
> +
> + additionalProperties: false
> +
> + "^channel-[0-19]$":
> + type: object
> + description:
> + Represents a single sensing channel. A channel is active if defined and
> + inactive otherwise.
> +
> + Note that in the case of IQS7222A, channels 10 and 11 are restricted to
> + Hall-effect sensing with events reported on channel 10 only.
> +
> + properties:
> + azoteq,ulp-allow:
> + type: boolean
> + description:
> + Permits the device to enter ultra-low-power mode while the channel
> + lies in a state of touch or proximity.
> +
> + azoteq,ref-select:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 9
> + description: Specifies a separate reference channel to be followed.
> +
> + azoteq,ref-weight:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 65535
> + description: Specifies the relative weight of the reference channel.
> +
> + azoteq,use-prox:
> + type: boolean
> + description:
> + Activates the reference channel in response to proximity events
> + instead of touch events.
> +
> + azoteq,ati-band:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3]
> + description: |
> + Specifies the channel's ATI band as a fraction of its ATI target as
> + follows:
> + 0: 1/16
> + 1: 1/8
> + 2: 1/4
> + 3: 1/2
> +
> + azoteq,global-halt:
> + type: boolean
> + description:
> + Specifies that the channel's long-term average is to freeze if any
> + other participating channel lies in a proximity or touch state.
> +
> + azoteq,invert-enable:
> + type: boolean
> + description:
> + Inverts the polarity of the states reported for proximity and touch
> + events relative to their respective thresholds.
> +
> + azoteq,dual-direction:
> + type: boolean
> + description:
> + Specifies that the channel's long-term average is to freeze in the
> + presence of either increasing or decreasing counts, thereby permit-
> + ting events to be reported in either direction.
> +
> + azoteq,rx-enable:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 4
> + items:
> + minimum: 0
> + maximum: 7
> + description: Specifies the CRx pin(s) associated with the channel.
> +
> + azoteq,samp-cap-double:
> + type: boolean
> + description: Doubles the sampling capacitance from 40 pF to 80 pF.
> +
> + azoteq,vref-half:
> + type: boolean
> + description: Halves the discharge threshold from 1.0 V to 0.5 V.
> +
> + azoteq,proj-bias:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3]
> + description: |
> + Specifies the bias current applied during mutual (projected)
> + capacitive sensing as follows:
> + 0: 2 uA
> + 1: 5 uA
> + 2: 7 uA
> + 3: 10 uA
> +
> + azoteq,ati-target:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + multipleOf: 8
> + minimum: 0
> + maximum: 2040
> + description: Specifies the channel's ATI target.
> +
> + azoteq,ati-base:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + multipleOf: 16
> + minimum: 0
> + maximum: 496
> + description: Specifies the channel's ATI base.
> +
> + azoteq,ati-mode:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3, 4, 5]
> + description: |
> + Specifies the channel's ATI mode as follows:
> + 0: Disabled
> + 1: Compensation
> + 2: Compensation divider
> + 3: Fine fractional divider
> + 4: Coarse fractional divider
> + 5: Full
> +
> + azoteq,ati-frac-div-fine:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 31
> + description: Specifies the channel's ATI fine fractional divider.
> +
> + azoteq,ati-frac-mult-coarse:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description: Specifies the channel's ATI coarse fractional multiplier.
> +
> + azoteq,ati-frac-div-coarse:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 31
> + description: Specifies the channel's ATI coarse fractional divider.
> +
> + azoteq,ati-comp-div:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 31
> + description: Specifies the channel's ATI compensation divider.
> +
> + azoteq,ati-comp-select:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 1023
> + description: Specifies the channel's ATI compensation selection.
> +
> + azoteq,debounce-enter:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description: Specifies the channel's debounce entrance factor.
> +
> + azoteq,debounce-exit:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description: Specifies the channel's debounce exit factor.
> +
> + patternProperties:
> + "^event-(prox|touch)$":
> + type: object
> + description:
> + Represents a proximity or touch event reported by the channel.
> +
> + properties:
> + azoteq,gpio-select:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 3
> + items:
> + minimum: 0
> + maximum: 2
> + description: |
> + Specifies one or more GPIO mapped to the event as follows:
> + 0: GPIO0
> + 1: GPIO3 (IQS7222C only)
> + 2: GPIO4 (IQS7222C only)
> +
> + Note that although multiple events can be mapped to a single
> + GPIO, they must all be of the same type (proximity, touch or
> + slider gesture).
> +
> + azoteq,thresh:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Specifies the threshold for the event. Valid entries range from
> + 0-127 and 0-255 for proximity and touch events, respectively.
> +
> + azoteq,hyst:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 255
> + description:
> + Specifies the hysteresis for the event (touch events only).
> +
> + azoteq,timeout-press-ms:
> + multipleOf: 500
> + minimum: 0
> + maximum: 127500
> + description:
> + Specifies the length of time (in ms) to wait before automatically
> + releasing a press event. Specify zero to allow the press state to
> + persist indefinitely.
> +
> + The IQS7222B does not feature channel-specific timeouts; the time-
> + out specified for any one channel applies to all channels.
> +
> + linux,code:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Numeric key or switch code associated with the event. Specify
> + KEY_RESERVED (0) to opt out of event reporting.
> +
> + linux,input-type:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [1, 5]
> + default: 1
> + description:
> + Specifies whether the event is to be interpreted as a key (1)
> + or a switch (5).
> +
> + required:
> + - linux,code
> +
> + additionalProperties: false
> +
> + dependencies:
> + azoteq,ref-weight: ["azoteq,ref-select"]
> + azoteq,use-prox: ["azoteq,ref-select"]
> +
> + additionalProperties: false
> +
> + "^slider-[0-1]$":
> + type: object
> + description: Represents a slider comprising three or four channels.
> +
> + properties:
> + azoteq,channel-select:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 3
> + maxItems: 4
> + items:
> + minimum: 0
> + maximum: 9
> + description:
> + Specifies the order of the channels that participate in the slider.
> +
> + azoteq,slider-size:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 65535
> + description:
> + Specifies the slider's one-dimensional resolution, equal to the
> + maximum coordinate plus one.
> +
> + azoteq,lower-cal:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 255
> + description: Specifies the slider's lower starting point.
> +
> + azoteq,upper-cal:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 255
> + description: Specifies the slider's upper starting point.
> +
> + azoteq,top-speed:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 65535
> + description:
> + Specifies the speed of movement after which coordinate filtering is
> + no longer applied.
> +
> + azoteq,bottom-speed:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + multipleOf: 4
> + minimum: 0
> + maximum: 1020
> + description:
> + Specifies the speed of movement after which coordinate filtering is
> + linearly reduced.
> +
> + azoteq,bottom-beta:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 7
> + description:
> + Specifies the coordinate filter damping factor to be applied
> + while the speed of movement is below that which is specified
> + by azoteq,bottom-speed.
> +
> + azoteq,static-beta:
> + type: boolean
> + description:
> + Applies the coordinate filter damping factor specified by
> + azoteq,bottom-beta regardless of the speed of movement.
> +
> + azoteq,use-prox:
> + type: boolean
> + description:
> + Directs the slider to respond to the proximity states of the selected
> + channels instead of their corresponding touch states. Note the slider
> + cannot report granular coordinates during a state of proximity.
> +
> + linux,axis:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Specifies the absolute axis to which coordinates are mapped. Specify
> + ABS_WHEEL to operate the slider as a wheel (IQS7222C only).
> +
> + patternProperties:
> + "^event-(press|tap|(swipe|flick)-(pos|neg))$":
> + type: object
> + description:
> + Represents a press or gesture (IQS7222A only) event reported by
> + the slider.
> +
> + properties:
> + linux,code:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Numeric key code associated with the event.
> +
> + azoteq,gesture-max-ms:
> + multipleOf: 4
> + minimum: 0
> + maximum: 1020
> + description:
> + Specifies the length of time (in ms) within which a tap, swipe
> + or flick gesture must be completed in order to be acknowledged
> + by the device. The number specified for any one swipe or flick
> + gesture applies to all remaining swipe or flick gestures.
> +
> + azoteq,gesture-min-ms:
> + multipleOf: 4
> + minimum: 0
> + maximum: 124
> + description:
> + Specifies the length of time (in ms) for which a tap gesture must
> + be held in order to be acknowledged by the device.
> +
> + azoteq,gesture-dist:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + multipleOf: 16
> + minimum: 0
> + maximum: 4080
> + description:
> + Specifies the distance across which a swipe or flick gesture must
> + travel in order to be acknowledged by the device. The number spec-
> + ified for any one swipe or flick gesture applies to all remaining
> + swipe or flick gestures.
> +
> + azoteq,gpio-select:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 1
> + items:
> + minimum: 0
> + maximum: 0
> + description: |
> + Specifies an individual GPIO mapped to a tap, swipe or flick
> + gesture as follows:
> + 0: GPIO0
> + 1: GPIO3 (reserved)
> + 2: GPIO4 (reserved)
> +
> + Note that although multiple events can be mapped to a single
> + GPIO, they must all be of the same type (proximity, touch or
> + slider gesture).
> +
> + required:
> + - linux,code
> +
> + additionalProperties: false
> +
> + required:
> + - azoteq,channel-select
> +
> + additionalProperties: false
> +
> + "^gpio-[0-2]$":
> + type: object
> + description: |
> + Represents a GPIO mapped to one or more events as follows:
> + gpio-0: GPIO0
> + gpio-1: GPIO3 (IQS7222C only)
> + gpio-2: GPIO4 (IQS7222C only)
> +
> + allOf:
> + - $ref: ../pinctrl/pincfg-node.yaml#
> +
> + properties:
> + drive-open-drain: true
> +
> + additionalProperties: false
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: azoteq,iqs7222b
> +
> + then:
> + patternProperties:
> + "^cycle-[0-9]$":
> + properties:
> + azoteq,iref-enable: false
> +
> + "^channel-[0-19]$":
> + properties:
> + azoteq,ref-select: false
> +
> + patternProperties:
> + "^event-(prox|touch)$":
> + properties:
> + azoteq,gpio-select: false
> +
> + "^slider-[0-1]$": false
> +
> + "^gpio-[0-2]$": false
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: azoteq,iqs7222a
> +
> + then:
> + patternProperties:
> + "^channel-[0-19]$":
> + patternProperties:
> + "^event-(prox|touch)$":
> + properties:
> + azoteq,gpio-select:
> + maxItems: 1
> + items:
> + maximum: 0
> +
> + "^slider-[0-1]$":
> + properties:
> + azoteq,slider-size:
> + multipleOf: 16
> + maximum: 4080
> +
> + azoteq,top-speed:
> + multipleOf: 4
> + maximum: 1020
> +
> + else:
> + patternProperties:
> + "^channel-[0-19]$":
> + properties:
> + azoteq,ulp-allow: false
> +
> + "^slider-[0-1]$":
> + patternProperties:
> + "^event-(press|tap|(swipe|flick)-(pos|neg))$":
> + properties:
> + azoteq,gesture-max-ms: false
> +
> + azoteq,gesture-min-ms: false
> +
> + azoteq,gesture-dist: false
> +
> + azoteq,gpio-select: false
> +
> +required:
> + - compatible
> + - reg
> + - irq-gpios
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/input/input.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + iqs7222a@44 {
> + compatible = "azoteq,iqs7222a";
> + reg = <0x44>;
> + irq-gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
> + azoteq,lta-beta-lp = <7>;
> + azoteq,lta-beta-np = <8>;
> + azoteq,counts-beta-lp = <2>;
> + azoteq,counts-beta-np = <3>;
> + azoteq,lta-fast-beta-lp = <3>;
> + azoteq,lta-fast-beta-np = <4>;
> +
> + cycle-0 {
> + azoteq,conv-period = <5>;
> + azoteq,conv-frac = <127>;
> + azoteq,tx-enable = <1>, <2>, <4>, <5>;
> + azoteq,dead-time-enable;
> + azoteq,sense-mode = <2>;
> + };
> +
> + cycle-1 {
> + azoteq,conv-period = <5>;
> + azoteq,conv-frac = <127>;
> + azoteq,tx-enable = <5>;
> + azoteq,dead-time-enable;
> + azoteq,sense-mode = <2>;
> + };
> +
> + cycle-2 {
> + azoteq,conv-period = <5>;
> + azoteq,conv-frac = <127>;
> + azoteq,tx-enable = <4>;
> + azoteq,dead-time-enable;
> + azoteq,sense-mode = <2>;
> + };
> +
> + cycle-3 {
> + azoteq,conv-period = <5>;
> + azoteq,conv-frac = <127>;
> + azoteq,tx-enable = <2>;
> + azoteq,dead-time-enable;
> + azoteq,sense-mode = <2>;
> + };
> +
> + cycle-4 {
> + azoteq,conv-period = <5>;
> + azoteq,conv-frac = <127>;
> + azoteq,tx-enable = <1>;
> + azoteq,dead-time-enable;
> + azoteq,sense-mode = <2>;
> + };
> +
> + cycle-5 {
> + azoteq,conv-period = <2>;
> + azoteq,conv-frac = <0>;
> + };
> +
> + cycle-6 {
> + azoteq,conv-period = <2>;
> + azoteq,conv-frac = <0>;
> + };
> +
> + channel-0 {
> + azoteq,ulp-allow;
> + azoteq,global-halt;
> + azoteq,invert-enable;
> + azoteq,rx-enable = <3>;
> + azoteq,ati-target = <800>;
> + azoteq,ati-base = <208>;
> + azoteq,ati-mode = <5>;
> + };
> +
> + channel-1 {
> + azoteq,global-halt;
> + azoteq,invert-enable;
> + azoteq,rx-enable = <3>;
> + azoteq,ati-target = <496>;
> + azoteq,ati-base = <208>;
> + azoteq,ati-mode = <5>;
> + };
> +
> + channel-2 {
> + azoteq,global-halt;
> + azoteq,invert-enable;
> + azoteq,rx-enable = <3>;
> + azoteq,ati-target = <496>;
> + azoteq,ati-base = <208>;
> + azoteq,ati-mode = <5>;
> + };
> +
> + channel-3 {
> + azoteq,global-halt;
> + azoteq,invert-enable;
> + azoteq,rx-enable = <3>;
> + azoteq,ati-target = <496>;
> + azoteq,ati-base = <208>;
> + azoteq,ati-mode = <5>;
> + };
> +
> + channel-4 {
> + azoteq,global-halt;
> + azoteq,invert-enable;
> + azoteq,rx-enable = <3>;
> + azoteq,ati-target = <496>;
> + azoteq,ati-base = <208>;
> + azoteq,ati-mode = <5>;
> + };
> +
> + channel-5 {
> + azoteq,ulp-allow;
> + azoteq,global-halt;
> + azoteq,invert-enable;
> + azoteq,rx-enable = <6>;
> + azoteq,ati-target = <800>;
> + azoteq,ati-base = <144>;
> + azoteq,ati-mode = <5>;
> + };
> +
> + channel-6 {
> + azoteq,global-halt;
> + azoteq,invert-enable;
> + azoteq,rx-enable = <6>;
> + azoteq,ati-target = <496>;
> + azoteq,ati-base = <160>;
> + azoteq,ati-mode = <5>;
> +
> + event-touch {
> + linux,code = <KEY_MUTE>;
> + };
> + };
> +
> + channel-7 {
> + azoteq,global-halt;
> + azoteq,invert-enable;
> + azoteq,rx-enable = <6>;
> + azoteq,ati-target = <496>;
> + azoteq,ati-base = <160>;
> + azoteq,ati-mode = <5>;
> +
> + event-touch {
> + linux,code = <KEY_VOLUMEDOWN>;
> + };
> + };
> +
> + channel-8 {
> + azoteq,global-halt;
> + azoteq,invert-enable;
> + azoteq,rx-enable = <6>;
> + azoteq,ati-target = <496>;
> + azoteq,ati-base = <160>;
> + azoteq,ati-mode = <5>;
> +
> + event-touch {
> + linux,code = <KEY_VOLUMEUP>;
> + };
> + };
> +
> + channel-9 {
> + azoteq,global-halt;
> + azoteq,invert-enable;
> + azoteq,rx-enable = <6>;
> + azoteq,ati-target = <496>;
> + azoteq,ati-base = <160>;
> + azoteq,ati-mode = <5>;
> +
> + event-touch {
> + linux,code = <KEY_POWER>;
> + };
> + };
> +
> + channel-10 {
> + azoteq,ulp-allow;
> + azoteq,ati-target = <496>;
> + azoteq,ati-base = <112>;
> +
> + event-touch {
> + linux,code = <SW_LID>;
> + linux,input-type = <EV_SW>;
> + };
> + };
> +
> + channel-11 {
> + azoteq,ati-target = <496>;
> + azoteq,ati-base = <112>;
> + };
> +
> + slider-0 {
> + azoteq,channel-select = <1>, <2>, <3>, <4>;
> + azoteq,slider-size = <4080>;
> + azoteq,upper-cal = <50>;
> + azoteq,lower-cal = <30>;
> + azoteq,top-speed = <200>;
> + azoteq,bottom-speed = <1>;
> + azoteq,bottom-beta = <3>;
> +
> + event-tap {
> + linux,code = <KEY_PLAYPAUSE>;
> + azoteq,gesture-max-ms = <600>;
> + azoteq,gesture-min-ms = <24>;
> + };
> +
> + event-flick-pos {
> + linux,code = <KEY_NEXTSONG>;
> + azoteq,gesture-max-ms = <600>;
> + azoteq,gesture-dist = <816>;
> + };
> +
> + event-flick-neg {
> + linux,code = <KEY_PREVIOUSSONG>;
> + };
> + };
> + };
> + };
> +
> +...
> --
> 2.25.1
>
>
^ permalink raw reply
* [PATCH 0/2] ic2: mux: pca9541: add delayed-release support
From: Zev Weiss @ 2022-01-24 21:38 UTC (permalink / raw)
To: linux-i2c, Guenter Roeck, Peter Rosin, Rob Herring
Cc: Zev Weiss, openbmc, linux-kernel, devicetree
Hello,
This series adds support for a new pca9541 device-tree property
("release-delay-us"), which delays releasing ownership of the bus
after a transaction for a configurable duration, anticipating that
another transaction may follow shortly. By avoiding a
release/reacquisition between transactions, this can provide a
substantial performance improvement for back-to-back operations -- on
a Delta AHE-50DC (ASPEED AST1250) system running OpenBMC with LM25066
PMICs behind PCA9541-arbitrated busses, a setting of 10000 (10 ms)
reduces the median latency of reading hwmon sysfs files from 2.28 ms
to 0.99 ms (a 57% improvement).
Thanks,
Zev
Zev Weiss (2):
i2c: mux: pca9541: add delayed-release support
dt-bindings: i2c: add nxp,pca9541 release-delay-us property
.../devicetree/bindings/i2c/nxp,pca9541.txt | 10 ++++
drivers/i2c/muxes/i2c-mux-pca9541.c | 56 ++++++++++++++++---
2 files changed, 57 insertions(+), 9 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 2/2] dt-bindings: i2c: add nxp,pca9541 release-delay-us property
From: Zev Weiss @ 2022-01-24 21:38 UTC (permalink / raw)
To: linux-i2c, Rob Herring, devicetree
Cc: Zev Weiss, openbmc, linux-kernel, Guenter Roeck, Peter Rosin
In-Reply-To: <20220124213850.3766-1-zev@bewilderbeest.net>
This property can be used to reduce arbitration overhead on busy i2c
busses by retaining ownership for a brief period in anticipation of
another transaction in the near future.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
---
Documentation/devicetree/bindings/i2c/nxp,pca9541.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt b/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
index 42bfc09c8918..c755da59d6ec 100644
--- a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
+++ b/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
@@ -6,6 +6,14 @@ Required Properties:
- reg: The I2C address of the device.
+Optional Properties:
+
+ - release-delay-us: the number of microseconds to delay before
+ releasing the bus after a transaction. If unspecified the default
+ is zero (the bus is released immediately). Non-zero values can
+ reduce arbitration overhead for back-to-back transactions, at the
+ cost of delaying the other master's access to the bus.
+
The following required properties are defined externally:
- I2C arbitration bus node. See i2c-arb.txt in this directory.
@@ -13,9 +21,11 @@ Required Properties:
Example:
+ #include <dt-bindings/mux/mux.h>
i2c-arbitrator@74 {
compatible = "nxp,pca9541";
reg = <0x74>;
+ release-delay-us = <20000>;
i2c-arb {
#address-cells = <1>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/5] dt-bindings: clock: gcc-msm8998: Add definitions of SSC-related clocks
From: Stephen Boyd @ 2022-01-25 0:12 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Philipp Zabel, Rob Herring,
michael.srba
Cc: Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, devicetree,
Michael Srba
In-Reply-To: <20220123183547.15830-1-michael.srba@seznam.cz>
Quoting michael.srba@seznam.cz (2022-01-23 10:35:43)
> From: Michael Srba <Michael.Srba@seznam.cz>
>
> This patch adds definitions of four clocks which need to be manipulated
> in order to initialize the AHB bus which exposes the SCC block in the
> global address space.
>
> Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
PLease Cc linux-clk@vger.kernel.org on clk related patches.
^ permalink raw reply
* Re: [RFC PATCH 1/2] dt-bindings: mtd: partitions: Document new dynamic-partitions node
From: Rafał Miłecki @ 2022-01-24 22:02 UTC (permalink / raw)
To: Ansuel Smith, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Rob Herring, linux-mtd, devicetree,
linux-kernel
In-Reply-To: <20220120202615.28076-2-ansuelsmth@gmail.com>
On 20.01.2022 21:26, Ansuel Smith wrote:
> Document new dynamic-partitions node used to provide an of node for
> partition registred at runtime by parsers. This is required for nvmem
> system to declare and detect nvmem-cells.
>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
> .../mtd/partitions/dynamic-partitions.yaml | 59 +++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml
>
> diff --git a/Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml
> new file mode 100644
> index 000000000000..7528e49f2d7e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/partitions/dynamic-partitions.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Dynamic partitions
> +
> +description: |
> + This binding can be used on platforms which have partitions registered at
> + runtime by parsers or partition table present on the flash. Example are
> + partitions declared from smem parser or cmdlinepart. This will create an
> + of node for these dynamic partition where systems like Nvmem can get a
> + reference to register nvmem-cells.
> +
> + The partition table should be a node named "dynamic-partitions".
> + Partitions are then defined as subnodes. Only the label is required
> + as any other data will be taken from the parser.
> +
> +maintainers:
> + - Ansuel Smith <ansuelsmth@gmail.com>
> +
> +properties:
> + compatible:
> + const: dynamic-partitions
> +
> +patternProperties:
> + "@[0-9a-f]+$":
> + $ref: "partition.yaml#"
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + partitions {
> + compatible = "qcom,smem";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> +
> + dynamic-partitions {
> + compatible = "dynamic-partitions";
> +
> + art: art {
> + label = "0:art";
> + read-only;
> + compatible = "nvmem-cells";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + macaddr_art_0: macaddr@0 {
> + reg = <0x0 0x6>;
> + };
> +
> + macaddr_art_6: macaddr@6 {
> + reg = <0x6 0x6>;
> + };
> + };
> + };
First of all: I fully support such a feature. I need it for Broadom
platforms that use "brcm,bcm947xx-cfe-partitions" dynamic partitions.
In my case bootloader partition is created dynamically (it doesn't have
const offset and size). It contains NVMEM data however that needs to be
described in DT.
This binding however looks loose and confusing to me.
First of all did you really mean to use "qcom,smem"? My first guess is
you meant "qcom,smem-part".
Secondly can't we have partitions defined just as subnodes of the
partitions { ... }; node?
I think sth like below would make more sense:
partitions {
compatible = "qcom,smem-part";
art {
label = "0:art";
read-only;
compatible = "nvmem-cells";
#address-cells = <1>;
#size-cells = <1>;
macaddr_art_0: macaddr@0 {
reg = <0x0 0x6>;
};
macaddr_art_6: macaddr@6 {
reg = <0x6 0x6>;
};
};
};
Then I could also reuse that for something like:
partitions {
compatible = "brcm,bcm947xx-cfe-partitions";
partition-0 {
compatible = "nvmem-cells";
label = "boot";
#address-cells = <1>;
#size-cells = <1>;
mac: macaddr@0 {
reg = <0x100 0x6>;
};
}
};
^ permalink raw reply
* Re: [RFC 5/6] ASoC: dt-bindings: samsung,snow: convert to dtschema
From: Rob Herring @ 2022-01-25 0:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Liam Girdwood, Mark Brown, Sylwester Nawrocki, Jonathan Bakker,
alsa-devel, devicetree, linux-kernel
In-Reply-To: <20220124170336.164320-5-krzysztof.kozlowski@canonical.com>
On Mon, Jan 24, 2022 at 06:03:35PM +0100, Krzysztof Kozlowski wrote:
> Convert the audio complex on Google Snow boards with Samsung Exynos SoC
> to DT schema format.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
>
> ---
>
> TODO: The DTS do not pass cleanly. cpu/sound-dai should be fixed.
> ---
> .../bindings/sound/samsung,snow.yaml | 78 +++++++++++++++++++
> .../devicetree/bindings/sound/snow.txt | 31 --------
> 2 files changed, 78 insertions(+), 31 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/sound/samsung,snow.yaml
> delete mode 100644 Documentation/devicetree/bindings/sound/snow.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/samsung,snow.yaml b/Documentation/devicetree/bindings/sound/samsung,snow.yaml
> new file mode 100644
> index 000000000000..df969b384839
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/samsung,snow.yaml
> @@ -0,0 +1,78 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/samsung,snow.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Google Snow audio complex with MAX9809x codec
> +
> +maintainers:
> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> + - Sylwester Nawrocki <s.nawrocki@samsung.com>
> +
> +properties:
> + compatible:
> + enum:
> + - google,snow-audio-max98090
> + - google,snow-audio-max98091
> + - google,snow-audio-max98095
> +
> + codec:
> + type: object
> + properties:
> + sound-dai:
> + description: List of phandles to the CODEC and HDMI IP nodes.
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + - description: Phandle to the MAX98090, MAX98091 or MAX98095 CODEC.
> + - description: Phandle to the HDMI IP block node.
Thinking about this and the issue you raised some more, we should make
sure there's a common definition for sound-dai. And then here, it should
just be the number of entries ('maxItems: 1').
Rob
^ permalink raw reply
* [PATCH net-next 0/4] dt-binding: can: add common CAN controller bindings to existing CAN driver bindings
From: Marc Kleine-Budde @ 2022-01-24 22:06 UTC (permalink / raw)
To: linux-can; +Cc: Rob Herring, devicetree
Hello,
this series adds the common CAN controller binding to the existing CAN
driver bindings.
regards,
Marc
^ permalink raw reply
* [PATCH net-next 1/4] dt-binding: can: mcp251xfd: include common CAN controller bindings
From: Marc Kleine-Budde @ 2022-01-24 22:06 UTC (permalink / raw)
To: linux-can
Cc: Rob Herring, devicetree, Marc Kleine-Budde, Manivannan Sadhasivam,
Thomas Kopp
In-Reply-To: <20220124220653.3477172-1-mkl@pengutronix.de>
Since commit
| 1f9234401ce0 ("dt-bindings: can: add can-controller.yaml")
there is a common CAN controller binding. Add this to the mcp251xfd
binding.
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Thomas Kopp <thomas.kopp@microchip.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
.../devicetree/bindings/net/can/microchip,mcp251xfd.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
index 2a884c1fe0e0..b3826af6bd6e 100644
--- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
@@ -11,6 +11,9 @@ title:
maintainers:
- Marc Kleine-Budde <mkl@pengutronix.de>
+allOf:
+ - $ref: can-controller.yaml#
+
properties:
compatible:
oneOf:
--
2.34.1
^ permalink raw reply related
* [PATCH net-next 4/4] dt-binding: can: rcar-can: include common CAN controller bindings
From: Marc Kleine-Budde @ 2022-01-24 22:06 UTC (permalink / raw)
To: linux-can
Cc: Rob Herring, devicetree, Marc Kleine-Budde, Yoshihiro Shimoda,
lrich Hecht
In-Reply-To: <20220124220653.3477172-1-mkl@pengutronix.de>
Since commit
| 1f9234401ce0 ("dt-bindings: can: add can-controller.yaml")
there is a common CAN controller binding. Add this to the rcar-can
binding.
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: lrich Hecht <uli+renesas@fpond.eu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
.../devicetree/bindings/net/can/renesas,rcar-can.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml
index fadc871fd6b0..64247d3635e9 100644
--- a/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml
+++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml
@@ -9,6 +9,9 @@ title: Renesas R-Car CAN Controller
maintainers:
- Sergei Shtylyov <sergei.shtylyov@gmail.com>
+allOf:
+ - $ref: can-controller.yaml#
+
properties:
compatible:
oneOf:
--
2.34.1
^ permalink raw reply related
* [PATCH net-next 2/4] dt-binding: can: sun4i_can: include common CAN controller bindings
From: Marc Kleine-Budde @ 2022-01-24 22:06 UTC (permalink / raw)
To: linux-can
Cc: Rob Herring, devicetree, Marc Kleine-Budde, Evgeny Boger,
Gerhard Bertelsmann
In-Reply-To: <20220124220653.3477172-1-mkl@pengutronix.de>
Since commit
| 1f9234401ce0 ("dt-bindings: can: add can-controller.yaml")
there is a common CAN controller binding. Add this to the sun4i_can
binding.
Cc: Evgeny Boger <boger@wirenboard.com>
Cc: Gerhard Bertelsmann <info@gerhard-bertelsmann.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
.../devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml
index c93fe9d3ea82..3c51b2d02957 100644
--- a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml
+++ b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml
@@ -10,6 +10,9 @@ maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
+allOf:
+ - $ref: can-controller.yaml#
+
properties:
compatible:
oneOf:
--
2.34.1
^ permalink raw reply related
* [PATCH net-next 3/4] dt-binding: can: m_can: include common CAN controller bindings
From: Marc Kleine-Budde @ 2022-01-24 22:06 UTC (permalink / raw)
To: linux-can
Cc: Rob Herring, devicetree, Marc Kleine-Budde,
Chandrasekar Ramakrishnan
In-Reply-To: <20220124220653.3477172-1-mkl@pengutronix.de>
Since commit
| 1f9234401ce0 ("dt-bindings: can: add can-controller.yaml")
there is a common CAN controller binding. Add this to the m_can
binding.
Cc: Chandrasekar Ramakrishnan <rcsekar@samsung.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
index fb547e26c676..710880dc7594 100644
--- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
+++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
@@ -11,6 +11,9 @@ description: Bosch MCAN controller for CAN bus
maintainers:
- Sriram Dash <sriram.dash@samsung.com>
+allOf:
+ - $ref: can-controller.yaml#
+
properties:
compatible:
const: bosch,m_can
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v9 1/2] dt-bindings: clk: microchip: Add Microchip PolarFire host binding
From: Stephen Boyd @ 2022-01-25 0:26 UTC (permalink / raw)
To: conor.dooley, devicetree, linux-clk, mturquette, robh+dt
Cc: krzysztof.kozlowski, geert, david.abdurachmanov, palmer,
daire.mcnamara, cyril.jean, conor.dooley, Rob Herring
In-Reply-To: <20211216140022.16146-2-conor.dooley@microchip.com>
Quoting conor.dooley@microchip.com (2021-12-16 06:00:21)
> From: Daire McNamara <daire.mcnamara@microchip.com>
>
> Add device tree bindings for the Microchip PolarFire system
> clock controller
>
> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
>
> Signed-off-by: Daire McNamara <daire.mcnamara@microchip.com>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
Applied to clk-next
^ permalink raw reply
* [RESEND PATCH 0/2] regulator: scmi: add support for registering SCMI regulators by name
From: David Collins @ 2022-01-25 0:27 UTC (permalink / raw)
To: Rob Herring, Sudeep Holla, Mark Brown, Liam Girdwood, devicetree
Cc: David Collins, Cristian Marussi, linux-arm-kernel, linux-kernel,
linux-arm-msm, Subbaraman Narayanamurthy
Add support to register SCMI regulator subnodes based on an SCMI
Voltage Domain name specified via the 'regulator-name' device tree
property. In doing so, make the 'reg' property optional with the
constraint that at least one of 'reg' or 'regulator-name' must be
specified. If both are specified, then both must match the
Voltage Domain data exposed by the SCMI platform.
Name based SCMI regulator registration helps ensure that an SCMI
agent doesn't need to be aware of the numbering scheme used for
Voltage Domains by the SCMI platform. It also ensures that the
correct Voltage Domain is selected for a given physical regulator.
This cannot be guaranteed with numeric Voltage Domain IDs alone.
David Collins (2):
dt-bindings: firmware: arm,scmi: define support for name based
regulators
regulator: scmi: add support for registering SCMI regulators by name
.../bindings/firmware/arm,scmi.yaml | 11 +++-
drivers/regulator/scmi-regulator.c | 57 ++++++++++++++++++-
2 files changed, 62 insertions(+), 6 deletions(-)
--
2.17.1
^ permalink raw reply
* [RESEND PATCH 1/2] dt-bindings: firmware: arm,scmi: define support for name based regulators
From: David Collins @ 2022-01-25 0:27 UTC (permalink / raw)
To: Rob Herring, Sudeep Holla, devicetree
Cc: David Collins, Mark Brown, Liam Girdwood, Cristian Marussi,
linux-arm-kernel, linux-kernel, linux-arm-msm,
Subbaraman Narayanamurthy
In-Reply-To: <cover.1643069954.git.quic_collinsd@quicinc.com>
Allow SCMI regulator subnodes to be specified either by ID using
the "reg" property or by name using the "regulator-name" property.
Name based SCMI regulator specification helps ensure that an SCMI
agent doesn't need to be aware of the numbering scheme used for
Voltage Domains by the SCMI platform. It also ensures that the
correct Voltage Domain is selected for a given physical regulator.
This cannot be guaranteed with numeric Voltage Domain IDs alone.
Signed-off-by: David Collins <quic_collinsd@quicinc.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/firmware/arm,scmi.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 5c4c6782e052..bc4a84fe25d2 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -155,7 +155,7 @@ properties:
The list of all regulators provided by this SCMI controller.
patternProperties:
- '^regulators@[0-9a-f]+$':
+ '^regulator.+$':
type: object
$ref: "../regulator/regulator.yaml#"
@@ -164,8 +164,13 @@ properties:
maxItems: 1
description: Identifier for the voltage regulator.
- required:
- - reg
+ regulator-name: true
+
+ anyOf:
+ - required:
+ - reg
+ - required:
+ - regulator-name
additionalProperties: false
--
2.17.1
^ permalink raw reply related
* Re: [RFC PATCH 1/2] dt-bindings: mtd: partitions: Document new dynamic-partitions node
From: Ansuel Smith @ 2022-01-24 22:12 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, linux-mtd, devicetree, linux-kernel
In-Reply-To: <a823e730-853d-901b-1b9f-937e1ec76444@gmail.com>
On Mon, Jan 24, 2022 at 11:02:24PM +0100, Rafał Miłecki wrote:
> On 20.01.2022 21:26, Ansuel Smith wrote:
> > Document new dynamic-partitions node used to provide an of node for
> > partition registred at runtime by parsers. This is required for nvmem
> > system to declare and detect nvmem-cells.
> >
> > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > ---
> > .../mtd/partitions/dynamic-partitions.yaml | 59 +++++++++++++++++++
> > 1 file changed, 59 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml
> > new file mode 100644
> > index 000000000000..7528e49f2d7e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/partitions/dynamic-partitions.yaml
> > @@ -0,0 +1,59 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mtd/partitions/dynamic-partitions.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Dynamic partitions
> > +
> > +description: |
> > + This binding can be used on platforms which have partitions registered at
> > + runtime by parsers or partition table present on the flash. Example are
> > + partitions declared from smem parser or cmdlinepart. This will create an
> > + of node for these dynamic partition where systems like Nvmem can get a
> > + reference to register nvmem-cells.
> > +
> > + The partition table should be a node named "dynamic-partitions".
> > + Partitions are then defined as subnodes. Only the label is required
> > + as any other data will be taken from the parser.
> > +
> > +maintainers:
> > + - Ansuel Smith <ansuelsmth@gmail.com>
> > +
> > +properties:
> > + compatible:
> > + const: dynamic-partitions
> > +
> > +patternProperties:
> > + "@[0-9a-f]+$":
> > + $ref: "partition.yaml#"
> > +
> > +additionalProperties: true
> > +
> > +examples:
> > + - |
> > + partitions {
> > + compatible = "qcom,smem";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + };
> > +
> > + dynamic-partitions {
> > + compatible = "dynamic-partitions";
> > +
> > + art: art {
> > + label = "0:art";
> > + read-only;
> > + compatible = "nvmem-cells";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + macaddr_art_0: macaddr@0 {
> > + reg = <0x0 0x6>;
> > + };
> > +
> > + macaddr_art_6: macaddr@6 {
> > + reg = <0x6 0x6>;
> > + };
> > + };
> > + };
>
> First of all: I fully support such a feature. I need it for Broadom
> platforms that use "brcm,bcm947xx-cfe-partitions" dynamic partitions.
> In my case bootloader partition is created dynamically (it doesn't have
> const offset and size). It contains NVMEM data however that needs to be
> described in DT.
>
> This binding however looks loose and confusing to me.
>
I agree.
> First of all did you really mean to use "qcom,smem"? My first guess is
> you meant "qcom,smem-part".
>
Yes sorry, I was referring to the smem parser qcom,smem-part
> Secondly can't we have partitions defined just as subnodes of the
> partitions { ... }; node?
>
I would love to use it. My only concern is that due to the fact
that we have to support legacy partition declaring, wonder if this could
create some problem. I'm referring to declaring fixed partition without
using any compatible/standard binding name.
I remember we improved that with the introduction of the nvmem binding
by making the fixed-partition compatible mandatory. But I would like to
have extra check. Wonder if to be on the safe part we can consider
appending to the "dynamic parser" a compatible like "dynamic-partitions"
and use your way to declare them (aka keeping the dynamic-partition and
removing the extra parallel partitions list)
Feel free to tell me it's just a stupid and unnecessary idea. I just
have fear to introduce regression in the partition parsing logic.
>
> I think sth like below would make more sense:
>
> partitions {
> compatible = "qcom,smem-part";
>
> art {
> label = "0:art";
> read-only;
> compatible = "nvmem-cells";
> #address-cells = <1>;
> #size-cells = <1>;
>
> macaddr_art_0: macaddr@0 {
> reg = <0x0 0x6>;
> };
>
> macaddr_art_6: macaddr@6 {
> reg = <0x6 0x6>;
> };
> };
> };
>
>
> Then I could also reuse that for something like:
>
> partitions {
> compatible = "brcm,bcm947xx-cfe-partitions";
>
> partition-0 {
> compatible = "nvmem-cells";
> label = "boot";
>
> #address-cells = <1>;
> #size-cells = <1>;
>
> mac: macaddr@0 {
> reg = <0x100 0x6>;
> };
> }
> };
--
Ansuel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox