* Re: [PATCH resend 0/2] dts: keystone-k2g-evm: Display support
From: Tomi Valkeinen @ 2020-06-02 8:13 UTC (permalink / raw)
To: santosh.shilimkar, Jyri Sarha, dri-devel, ssantosh,
linux-arm-kernel, devicetree
Cc: mark.rutland, praneeth, robh+dt, peter.ujfalusi, tomi.valkeinen,
laurent.pinchart
In-Reply-To: <6749076a-cbc1-d8e2-bc35-2e2a9ad80a6d@oracle.com>
Hi Santosh,
On 14/02/2020 19:40, santosh.shilimkar@oracle.com wrote:
> On 2/14/20 1:22 AM, Jyri Sarha wrote:
>> Resend because the earlier recipient list was wrong.
>>
>> Now that drm/tidss is queued for mainline, lets add display support for
>> k2g-evm. There is no hurry since tidss is out only in v5.7, but it
>> should not harm to have the dts changes in place before that.
>>
>> Jyri Sarha (2):
>> ARM: dts: keystone-k2g: Add DSS node
>> ARM: dts: keystone-k2g-evm: add HDMI video support
>>
>> arch/arm/boot/dts/keystone-k2g-evm.dts | 101 +++++++++++++++++++++++++
>> arch/arm/boot/dts/keystone-k2g.dtsi | 22 ++++++
>> 2 files changed, 123 insertions(+)
>>
> Ok. Will add this to the next queue.
What happened with this one? It used to be in linux-next, but now I don't see it anymore.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH v4 1/2] clk: rockchip: rk3288: Handle clock tree for rk3288w
From: Mylène Josserand @ 2020-06-02 8:06 UTC (permalink / raw)
To: mturquette, sboyd, heiko, robh+dt
Cc: linux-clk, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, mylene.josserand, kernel
In-Reply-To: <20200602080644.11333-1-mylene.josserand@collabora.com>
The revision rk3288w has a different clock tree about "hclk_vio"
clock, according to the BSP kernel code.
This patch handles this difference by detecting which device-tree
we are using. If it is a "rockchip,rk3288-cru", let's register
the clock tree as it was before. If the device-tree node is
"rockchip,rk3288w-cru", we will apply the difference with this
version of this SoC.
Noticed that this new device-tree compatible must be handled in
bootloader such as u-boot.
Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com>
---
drivers/clk/rockchip/clk-rk3288.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
index cc2a177bbdbf..204976e2d0cb 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -425,8 +425,6 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
COMPOSITE(0, "aclk_vio0", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(31), 6, 2, MFLAGS, 0, 5, DFLAGS,
RK3288_CLKGATE_CON(3), 0, GFLAGS),
- DIV(0, "hclk_vio", "aclk_vio0", 0,
- RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
COMPOSITE(0, "aclk_vio1", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(31), 14, 2, MFLAGS, 8, 5, DFLAGS,
RK3288_CLKGATE_CON(3), 2, GFLAGS),
@@ -819,6 +817,16 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
INVERTER(0, "pclk_isp", "pclk_isp_in", RK3288_CLKSEL_CON(29), 3, IFLAGS),
};
+static struct rockchip_clk_branch rk3288w_hclkvio_branch[] __initdata = {
+ DIV(0, "hclk_vio", "aclk_vio1", 0,
+ RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
+};
+
+static struct rockchip_clk_branch rk3288_hclkvio_branch[] __initdata = {
+ DIV(0, "hclk_vio", "aclk_vio0", 0,
+ RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
+};
+
static const char *const rk3288_critical_clocks[] __initconst = {
"aclk_cpu",
"aclk_peri",
@@ -936,6 +944,14 @@ static void __init rk3288_clk_init(struct device_node *np)
RK3288_GRF_SOC_STATUS1);
rockchip_clk_register_branches(ctx, rk3288_clk_branches,
ARRAY_SIZE(rk3288_clk_branches));
+
+ if (of_device_is_compatible(np, "rockchip,rk3288w-cru"))
+ rockchip_clk_register_branches(ctx, rk3288w_hclkvio_branch,
+ ARRAY_SIZE(rk3288w_hclkvio_branch));
+ else
+ rockchip_clk_register_branches(ctx, rk3288_hclkvio_branch,
+ ARRAY_SIZE(rk3288_hclkvio_branch));
+
rockchip_clk_protect_critical(rk3288_critical_clocks,
ARRAY_SIZE(rk3288_critical_clocks));
--
2.26.2
^ permalink raw reply related
* [PATCH v4 2/2] dt-bindings: clocks: rk3288: add rk3288w compatible
From: Mylène Josserand @ 2020-06-02 8:06 UTC (permalink / raw)
To: mturquette, sboyd, heiko, robh+dt
Cc: linux-clk, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, mylene.josserand, kernel
In-Reply-To: <20200602080644.11333-1-mylene.josserand@collabora.com>
Add the possible compatible "rockchip,rk3288w-cru" that handles
the difference between the rk3288 and the new revision rk3288w.
This compatible will be added by bootloaders.
Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com>
---
.../devicetree/bindings/clock/rockchip,rk3288-cru.txt | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt
index 8cb47c39ba53..bf3a9ec19241 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt
@@ -4,9 +4,15 @@ The RK3288 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
+A revision of this SoC is available: rk3288w. The clock tree is a bit
+different so another dt-compatible is available. Noticed that it is only
+setting the difference but there is no automatic revision detection. This
+should be performed by bootloaders.
+
Required Properties:
-- compatible: should be "rockchip,rk3288-cru"
+- compatible: should be "rockchip,rk3288-cru" or "rockchip,rk3288w-cru" in
+ case of this revision of Rockchip rk3288.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
--
2.26.2
^ permalink raw reply related
* [PATCH v4 0/2] ARM: Add Rockchip rk3288w support
From: Mylène Josserand @ 2020-06-02 8:06 UTC (permalink / raw)
To: mturquette, sboyd, heiko, robh+dt
Cc: linux-clk, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, mylene.josserand, kernel
Hello everyone,
Context
-------
Here is my V4 of my patches that add the support for the Rockchip
RK3288w which is a revision of the RK3288. It is mostly the same SOC
except for, at least, one clock tree which is different.
This difference is only known by looking at the BSP kernel [1].
Currently, the mainline kernel will not hang on rk3288w but it is
probably by "chance" because we got an issue on a lower kernel version.
According to Rockchip's U-Boot [2], the rk3288w can be detected using
the HDMI revision number (= 0x1A) in this version of the SOC.
Changelog
---------
This V4 is pretty much the same than the V3. Added the dt-bindings
documentation in clock-controller dt-bindings and fixed some typos
according to Heiko's reviews.
Changes since v3:
- Updated clock-controller's dt-bindings
- Fixed indentation
Best regards,
Mylène Josserand
[1] https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/clk/rockchip/clk-rk3288.c#L960..L964
[2] https://github.com/rockchip-linux/u-boot/blob/next-dev/arch/arm/mach-rockchip/rk3288/rk3288.c#L378..L388
Mylène Josserand (2):
clk: rockchip: rk3288: Handle clock tree for rk3288w
dt-bindings: clocks: rk3288: add possible rk3288w
.../bindings/clock/rockchip,rk3288-cru.txt | 8 +++++++-
drivers/clk/rockchip/clk-rk3288.c | 20 +++++++++++++++++--
2 files changed, 25 insertions(+), 3 deletions(-)
--
2.26.2
^ permalink raw reply
* Re: [PATCH v2 01/12] iio: imu: inv_icm42600: add core of new inv_icm42600 driver
From: Jean-Baptiste Maneyrol @ 2020-06-02 7:56 UTC (permalink / raw)
To: Jonathan Cameron
Cc: robh+dt@kernel.org, robh@kernel.org, mchehab+huawei@kernel.org,
davem@davemloft.net, gregkh@linuxfoundation.org,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20200531123437.05b3df36@archlinux>
Hi Jonathan,
I've given my review tag for the const change of iio_device_get_drvdata(). Would be perfect to have this cleaned up for the v3.
For vddio regulator you are missing something. In all suspend callbacks (system and runtime) I am calling directly regulator_disable to shut vddio off at then end. And in all resume callbacks I am calling inv_icm42600_enable_regulator_vddio() that is turning vddio regulator back on and is sleeping to wait a little for the supply ramp.
Indeed this doesn't look symmetric, but I was not very happy to add a inv_icm42600_disable_regulator_vddio() that would just do regulator_disable, or copy/paste the sleeping value in all resume handlers.
Tell me what you prefer.
Thanks,
JB
From: linux-iio-owner@vger.kernel.org <linux-iio-owner@vger.kernel.org> on behalf of Jonathan Cameron <jic23@kernel.org>
Sent: Sunday, May 31, 2020 13:34
To: Jean-Baptiste Maneyrol <JManeyrol@invensense.com>
Cc: robh+dt@kernel.org <robh+dt@kernel.org>; robh@kernel.org <robh@kernel.org>; mchehab+huawei@kernel.org <mchehab+huawei@kernel.org>; davem@davemloft.net <davem@davemloft.net>; gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>; linux-iio@vger.kernel.org <linux-iio@vger.kernel.org>; devicetree@vger.kernel.org <devicetree@vger.kernel.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 01/12] iio: imu: inv_icm42600: add core of new inv_icm42600 driver
CAUTION: This email originated from outside of the organization. Please make sure the sender is who they say they are and do not click links or open attachments unless you recognize the sender and know the content is safe.
On Wed, 27 May 2020 20:57:00 +0200
Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> wrote:
> Core component of a new driver for InvenSense ICM-426xx devices.
> It includes registers definition, main probe/setup, and device
> utility functions.
>
> ICM-426xx devices are latest generation of 6-axis IMU,
> gyroscope+accelerometer and temperature sensor. This device
> includes a 2K FIFO, supports I2C/I3C/SPI, and provides
> intelligent motion features like pedometer, tilt detection,
> and tap detection.
>
> Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
A few things inline.
Either I'm missing something or I'm guessing vddio is not controllable
on your test board.
> ---
> drivers/iio/imu/inv_icm42600/inv_icm42600.h | 372 ++++++++++
> .../iio/imu/inv_icm42600/inv_icm42600_core.c | 635 ++++++++++++++++++
> 2 files changed, 1007 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600.h
> create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
>
...
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> new file mode 100644
> index 000000000000..81b171d6782c
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> +const struct iio_mount_matrix *
> +inv_icm42600_get_mount_matrix(const struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan)
> +{
> + const struct inv_icm42600_state *st =
> + iio_device_get_drvdata((struct iio_dev *)indio_dev);
If you review my patch to the core, I can get that applied and we can drop
the ugly cast from here!
Just waiting for someone to sanity check it.
> +
> + return &st->orientation;
> +}
...
> +/* Runtime suspend will turn off sensors that are enabled by iio devices. */
> +static int __maybe_unused inv_icm42600_runtime_suspend(struct device *dev)
> +{
> + struct inv_icm42600_state *st = dev_get_drvdata(dev);
> + int ret;
> +
> + mutex_lock(&st->lock);
> +
> + /* disable all sensors */
> + ret = inv_icm42600_set_pwr_mgmt0(st, INV_ICM42600_SENSOR_MODE_OFF,
> + INV_ICM42600_SENSOR_MODE_OFF, false,
> + NULL);
> + if (ret)
> + goto error_unlock;
> +
> + regulator_disable(st->vddio_supply);
Don't seem to turn this on again in runtime_resume..
Why? Definitely needs at least a comment.
> +
> +error_unlock:
> + mutex_unlock(&st->lock);
> + return ret;
> +}
> +
> +/* Sensors are enabled by iio devices, no need to turn them back on here. */
> +static int __maybe_unused inv_icm42600_runtime_resume(struct device *dev)
> +{
> + struct inv_icm42600_state *st = dev_get_drvdata(dev);
> + int ret;
> +
> + mutex_lock(&st->lock);
> +
> + ret = inv_icm42600_enable_regulator_vddio(st);
> +
> + mutex_unlock(&st->lock);
> + return ret;
> +}
> +
> +const struct dev_pm_ops inv_icm42600_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(inv_icm42600_suspend, inv_icm42600_resume)
> + SET_RUNTIME_PM_OPS(inv_icm42600_runtime_suspend,
> + inv_icm42600_runtime_resume, NULL)
> +};
> +EXPORT_SYMBOL_GPL(inv_icm42600_pm_ops);
> +
> +MODULE_AUTHOR("InvenSense, Inc.");
> +MODULE_DESCRIPTION("InvenSense ICM-426xx device driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH v4 08/10] PCI: qcom: Add ipq8064 rev2 variant and set tx term offset
From: Stanimir Varbanov @ 2020-06-02 7:53 UTC (permalink / raw)
To: Ansuel Smith, Bjorn Andersson
Cc: Sham Muthayyan, Andy Gross, Bjorn Helgaas, Rob Herring,
Mark Rutland, Lorenzo Pieralisi, Andrew Murray, Philipp Zabel,
linux-arm-msm, linux-pci, devicetree, linux-kernel
In-Reply-To: <20200514200712.12232-9-ansuelsmth@gmail.com>
Hi,
On 5/14/20 11:07 PM, Ansuel Smith wrote:
> Add tx term offset support to pcie qcom driver need in some revision of
> the ipq806x SoC. Ipq8064 have tx term offset set to 7. Ipq8064-v2 revision
> and ipq8065 have the tx term offset set to 0.
>
> Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index f5398b0d270c..ab6f1bdd24c3 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -45,6 +45,9 @@
> #define PCIE_CAP_CPL_TIMEOUT_DISABLE 0x10
>
> #define PCIE20_PARF_PHY_CTRL 0x40
> +#define PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK GENMASK(20, 16)
I see you changed the mask, did you found the issue in previous v3 mask
and shift?
> +#define PHY_CTRL_PHY_TX0_TERM_OFFSET(x) ((x) << 16)
> +
> #define PCIE20_PARF_PHY_REFCLK 0x4C
> #define PHY_REFCLK_SSP_EN BIT(16)
> #define PHY_REFCLK_USE_PAD BIT(12)
> @@ -363,7 +366,8 @@ static int qcom_pcie_init_2_1_0(struct qcom_pcie *pcie)
> val &= ~BIT(0);
> writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
>
> - if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> + if (of_device_is_compatible(node, "qcom,pcie-ipq8064") |
this should be logical OR
> + of_device_is_compatible(node, "qcom,pcie-ipq8064-v2")) {
> writel(PCS_DEEMPH_TX_DEEMPH_GEN1(24) |
> PCS_DEEMPH_TX_DEEMPH_GEN2_3_5DB(24) |
> PCS_DEEMPH_TX_DEEMPH_GEN2_6DB(34),
> @@ -374,9 +378,18 @@ static int qcom_pcie_init_2_1_0(struct qcom_pcie *pcie)
> writel(PHY_RX0_EQ(4), pcie->parf + PCIE20_PARF_CONFIG_BITS);
> }
>
> + if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> + /* set TX termination offset */
> + val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
> + val &= ~PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK;
> + val |= PHY_CTRL_PHY_TX0_TERM_OFFSET(7);
> + writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> + }
> +
> /* enable external reference clock */
> val = readl(pcie->parf + PCIE20_PARF_PHY_REFCLK);
> - val |= BIT(16);
> + val &= ~PHY_REFCLK_USE_PAD;
> + val |= PHY_REFCLK_SSP_EN;
> writel(val, pcie->parf + PCIE20_PARF_PHY_REFCLK);
>
> /* wait for clock acquisition */
> @@ -1452,6 +1465,7 @@ static int qcom_pcie_probe(struct platform_device *pdev)
> static const struct of_device_id qcom_pcie_match[] = {
> { .compatible = "qcom,pcie-apq8084", .data = &ops_1_0_0 },
> { .compatible = "qcom,pcie-ipq8064", .data = &ops_2_1_0 },
> + { .compatible = "qcom,pcie-ipq8064-v2", .data = &ops_2_1_0 },
> { .compatible = "qcom,pcie-apq8064", .data = &ops_2_1_0 },
> { .compatible = "qcom,pcie-msm8996", .data = &ops_2_3_2 },
> { .compatible = "qcom,pcie-ipq8074", .data = &ops_2_3_3 },
>
--
regards,
Stan
^ permalink raw reply
* Re: [PATCH v2] check: Add 10bit/slave i2c reg flags support
From: Wolfram Sang @ 2020-06-02 7:46 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Devicetree Compiler, Serge Semin, Alexey Malahov,
Thomas Bogendoerfer, Jarkko Nikula, Andy Shevchenko, Frank Rowand,
devicetree, Linux I2C, linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqJeod3Rm4K_7c3AcH8A4aMKKmT97CcbGpRbG4b0yWzrXA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 126 bytes --]
> Easier to just duplicate the define here which Joel's patches do.
Well, seems this case is closed then. Thanks everyone!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] iio: chemical: scd30: add core driver
From: Tomasz Duszynski @ 2020-06-02 7:13 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Tomasz Duszynski, Jonathan Cameron, linux-iio, linux-kernel,
devicetree, robh+dt, andy.shevchenko, pmeerw
In-Reply-To: <20200601144120.000038ba@Huawei.com>
On Mon, Jun 01, 2020 at 02:41:20PM +0100, Jonathan Cameron wrote:
> ...
>
> > > > > > +
> > > > > > + return ret;
> > > > > > +}
> > > > > > +
> > > > > > +int scd30_probe(struct device *dev, int irq, const char *name, void *priv,
> > > > > > + scd30_command_t command)
> > > > > > +{
> > > > > > + static const unsigned long scd30_scan_masks[] = { 0x07, 0x00 };
> > > > > > + struct scd30_state *state;
> > > > > > + struct iio_dev *indio_dev;
> > > > > > + int ret;
> > > > > > + u16 val;
> > > > > > +
> > > > > > + indio_dev = devm_iio_device_alloc(dev, sizeof(*state));
> > > > > > + if (!indio_dev)
> > > > > > + return -ENOMEM;
> > > > > > +
> > > > > > + state = iio_priv(indio_dev);
> > > > > > + state->dev = dev;
> > > > >
> > > > > Doesn't seem to be used.
> > > > >
> > > > > > + state->priv = priv;
> > > > >
> > > > > What's this for? At least at first glance I can't find it being used
> > > > > anywhere.
> > > > >
> > > > > > + state->irq = irq;
> > > > > > + state->pressure_comp = SCD30_PRESSURE_COMP_DEFAULT;
> > > > > > + state->meas_interval = SCD30_MEAS_INTERVAL_DEFAULT;
> > > > > > + state->command = command;
> > > > > > + mutex_init(&state->lock);
> > > > > > + init_completion(&state->meas_ready);
> > > > > > +
> > > > > > + dev_set_drvdata(dev, indio_dev);
> > > > > > +
> > > > > > + indio_dev->dev.parent = dev;
> > > > >
> > > > > Side note that there is a series moving this into the core under revision at
> > > > > the moment. Hopefully I'll remember to fix this up when applying your patch
> > > > > if that one has gone in ahead of it.
> > > > >
> > > > > > + indio_dev->info = &scd30_info;
> > > > > > + indio_dev->name = name;
> > > > > > + indio_dev->channels = scd30_channels;
> > > > > > + indio_dev->num_channels = ARRAY_SIZE(scd30_channels);
> > > > > > + indio_dev->modes = INDIO_DIRECT_MODE;
> > > > > > + indio_dev->available_scan_masks = scd30_scan_masks;
> > > > > > +
> > > > > > + state->vdd = devm_regulator_get(dev, "vdd");
> > > > > > + if (IS_ERR(state->vdd)) {
> > > > > > + if (PTR_ERR(state->vdd) == -EPROBE_DEFER)
> > > > > > + return -EPROBE_DEFER;
> > > > > > +
> > > > > > + dev_err(dev, "failed to get regulator\n");
> > > > > > + return PTR_ERR(state->vdd);
> > > > > > + }
> > > > > > +
> > > > > > + ret = regulator_enable(state->vdd);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > +
> > > > > > + ret = devm_add_action_or_reset(dev, scd30_disable_regulator, state);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > +
> > > > >
> > > > > A comment here on why it makes sense to register this here. What
> > > > > started mesurement? It seems that happens well below here so
> > > > > we should really call this after that start all.
> > > > >
> > > >
> > > > Sensor after being powered up starts in mode it was left in.
> > > > Chances are it was continuous mode and we want to shut it down.
> > >
> > > That's fine. The question is why 'here' as opposed to after the below where you
> > > put it into continuous mode.
> > >
> >
> > Let's suppose sensor got energized and started measuring. Then without
> > registering action which stops measurement we jump to device reset etc.
> >
> > Now if reset failed for whatever reason (same applies to everything
> > below reset) devm will gracefully unwind previous actions but sensor
> > will continue doing his job. But there's no point. Better to save some
> > milliaps for later.
>
> I'm not convinced. Note that in your example, the sensor was already on.
> If we never loaded the driver it would stay on. We should
> deal with only problems we have potentially created.
>
Fair enough.
> If reset fails, it shouldn't 'enable' the sensor hence we are just in
> the same state as if the driver hadn't loaded at all. Also if reset
> fails the chance of a disable succeeding is very low.
>
> The code is much more logical with this being done immediately after
> the action to enable thing we are disabling. So please put it down
> there.
>
>
>
> >
> > In case we have real regulator then there's no real issue because
> > power gets cut off during cleanup.
> >
> > Quite often though there's only a dummy one which does nothing useful
> > except making regulator framework happy.
> >
> > So my thinking here is that we're slightly better off registering
> > scd30_stop_meas() action earlier to prevent such scenario from happening.
> >
> > > >
> > > > > > + ret = devm_add_action_or_reset(dev, scd30_stop_meas, state);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > +
> > > > > > + ret = scd30_reset(state);
> > > > > > + if (ret) {
> > > > > > + dev_err(dev, "failed to reset device: %d\n", ret);
> > > > > > + return ret;
> > > > > > + }
> > > > > > +
> > > > > > + if (state->irq > 0) {
> > > > > > + ret = scd30_setup_trigger(indio_dev);
> > > > > > + if (ret) {
> > > > > > + dev_err(dev, "failed to setup trigger: %d\n", ret);
> > > > > > + return ret;
> > > > > > + }
> > > > > > + }
> > > > > > +
> > > > > > + ret = devm_iio_triggered_buffer_setup(dev, indio_dev, NULL,
> > > > > > + scd30_trigger_handler, NULL);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > +
> > > > > > + ret = scd30_command_read(state, CMD_FW_VERSION, &val);
> > > > > > + if (ret) {
> > > > > > + dev_err(dev, "failed to read firmware version: %d\n", ret);
> > > > > > + return ret;
> > > > > > + }
> > > > > > + dev_info(dev, "firmware version: %d.%d\n", val >> 8, (char)val);
> > > > > > +
> > > > > > + ret = scd30_command_write(state, CMD_MEAS_INTERVAL,
> > > > > > + state->meas_interval);
> > > > > > + if (ret) {
> > > > > > + dev_err(dev, "failed to set measurement interval: %d\n", ret);
> > > > > > + return ret;
> > > > > > + }
> > > > > > +
> > > > > > + ret = scd30_command_write(state, CMD_START_MEAS, state->pressure_comp);
> > > > > > + if (ret) {
> > > > > > + dev_err(dev, "failed to start measurement: %d\n", ret);
> > > > > > + return ret;
> > > > > > + }
> Here is where we should register that cleanup handler.
>
> Jonathan
>
> > > > > > +
> > > > > > + return devm_iio_device_register(dev, indio_dev);
> > > > > > +}
> > > > > > +EXPORT_SYMBOL(scd30_probe);
> > > > > > +
> > > > > > +MODULE_AUTHOR("Tomasz Duszynski <tomasz.duszynski@octakon.com>");
> > > > > > +MODULE_DESCRIPTION("Sensirion SCD30 carbon dioxide sensor core driver");
> > > > > > +MODULE_LICENSE("GPL v2");
> > > > > > --
> > > > > > 2.26.2
> > > > > >
> > > > >
> > >
> > >
>
>
^ permalink raw reply
* Re: [PATCHv1 00/19] Improve SBS battery support
From: Marek Szyprowski @ 2020-06-02 7:17 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Rob Herring, Greg Kroah-Hartman, Rafael J . Wysocki, linux-pm,
devicetree, linux-kernel, kernel, 'Linux Samsung SOC'
In-Reply-To: <20200601170528.r5w3aeijny3v5yx3@earth.universe>
Hi Sebastian,
On 01.06.2020 19:05, Sebastian Reichel wrote:
> On Mon, Jun 01, 2020 at 12:40:27PM +0200, Marek Szyprowski wrote:
>> On 13.05.2020 20:55, Sebastian Reichel wrote:
>>> This patchset improves support for SBS compliant batteries. Due to
>>> the changes, the battery now exposes 32 power supply properties and
>>> (un)plugging it generates a backtrace containing the following message
>>> without the first patch in this series:
>>>
>>> ---------------------------
>>> WARNING: CPU: 0 PID: 20 at lib/kobject_uevent.c:659 add_uevent_var+0xd4/0x104
>>> add_uevent_var: too many keys
>>> ---------------------------
>>>
>>> For references this is what an SBS battery status looks like after
>>> the patch series has been applied:
>>>
>>> cat /sys/class/power_supply/sbs-0-000b/uevent
>>> POWER_SUPPLY_NAME=sbs-0-000b
>>> POWER_SUPPLY_TYPE=Battery
>>> POWER_SUPPLY_STATUS=Discharging
>>> POWER_SUPPLY_CAPACITY_LEVEL=Normal
>>> POWER_SUPPLY_HEALTH=Good
>>> POWER_SUPPLY_PRESENT=1
>>> POWER_SUPPLY_TECHNOLOGY=Li-ion
>>> POWER_SUPPLY_CYCLE_COUNT=12
>>> POWER_SUPPLY_VOLTAGE_NOW=11441000
>>> POWER_SUPPLY_CURRENT_NOW=-26000
>>> POWER_SUPPLY_CURRENT_AVG=-24000
>>> POWER_SUPPLY_CAPACITY=76
>>> POWER_SUPPLY_CAPACITY_ERROR_MARGIN=1
>>> POWER_SUPPLY_TEMP=198
>>> POWER_SUPPLY_TIME_TO_EMPTY_AVG=438600
>>> POWER_SUPPLY_TIME_TO_FULL_AVG=3932100
>>> POWER_SUPPLY_SERIAL_NUMBER=0000
>>> POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
>>> POWER_SUPPLY_VOLTAGE_MAX_DESIGN=10800000
>>> POWER_SUPPLY_ENERGY_NOW=31090000
>>> POWER_SUPPLY_ENERGY_FULL=42450000
>>> POWER_SUPPLY_ENERGY_FULL_DESIGN=41040000
>>> POWER_SUPPLY_CHARGE_NOW=2924000
>>> POWER_SUPPLY_CHARGE_FULL=3898000
>>> POWER_SUPPLY_CHARGE_FULL_DESIGN=3800000
>>> POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=3000000
>>> POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=12300000
>>> POWER_SUPPLY_MANUFACTURE_YEAR=2017
>>> POWER_SUPPLY_MANUFACTURE_MONTH=7
>>> POWER_SUPPLY_MANUFACTURE_DAY=3
>>> POWER_SUPPLY_MANUFACTURER=UR18650A
>>> POWER_SUPPLY_MODEL_NAME=GEHC
>> This patch landed in linux-next dated 20200529. Sadly it causes a
>> regression on Samsung Exynos-based Chromebooks (Exynos5250 Snow,
>> Exynos5420 Peach-Pi and Exynos5800 Peach-Pit). System boots to
>> userspace, but then, when udev populates /dev, booting hangs:
>>
>> [ 4.435167] VFS: Mounted root (ext4 filesystem) readonly on device
>> 179:51.
>> [ 4.457477] devtmpfs: mounted
>> [ 4.460235] Freeing unused kernel memory: 1024K
>> [ 4.464022] Run /sbin/init as init process
>> INIT: version 2.88 booting
>> [info] Using makefile-style concurrent boot in runlevel S.
>> [ 5.102096] random: crng init done
>> [....] Starting the hotplug events dispatcher: systemd-udevdstarting
>> version 236
>> [ ok .
>> [....] Synthesizing the initial hotplug events...[ ok done.
>> [....] Waiting for /dev to be fully populated...[ 34.409914]
>> TPS65090_RAILSDCDC1: disabling
>> [ 34.412977] TPS65090_RAILSDCDC2: disabling
>> [ 34.417021] TPS65090_RAILSDCDC3: disabling
>> [ 34.423848] TPS65090_RAILSLDO1: disabling
>> [ 34.429068] TPS65090_RAILSLDO2: disabling
> :(
>
> log does not look useful either.
>
>> Bisect between v5.7-rc1 and next-20200529 pointed me to the first bad
>> commit: [c4b12a2f3f3de670f6be5e96092a2cab0b877f1a] power: supply:
>> sbs-battery: simplify read_read_string_data.
> ok. I tested this on an to-be-upstreamed i.MX6 based system
> and arch/arm/boot/dts/imx53-ppd.dts. I think the difference
> is, that i2c-exynos5 does not expose I2C_FUNC_SMBUS_READ_BLOCK_DATA.
> I hoped all systems using SBS battery support this, but now
> I see I2C_FUNC_SMBUS_EMUL only supports writing block data.
> Looks like I need to add another patch implementing that
> using the old code with added PEC support.
>
> In any case that should only return -ENODEV for the property
> (and uevent), but not break boot. So something fishy is going
> on.
>
>> However reverting it in linux-next doesn't fix the issue, so the
>> next commits are also relevant to this issue.
> The next patch, which adds PEC support depends on the simplification
> of sbs_read_string_data. The old, open coded variant will result in
> PEC failure for string properties (which should not stop boot either
> of course). Can you try reverting both?
Indeed, reverting both (and fixing the conflict) restores proper boot.
> If that helps I will revert those two instead of dropping the whole
> series for this merge window.
>
>> Let me know how can I help debugging it.
> I suspect, that this is userspace endlessly retrying reading the
> battery uevent when an error is returned. Could you check this?
> Should be easy to see by adding some printfs.
I've added some debug messages in sbs_get_property() and it read the
same properties many times. However I've noticed that if I wait long
enough booting finally continues.
> That would mean a faulty battery could stall complete boot without
> a useful error message, which is bad and needs to be fixed.
>
> Sorry for the inconvience and thanks for your report,
No problem, finding regressions is one of the linux-next goal.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 2/3] ARM: dts: imx: Change esdhc node name on i.MX2/i.MX3/i.MX5 SoCs
From: Anson Huang @ 2020-06-02 6:24 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591079092-18625-1-git-send-email-Anson.Huang@nxp.com>
Change i.MX2/i.MX3/i.MX5 SoCs esdhc node name from esdhc to mmc to
be compliant with yaml schema, it requires the nodename to be "mmc".
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx25.dtsi | 4 ++--
arch/arm/boot/dts/imx35.dtsi | 6 +++---
arch/arm/boot/dts/imx50.dtsi | 8 ++++----
arch/arm/boot/dts/imx51.dtsi | 8 ++++----
arch/arm/boot/dts/imx53.dtsi | 8 ++++----
5 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 4eaf4eb..b045c6d 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -453,7 +453,7 @@
interrupts = <22>;
};
- esdhc1: esdhc@53fb4000 {
+ esdhc1: mmc@53fb4000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb4000 0x4000>;
interrupts = <9>;
@@ -462,7 +462,7 @@
status = "disabled";
};
- esdhc2: esdhc@53fb8000 {
+ esdhc2: mmc@53fb8000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb8000 0x4000>;
interrupts = <8>;
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 502112b..e154087 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -231,7 +231,7 @@
#interrupt-cells = <2>;
};
- esdhc1: esdhc@53fb4000 {
+ esdhc1: mmc@53fb4000 {
compatible = "fsl,imx35-esdhc";
reg = <0x53fb4000 0x4000>;
interrupts = <7>;
@@ -240,7 +240,7 @@
status = "disabled";
};
- esdhc2: esdhc@53fb8000 {
+ esdhc2: mmc@53fb8000 {
compatible = "fsl,imx35-esdhc";
reg = <0x53fb8000 0x4000>;
interrupts = <8>;
@@ -249,7 +249,7 @@
status = "disabled";
};
- esdhc3: esdhc@53fbc000 {
+ esdhc3: mmc@53fbc000 {
compatible = "fsl,imx35-esdhc";
reg = <0x53fbc000 0x4000>;
interrupts = <9>;
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index 1f4ecbc..377951a 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -115,7 +115,7 @@
reg = <0x50000000 0x40000>;
ranges;
- esdhc1: esdhc@50004000 {
+ esdhc1: mmc@50004000 {
compatible = "fsl,imx50-esdhc", "fsl,imx53-esdhc";
reg = <0x50004000 0x4000>;
interrupts = <1>;
@@ -127,7 +127,7 @@
status = "disabled";
};
- esdhc2: esdhc@50008000 {
+ esdhc2: mmc@50008000 {
compatible = "fsl,imx50-esdhc", "fsl,imx53-esdhc";
reg = <0x50008000 0x4000>;
interrupts = <2>;
@@ -176,7 +176,7 @@
status = "disabled";
};
- esdhc3: esdhc@50020000 {
+ esdhc3: mmc@50020000 {
compatible = "fsl,imx50-esdhc", "fsl,imx53-esdhc";
reg = <0x50020000 0x4000>;
interrupts = <3>;
@@ -188,7 +188,7 @@
status = "disabled";
};
- esdhc4: esdhc@50024000 {
+ esdhc4: mmc@50024000 {
compatible = "fsl,imx50-esdhc", "fsl,imx53-esdhc";
reg = <0x50024000 0x4000>;
interrupts = <4>;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index c83bc77..db5827d 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -185,7 +185,7 @@
reg = <0x70000000 0x40000>;
ranges;
- esdhc1: esdhc@70004000 {
+ esdhc1: mmc@70004000 {
compatible = "fsl,imx51-esdhc";
reg = <0x70004000 0x4000>;
interrupts = <1>;
@@ -196,7 +196,7 @@
status = "disabled";
};
- esdhc2: esdhc@70008000 {
+ esdhc2: mmc@70008000 {
compatible = "fsl,imx51-esdhc";
reg = <0x70008000 0x4000>;
interrupts = <2>;
@@ -245,7 +245,7 @@
status = "disabled";
};
- esdhc3: esdhc@70020000 {
+ esdhc3: mmc@70020000 {
compatible = "fsl,imx51-esdhc";
reg = <0x70020000 0x4000>;
interrupts = <3>;
@@ -257,7 +257,7 @@
status = "disabled";
};
- esdhc4: esdhc@70024000 {
+ esdhc4: mmc@70024000 {
compatible = "fsl,imx51-esdhc";
reg = <0x70024000 0x4000>;
interrupts = <4>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index ed6b0c8..9a4fc99 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -236,7 +236,7 @@
reg = <0x50000000 0x40000>;
ranges;
- esdhc1: esdhc@50004000 {
+ esdhc1: mmc@50004000 {
compatible = "fsl,imx53-esdhc";
reg = <0x50004000 0x4000>;
interrupts = <1>;
@@ -248,7 +248,7 @@
status = "disabled";
};
- esdhc2: esdhc@50008000 {
+ esdhc2: mmc@50008000 {
compatible = "fsl,imx53-esdhc";
reg = <0x50008000 0x4000>;
interrupts = <2>;
@@ -301,7 +301,7 @@
status = "disabled";
};
- esdhc3: esdhc@50020000 {
+ esdhc3: mmc@50020000 {
compatible = "fsl,imx53-esdhc";
reg = <0x50020000 0x4000>;
interrupts = <3>;
@@ -313,7 +313,7 @@
status = "disabled";
};
- esdhc4: esdhc@50024000 {
+ esdhc4: mmc@50024000 {
compatible = "fsl,imx53-esdhc";
reg = <0x50024000 0x4000>;
interrupts = <4>;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: imx: Change usdhc node name on i.MX6/i.MX7 SoCs
From: Anson Huang @ 2020-06-02 6:24 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591079092-18625-1-git-send-email-Anson.Huang@nxp.com>
Change i.MX6/i.MX7 SoCs usdhc node name from usdhc to mmc to be
compliant with yaml schema, it requires the nodename to be "mmc".
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++----
arch/arm/boot/dts/imx6sl.dtsi | 8 ++++----
arch/arm/boot/dts/imx6sx.dtsi | 8 ++++----
arch/arm/boot/dts/imx6ul.dtsi | 4 ++--
arch/arm/boot/dts/imx7s.dtsi | 6 +++---
5 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index deb09df..346a52f 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1056,7 +1056,7 @@
<0 126 IRQ_TYPE_LEVEL_HIGH>;
};
- usdhc1: usdhc@2190000 {
+ usdhc1: mmc@2190000 {
compatible = "fsl,imx6q-usdhc";
reg = <0x02190000 0x4000>;
interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
@@ -1068,7 +1068,7 @@
status = "disabled";
};
- usdhc2: usdhc@2194000 {
+ usdhc2: mmc@2194000 {
compatible = "fsl,imx6q-usdhc";
reg = <0x02194000 0x4000>;
interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
@@ -1080,7 +1080,7 @@
status = "disabled";
};
- usdhc3: usdhc@2198000 {
+ usdhc3: mmc@2198000 {
compatible = "fsl,imx6q-usdhc";
reg = <0x02198000 0x4000>;
interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
@@ -1092,7 +1092,7 @@
status = "disabled";
};
- usdhc4: usdhc@219c000 {
+ usdhc4: mmc@219c000 {
compatible = "fsl,imx6q-usdhc";
reg = <0x0219c000 0x4000>;
interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 11e7bf3..e2d2532 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -854,7 +854,7 @@
status = "disabled";
};
- usdhc1: usdhc@2190000 {
+ usdhc1: mmc@2190000 {
compatible = "fsl,imx6sl-usdhc", "fsl,imx6q-usdhc";
reg = <0x02190000 0x4000>;
interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
@@ -866,7 +866,7 @@
status = "disabled";
};
- usdhc2: usdhc@2194000 {
+ usdhc2: mmc@2194000 {
compatible = "fsl,imx6sl-usdhc", "fsl,imx6q-usdhc";
reg = <0x02194000 0x4000>;
interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
@@ -878,7 +878,7 @@
status = "disabled";
};
- usdhc3: usdhc@2198000 {
+ usdhc3: mmc@2198000 {
compatible = "fsl,imx6sl-usdhc", "fsl,imx6q-usdhc";
reg = <0x02198000 0x4000>;
interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
@@ -890,7 +890,7 @@
status = "disabled";
};
- usdhc4: usdhc@219c000 {
+ usdhc4: mmc@219c000 {
compatible = "fsl,imx6sl-usdhc", "fsl,imx6q-usdhc";
reg = <0x0219c000 0x4000>;
interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 995e1b1..430c21a 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -943,7 +943,7 @@
status = "disabled";
};
- usdhc1: usdhc@2190000 {
+ usdhc1: mmc@2190000 {
compatible = "fsl,imx6sx-usdhc", "fsl,imx6sl-usdhc";
reg = <0x02190000 0x4000>;
interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
@@ -955,7 +955,7 @@
status = "disabled";
};
- usdhc2: usdhc@2194000 {
+ usdhc2: mmc@2194000 {
compatible = "fsl,imx6sx-usdhc", "fsl,imx6sl-usdhc";
reg = <0x02194000 0x4000>;
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
@@ -967,7 +967,7 @@
status = "disabled";
};
- usdhc3: usdhc@2198000 {
+ usdhc3: mmc@2198000 {
compatible = "fsl,imx6sx-usdhc", "fsl,imx6sl-usdhc";
reg = <0x02198000 0x4000>;
interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
@@ -979,7 +979,7 @@
status = "disabled";
};
- usdhc4: usdhc@219c000 {
+ usdhc4: mmc@219c000 {
compatible = "fsl,imx6sx-usdhc", "fsl,imx6sl-usdhc";
reg = <0x0219c000 0x4000>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 2d64802..e5aab37 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -861,7 +861,7 @@
status = "disabled";
};
- usdhc1: usdhc@2190000 {
+ usdhc1: mmc@2190000 {
compatible = "fsl,imx6ul-usdhc", "fsl,imx6sx-usdhc";
reg = <0x02190000 0x4000>;
interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
@@ -875,7 +875,7 @@
status = "disabled";
};
- usdhc2: usdhc@2194000 {
+ usdhc2: mmc@2194000 {
compatible = "fsl,imx6ul-usdhc", "fsl,imx6sx-usdhc";
reg = <0x02194000 0x4000>;
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 3cba731..1cfaf41 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -1126,7 +1126,7 @@
reg = <0x30b30200 0x200>;
};
- usdhc1: usdhc@30b40000 {
+ usdhc1: mmc@30b40000 {
compatible = "fsl,imx7d-usdhc", "fsl,imx6sl-usdhc";
reg = <0x30b40000 0x10000>;
interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
@@ -1138,7 +1138,7 @@
status = "disabled";
};
- usdhc2: usdhc@30b50000 {
+ usdhc2: mmc@30b50000 {
compatible = "fsl,imx7d-usdhc", "fsl,imx6sl-usdhc";
reg = <0x30b50000 0x10000>;
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
@@ -1150,7 +1150,7 @@
status = "disabled";
};
- usdhc3: usdhc@30b60000 {
+ usdhc3: mmc@30b60000 {
compatible = "fsl,imx7d-usdhc", "fsl,imx6sl-usdhc";
reg = <0x30b60000 0x10000>;
interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: imx: Change sdhci node name on i.MX27/i.MX31 SoCs
From: Anson Huang @ 2020-06-02 6:24 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
Change i.MX27/i.MX31 node name from sdhci to mmc to be compliant
with yaml schema, it requires the nodename to be "mmc".
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx27.dtsi | 6 +++---
arch/arm/boot/dts/imx31.dtsi | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index ee04771..47de96b 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -265,7 +265,7 @@
status = "disabled";
};
- sdhci1: sdhci@10013000 {
+ sdhci1: mmc@10013000 {
compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
reg = <0x10013000 0x1000>;
interrupts = <11>;
@@ -277,7 +277,7 @@
status = "disabled";
};
- sdhci2: sdhci@10014000 {
+ sdhci2: mmc@10014000 {
compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
reg = <0x10014000 0x1000>;
interrupts = <10>;
@@ -431,7 +431,7 @@
status = "disabled";
};
- sdhci3: sdhci@1001e000 {
+ sdhci3: mmc@1001e000 {
compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
reg = <0x1001e000 0x1000>;
interrupts = <9>;
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 4f3d7ab..eedf2d7 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -173,7 +173,7 @@
reg = <0x50000000 0x100000>;
ranges;
- sdhci1: sdhci@50004000 {
+ sdhci1: mmc@50004000 {
compatible = "fsl,imx31-mmc";
reg = <0x50004000 0x4000>;
interrupts = <9>;
@@ -184,7 +184,7 @@
status = "disabled";
};
- sdhci2: sdhci@50008000 {
+ sdhci2: mmc@50008000 {
compatible = "fsl,imx31-mmc";
reg = <0x50008000 0x4000>;
interrupts = <8>;
--
2.7.4
^ permalink raw reply related
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Dongchun Zhu @ 2020-06-02 6:15 UTC (permalink / raw)
To: Tomasz Figa
Cc: Sakari Ailus, Rob Herring, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Mark Rutland,
Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Sj Huang,
Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
In-Reply-To: <CAAFQd5AY9gejoiwxojvvG0FaVfEAf8gCqOddvo-dxemQWFksVw@mail.gmail.com>
Hi Tomasz, Sakari,
On Mon, 2020-06-01 at 20:18 +0200, Tomasz Figa wrote:
> On Mon, Jun 1, 2020 at 4:35 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> >
> > Hi Tomasz,
> >
> > On Fri, 2020-05-29 at 15:43 +0200, Tomasz Figa wrote:
> > > On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > >
> > > > Hi Sakari,
> > > >
> > > > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote:
> > > > > Hi Dongchun,
> > > > >
> > > > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote:
> > > > > > Hi Sakari, Rob,
> > > > > >
> > > > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> > > > > > > Hi Rob, Dongchun,
> > > > > > >
> > > > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > > > > > > > + properties:
> > > > > > > > > > > + endpoint:
> > > > > > > > > > > + type: object
> > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > +
> > > > > > > > > > > + properties:
> > > > > > > > >
> > > > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here?
> > > > > > > >
> > > > > > > > Yes, if you are using it.
> > > > > > >
> > > > > > > Dongchun, can you confirm the chip has a single data and a single clock
> > > > > > > lane and that it does not support lane reordering?
> > > > > > >
> > > > > >
> > > > > > From the datasheet, 'MIPI inside the OV02A10 provides one single
> > > > > > uni-directional clock lane and one bi-directional data lane solution for
> > > > > > communication links between components inside a mobile device.
> > > > > > The data lane has full support for HS(uni-directional) and
> > > > > > LP(bi-directional) data transfer mode.'
> > > > > >
> > > > > > The sensor doesn't support lane reordering, so 'clock-lanes' property
> > > > > > would not be added in next release.
> > > > > >
> > > > > > > So if there's nothing to convey to the driver, also the data-lanes should
> > > > > > > be removed IMO.
> > > > > > >
> > > > > >
> > > > > > However, 'data-lanes' property may still be required.
> > > > > > It is known that either data-lanes or clock-lanes is an array of
> > > > > > physical data lane indexes. Position of an entry determines the logical
> > > > > > lane number, while the value of an entry indicates physical lane, e.g.,
> > > > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
> > > > > > the clock lane is on hardware lane 0.
> > > > > >
> > > > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
> > > > > > support lane reordering, so here we shall use 'data-lanes = <1>' as
> > > > > > there is only a clock lane for OV02A10.
> > > > > >
> > > > > > Reminder:
> > > > > > If 'data-lanes' property is not present, the driver would assume
> > > > > > four-lane operation. This means for one-lane or two-lane operation, this
> > > > > > property must be present and set to the right physical lane indexes.
> > > > > > If the hardware does not support lane reordering, monotonically
> > > > > > incremented values shall be used from 0 or 1 onwards, depending on
> > > > > > whether or not there is also a clock lane.
> > > > >
> > > > > How can the driver use four lanes, considering the device only supports a
> > > > > single lane??
> > > > >
> > > >
> > > > I understood your meaning.
> > > > If we omit the property 'data-lanes', the sensor should work still.
> > > > But then what's the meaning of the existence of 'data-lanes'?
> > > > If this property 'data-lanes' is always optional, then why dt-bindings
> > > > provide the interface?
> > > >
> > > > In the meantime, if omitting 'data-lanes' for one sensor(transmitter)
> > > > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2)
> > > > shall enable four-lane configuration, which may increase consumption of
> > > > both power and resource in the process of IIC communication.
> > >
> > > Wouldn't the receiver still have the data-lanes property under its
> > > endpoint node, telling it how many lanes and in which order should be
> > > used?
> > >
> >
> > The MIPI receiver(RX) shall use
> > v4l2_async_notifier_add_fwnode_remote_subdev() API to parse the property
> > "data-lanes" under sensor output port.
>
> That's not true. The MIPI receiver driver parses its own port node
> corresponding to the sensor. Also quoting the documentation [1]:
>
> "An endpoint subnode of a device contains all properties needed for
> _configuration of this device_ for data exchange with other device. In most
> cases properties at the peer 'endpoint' nodes will be identical, however they
> might need to be different when there is any signal modifications on the bus
> between two devices, e.g. there are logic signal inverters on the lines."
>
> In this case, there is such a signal modification if the sensor has a
> 1-lane bus and the receiver more lines, so the data-lanes properties
> would be different on both sides.
>
> [1] https://elixir.bootlin.com/linux/v5.7/source/Documentation/devicetree/bindings/media/video-interfaces.txt
>
Sorry for the misunderstanding.
After doing some experiments about the data-lanes property under sensor
i2c node, we found the API
v4l2_async_notifier_add_fwnode_remote_subdev() that MIPI receiver driver
used indeed parses the data-lanes under its own port node.
Sorry make a mistake for the use case of sensor data-lanes previously.
Now We may encounter one new question for this patch.
In practice we haven't used the data-lanes under sensor i2c node
anywhere, if sensor driver itself doesn't parse that.
But there is still one reason to keep the exactly right data-lanes in
DT. That is, the data-lanes under sensor i2c node could be used as a
reference for MIPI receiver driver.
Just as Tomasz said, 'The MIPI receiver driver parses its own port node
corresponding to the sensor'.
Sakari, Tomasz, what's your opinions about the present of data-lanes
under sensor node or not?
> Best regards,
> Tomasz
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Prabhakar Kushwaha @ 2020-06-02 5:38 UTC (permalink / raw)
To: John Donnelly
Cc: Bhupesh Sharma, Chen Zhou, Simon Horman, Devicetree List,
Baoquan He, Will Deacon, Linux Doc Mailing List, Catalin Marinas,
kexec mailing list, Linux Kernel Mailing List, Rob Herring,
Ingo Molnar, Arnd Bergmann, guohanjun, James Morse,
Thomas Gleixner, Prabhakar Kushwaha, RuiRui Yang,
linux-arm-kernel
In-Reply-To: <F64A309C-B9C0-45F2-A50D-D677005C33A6@oracle.com>
On Tue, Jun 2, 2020 at 3:29 AM John Donnelly <john.p.donnelly@oracle.com> wrote:
>
> Hi . See below !
>
> > On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> >
> > Hi John,
> >
> > On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
> >>
> >> Hi,
> >>
> >>
> >> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
> >>> Hi Chen,
> >>>
> >>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
> >>>> This patch series enable reserving crashkernel above 4G in arm64.
> >>>>
> >>>> There are following issues in arm64 kdump:
> >>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
> >>>> when there is no enough low memory.
> >>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
> >>>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
> >>>> will boot failure because there is no low memory available for allocation.
> >>>>
> >>>> To solve these issues, introduce crashkernel=X,low to reserve specified
> >>>> size low memory.
> >>>> Crashkernel=X tries to reserve memory for the crash dump kernel under
> >>>> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
> >>>> size low memory for crash kdump kernel devices firstly and then reserve
> >>>> memory above 4G.
> >>>>
> >>>> When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
> >>>> is specified simultaneously, kernel should reserve specified size low memory
> >>>> for crash dump kernel devices. So there may be two crash kernel regions, one
> >>>> is below 4G, the other is above 4G.
> >>>> In order to distinct from the high region and make no effect to the use of
> >>>> kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
> >>>> "linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
> >>>>
> >>>> Besides, we need to modify kexec-tools:
> >>>> arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
> >>>>
> >>>> The previous changes and discussions can be retrieved from:
> >>>>
> >>>> Changes since [v7]
> >>>> - Move x86 CRASH_ALIGN to 2M
> >>>> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M.
> >>>> - Update Documentation/devicetree/bindings/chosen.txt
> >>>> Add corresponding documentation to Documentation/devicetree/bindings/chosen.txt suggested by Arnd.
> >>>> - Add Tested-by from Jhon and pk
> >>>>
> >>>> Changes since [v6]
> >>>> - Fix build errors reported by kbuild test robot.
> >>>>
> >>>> Changes since [v5]
> >>>> - Move reserve_crashkernel_low() into kernel/crash_core.c.
> >>>> - Delete crashkernel=X,high.
> >>>> - Modify crashkernel=X,low.
> >>>> If crashkernel=X,low is specified simultaneously, reserve spcified size low
> >>>> memory for crash kdump kernel devices firstly and then reserve memory above 4G.
> >>>> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
> >>>> pass to crash dump kernel by DT property "linux,low-memory-range".
> >>>> - Update Documentation/admin-guide/kdump/kdump.rst.
> >>>>
> >>>> Changes since [v4]
> >>>> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
> >>>>
> >>>> Changes since [v3]
> >>>> - Add memblock_cap_memory_ranges back for multiple ranges.
> >>>> - Fix some compiling warnings.
> >>>>
> >>>> Changes since [v2]
> >>>> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
> >>>> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
> >>>> patch.
> >>>>
> >>>> Changes since [v1]:
> >>>> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
> >>>> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
> >>>> in fdt_enforce_memory_region().
> >>>> There are at most two crash kernel regions, for two crash kernel regions
> >>>> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
> >>>> and then remove the memory range in the middle.
> >>>>
> >>>> [1]: https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$
> >>>> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$
> >>>> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$
> >>>> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$
> >>>> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$
> >>>> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbl24n-79$
> >>>> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbs7r8G2a$
> >>>> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiFUH90G$
> >>>>
> >>>> Chen Zhou (5):
> >>>> x86: kdump: move reserve_crashkernel_low() into crash_core.c
> >>>> arm64: kdump: reserve crashkenel above 4G for crash dump kernel
> >>>> arm64: kdump: add memory for devices by DT property, low-memory-range
> >>>> kdump: update Documentation about crashkernel on arm64
> >>>> dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
> >>>>
> >>> We are getting "warn_alloc" [1] warning during boot of kdump kernel
> >>> with bootargs as [2] of primary kernel.
> >>> This error observed on ThunderX2 ARM64 platform.
> >>>
> >>> It is observed with latest upstream tag (v5.7-rc3) with this patch set
> >>> and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
> >>> Also **without** this patch-set
> >>> "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
> >>>
> >>> This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
> >>> More details discussed earlier in
> >>> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
> >>> solution
> >>>
> >>> This patch-set is expected to solve similar kind of issue.
> >>> i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
> >>> observation should be considered/fixed. .
> >>>
> >>> --pk
> >>>
> >>> [1]
> >>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
> >>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> >>> [ 30.367696] NET: Registered protocol family 16
> >>> [ 30.369973] swapper/0: page allocation failure: order:6,
> >>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> >>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
> >>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
> >>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> >>> [ 30.369984] Call trace:
> >>> [ 30.369989] dump_backtrace+0x0/0x1f8
> >>> [ 30.369991] show_stack+0x20/0x30
> >>> [ 30.369997] dump_stack+0xc0/0x10c
> >>> [ 30.370001] warn_alloc+0x10c/0x178
> >>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
> >>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
> >>> [ 30.370008] alloc_page_interleave+0x24/0x98
> >>> [ 30.370011] alloc_pages_current+0xe4/0x108
> >>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
> >>> [ 30.370020] do_one_initcall+0x54/0x228
> >>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
> >>> [ 30.370031] kernel_init+0x1c/0x110
> >>> [ 30.370034] ret_from_fork+0x10/0x18
> >>> [ 30.370036] Mem-Info:
> >>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
> >>> [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
> >>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
> >>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
> >>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
> >>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
> >>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
> >>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> >>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> >>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> >>> unstable:0kB all_unreclaimable? no
> >>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
> >>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> >>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> >>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> >>> unstable:0kB all_unreclaimable? no
> >>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
> >>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
> >>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> >>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
> >>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
> >>> high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>> present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
> >>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> >>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
> >>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
> >>> high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>> present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
> >>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
> >>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
> >>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> >>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> >>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> >>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
> >>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
> >>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
> >>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
> >>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
> >>> hugepages_surp=0 hugepages_size=1048576kB
> >>> [ 30.370130] 0 total pagecache pages
> >>> [ 30.370132] 0 pages in swap cache
> >>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
> >>> [ 30.370135] Free swap = 0kB
> >>> [ 30.370136] Total swap = 0kB
> >>> [ 30.370137] 2164609 pages RAM
> >>> [ 30.370139] 0 pages HighMem/MovableOnly
> >>> [ 30.370140] 612331 pages reserved
> >>> [ 30.370141] 0 pages hwpoisoned
> >>> [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
> >>> coherent allocation
> >>
> >>
> >> During my testing I saw the same error and Chen's solution corrected it .
> >
> > Which combination you are using on your side? I am using Prabhakar's
> > suggested environment and can reproduce the issue
> > with or without Chen's crashkernel support above 4G patchset.
> >
> > I am also using a ThunderX2 platform with latest makedumpfile code and
> > kexec-tools (with the suggested patch
> > <https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$ >).
> >
> > Thanks,
> > Bhupesh
>
>
> I did this activity 5 months ago and I have moved on to other activities. My DMA failures were related to PCI devices that could not be enumerated because low-DMA space was not available when crashkernel was moved above 4G; I don’t recall the exact platform.
>
>
>
> For this failure ,
>
> >>> DMA: failed to allocate 256 KiB pool for atomic
> >>> coherent allocation
>
>
> Is due to :
>
>
> 3618082c
> ("arm64 use both ZONE_DMA and ZONE_DMA32")
>
> With the introduction of ZONE_DMA to support the Raspberry DMA
> region below 1G, the crashkernel is placed in the upper 4G
> ZONE_DMA_32 region. Since the crashkernel does not have access
> to the ZONE_DMA region, it prints out call trace during bootup.
>
> It is due to having this CONFIG item ON :
>
>
> CONFIG_ZONE_DMA=y
>
> Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
> use the device tree to specify memory below 1G.
>
>
Disabling ZONE_DMA is temporary solution. We may need proper solution
> I would like to see Chen’s feature added , perhaps as EXPERIMENTAL, so we can get some configuration testing done on it. It corrects having a DMA zone in low memory while crash-kernel is above 4GB. This has been going on for a year now.
I will also like this patch to be added in Linux as early as possible.
Issue mentioned by me happens with or without this patch.
This patch-set can consider fixing because it uses low memory for DMA
& swiotlb only.
We can consider restricting crashkernel within the required range like below
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 7f9e5a6dc48c..bd67b90d35bd 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -354,7 +354,7 @@ int __init reserve_crashkernel_low(void)
return 0;
}
- low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
+ low_base = memblock_find_in_range(0, 0xc0000000, low_size, CRASH_ALIGN);
if (!low_base) {
pr_err("Cannot reserve %ldMB crashkernel low memory,
please try smaller size.\n",
(unsigned long)(low_size >> 20));
Similar change can be considered for scenario "without" this patch.
But it will decrease memory availability for crashkernel.
Hence increase the failure probability of crashkernel reservation.
--pk
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
From: Guenter Roeck @ 2020-06-02 5:34 UTC (permalink / raw)
To: Lukas Bulwahn, Julius Werner, Evan Benn, Wim Van Sebroeck,
linux-watchdog
Cc: Rob Herring, devicetree, Joe Perches, kernel-janitors,
linux-kernel
In-Reply-To: <20200602052104.7795-1-lukas.bulwahn@gmail.com>
On 6/1/20 10:21 PM, Lukas Bulwahn wrote:
> Commit 5c24a28b4eb8 ("dt-bindings: watchdog: Add ARM smc wdt for mt8173
> watchdog") added the new ARM SMC WATCHDOG DRIVER entry in MAINTAINERS, but
> slipped in a minor mistake.
>
> Luckily, ./scripts/get_maintainer.pl --self-test=patterns complains:
>
> warning: no file matches F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
>
> Update file entry to intended file location.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Julius, Evan, please ack.
>
> Wim, please pick this minor patch into your -next tree.
>
> applies cleanly on next-20200529
>
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b045b70e54df..dcfb09700b96 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1489,7 +1489,7 @@ ARM SMC WATCHDOG DRIVER
> M: Julius Werner <jwerner@chromium.org>
> R: Evan Benn <evanbenn@chromium.org>
> S: Maintained
> -F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
> +F: Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
> F: drivers/watchdog/arm_smc_wdt.c
>
> ARM SMMU DRIVERS
>
^ permalink raw reply
* RE: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
From: Peng Fan @ 2020-06-02 5:26 UTC (permalink / raw)
To: Oleksij Rempel
Cc: shawnguo@kernel.org, Fabio Estevam, kernel@pengutronix.de,
Aisheng Dong, robh+dt@kernel.org, sboyd@kernel.org,
linux@rempel-privat.de, jaswinder.singh@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx, Leonard Crestez,
Daniel Baluta, l.stach@pengutronix.de, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20200602052448.fxepmwltc4465q4i@pengutronix.de>
Hi Oleksij,
> Subject: Re: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
>
> On Mon, Jun 01, 2020 at 04:20:00PM +0800, peng.fan@nxp.com wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs
> >
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > index 26b7a88c2fea..906377acf2cd 100644
> > --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> > @@ -18,7 +18,8 @@ Messaging Unit Device Node:
> > Required properties:
> > -------------------
> > - compatible : should be "fsl,<chip>-mu", the supported chips include
> > - imx6sx, imx7s, imx8qxp, imx8qm.
> > + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn,
> > + imx8mp.
> > The "fsl,imx6sx-mu" compatible is seen as generic and should
> > be included together with SoC specific compatible.
> > There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
> > --
> > 2.16.4
> >
> >
>
> Hi Peng,
>
> The fsl,mu.yaml was already taken by Rob, so one or other patch will break by
> merge. I assume you should drop this change.
Yes. I'll rebase this patch based on Rob's tree. Thanks for reminding me.
Thanks,
Peng.
>
>
> Regards,
> Oleksij
> --
> Pengutronix e.K. |
> |
> Steuerwalder Str. 21 |
> http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone:
> +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax:
> +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
From: Oleksij Rempel @ 2020-06-02 5:24 UTC (permalink / raw)
To: peng.fan
Cc: shawnguo, fabio.estevam, kernel, aisheng.dong, robh+dt, sboyd,
linux, jaswinder.singh, linux-arm-kernel, linux-kernel, linux-imx,
leonard.crestez, daniel.baluta, l.stach, devicetree, linux-clk
In-Reply-To: <1590999602-29482-2-git-send-email-peng.fan@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]
On Mon, Jun 01, 2020 at 04:20:00PM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs
>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> index 26b7a88c2fea..906377acf2cd 100644
> --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> @@ -18,7 +18,8 @@ Messaging Unit Device Node:
> Required properties:
> -------------------
> - compatible : should be "fsl,<chip>-mu", the supported chips include
> - imx6sx, imx7s, imx8qxp, imx8qm.
> + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn,
> + imx8mp.
> The "fsl,imx6sx-mu" compatible is seen as generic and should
> be included together with SoC specific compatible.
> There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
> --
> 2.16.4
>
>
Hi Peng,
The fsl,mu.yaml was already taken by Rob, so one or other patch will
break by merge. I assume you should drop this change.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
From: Lukas Bulwahn @ 2020-06-02 5:21 UTC (permalink / raw)
To: Julius Werner, Evan Benn, Wim Van Sebroeck, Guenter Roeck,
linux-watchdog
Cc: Rob Herring, devicetree, Joe Perches, kernel-janitors,
linux-kernel, Lukas Bulwahn
Commit 5c24a28b4eb8 ("dt-bindings: watchdog: Add ARM smc wdt for mt8173
watchdog") added the new ARM SMC WATCHDOG DRIVER entry in MAINTAINERS, but
slipped in a minor mistake.
Luckily, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
Update file entry to intended file location.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
---
Julius, Evan, please ack.
Wim, please pick this minor patch into your -next tree.
applies cleanly on next-20200529
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b045b70e54df..dcfb09700b96 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1489,7 +1489,7 @@ ARM SMC WATCHDOG DRIVER
M: Julius Werner <jwerner@chromium.org>
R: Evan Benn <evanbenn@chromium.org>
S: Maintained
-F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
+F: Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
F: drivers/watchdog/arm_smc_wdt.c
ARM SMMU DRIVERS
--
2.17.1
^ permalink raw reply related
* [PATCH 0/3] Convert i.MX/MXS mmc binding to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
This patch series converts i.MX and MXS mmc binding to json-schema,
fix some minor issues in original binding doc, such as node name should
be 'mmc', compatible name for i.MX27, reg/interrupts should be required
properties etc..
Anson Huang (3):
dt-bindings: mmc: Convert imx esdhc to json-schema
dt-bindings: mmc: Convert imx mmc to json-schema
dt-bindings: mmc: Convert mxs mmc to json-schema
.../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 67 -----------
.../devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 122 +++++++++++++++++++++
.../devicetree/bindings/mmc/fsl-imx-mmc.txt | 23 ----
.../devicetree/bindings/mmc/fsl-imx-mmc.yaml | 51 +++++++++
Documentation/devicetree/bindings/mmc/mxs-mmc.txt | 27 -----
Documentation/devicetree/bindings/mmc/mxs-mmc.yaml | 56 ++++++++++
6 files changed, 229 insertions(+), 117 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
delete mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] dt-bindings: mmc: Convert imx esdhc to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591069066-12727-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX ESDHC binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 67 -----------
.../devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 122 +++++++++++++++++++++
2 files changed, 122 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
deleted file mode 100644
index de1b8bd..0000000
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX
-
-The Enhanced Secure Digital Host Controller on Freescale i.MX family
-provides an interface for MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties described
-by mmc.txt and the properties used by the sdhci-esdhc-imx driver.
-
-Required properties:
-- compatible : Should be "fsl,<chip>-esdhc", the supported chips include
- "fsl,imx25-esdhc"
- "fsl,imx35-esdhc"
- "fsl,imx51-esdhc"
- "fsl,imx53-esdhc"
- "fsl,imx6q-usdhc"
- "fsl,imx6sl-usdhc"
- "fsl,imx6sx-usdhc"
- "fsl,imx6ull-usdhc"
- "fsl,imx7d-usdhc"
- "fsl,imx7ulp-usdhc"
- "fsl,imx8mq-usdhc"
- "fsl,imx8mm-usdhc"
- "fsl,imx8mn-usdhc"
- "fsl,imx8mp-usdhc"
- "fsl,imx8qm-usdhc"
- "fsl,imx8qxp-usdhc"
-
-Optional properties:
-- fsl,wp-controller : Indicate to use controller internal write protection
-- fsl,delay-line : Specify the number of delay cells for override mode.
- This is used to set the clock delay for DLL(Delay Line) on override mode
- to select a proper data sampling window in case the clock quality is not good
- due to signal path is too long on the board. Please refer to eSDHC/uSDHC
- chapter, DLL (Delay Line) section in RM for details.
-- voltage-ranges : Specify the voltage range in case there are software
- transparent level shifters on the outputs of the controller. Two cells are
- required, first cell specifies minimum slot voltage (mV), second cell
- specifies maximum slot voltage (mV). Several ranges could be specified.
-- fsl,tuning-start-tap: Specify the start dealy cell point when send first CMD19
- in tuning procedure.
-- fsl,tuning-step: Specify the increasing delay cell steps in tuning procedure.
- The uSDHC use one delay cell as default increasing step to do tuning process.
- This property allows user to change the tuning step to more than one delay
- cells which is useful for some special boards or cards when the default
- tuning step can't find the proper delay window within limited tuning retries.
-- fsl,strobe-dll-delay-target: Specify the strobe dll control slave delay target.
- This delay target programming host controller loopback read clock, and this
- property allows user to change the delay target for the strobe input read clock.
- If not use this property, driver default set the delay target to value 7.
- Only eMMC HS400 mode need to take care of this property.
-
-Examples:
-
-esdhc@70004000 {
- compatible = "fsl,imx51-esdhc";
- reg = <0x70004000 0x4000>;
- interrupts = <1>;
- fsl,wp-controller;
-};
-
-esdhc@70008000 {
- compatible = "fsl,imx51-esdhc";
- reg = <0x70008000 0x4000>;
- interrupts = <2>;
- cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */
- wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */
-};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
new file mode 100644
index 0000000..7d0ea27
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/fsl-imx-esdhc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+
+description: |
+ The Enhanced Secure Digital Host Controller on Freescale i.MX family
+ provides an interface for MMC, SD, and SDIO types of memory cards.
+
+ This file documents differences between the core properties described
+ by mmc.txt and the properties used by the sdhci-esdhc-imx driver.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx25-esdhc
+ - fsl,imx35-esdhc
+ - fsl,imx51-esdhc
+ - fsl,imx53-esdhc
+ - fsl,imx6q-usdhc
+ - fsl,imx6sl-usdhc
+ - fsl,imx6sx-usdhc
+ - fsl,imx6ull-usdhc
+ - fsl,imx7d-usdhc
+ - fsl,imx7ulp-usdhc
+ - fsl,imx8mq-usdhc
+ - fsl,imx8mm-usdhc
+ - fsl,imx8mn-usdhc
+ - fsl,imx8mp-usdhc
+ - fsl,imx8qm-usdhc
+ - fsl,imx8qxp-usdhc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,wp-controller:
+ description: |
+ boolean, if present, indicate to use controller internal write protection.
+ type: boolean
+
+ fsl,delay-line:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the number of delay cells for override mode.
+ This is used to set the clock delay for DLL(Delay Line) on override mode
+ to select a proper data sampling window in case the clock quality is not good
+ due to signal path is too long on the board. Please refer to eSDHC/uSDHC
+ chapter, DLL (Delay Line) section in RM for details.
+ default: 0
+
+ voltage-ranges:
+ $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ description: |
+ Specify the voltage range in case there are software
+ transparent level shifters on the outputs of the controller. Two cells are
+ required, first cell specifies minimum slot voltage (mV), second cell
+ specifies maximum slot voltage (mV). Several ranges could be specified.
+ items:
+ items:
+ - description: value for minimum slot voltage
+ - description: value for maximum slot voltage
+ maxItems: 1
+
+ fsl,tuning-start-tap:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the start dealy cell point when send first CMD19 in tuning procedure.
+ default: 0
+
+ fsl,tuning-step:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the increasing delay cell steps in tuning procedure.
+ The uSDHC use one delay cell as default increasing step to do tuning process.
+ This property allows user to change the tuning step to more than one delay
+ cells which is useful for some special boards or cards when the default
+ tuning step can't find the proper delay window within limited tuning retries.
+ default: 0
+
+ fsl,strobe-dll-delay-target:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specify the strobe dll control slave delay target.
+ This delay target programming host controller loopback read clock, and this
+ property allows user to change the delay target for the strobe input read clock.
+ If not use this property, driver default set the delay target to value 7.
+ Only eMMC HS400 mode need to take care of this property.
+ default: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ mmc@70004000 {
+ compatible = "fsl,imx51-esdhc";
+ reg = <0x70004000 0x4000>;
+ interrupts = <1>;
+ fsl,wp-controller;
+ };
+
+ mmc@70008000 {
+ compatible = "fsl,imx51-esdhc";
+ reg = <0x70008000 0x4000>;
+ interrupts = <2>;
+ cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */
+ wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: mmc: Convert imx mmc to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591069066-12727-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX MMC binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/mmc/fsl-imx-mmc.txt | 23 ----------
.../devicetree/bindings/mmc/fsl-imx-mmc.yaml | 51 ++++++++++++++++++++++
2 files changed, 51 insertions(+), 23 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
deleted file mode 100644
index 184ccff..0000000
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-* Freescale Secure Digital Host Controller for i.MX2/3 series
-
-This file documents differences to the properties defined in mmc.txt.
-
-Required properties:
-- compatible : Should be "fsl,<chip>-mmc", chip can be imx21 or imx31
-
-Optional properties:
-- dmas: One DMA phandle with arguments as defined by the devicetree bindings
- of the used DMA controller.
-- dma-names: Has to be "rx-tx".
-
-Example:
-
-sdhci1: sdhci@10014000 {
- compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
- reg = <0x10014000 0x1000>;
- interrupts = <11>;
- dmas = <&dma 7>;
- dma-names = "rx-tx";
- bus-width = <4>;
- cd-gpios = <&gpio3 29>;
-};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
new file mode 100644
index 0000000..777a732
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/fsl-imx-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Secure Digital Host Controller for i.MX2/3 series
+
+maintainers:
+ - Markus Pargmann <mpa@pengutronix.de>
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+
+properties:
+ compatible:
+ oneOf:
+ - const: fsl,imx21-mmc
+ - const: fsl,imx31-mmc
+ - items:
+ - const: fsl,imx27-mmc
+ - const: fsl,imx21-mmc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ mmc@10014000 {
+ compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
+ reg = <0x10014000 0x1000>;
+ interrupts = <11>;
+ dmas = <&dma 7>;
+ dma-names = "rx-tx";
+ bus-width = <4>;
+ cd-gpios = <&gpio3 29>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: mmc: Convert mxs mmc to json-schema
From: Anson Huang @ 2020-06-02 3:37 UTC (permalink / raw)
To: ulf.hansson, robh+dt, shawnguo, s.hauer, kernel, festevam, mpa,
linux-mmc, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591069066-12727-1-git-send-email-Anson.Huang@nxp.com>
Convert the MXS MMC binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Documentation/devicetree/bindings/mmc/mxs-mmc.txt | 27 -----------
Documentation/devicetree/bindings/mmc/mxs-mmc.yaml | 56 ++++++++++++++++++++++
2 files changed, 56 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
deleted file mode 100644
index 515addc..0000000
--- a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Freescale MXS MMC controller
-
-The Freescale MXS Synchronous Serial Ports (SSP) can act as a MMC controller
-to support MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties in mmc.txt
-and the properties used by the mxsmmc driver.
-
-Required properties:
-- compatible: Should be "fsl,<chip>-mmc". The supported chips include
- imx23 and imx28.
-- interrupts: Should contain ERROR interrupt number
-- dmas: DMA specifier, consisting of a phandle to DMA controller node
- and SSP DMA channel ID.
- Refer to dma.txt and fsl-mxs-dma.txt for details.
-- dma-names: Must be "rx-tx".
-
-Examples:
-
-ssp0: ssp@80010000 {
- compatible = "fsl,imx28-mmc";
- reg = <0x80010000 2000>;
- interrupts = <96>;
- dmas = <&dma_apbh 0>;
- dma-names = "rx-tx";
- bus-width = <8>;
-};
diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
new file mode 100644
index 0000000..8fb9e59
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/mxs-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS MMC controller
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+description: |
+ The Freescale MXS Synchronous Serial Ports (SSP) can act as a MMC controller
+ to support MMC, SD, and SDIO types of memory cards.
+
+ This file documents differences between the core properties in mmc.txt
+ and the properties used by the mxsmmc driver.
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx23-mmc
+ - fsl,imx28-mmc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ mmc@80010000 {
+ compatible = "fsl,imx28-mmc";
+ reg = <0x80010000 2000>;
+ interrupts = <96>;
+ dmas = <&dma_apbh 0>;
+ dma-names = "rx-tx";
+ bus-width = <8>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH V4] dt-bindings: thermal: Convert qoriq to json-schema
From: Anson Huang @ 2020-06-02 1:22 UTC (permalink / raw)
To: rui.zhang, daniel.lezcano, amit.kucheria, robh+dt, linux-pm,
devicetree, linux-kernel
Cc: Linux-imx
Convert the qoriq thermal binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V3:
- Update maintainer since previous maintainer's email is NOT longer available.
---
.../devicetree/bindings/thermal/qoriq-thermal.txt | 71 -------------
.../devicetree/bindings/thermal/qoriq-thermal.yaml | 112 +++++++++++++++++++++
2 files changed, 112 insertions(+), 71 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
deleted file mode 100644
index 28f2cba..0000000
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
-
-Required properties:
-- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The
- version of the device is determined by the TMU IP Block Revision
- Register (IPBRR0) at offset 0x0BF8.
- Table of correspondences between IPBRR0 values and example chips:
- Value Device
- ---------- -----
- 0x01900102 T1040
-- reg : Address range of TMU registers.
-- interrupts : Contains the interrupt for TMU.
-- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by
- the SoC reference manual. The first cell is TTR0CR, the second is
- TTR1CR, etc.
-- fsl,tmu-calibration : A list of cell pairs containing temperature
- calibration data, as specified by the SoC reference manual.
- The first cell of each pair is the value to be written to TTCFGR,
- and the second is the value to be written to TSCFGR.
-- #thermal-sensor-cells : Must be 1. The sensor specifier is the monitoring
- site ID, and represents the "n" in TRITSRn and TRATSRn.
-
-Optional property:
-- little-endian : If present, the TMU registers are little endian. If absent,
- the default is big endian.
-- clocks : the clock for clocking the TMU silicon.
-
-Example:
-
-tmu@f0000 {
- compatible = "fsl,qoriq-tmu";
- reg = <0xf0000 0x1000>;
- interrupts = <18 2 0 0>;
- fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
- fsl,tmu-calibration = <0x00000000 0x00000025
- 0x00000001 0x00000028
- 0x00000002 0x0000002d
- 0x00000003 0x00000031
- 0x00000004 0x00000036
- 0x00000005 0x0000003a
- 0x00000006 0x00000040
- 0x00000007 0x00000044
- 0x00000008 0x0000004a
- 0x00000009 0x0000004f
- 0x0000000a 0x00000054
-
- 0x00010000 0x0000000d
- 0x00010001 0x00000013
- 0x00010002 0x00000019
- 0x00010003 0x0000001f
- 0x00010004 0x00000025
- 0x00010005 0x0000002d
- 0x00010006 0x00000033
- 0x00010007 0x00000043
- 0x00010008 0x0000004b
- 0x00010009 0x00000053
-
- 0x00020000 0x00000010
- 0x00020001 0x00000017
- 0x00020002 0x0000001f
- 0x00020003 0x00000029
- 0x00020004 0x00000031
- 0x00020005 0x0000003c
- 0x00020006 0x00000042
- 0x00020007 0x0000004d
- 0x00020008 0x00000056
-
- 0x00030000 0x00000012
- 0x00030001 0x0000001d>;
- #thermal-sensor-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
new file mode 100644
index 0000000..ae76208
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
+
+maintainers:
+ - Anson Huang <Anson.Huang@nxp.com>
+
+properties:
+ compatible:
+ description: |
+ The version of the device is determined by the TMU IP Block Revision
+ Register (IPBRR0) at offset 0x0BF8.
+ Table of correspondences between IPBRR0 values and example chips:
+ Value Device
+ ---------- -----
+ 0x01900102 T1040
+ enum:
+ - fsl,qoriq-tmu
+ - fsl,imx8mq-tmu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,tmu-range:
+ $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ description: |
+ The values to be programmed into TTRnCR, as specified by the SoC
+ reference manual. The first cell is TTR0CR, the second is TTR1CR, etc.
+ maxItems: 4
+
+ fsl,tmu-calibration:
+ $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ description: |
+ A list of cell pairs containing temperature calibration data, as
+ specified by the SoC reference manual. The first cell of each pair
+ is the value to be written to TTCFGR, and the second is the value
+ to be written to TSCFGR.
+ items:
+ items:
+ - description: value for TTCFGR
+ - description: value for TSCFGR
+ minItems: 1
+ maxItems: 64
+
+ little-endian:
+ description: |
+ boolean, if present, the TMU registers are little endian. If absent,
+ the default is big endian.
+ type: boolean
+
+ clocks:
+ maxItems: 1
+
+ "#thermal-sensor-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,tmu-range
+ - fsl,tmu-calibration
+ - '#thermal-sensor-cells'
+
+examples:
+ - |
+ tmu@f0000 {
+ compatible = "fsl,qoriq-tmu";
+ reg = <0xf0000 0x1000>;
+ interrupts = <18 2 0 0>;
+ fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
+ fsl,tmu-calibration = <0x00000000 0x00000025>,
+ <0x00000001 0x00000028>,
+ <0x00000002 0x0000002d>,
+ <0x00000003 0x00000031>,
+ <0x00000004 0x00000036>,
+ <0x00000005 0x0000003a>,
+ <0x00000006 0x00000040>,
+ <0x00000007 0x00000044>,
+ <0x00000008 0x0000004a>,
+ <0x00000009 0x0000004f>,
+ <0x0000000a 0x00000054>,
+ <0x00010000 0x0000000d>,
+ <0x00010001 0x00000013>,
+ <0x00010002 0x00000019>,
+ <0x00010003 0x0000001f>,
+ <0x00010004 0x00000025>,
+ <0x00010005 0x0000002d>,
+ <0x00010006 0x00000033>,
+ <0x00010007 0x00000043>,
+ <0x00010008 0x0000004b>,
+ <0x00010009 0x00000053>,
+ <0x00020000 0x00000010>,
+ <0x00020001 0x00000017>,
+ <0x00020002 0x0000001f>,
+ <0x00020003 0x00000029>,
+ <0x00020004 0x00000031>,
+ <0x00020005 0x0000003c>,
+ <0x00020006 0x00000042>,
+ <0x00020007 0x0000004d>,
+ <0x00020008 0x00000056>,
+ <0x00030000 0x00000012>,
+ <0x00030001 0x0000001d>;
+ #thermal-sensor-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* RE: [PATCH V2] dt-bindings: thermal: Convert qoriq to json-schema
From: Anson Huang @ 2020-06-02 1:30 UTC (permalink / raw)
To: Rob Herring
Cc: Zhang Rui, Daniel Lezcano, Amit Kucheria, open list:THERMAL,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
dl-linux-imx, Jia Hongtao
In-Reply-To: <CAL_JsqKVL4J=-aLPsSYgGVdnx3qjA=J8M08ztzv9=0V9gY=14A@mail.gmail.com>
Hi, Rob
> Subject: Re: [PATCH V2] dt-bindings: thermal: Convert qoriq to json-schema
>
> On Sun, May 31, 2020 at 9:45 PM Anson Huang <Anson.Huang@nxp.com>
> wrote:
> >
> > Convert the qoriq thermal binding to DT schema format using
> > json-schema
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > Changes since V1:
> > - add 'maxItems' for 'fsl,tmu-range' property;
> > - add 'minItems'/'maxItems' and items descriptions for
> 'fsl,tmu-calibration' property;
> > - remove description for common property '#thermal-sensor-cells';
> > - refine 'fsl,tmu-calibration' format in example.
> > ---
> > .../devicetree/bindings/thermal/qoriq-thermal.txt | 71
> > ------------- .../devicetree/bindings/thermal/qoriq-thermal.yaml |
> > 112 +++++++++++++++++++++
> > 2 files changed, 112 insertions(+), 71 deletions(-) delete mode
> > 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> > create mode 100644
> > Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
>
> [...]
>
> > diff --git
> > a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> > b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> > new file mode 100644
> > index 0000000..c5df999
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> > @@ -0,0 +1,112 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Fthermal%2Fqoriq-thermal.yaml%23&data=0
> 2%7C
> >
> +01%7CAnson.Huang%40nxp.com%7Cbb14200bf9dd47404fd308d8064c5719
> %7C686ea
> >
> +1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637266272232329711&am
> p;sdata=gz
> > +zLUrr9f56HcPB1iy4xQvj2tw41Mc9Af5QUJbuvnCY%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7CAns
> on.Hua
> >
> +ng%40nxp.com%7Cbb14200bf9dd47404fd308d8064c5719%7C686ea1d3bc2
> b4c6fa92
> >
> +cd99c5c301635%7C0%7C0%7C637266272232329711&sdata=7qkHkpj
> XPXMYn13c
> > +I1pndBwFgfI2%2F6gMfCgWPrQSnmc%3D&reserved=0
> > +
> > +title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
> > +
> > +maintainers:
> > + - Hongtao Jia <hongtao.jia@freescale.com>
>
> This email is bouncing. Should be @nxp.com?
Yes, but looks like hongtao is no longer in NXP, so the hongtao.jia@nxp.com
can NOT be touched in, I sent out V3 patch and also got the notification of failed
to send to hongtao.jia@nxp.com, so I will use myself as maintainer, correct me if anything
wrong. Will send a V4.
Thanks,
Anson
^ permalink raw reply
* [PATCH V3] dt-bindings: thermal: Convert qoriq to json-schema
From: Anson Huang @ 2020-06-02 1:15 UTC (permalink / raw)
To: rui.zhang, daniel.lezcano, amit.kucheria, robh+dt, hongtao.jia,
linux-pm, devicetree, linux-kernel
Cc: Linux-imx
Convert the qoriq thermal binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V2:
- correct maintainer's email address.
---
.../devicetree/bindings/thermal/qoriq-thermal.txt | 71 -------------
.../devicetree/bindings/thermal/qoriq-thermal.yaml | 112 +++++++++++++++++++++
2 files changed, 112 insertions(+), 71 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
deleted file mode 100644
index 28f2cba..0000000
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
-
-Required properties:
-- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The
- version of the device is determined by the TMU IP Block Revision
- Register (IPBRR0) at offset 0x0BF8.
- Table of correspondences between IPBRR0 values and example chips:
- Value Device
- ---------- -----
- 0x01900102 T1040
-- reg : Address range of TMU registers.
-- interrupts : Contains the interrupt for TMU.
-- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by
- the SoC reference manual. The first cell is TTR0CR, the second is
- TTR1CR, etc.
-- fsl,tmu-calibration : A list of cell pairs containing temperature
- calibration data, as specified by the SoC reference manual.
- The first cell of each pair is the value to be written to TTCFGR,
- and the second is the value to be written to TSCFGR.
-- #thermal-sensor-cells : Must be 1. The sensor specifier is the monitoring
- site ID, and represents the "n" in TRITSRn and TRATSRn.
-
-Optional property:
-- little-endian : If present, the TMU registers are little endian. If absent,
- the default is big endian.
-- clocks : the clock for clocking the TMU silicon.
-
-Example:
-
-tmu@f0000 {
- compatible = "fsl,qoriq-tmu";
- reg = <0xf0000 0x1000>;
- interrupts = <18 2 0 0>;
- fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
- fsl,tmu-calibration = <0x00000000 0x00000025
- 0x00000001 0x00000028
- 0x00000002 0x0000002d
- 0x00000003 0x00000031
- 0x00000004 0x00000036
- 0x00000005 0x0000003a
- 0x00000006 0x00000040
- 0x00000007 0x00000044
- 0x00000008 0x0000004a
- 0x00000009 0x0000004f
- 0x0000000a 0x00000054
-
- 0x00010000 0x0000000d
- 0x00010001 0x00000013
- 0x00010002 0x00000019
- 0x00010003 0x0000001f
- 0x00010004 0x00000025
- 0x00010005 0x0000002d
- 0x00010006 0x00000033
- 0x00010007 0x00000043
- 0x00010008 0x0000004b
- 0x00010009 0x00000053
-
- 0x00020000 0x00000010
- 0x00020001 0x00000017
- 0x00020002 0x0000001f
- 0x00020003 0x00000029
- 0x00020004 0x00000031
- 0x00020005 0x0000003c
- 0x00020006 0x00000042
- 0x00020007 0x0000004d
- 0x00020008 0x00000056
-
- 0x00030000 0x00000012
- 0x00030001 0x0000001d>;
- #thermal-sensor-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
new file mode 100644
index 0000000..4bc344a
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
+
+maintainers:
+ - Hongtao Jia <hongtao.jia@nxp.com>
+
+properties:
+ compatible:
+ description: |
+ The version of the device is determined by the TMU IP Block Revision
+ Register (IPBRR0) at offset 0x0BF8.
+ Table of correspondences between IPBRR0 values and example chips:
+ Value Device
+ ---------- -----
+ 0x01900102 T1040
+ enum:
+ - fsl,qoriq-tmu
+ - fsl,imx8mq-tmu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,tmu-range:
+ $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ description: |
+ The values to be programmed into TTRnCR, as specified by the SoC
+ reference manual. The first cell is TTR0CR, the second is TTR1CR, etc.
+ maxItems: 4
+
+ fsl,tmu-calibration:
+ $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ description: |
+ A list of cell pairs containing temperature calibration data, as
+ specified by the SoC reference manual. The first cell of each pair
+ is the value to be written to TTCFGR, and the second is the value
+ to be written to TSCFGR.
+ items:
+ items:
+ - description: value for TTCFGR
+ - description: value for TSCFGR
+ minItems: 1
+ maxItems: 64
+
+ little-endian:
+ description: |
+ boolean, if present, the TMU registers are little endian. If absent,
+ the default is big endian.
+ type: boolean
+
+ clocks:
+ maxItems: 1
+
+ "#thermal-sensor-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,tmu-range
+ - fsl,tmu-calibration
+ - '#thermal-sensor-cells'
+
+examples:
+ - |
+ tmu@f0000 {
+ compatible = "fsl,qoriq-tmu";
+ reg = <0xf0000 0x1000>;
+ interrupts = <18 2 0 0>;
+ fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
+ fsl,tmu-calibration = <0x00000000 0x00000025>,
+ <0x00000001 0x00000028>,
+ <0x00000002 0x0000002d>,
+ <0x00000003 0x00000031>,
+ <0x00000004 0x00000036>,
+ <0x00000005 0x0000003a>,
+ <0x00000006 0x00000040>,
+ <0x00000007 0x00000044>,
+ <0x00000008 0x0000004a>,
+ <0x00000009 0x0000004f>,
+ <0x0000000a 0x00000054>,
+ <0x00010000 0x0000000d>,
+ <0x00010001 0x00000013>,
+ <0x00010002 0x00000019>,
+ <0x00010003 0x0000001f>,
+ <0x00010004 0x00000025>,
+ <0x00010005 0x0000002d>,
+ <0x00010006 0x00000033>,
+ <0x00010007 0x00000043>,
+ <0x00010008 0x0000004b>,
+ <0x00010009 0x00000053>,
+ <0x00020000 0x00000010>,
+ <0x00020001 0x00000017>,
+ <0x00020002 0x0000001f>,
+ <0x00020003 0x00000029>,
+ <0x00020004 0x00000031>,
+ <0x00020005 0x0000003c>,
+ <0x00020006 0x00000042>,
+ <0x00020007 0x0000004d>,
+ <0x00020008 0x00000056>,
+ <0x00030000 0x00000012>,
+ <0x00030001 0x0000001d>;
+ #thermal-sensor-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
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