* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-05-28 22:20 UTC (permalink / raw)
To: Baoquan He, Chen Zhou
Cc: tglx, mingo, catalin.marinas, will, dyoung, robh+dt, arnd,
devicetree, linux-doc, kexec, linux-kernel, horms, guohanjun,
pkushwaha, linux-arm-kernel
In-Reply-To: <20200526014242.GF20045@MiWiFi-R3L-srv>
On 5/25/20 8:42 PM, Baoquan He wrote:
> On 05/21/20 at 05:38pm, Chen Zhou 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.
> OK, moving x86 CRASH_ALIGN to 2M is suggested by Dave. Because
> CONFIG_PHYSICAL_ALIGN can be selected from 2M to 16M. So 2M seems good.
> But, anyway, we should tell the reason why it need be changed in commit
> log.
>
>
> arch/x86/Kconfig:
> config PHYSICAL_ALIGN
> hex "Alignment value to which kernel should be aligned"
> default "0x200000"
> range 0x2000 0x1000000 if X86_32
> range 0x200000 0x1000000 if X86_64
>
>> - 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.
> And the crashkernel=X,high being deleted need be told too. Otherwise
> people reading the commit have to check why themselves. I didn't follow
> the old version, can't see why ,high can't be specified explicitly.
>
>> - 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!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJwQs3C4x$
>> [v1]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ6e-mIEp$
>> [v2]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJyUVjUta$
>> [v3]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ3CXBRdT$
>> [v4]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ7SxW1Vj$
>> [v5]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ2wyJ9tj$
>> [v6]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJzvGhWBh$
>> [v7]: https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ6pAg6tX$
>>
>> 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
>>
>> Documentation/admin-guide/kdump/kdump.rst | 13 ++-
>> .../admin-guide/kernel-parameters.txt | 12 ++-
>> Documentation/devicetree/bindings/chosen.txt | 25 ++++++
>> arch/arm64/kernel/setup.c | 8 +-
>> arch/arm64/mm/init.c | 61 ++++++++++++-
>> arch/x86/kernel/setup.c | 66 ++------------
>> include/linux/crash_core.h | 3 +
>> include/linux/kexec.h | 2 -
>> kernel/crash_core.c | 85 +++++++++++++++++++
>> kernel/kexec_core.c | 17 ----
>> 10 files changed, 208 insertions(+), 84 deletions(-)
>>
>> --
>> 2.20.1
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/kexec__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJwwX8HSl$
>>
Hi,
This proposal to improve vmcore creation on Arm has been going on for
almost a year now.
Who is the final maintainer that needs to approve and except these ?
What are the lingering issues that are remaining so we get these
accepted into a upstream commit ?
Thank you.
John.
^ permalink raw reply
* Re: [PATCH v11 4/4] power: supply: bq25150 introduce the bq25150
From: Ricardo Rivera-Matos @ 2020-05-28 22:20 UTC (permalink / raw)
To: Andrew F. Davis, sre, pali, robh
Cc: dmurphy, linux-pm, linux-kernel, devicetree, sspatil
In-Reply-To: <95fcf5ae-cf49-4618-08cc-da7487450e53@ti.com>
On 5/28/20 9:43 AM, Andrew F. Davis wrote:
> On 5/28/20 10:05 AM, Ricardo Rivera-Matos wrote:
>> +static int bq2515x_set_precharge_current(struct bq2515x_device *bq2515x,
>> + int val)
>> +{
>> + int ret;
>> + unsigned int pchrgctrl;
>> + unsigned int icharge_range;
>> + unsigned int precharge_reg_code;
>> + u16 precharge_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
>> + u16 precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_1875_UA;
>
> Why u16? looks like it gets promoted everywhere it's used anyway.
ACK
>
>
>> +
>> + ret = regmap_read(bq2515x->regmap, BQ2515X_PCHRGCTRL, &pchrgctrl);
>> + if (ret)
>> + return ret;
>> +
>> + icharge_range = pchrgctrl & BQ2515X_ICHARGE_RANGE;
>> +
>> + if (icharge_range) {
>> + precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_3750_UA;
>> + precharge_multiplier = BQ2515X_ICHG_RNG_1B1_UA;
> This is a little hard to read when we have a default value overwritten
> in an if, it basically hides the else logic, suggest:
>
>
> if (icharge_range) {
> precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_3750_UA;
> precharge_multiplier = BQ2515X_ICHG_RNG_1B1_UA;
> } else {
> precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_1875_UA;
> precharge_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
> }
ACK. I originally had it as an if/else deal, but I got feedback it was
too verbose. It will stay verbose.
>
>
>> + }
>> + if (val > precharge_max_ua || val < BQ2515X_ICHG_MIN_UA)
>> + return -EINVAL;
>> +
>> + precharge_reg_code = val / precharge_multiplier;
>> +
>> + ret = bq2515x_set_charge_disable(bq2515x, 1);
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_update_bits(bq2515x->regmap, BQ2515X_PCHRGCTRL,
>> + BQ2515X_PRECHARGE_MASK, precharge_reg_code);
>> + if (ret)
>> + return ret;
>> +
>> + return bq2515x_set_charge_disable(bq2515x, 0);
>> +}
> [snip]
>
>> +
>> +static int bq2515x_set_ilim_lvl(struct bq2515x_device *bq2515x, int val)
>> +{
>> + int i = 0;
>> + unsigned int array_size = ARRAY_SIZE(bq2515x_ilim_lvl_values);
>> +
>> + if (val >= bq2515x_ilim_lvl_values[array_size - 1]) {
>
> Isn't this check the same as is done in first iteration of the below loop?
>
> Andrew
ACK
>
>
>> + i = array_size - 1;
>> + } else {
>> + for (i = array_size - 1; i > 0; i--) {
>> + if (val >= bq2515x_ilim_lvl_values[i])
>> + break;
>> + }
>> + }
>> + return regmap_write(bq2515x->regmap, BQ2515X_ILIMCTRL, i);
>> +}
>> +
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: omap: Update PRM binding for genpd
From: Rob Herring @ 2020-05-28 22:20 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Andrew F . Davis, Santosh Shilimkar, Suman Anna,
Tero Kristo, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <20200520211334.61814-2-tony@atomide.com>
On Wed, May 20, 2020 at 02:13:29PM -0700, Tony Lindgren wrote:
> The PRM (Power and Reset Module) has registers to enable and disable
> power domains, so let's update the binding for that.
multiple domains? Then why 0 cells?
>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> Documentation/devicetree/bindings/arm/omap/prm-inst.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> --- a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> @@ -18,6 +18,7 @@ Required properties:
> (base address and length)
>
> Optional properties:
> +- #power-domain-cells: Should be 0 if the PRM instance is a power domain.
...power domain provider.
> - #reset-cells: Should be 1 if the PRM instance in question supports resets.
>
> Example:
> @@ -25,5 +26,6 @@ Example:
> prm_dsp2: prm@1b00 {
> compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
> reg = <0x1b00 0x40>;
> + #power-domain-cells = <0>;
> #reset-cells = <1>;
> };
> --
> 2.26.2
^ permalink raw reply
* Re: [v1] drm/msm: add shutdown support for display platform_driver
From: Stephen Boyd @ 2020-05-28 22:20 UTC (permalink / raw)
To: Krishna Manikandan, devicetree, dri-devel, freedreno,
linux-arm-msm
Cc: Krishna Manikandan, linux-kernel, robdclark, seanpaul, hoegsberg,
kalyan_t, nganji, mka
In-Reply-To: <1590655103-21568-1-git-send-email-mkrishn@codeaurora.org>
Quoting Krishna Manikandan (2020-05-28 01:38:23)
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index e4b750b..7a8953f 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1322,6 +1322,18 @@ static int msm_pdev_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static void msm_pdev_shutdown(struct platform_device *pdev)
> +{
> + struct drm_device *drm = platform_get_drvdata(pdev);
> +
> + if (!drm) {
> + DRM_ERROR("Invalid drm device node\n");
> + return;
> + }
When would this ever happen? Please drop this useless check.
> +
> + drm_atomic_helper_shutdown(drm);
> +}
> +
> static const struct of_device_id dt_match[] = {
> { .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
> { .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
^ permalink raw reply
* Re: [PATCH 04/12] dt-bindings: irqchip: ti,sci-intr: Update bindings to drop the usage of gic as parent
From: Rob Herring @ 2020-05-28 22:14 UTC (permalink / raw)
To: Lokesh Vutla
Cc: Marc Zyngier, Thomas Gleixner, Nishanth Menon, Tero Kristo,
Santosh Shilimkar, Linux ARM Mailing List, Sekhar Nori,
Grygorii Strashko, Peter Ujfalusi, Device Tree Mailing List
In-Reply-To: <20200520124454.10532-5-lokeshvutla@ti.com>
On Wed, May 20, 2020 at 06:14:46PM +0530, Lokesh Vutla wrote:
> Drop the firmware related dt-bindings and use the hardware specified
> interrupt numbers within Interrupt Router. This ensures interrupt router
> DT node need not assume any interrupt parent type.
I didn't like this binding to begin with, but now you're breaking
compatibility.
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> .../interrupt-controller/ti,sci-intr.txt | 31 ++++++++++---------
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> index 1a8718f8855d..8b56b2de1c73 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> @@ -44,15 +44,17 @@ Required Properties:
> 4: If intr supports level triggered interrupts.
> - interrupt-controller: Identifies the node as an interrupt controller
> - #interrupt-cells: Specifies the number of cells needed to encode an
> - interrupt source. The value should be 2.
> - First cell should contain the TISCI device ID of source
> - Second cell should contain the interrupt source offset
> - within the device.
> + interrupt source. The value should be 1.
> + First cell should contain interrupt router input number
> + as specified by hardware.
> - ti,sci: Phandle to TI-SCI compatible System controller node.
> -- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
> -- ti,sci-rm-range-girq: Array of TISCI subtype ids representing the host irqs
> - assigned to this interrupt router. Each subtype id
> - corresponds to a range of host irqs.
> +- ti,sci-dev-id: TISCI device id of interrupt controller.
> +- ti,interrupt-ranges: Set of triplets containing ranges that convert
> + the INTR output interrupt numbers to parent's
> + interrupt number. Each triplet has following entries:
> + - First entry specifies the base for intr output irq
> + - Second entry specifies the base for parent irqs
> + - Third entry specifies the limit
Humm, sounds like what interrupt-map does.
>
> For more details on TISCI IRQ resource management refer:
> http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
> @@ -62,21 +64,20 @@ Example:
> The following example demonstrates both interrupt router node and the consumer
> node(main gpio) on the AM654 SoC:
>
> -main_intr: interrupt-controller0 {
> +main_gpio_intr: interrupt-controller0 {
> compatible = "ti,sci-intr";
> ti,intr-trigger-type = <1>;
> interrupt-controller;
> interrupt-parent = <&gic500>;
> - #interrupt-cells = <2>;
> + #interrupt-cells = <1>;
> ti,sci = <&dmsc>;
> - ti,sci-dst-id = <56>;
> - ti,sci-rm-range-girq = <0x1>;
> + ti,sci-dev-id = <131>;
> + ti,interrupt-ranges = <0 360 32>;
> };
>
> main_gpio0: gpio@600000 {
> ...
> - interrupt-parent = <&main_intr>;
> - interrupts = <57 256>, <57 257>, <57 258>,
> - <57 259>, <57 260>, <57 261>;
> + interrupt-parent = <&main_gpio_intr>;
> + interrupts = <192>, <193>, <194>, <195>, <196>, <197>;
> ...
> };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH V4] dt-bindings: thermal: Convert i.MX to json-schema
From: Rob Herring @ 2020-05-28 22:05 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, robh+dt, shawnguo, s.hauer, daniel.lezcano, kernel,
Linux-imx, linux-kernel, linux-arm-kernel, rui.zhang,
amit.kucheria, linux-pm, festevam
In-Reply-To: <1589967737-1128-1-git-send-email-Anson.Huang@nxp.com>
On Wed, 20 May 2020 17:42:17 +0800, Anson Huang wrote:
> Convert the i.MX thermal binding to DT schema format using json-schema
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> Changes since V3:
> - improve "fsl,tempmon" description.
> ---
> .../devicetree/bindings/thermal/imx-thermal.txt | 61 ------------
> .../devicetree/bindings/thermal/imx-thermal.yaml | 102 +++++++++++++++++++++
> 2 files changed, 102 insertions(+), 61 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/thermal/imx-thermal.txt
> create mode 100644 Documentation/devicetree/bindings/thermal/imx-thermal.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: mailbox: Add devicetree binding for Qcom IPCC
From: Rob Herring @ 2020-05-28 22:03 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-kernel, linux-arm-msm, bjorn.andersson, robh+dt, devicetree,
jassisinghbrar
In-Reply-To: <20200520084854.19729-2-manivannan.sadhasivam@linaro.org>
On Wed, 20 May 2020 14:18:52 +0530, Manivannan Sadhasivam wrote:
> Add devicetree YAML binding for Qualcomm Inter-Processor Communication
> Controller (IPCC) block.
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/mailbox/qcom-ipcc.yaml | 80 +++++++++++++++++++
> include/dt-bindings/mailbox/qcom-ipcc.h | 33 ++++++++
> 2 files changed, 113 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> create mode 100644 include/dt-bindings/mailbox/qcom-ipcc.h
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: edt-ft5x06: change reg property
From: Heiko Stübner @ 2020-05-28 22:02 UTC (permalink / raw)
To: Rob Herring
Cc: Dmitry Torokhov, Johan Jonker, linux-input, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20200528220136.GA748777@bogus>
Am Freitag, 29. Mai 2020, 00:01:36 CEST schrieb Rob Herring:
> On Wed, May 20, 2020 at 08:41:59PM +0200, Heiko Stübner wrote:
> > Hi Dmitry,
> >
> > Am Mittwoch, 20. Mai 2020, 19:13:24 CEST schrieb Dmitry Torokhov:
> > > Hi Johan,
> > >
> > > On Wed, May 20, 2020 at 09:33:27AM +0200, Johan Jonker wrote:
> > > > A test with the command below gives this error:
> > > >
> > > > arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml:
> > > > touchscreen@3e: reg:0:0: 56 was expected
> > > >
> > > > The touchscreen chip on 'rk3188-bqedison2qc' and other BQ models
> > > > was shipped with different addresses then the binding currently allows.
> > > > Change the reg property that any address will pass.
> > > >
> > > > make ARCH=arm dtbs_check
> > > > DT_SCHEMA_FILES=Documentation/devicetree/bindings/input/touchscreen/
> > > > edt-ft5x06.yaml
> > > >
> > > > Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> > > > ---
> > > > Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > > index 383d64a91..baa8e8f7e 100644
> > > > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > > @@ -42,7 +42,7 @@ properties:
> > > > - focaltech,ft6236
> > > >
> > > > reg:
> > > > - const: 0x38
> > > > + maxItems: 1
> > >
> > > Should we have a list of valid addresses instead of allowing any
> > > address? Controllers usually have only a couple of addresses that they
> > > support.
> >
> > from what I've read, the fdt touchscreen controllers are just a generic
> > cpu with device-specific (or better panel-specific) firmware, which seems
> > to include the address as well - so it looks to be variable.
> >
> > But of course that is only 2nd hand knowledge for me ;-)
> >
> >
> > But also, the i2c address is something you cannot really mess up,
> > either it is correct and your touchscreen works, or it isn't and and
> > adding entries to this list every time a new address variant pops up
> > feels clumsy.
>
> Is that an Ack?
for the patch itself:
Acked-by: Heiko Stuebner <heiko@sntech.de>
> I'm fine either way. It's really only useful if there's a single
> address because with a list it could still be wrong just as any other
> data like an interrupt number could be wrong.
>
> Rob
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: edt-ft5x06: change reg property
From: Rob Herring @ 2020-05-28 22:01 UTC (permalink / raw)
To: Heiko Stübner
Cc: Dmitry Torokhov, Johan Jonker, linux-input, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <4727344.YYj2SkWT1V@diego>
On Wed, May 20, 2020 at 08:41:59PM +0200, Heiko Stübner wrote:
> Hi Dmitry,
>
> Am Mittwoch, 20. Mai 2020, 19:13:24 CEST schrieb Dmitry Torokhov:
> > Hi Johan,
> >
> > On Wed, May 20, 2020 at 09:33:27AM +0200, Johan Jonker wrote:
> > > A test with the command below gives this error:
> > >
> > > arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml:
> > > touchscreen@3e: reg:0:0: 56 was expected
> > >
> > > The touchscreen chip on 'rk3188-bqedison2qc' and other BQ models
> > > was shipped with different addresses then the binding currently allows.
> > > Change the reg property that any address will pass.
> > >
> > > make ARCH=arm dtbs_check
> > > DT_SCHEMA_FILES=Documentation/devicetree/bindings/input/touchscreen/
> > > edt-ft5x06.yaml
> > >
> > > Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> > > ---
> > > Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > index 383d64a91..baa8e8f7e 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > @@ -42,7 +42,7 @@ properties:
> > > - focaltech,ft6236
> > >
> > > reg:
> > > - const: 0x38
> > > + maxItems: 1
> >
> > Should we have a list of valid addresses instead of allowing any
> > address? Controllers usually have only a couple of addresses that they
> > support.
>
> from what I've read, the fdt touchscreen controllers are just a generic
> cpu with device-specific (or better panel-specific) firmware, which seems
> to include the address as well - so it looks to be variable.
>
> But of course that is only 2nd hand knowledge for me ;-)
>
>
> But also, the i2c address is something you cannot really mess up,
> either it is correct and your touchscreen works, or it isn't and and
> adding entries to this list every time a new address variant pops up
> feels clumsy.
Is that an Ack?
I'm fine either way. It's really only useful if there's a single
address because with a list it could still be wrong just as any other
data like an interrupt number could be wrong.
Rob
^ permalink raw reply
* Re: [PATCH v2 4/4] drm/bridge: tfp410: Fix setup and hold time calculation
From: Laurent Pinchart @ 2020-05-28 21:46 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, dri-devel, linux-arm-kernel, jason,
tomi.valkeinen, robh+dt, airlied, shawnguo
In-Reply-To: <20200514143612.2094-5-ricardo.canuelo@collabora.com>
Hi Ricardo,
Thank you for the patch.
On Thu, May 14, 2020 at 04:36:12PM +0200, Ricardo Cañuelo wrote:
> The tfp410 has a data de-skew feature that allows the user to compensate
> the skew between IDCK and the pixel data and control signals.
>
> In the driver, the setup and hold times are calculated from the de-skew
> value. This retrieves the deskew value from the DT using the proper
> datatype and range check as described by the binding (u32 from 0 to 7)
> and fixes the calculation of the setup and hold times.
How about mentioning that the fix results from a change in the DT
bindings ? Otherwise it sounds it was a bug in the driver.
I would also mention that the patch fixes the min() calculation, which
was clearly wrong. I think I would have split this in two patches.
With this addressed,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
> index e3eb6364c0f7..21d99b4ea0c9 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -220,7 +220,7 @@ static int tfp410_parse_timings(struct tfp410 *dvi, bool i2c)
> struct device_node *ep;
> u32 pclk_sample = 0;
> u32 bus_width = 24;
> - s32 deskew = 0;
> + u32 deskew = 0;
>
> /* Start with defaults. */
> *timings = tfp410_default_timings;
> @@ -274,12 +274,12 @@ static int tfp410_parse_timings(struct tfp410 *dvi, bool i2c)
> }
>
> /* Get the setup and hold time from vendor-specific properties. */
> - of_property_read_u32(dvi->dev->of_node, "ti,deskew", (u32 *)&deskew);
> - if (deskew < -4 || deskew > 3)
> + of_property_read_u32(dvi->dev->of_node, "ti,deskew", &deskew);
> + if (deskew > 7)
> return -EINVAL;
>
> - timings->setup_time_ps = min(0, 1200 - 350 * deskew);
> - timings->hold_time_ps = min(0, 1300 + 350 * deskew);
> + timings->setup_time_ps = 1200 - 350 * ((s32)deskew - 4);
> + timings->hold_time_ps = max(0, 1300 + 350 * ((s32)deskew - 4));
>
> return 0;
> }
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: mtd: Convert ingenic,jz4780-nand.txt to YAML
From: Rob Herring @ 2020-05-28 21:45 UTC (permalink / raw)
To: Paul Cercueil
Cc: Boris Brezillon, od, Rob Herring, devicetree, linux-mtd,
linux-kernel, linux-gpio
In-Reply-To: <20200520002234.418025-3-paul@crapouillou.net>
On Wed, 20 May 2020 02:22:34 +0200, Paul Cercueil wrote:
> Convert the ingenic,jz4780-nand.txt doc file to ingenic,nand.yaml.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v2: - Don't include ingenic,nemc-client.yaml which is gone
> - Use 'partitions' property instead of '^partitions$' pattern
>
> .../bindings/mtd/ingenic,jz4780-nand.txt | 92 ------------
> .../devicetree/bindings/mtd/ingenic,nand.yaml | 132 ++++++++++++++++++
> 2 files changed, 132 insertions(+), 92 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> create mode 100644 Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: memory: Convert ingenic,jz4780-nemc.txt to YAML
From: Rob Herring @ 2020-05-28 21:45 UTC (permalink / raw)
To: Paul Cercueil
Cc: od, linux-gpio, devicetree, linux-kernel, Boris Brezillon,
Rob Herring, linux-mtd
In-Reply-To: <20200520002234.418025-2-paul@crapouillou.net>
On Wed, 20 May 2020 02:22:33 +0200, Paul Cercueil wrote:
> Convert the ingenic,jz4780-nemc.txt doc file to ingenic,nemc.yaml.
>
> The ingenic,jz4725b-nemc compatible string was added in the process,
> with a fallback to ingenic,jz4740-nemc.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v2: - Inline content of ingenic,nemc-client.yaml inside ingenic,nemc.yaml
> - Add missing 'reg' property to sub-nodes and mark it as required
> - Use a more generic wildcard to match all sub-nodes.
>
> .../ingenic,jz4780-nemc.txt | 76 -----------
> .../memory-controllers/ingenic,nemc.yaml | 126 ++++++++++++++++++
> 2 files changed, 126 insertions(+), 76 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: display: ti,tfp410.txt: convert to yaml
From: Laurent Pinchart @ 2020-05-28 21:43 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, dri-devel, linux-arm-kernel, jason,
tomi.valkeinen, robh+dt, airlied, shawnguo
In-Reply-To: <20200514143612.2094-4-ricardo.canuelo@collabora.com>
Hi Ricardo,
Thank you for the patch.
On Thu, May 14, 2020 at 04:36:11PM +0200, Ricardo Cañuelo wrote:
> Convert the DT binding documentation for the TI TFP410 DPI-to-DVI
> encoder to json-schema.
>
> The 'ti,deskew' is now an unsigned value from 0 to 7 instead of a signed
> value from -4 to 3. The rest of the binding is a direct translation from
> the old one.
I would have modified this in a separate patch.
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> .../bindings/display/bridge/ti,tfp410.txt | 66 ----------
> .../bindings/display/bridge/ti,tfp410.yaml | 124 ++++++++++++++++++
> 2 files changed, 124 insertions(+), 66 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> deleted file mode 100644
> index 5ff4f64ef8e8..000000000000
> --- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> +++ /dev/null
> @@ -1,66 +0,0 @@
> -TFP410 DPI to DVI encoder
> -=========================
> -
> -Required properties:
> -- compatible: "ti,tfp410"
> -
> -Optional properties:
> -- powerdown-gpios: power-down gpio
> -- reg: I2C address. If and only if present the device node should be placed
> - into the I2C controller node where the TFP410 I2C is connected to.
> -- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured
> - through th DK[3:1] pins. This property shall be present only if the TFP410
> - is not connected through I2C.
> -
> -Required nodes:
> -
> -This device has two video ports. Their connections are modeled using the OF
> -graph bindings specified in [1]. Each port node shall have a single endpoint.
> -
> -- Port 0 is the DPI input port. Its endpoint subnode shall contain a
> - pclk-sample and bus-width property and a remote-endpoint property as specified
> - in [1].
> - - If pclk-sample is not defined, pclk-sample = 0 should be assumed for
> - backward compatibility.
> - - If bus-width is not defined then bus-width = 24 should be assumed for
> - backward compatibility.
> - bus-width = 24: 24 data lines are connected and single-edge mode
> - bus-width = 12: 12 data lines are connected and dual-edge mode
> -
> -- Port 1 is the DVI output port. Its endpoint subnode shall contain a
> - remote-endpoint property is specified in [1].
> -
> -[1] Documentation/devicetree/bindings/media/video-interfaces.txt
> -
> -
> -Example
> --------
> -
> -tfp410: encoder@0 {
> - compatible = "ti,tfp410";
> - powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
> - ti,deskew = <4>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> -
> - tfp410_in: endpoint@0 {
> - pclk-sample = <1>;
> - bus-width = <24>;
> - remote-endpoint = <&dpi_out>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> -
> - tfp410_out: endpoint@0 {
> - remote-endpoint = <&dvi_connector_in>;
> - };
> - };
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
> new file mode 100644
> index 000000000000..a9f4fd8ea621
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
> @@ -0,0 +1,124 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ti,tfp410.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TFP410 DPI to DVI encoder
> +
> +maintainers:
> + - Tomi Valkeinen <tomi.valkeinen@ti.com>
> + - Jyri Sarha <jsarha@ti.com>
> +
> +properties:
> + compatible:
> + const: ti,tfp410
> +
> + reg:
> + description: I2C address of the device.
> + maxItems: 1
> +
> + powerdown-gpios:
> + maxItems: 1
> +
> + ti,deskew:
> + description:
> + Data de-skew value in 350ps increments, from 0 to 7, as configured
> + through the DK[3:1] pins. The de-skew multiplier is computed as
> + (DK[3:1] - 4), so it ranges from -4 to 3. This property shall be
> + present only if the TFP410 is not connected through I2C.
I'd replace the last sentence with
if:
required:
- reg
then:
properties:
ti,deskew: false
else:
required:
- ti,deskew
(between the required: and additionalProperties: objects below)
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 7
> +
> + ports:
> + description:
> + A node containing input and output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + type: object
> +
> + properties:
> + port@0:
> + description: DPI input port.
> + type: object
> +
> + properties:
> + reg:
> + const: 0
> +
> + endpoint:
> + type: object
> +
> + properties:
> + pclk-sample:
> + description:
> + Endpoint sampling edge. If not defined, pclk-sample =
> + 0 should be assumed for backwards compatibility.
Should the second sentence be dropped, as it's expressed with default: 0
?
> + enum:
> + - 0 # Falling edge
> + - 1 # Rising edge
> + default: 0
> +
> + bus-width:
> + description:
> + Endpoint bus width. If not defined, bus-width = 24
> + should be assumed for backwards compatibility.
Same here for the second sentence.
With these small issues fixed,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + enum:
> + - 12 # 12 data lines connected and dual-edge mode
> + - 24 # 24 data lines connected and single-edge mode
> + default: 24
> +
> + port@1:
> + description: DVI output port.
> + type: object
> +
> + properties:
> + reg:
> + const: 1
> +
> + endpoint:
> + type: object
> +
> + required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + tfp410: encoder {
> + compatible = "ti,tfp410";
> + powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
> + ti,deskew = <3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + tfp410_in: endpoint {
> + pclk-sample = <1>;
> + bus-width = <24>;
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + tfp410_out: endpoint {
> + remote-endpoint = <&dvi_connector_in>;
> + };
> + };
> + };
> + };
> +
> +...
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: pinctrl: Convert ingenic,pinctrl.txt to YAML
From: Rob Herring @ 2020-05-28 21:42 UTC (permalink / raw)
To: Paul Cercueil
Cc: Boris Brezillon, od, devicetree, linux-kernel, linux-mtd,
linux-gpio
In-Reply-To: <20200520002234.418025-1-paul@crapouillou.net>
On Wed, May 20, 2020 at 02:22:32AM +0200, Paul Cercueil wrote:
> Convert the ingenic,pinctrl.txt doc file to ingenic,pinctrl.yaml.
>
> In the process, some compatible strings now require a fallback, as the
> corresponding SoCs are pin-compatible with their fallback variant.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v2: - Use 'pinctrl' instead of 'pin-controller' as the node name
> - remove 'additionalProperties: false' since we will have pin conf nodes
You need to describe those nodes and not just allow anything.
>
> .../bindings/pinctrl/ingenic,pinctrl.txt | 81 -----------
> .../bindings/pinctrl/ingenic,pinctrl.yaml | 136 ++++++++++++++++++
> 2 files changed, 136 insertions(+), 81 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
> create mode 100644 Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
> diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
> new file mode 100644
> index 000000000000..5be2b1e95b36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/ingenic,pinctrl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ingenic SoCs pin controller devicetree bindings
> +
> +description: >
> + Please refer to pinctrl-bindings.txt in this directory for details of the
> + common pinctrl bindings used by client devices, including the meaning of the
> + phrase "pin configuration node".
> +
> + For the Ingenic SoCs, pin control is tightly bound with GPIO ports. All pins
> + may be used as GPIOs, multiplexed device functions are configured within the
> + GPIO port configuration registers and it is typical to refer to pins using the
> + naming scheme "PxN" where x is a character identifying the GPIO port with
> + which the pin is associated and N is an integer from 0 to 31 identifying the
> + pin within that GPIO port. For example PA0 is the first pin in GPIO port A,
> + and PB31 is the last pin in GPIO port B. The JZ4740, the X1000 and the X1830
> + contains 4 GPIO ports, PA to PD, for a total of 128 pins. The JZ4760, the
> + JZ4770 and the JZ4780 contains 6 GPIO ports, PA to PF, for a total of 192
> + pins.
> +
> +maintainers:
> + - Paul Cercueil <paul@crapouillou.net>
> +
> +properties:
> + nodename:
It's $nodename as that's not a real property. And that will expose the
error in the example for you.
> + pattern: "^pinctrl@[0-9a-f]+$"
> +
> + compatible:
> + oneOf:
> + - enum:
> + - ingenic,jz4740-pinctrl
> + - ingenic,jz4725b-pinctrl
> + - ingenic,jz4760-pinctrl
> + - ingenic,jz4770-pinctrl
> + - ingenic,jz4780-pinctrl
> + - ingenic,x1000-pinctrl
> + - ingenic,x1500-pinctrl
> + - ingenic,x1830-pinctrl
> + - items:
> + - const: ingenic,jz4760b-pinctrl
> + - const: ingenic,jz4760-pinctrl
> + - items:
> + - const: ingenic,x1000e-pinctrl
> + - const: ingenic,x1000-pinctrl
> +
> + reg:
> + maxItems: 1
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> +patternProperties:
> + "^gpio@[0-9]$":
> + type: object
> + properties:
> + compatible:
> + enum:
> + - ingenic,jz4740-gpio
> + - ingenic,jz4725b-gpio
> + - ingenic,jz4760-gpio
> + - ingenic,jz4770-gpio
> + - ingenic,jz4780-gpio
> + - ingenic,x1000-gpio
> + - ingenic,x1500-gpio
> + - ingenic,x1830-gpio
> +
> + reg:
> + items:
> + - description: The GPIO bank number
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> +
> + gpio-ranges:
> + maxItems: 1
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 2
> + description:
> + Refer to ../interrupt-controller/interrupts.txt for more details.
> +
> + interrupts:
> + maxItems: 1
> +
> + required:
> + - compatible
> + - reg
> + - gpio-controller
> + - "#gpio-cells"
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> +
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> +
> +examples:
> + - |
> + pin-controller@10010000 {
> + compatible = "ingenic,jz4770-pinctrl";
> + reg = <0x10010000 0x600>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio@0 {
> + compatible = "ingenic,jz4770-gpio";
> + reg = <0>;
> +
> + gpio-controller;
> + gpio-ranges = <&pinctrl 0 0 32>;
> + #gpio-cells = <2>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <17>;
> + };
> + };
> --
> 2.26.2
>
^ permalink raw reply
* Re: [v1] drm/bridge: ensure bridge suspend happens during PM sleep
From: Doug Anderson @ 2020-05-28 21:37 UTC (permalink / raw)
To: Stephen Boyd
Cc: Harigovindan P,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
dri-devel, freedreno, linux-arm-msm, LKML, Rob Clark, Sean Paul,
Kristian H. Kristensen, Kalyan Thota, nganji, Sam Ravnborg
In-Reply-To: <158931520588.215346.14524550377627605126@swboyd.mtv.corp.google.com>
Hi,
On Tue, May 12, 2020 at 1:26 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> The subject is not specific enough. I'd expect it to be something like:
>
> drm/bridge: ti-sn65dsi86: ensure bridge suspend happens during PM sleep
>
> Quoting Harigovindan P (2020-04-22 02:04:43)
> > ti-sn65dsi86 bridge is enumerated as a runtime device.
> >
> > Adding sleep ops to force runtime_suspend when PM suspend is
> > requested on the device.
> >
> > This change needs to be taken along with the series:
> > https://patchwork.kernel.org/patch/11494309/
>
> Why? It doesn't seem like it should be required to go along with a qcom
> specific driver patch.
>
> >
> > Signed-off-by: Harigovindan P <harigovi@codeaurora.org>
> > ---
>
> Besides the subject:
>
> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Are you planning to re-post with the changes Stephen requested? Maybe
CC Sam too who was nice enough to help land some of my recent changes
to this driver.
-Doug
^ permalink raw reply
* Re: [PATCH] dt-bindings: gpio: Convert mxs to json-schema
From: Rob Herring @ 2020-05-28 21:24 UTC (permalink / raw)
To: Anson Huang
Cc: Linux-imx, linux-arm-kernel, devicetree, linux-kernel,
bgolaszewski, s.hauer, festevam, linux-gpio, shawnguo,
linus.walleij, kernel, robh+dt
In-Reply-To: <1589934035-5309-1-git-send-email-Anson.Huang@nxp.com>
On Wed, 20 May 2020 08:20:35 +0800, Anson Huang wrote:
> Convert the MXS GPIO binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/gpio/gpio-mxs.txt | 88 -------------
> .../devicetree/bindings/gpio/gpio-mxs.yaml | 136 +++++++++++++++++++++
> 2 files changed, 136 insertions(+), 88 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-mxs.txt
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mxs.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: mtd: nand: Document the generic rb-gpios property
From: Rob Herring @ 2020-05-28 21:22 UTC (permalink / raw)
To: Boris Brezillon
Cc: devicetree, Richard Weinberger, Tudor Ambarus, Mark Rutland,
linux-mtd, Miquel Raynal, Vignesh Raghavendra, Rob Herring,
Harvey Hunt, Paul Cercueil
In-Reply-To: <20200519232454.374081-2-boris.brezillon@collabora.com>
On Wed, 20 May 2020 01:24:52 +0200, Boris Brezillon wrote:
> A few drivers use this property to describe GPIO pins used to sample
> the NAND Ready/Busy state. Let's make it part of the generic binding
> doc.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> Changes in v2:
> * New patch
> ---
> Documentation/devicetree/bindings/mtd/nand-controller.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 2/4] dt-bindings: regulator: add pca9450 regulator yaml
From: Rob Herring @ 2020-05-28 21:20 UTC (permalink / raw)
To: Robin Gong
Cc: broonie, kernel, john.lee, anson.huang, linux-imx,
catalin.marinas, s.hauer, linux-arm-kernel, robh+dt, linux-kernel,
devicetree, will, lgirdwood, festevam, shawnguo
In-Reply-To: <1589925907-9195-3-git-send-email-yibin.gong@nxp.com>
On Wed, 20 May 2020 06:05:05 +0800, Robin Gong wrote:
> Add device binding doc for pca9450 pmic driver.
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> ---
> .../bindings/regulator/nxp,pca9450-regulator.yaml | 190 +++++++++++++++++++++
> 1 file changed, 190 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 08/10] dt-bindings: mmc: owl: add compatible string actions, s700-mmc
From: Rob Herring @ 2020-05-28 21:17 UTC (permalink / raw)
To: Amit Singh Tomar
Cc: cristian.ciocaltea, andre.przywara, devicetree, linux-arm-kernel,
afaerber, linux-actions, linux-kernel, manivannan.sadhasivam,
robh+dt
In-Reply-To: <1589912368-480-9-git-send-email-amittomer25@gmail.com>
On Tue, 19 May 2020 23:49:26 +0530, Amit Singh Tomar wrote:
> The commit adds a new SoC specific compatible string "actions,s700-mmc"
> in combination with more generic string "actions,owl-mmc".
>
> Placement order of these strings should abide by the principle of
> "from most specific to most general".
>
> Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
> ---
> * Newly added patch in v2.
> ---
> Documentation/devicetree/bindings/mmc/owl-mmc.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 05/10] dt-bindings: dmaengine: convert Actions Semi Owl SoCs bindings to yaml
From: Rob Herring @ 2020-05-28 21:17 UTC (permalink / raw)
To: Amit Singh Tomar
Cc: andre.przywara, afaerber, vkoul, manivannan.sadhasivam,
dan.j.williams, cristian.ciocaltea, linux-kernel,
linux-arm-kernel, linux-actions, devicetree
In-Reply-To: <1589912368-480-6-git-send-email-amittomer25@gmail.com>
On Tue, May 19, 2020 at 11:49:23PM +0530, Amit Singh Tomar wrote:
> Converts the device tree bindings for the Actions Semi Owl SoCs DMA
> Controller over to YAML schemas.
>
> It also adds new compatible string "actions,s700-dma".
>
> Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
> ---
> Change since v1:
> * Updated the description field to reflect
> only the necessary information.
> * replaced the maxItems field with description for each
> controller attribute(except interrupts).
> * Replaced the clock macro with number to keep the example
> as independent as possible.
>
> New patch, was not there in RFC.
> ---
> Documentation/devicetree/bindings/dma/owl-dma.txt | 47 -------------
> Documentation/devicetree/bindings/dma/owl-dma.yaml | 76 ++++++++++++++++++++++
> 2 files changed, 76 insertions(+), 47 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
> create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.yaml
>
> diff --git a/Documentation/devicetree/bindings/dma/owl-dma.txt b/Documentation/devicetree/bindings/dma/owl-dma.txt
> deleted file mode 100644
> index 03e9bb12b75f..000000000000
> --- a/Documentation/devicetree/bindings/dma/owl-dma.txt
> +++ /dev/null
> @@ -1,47 +0,0 @@
> -* Actions Semi Owl SoCs DMA controller
> -
> -This binding follows the generic DMA bindings defined in dma.txt.
> -
> -Required properties:
> -- compatible: Should be "actions,s900-dma".
> -- reg: Should contain DMA registers location and length.
> -- interrupts: Should contain 4 interrupts shared by all channel.
> -- #dma-cells: Must be <1>. Used to represent the number of integer
> - cells in the dmas property of client device.
> -- dma-channels: Physical channels supported.
> -- dma-requests: Number of DMA request signals supported by the controller.
> - Refer to Documentation/devicetree/bindings/dma/dma.txt
> -- clocks: Phandle and Specifier of the clock feeding the DMA controller.
> -
> -Example:
> -
> -Controller:
> - dma: dma-controller@e0260000 {
> - compatible = "actions,s900-dma";
> - reg = <0x0 0xe0260000 0x0 0x1000>;
> - interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> - #dma-cells = <1>;
> - dma-channels = <12>;
> - dma-requests = <46>;
> - clocks = <&clock CLK_DMAC>;
> - };
> -
> -Client:
> -
> -DMA clients connected to the Actions Semi Owl SoCs DMA controller must
> -use the format described in the dma.txt file, using a two-cell specifier
> -for each channel.
> -
> -The two cells in order are:
> -1. A phandle pointing to the DMA controller.
> -2. The channel id.
> -
> -uart5: serial@e012a000 {
> - ...
> - dma-names = "tx", "rx";
> - dmas = <&dma 26>, <&dma 27>;
> - ...
> -};
> diff --git a/Documentation/devicetree/bindings/dma/owl-dma.yaml b/Documentation/devicetree/bindings/dma/owl-dma.yaml
> new file mode 100644
> index 000000000000..82e7d261e967
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/owl-dma.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dma/owl-dma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Actions Semi Owl SoCs DMA controller
> +
> +description: |
> + The OWL DMA is a general-purpose direct memory access controller capable of
> + supporting 10 and 12 independent DMA channels for S700 and S900 SoCs
> + respectively.
> +
> +maintainers:
> + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> +
> +allOf:
> + - $ref: "dma-controller.yaml#"
> +
> +properties:
> + compatible:
> + enum:
> + - actions,s900-dma
> + - actions,s700-dma
> +
> + reg:
> + description:
> + DMA registers location and length.
Don't need a description. Just need:
maxItems: 1
> +
> + interrupts:
> + description:
> + controller supports 4 interrupts, which are freely assignable to the
> + DMA channels.
> + maxItems: 4
> +
> + "#dma-cells":
> + const: 1
> +
> + dma-channels:
> + description:
> + Physical channels supported.
Already defined in dma-controller.yaml. You need to add any constraints.
2^32 channels okay?
> +
> + dma-requests:
> + description:
> + Number of DMA request signals supported by the controller.
Same here.
> +
> + clocks:
> + description:
> + Phandle and Specifier of the clock feeding the DMA controller.
How many?
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - "#dma-cells"
> + - dma-channels
> + - dma-requests
> + - clocks
Add:
unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + dma: dma-controller@e0260000 {
> + compatible = "actions,s900-dma";
> + reg = <0x0 0xe0260000 0x0 0x1000>;
> + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> + #dma-cells = <1>;
> + dma-channels = <12>;
> + dma-requests = <46>;
> + clocks = <&clock 22>;
> + };
> +
> +...
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2 1/4] ARM: dts: dove: Make the DT compliant with the ti,tfp410 binding
From: Laurent Pinchart @ 2020-05-28 21:12 UTC (permalink / raw)
To: Rob Herring
Cc: Ricardo Cañuelo, kernel, devicetree, dri-devel,
linux-arm-kernel, jason, tomi.valkeinen, airlied, shawnguo
In-Reply-To: <20200528173755.GA113289@bogus>
Hi Rob,
On Thu, May 28, 2020 at 11:37:55AM -0600, Rob Herring wrote:
> On Thu, May 14, 2020 at 04:36:09PM +0200, Ricardo Cañuelo wrote:
> > Define a 'ports' node for 'dvi: video@39' and use the proper naming for
> > the powerdown-gpios property to make it compliant with the ti,tfp410
> > binding.
> >
> > This fills the minimum requirements to meet the binding requirements,
> > port endpoints are not defined.
>
> Just make 'ports' optional. This isn't really any better unless you add
> endpoints too.
I wonder how this is supposed to work though. The ti-tfp410 driver will
fail to probe if there's no endpoint. I'd rather already add a node for
the DVI connector and connect it to port@1 of the TFP410.
> > Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> > ---
> > arch/arm/boot/dts/dove-sbc-a510.dts | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/dove-sbc-a510.dts b/arch/arm/boot/dts/dove-sbc-a510.dts
> > index 2bb85a9b7614..32804c981625 100644
> > --- a/arch/arm/boot/dts/dove-sbc-a510.dts
> > +++ b/arch/arm/boot/dts/dove-sbc-a510.dts
> > @@ -132,7 +132,18 @@
> > dvi: video@39 {
> > compatible = "ti,tfp410";
> > reg = <0x39>;
> > - powerdown-gpio = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
> > + powerdown-gpios = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + port@0 {
> > + reg = <0>;
> > + };
> > + port@1 {
> > + reg = <1>;
> > + };
> > + };
> > };
> > };
> >
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] dt-bindings: serial: Add renesas,em-uart bindings
From: Rob Herring @ 2020-05-28 21:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Greg Kroah-Hartman, Rob Herring, linux-serial, devicetree,
Magnus Damm, linux-renesas-soc
In-Reply-To: <20200519080945.28798-1-geert+renesas@glider.be>
On Tue, 19 May 2020 10:09:45 +0200, Geert Uytterhoeven wrote:
> Document Device Tree bindings for the Renesas EMMA Mobile UART
> Interface.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> .../bindings/serial/renesas,em-uart.yaml | 49 +++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: memory-controllers: renesas,dbsc: Convert to json-schema
From: Rob Herring @ 2020-05-28 21:11 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: devicetree, linux-renesas-soc, Rob Herring
In-Reply-To: <20200519080812.28632-1-geert+renesas@glider.be>
On Tue, 19 May 2020 10:08:12 +0200, Geert Uytterhoeven wrote:
> Convert the Renesas DDR Bus Controller Device Tree binding documentation
> to json-schema.
>
> Drop referrals to driver behavior.
> Make power-domains required, as it is present for all current users.
> Update the example to match reality.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> .../memory-controllers/renesas,dbsc.txt | 44 ---------------
> .../memory-controllers/renesas,dbsc.yaml | 56 +++++++++++++++++++
> 2 files changed, 56 insertions(+), 44 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.txt
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] dt-bindings: interrupt-controller: arm, gic: Document resets property
From: Rob Herring @ 2020-05-28 21:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Andre Przywara, linux-arm-kernel, Marc Zyngier, Thomas Gleixner,
linux-renesas-soc, Jason Cooper, linux-kernel, devicetree,
Rob Herring
In-Reply-To: <20200519080519.28324-1-geert+renesas@glider.be>
On Tue, 19 May 2020 10:05:19 +0200, Geert Uytterhoeven wrote:
> A generic GIC block embedded in an SoC may be connected to an on-SoC
> reset controller. Hence allow the DTS writer to describe this relation,
> by documenting the optional presence of a "reset" property.
>
> This gets rid of "make dtbs_check" warnings like:
>
> arch/arm/boot/dts/r8a7791-porter.dt.yaml: interrupt-controller@f1001000: 'resets' does not match any of the regexes: '^v2m@[0-9a-f]+$', 'pinctrl-[0-9]+'
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> .../devicetree/bindings/interrupt-controller/arm,gic.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] ASoC: fsi: Add missing properties to DT bindings
From: Rob Herring @ 2020-05-28 21:09 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Kuninori Morimoto, Mark Brown, alsa-devel, Rob Herring,
Liam Girdwood, linux-renesas-soc, devicetree
In-Reply-To: <20200519075858.27869-1-geert+renesas@glider.be>
On Tue, 19 May 2020 09:58:58 +0200, Geert Uytterhoeven wrote:
> make dtbs_check:
>
> arch/arm/boot/dts/r8a7740-armadillo800eva.dt.yaml: sound@fe1f0000: '#sound-dai-cells', 'clocks', 'power-domains' do not match any of the regexes: 'pinctrl-[0-9]+'
>
> Fix this by documenting the missing properties.
> Update the example to match reality.
> While at it, improve the document title, and comment the various
> compatible values with the corresponding SoC names.
>
> Fixes: 7f464532b05dadc8 ("dt-bindings: Add missing 'additionalProperties: false'")
> Fixes: 2f52475bac7e1572 ("ASoC: fsi: switch to yaml base Documentation")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> For a clean "make dtbs_check", this depends on "ARM: dts: sh73a0: Add
> missing clocks to sound node"
> (http://lore.kernel.org/r/20200519075525.24742-1-geert+renesas@glider.be).
> ---
> .../bindings/sound/renesas,fsi.yaml | 29 +++++++++++++++----
> 1 file changed, 23 insertions(+), 6 deletions(-)
>
Applied, thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox