* Re: [PATCH v2 07/15] arm64: dts: imx8: switch to two cell scu clock binding
From: Fabio Estevam @ 2019-07-16 19:28 UTC (permalink / raw)
To: Dong Aisheng
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Dong Aisheng, Catalin Marinas, Will Deacon, Rob Herring,
NXP Linux Team, Sascha Hauer, Fabio Estevam, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <1563290089-11085-8-git-send-email-aisheng.dong@nxp.com>
On Tue, Jul 16, 2019 at 12:37 PM Dong Aisheng <aisheng.dong@nxp.com> wrote:
>
> switch to two cell scu clock binding
Please explain why you are doing this.
^ permalink raw reply
* Re: [PATCH v2 09/15] arm64: dts: imx8qm: add lsio ss support
From: Fabio Estevam @ 2019-07-16 19:30 UTC (permalink / raw)
To: Dong Aisheng
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Dong Aisheng, Catalin Marinas, Will Deacon, Rob Herring,
NXP Linux Team, Sascha Hauer, Fabio Estevam, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <1563290089-11085-10-git-send-email-aisheng.dong@nxp.com>
On Tue, Jul 16, 2019 at 12:37 PM Dong Aisheng <aisheng.dong@nxp.com> wrote:
> +&lsio_gpio0 {
> + compatible = "fsl,imx8qm-gpio", "fsl,imx35-gpio";
fsl,imx8qm-gpio needs to be documented.
^ permalink raw reply
* Re: [PATCH v2 10/15] arm64: dts: imx8qm: add conn ss support
From: Fabio Estevam @ 2019-07-16 19:31 UTC (permalink / raw)
To: Dong Aisheng
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Dong Aisheng, Catalin Marinas, Will Deacon, Rob Herring,
NXP Linux Team, Sascha Hauer, Fabio Estevam, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <1563290089-11085-11-git-send-email-aisheng.dong@nxp.com>
On Tue, Jul 16, 2019 at 12:37 PM Dong Aisheng <aisheng.dong@nxp.com> wrote:
>
> The CONN SS of MX8QM is mostly the same as MX8QXP except it has one more
> USB HSIC module support. So we can fully reuse the exist CONN SS dtsi.
> Add <soc>-ss-conn.dtsi with compatible string updated according to
> imx8-ss-conn.dtsi.
Subject and commit log does not match what the patch is actually doing.
^ permalink raw reply
* Re: [PATCH v2 13/15] arm64: dts: imx: add imx8qm common dts file
From: Fabio Estevam @ 2019-07-16 19:33 UTC (permalink / raw)
To: Dong Aisheng
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Dong Aisheng, Catalin Marinas, Will Deacon, Rob Herring,
NXP Linux Team, Sascha Hauer, Fabio Estevam, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <1563290089-11085-14-git-send-email-aisheng.dong@nxp.com>
On Tue, Jul 16, 2019 at 12:37 PM Dong Aisheng <aisheng.dong@nxp.com> wrote:
> --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> @@ -144,7 +144,7 @@
> };
>
> clk: clock-controller {
> - compatible = "fsl,imx8qxp-clk";
> + compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
This looks like unrelated to adding imx8qm support.
^ permalink raw reply
* RE: [v5,2/2] Documentation: dt: binding: rtc: add binding for ftm alarm driver
From: Leo Li @ 2019-07-16 20:31 UTC (permalink / raw)
To: a.zummo@towertech.it, alexandre.belloni@bootlin.com,
robh+dt@kernel.org
Cc: linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiaobo Xie, Jiafei Pan, Ran Wang, mark.rutland@arm.com,
devicetree@vger.kernel.org, Biwen Li
In-Reply-To: <20190716101655.47418-2-biwen.li@nxp.com>
> -----Original Message-----
> From: Biwen Li <biwen.li@nxp.com>
> Sent: Tuesday, July 16, 2019 5:17 AM
> To: a.zummo@towertech.it; alexandre.belloni@bootlin.com; Leo Li
> <leoyang.li@nxp.com>; robh+dt@kernel.org
> Cc: linux-rtc@vger.kernel.org; linux-kernel@vger.kernel.org; Xiaobo Xie
> <xiaobo.xie@nxp.com>; Jiafei Pan <jiafei.pan@nxp.com>; Ran Wang
> <ran.wang_1@nxp.com>; mark.rutland@arm.com;
> devicetree@vger.kernel.org; Biwen Li <biwen.li@nxp.com>
> Subject: [v5,2/2] Documentation: dt: binding: rtc: add binding for ftm alarm
> driver
>
> The patch adds binding for ftm alarm driver
>
> Signed-off-by: Biwen Li <biwen.li@nxp.com>
> ---
> Change in v5:
> - None
>
> Change in v4:
> - add note about dts and kernel options
> - add aliases in example
>
> Change in v3:
> - remove reg-names property
> - correct cells number
>
> Change in v2:
> - replace ls1043a with ls1088a as example
> - add rcpm node and fsl,rcpm-wakeup property
>
>
> .../bindings/rtc/rtc-fsl-ftm-alarm.txt | 49 +++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-
> alarm.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> new file mode 100644
> index 000000000000..fb018065406c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> @@ -0,0 +1,49 @@
> +Freescale FlexTimer Module (FTM) Alarm
> +
> +Note:
> +- The driver depends on RCPM driver
> + to wake up system in sleep.
> +- Need stop using RTC_HCTOSYS or use the DT aliases
> + to ensure the driver is not used as the primary RTC.
> + (Select DT aliases defaultly)
> +
> +Required properties:
> +- compatible : Should be "fsl,<chip>-ftm-alarm", the
> + supported chips include
> + "fsl,ls1012a-ftm-alarm"
> + "fsl,ls1021a-ftm-alarm"
> + "fsl,ls1028a-ftm-alarm"
> + "fsl,ls1043a-ftm-alarm"
> + "fsl,ls1046a-ftm-alarm"
> + "fsl,ls1088a-ftm-alarm"
> + "fsl,ls208xa-ftm-alarm"
> +- reg : Specifies base physical address and size of the register sets for the
> + FlexTimer Module and base physical address of IP Powerdown Exception
> Control
> + Register.
You removed the IP Powerdown exception register in the examples, but not here.
> +- interrupts : Should be the FlexTimer Module interrupt.
> +- fsl,rcpm-wakeup property and rcpm node : Please refer
> + Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> +
> +Optional properties:
> +- big-endian: If the host controller is big-endian mode, specify this property.
> + The default endian mode is little-endian.
> +
> +Example:
> +aliases {
> + ...
> + rtc1 = ftm_alarm0; /* Use flextimer alarm driver as /dev/rtc1 */
> + ...
> +};
> +
> +rcpm: rcpm@1e34040 {
> + compatible = "fsl,ls1088a-rcpm", "fsl,qoriq-rcpm-2.1+";
> + reg = <0x0 0x1e34040 0x0 0x18>;
> + fsl,#rcpm-wakeup-cells = <6>;
> +};
> +
> +ftm_alarm0: timer@2800000 {
> + compatible = "fsl,ls1088a-ftm-alarm";
> + reg = <0x0 0x2800000 0x0 0x10000>;
> + fsl,rcpm-wakeup = <&rcpm 0x0 0x0 0x0 0x0 0x4000 0x0>;
> + interrupts = <0 44 4>;
> +};
> --
> 2.17.1
^ permalink raw reply
* [PATCH 1/2] dt-bindings: iio: avia-hx711: Fix avdd-supply typo in example
From: Rob Herring @ 2019-07-16 20:33 UTC (permalink / raw)
To: devicetree, Jonathan Cameron; +Cc: linux-kernel, Andreas Klinger, linux-iio
Now that examples are validated against the DT schema, a typo in
avia-hx711 example generates a warning:
Documentation/devicetree/bindings/iio/adc/avia-hx711.example.dt.yaml: weight: 'avdd-supply' is a required property
Fix the typo.
Fixes: 5150ec3fe125 ("avia-hx711.yaml: transform DT binding to YAML")
Cc: Andreas Klinger <ak@it-klinger.de>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
Jonathan,
I have some other fixes I'm sending to Linus and can take these 2 if
that's easier.
Rob
Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
index 8a4100ceeaf2..d76ece97c76c 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
@@ -61,6 +61,6 @@ examples:
compatible = "avia,hx711";
sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
- avdd-suppy = <&avdd>;
+ avdd-supply = <&avdd>;
clock-frequency = <100000>;
};
--
2.20.1
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: iio: ad7124: Fix dtc warnings in example
From: Rob Herring @ 2019-07-16 20:33 UTC (permalink / raw)
To: devicetree, Jonathan Cameron; +Cc: linux-kernel, linux-iio
In-Reply-To: <20190716203324.12198-1-robh@kernel.org>
With the conversion to DT schema, the examples are now compiled with
dtc. The ad7124 binding example has the following warning:
Documentation/devicetree/bindings/iio/adc/adi,ad7124.example.dts:19.11-21: \
Warning (reg_format): /example-0/adc@0:reg: property has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
There's a default #size-cells and #address-cells values of 1 for
examples. For examples needing different values such as this one on a
SPI bus, they need to provide a SPI bus parent node.
Fixes: 26ae15e62d3c ("Convert AD7124 bindings documentation to YAML format.")
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
.../bindings/iio/adc/adi,ad7124.yaml | 71 ++++++++++---------
1 file changed, 38 insertions(+), 33 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
index cf494a08b837..9692b7f719f5 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
@@ -114,42 +114,47 @@ patternProperties:
examples:
- |
- adc@0 {
- compatible = "adi,ad7124-4";
- reg = <0>;
- spi-max-frequency = <5000000>;
- interrupts = <25 2>;
- interrupt-parent = <&gpio>;
- refin1-supply = <&adc_vref>;
- clocks = <&ad7124_mclk>;
- clock-names = "mclk";
-
+ spi {
#address-cells = <1>;
#size-cells = <0>;
- channel@0 {
+ adc@0 {
+ compatible = "adi,ad7124-4";
reg = <0>;
- diff-channels = <0 1>;
- adi,reference-select = <0>;
- adi,buffered-positive;
- };
-
- channel@1 {
- reg = <1>;
- bipolar;
- diff-channels = <2 3>;
- adi,reference-select = <0>;
- adi,buffered-positive;
- adi,buffered-negative;
- };
-
- channel@2 {
- reg = <2>;
- diff-channels = <4 5>;
- };
-
- channel@3 {
- reg = <3>;
- diff-channels = <6 7>;
+ spi-max-frequency = <5000000>;
+ interrupts = <25 2>;
+ interrupt-parent = <&gpio>;
+ refin1-supply = <&adc_vref>;
+ clocks = <&ad7124_mclk>;
+ clock-names = "mclk";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ diff-channels = <0 1>;
+ adi,reference-select = <0>;
+ adi,buffered-positive;
+ };
+
+ channel@1 {
+ reg = <1>;
+ bipolar;
+ diff-channels = <2 3>;
+ adi,reference-select = <0>;
+ adi,buffered-positive;
+ adi,buffered-negative;
+ };
+
+ channel@2 {
+ reg = <2>;
+ diff-channels = <4 5>;
+ };
+
+ channel@3 {
+ reg = <3>;
+ diff-channels = <6 7>;
+ };
};
};
--
2.20.1
^ permalink raw reply related
* Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks
From: Dmitry Osipenko @ 2019-07-16 20:47 UTC (permalink / raw)
To: Sowjanya Komatineni, Peter De Schrijver, Joseph Lo
Cc: thierry.reding, jonathanh, tglx, jason, marc.zyngier,
linus.walleij, stefan, mark.rutland, pgaikwad, sboyd, linux-clk,
linux-gpio, jckuo, talho, linux-tegra, linux-kernel, mperttunen,
spatra, robh+dt, devicetree
In-Reply-To: <ef63f72a-db03-ef28-a371-e578f351c713@nvidia.com>
16.07.2019 22:26, Sowjanya Komatineni пишет:
>
> On 7/16/19 11:43 AM, Dmitry Osipenko wrote:
>> 16.07.2019 21:30, Sowjanya Komatineni пишет:
>>> On 7/16/19 11:25 AM, Dmitry Osipenko wrote:
>>>> 16.07.2019 21:19, Sowjanya Komatineni пишет:
>>>>> On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:
>>>>>> On 7/16/19 8:00 AM, Dmitry Osipenko wrote:
>>>>>>> 16.07.2019 11:06, Peter De Schrijver пишет:
>>>>>>>> On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo wrote:
>>>>>>>>>> OK, Will add to CPUFreq driver...
>>>>>>>>>>> The other thing that also need attention is that T124 CPUFreq
>>>>>>>>>>> driver
>>>>>>>>>>> implicitly relies on DFLL driver to be probed first, which is
>>>>>>>>>>> icky.
>>>>>>>>>>>
>>>>>>>>>> Should I add check for successful dfll clk register explicitly in
>>>>>>>>>> CPUFreq driver probe and defer till dfll clk registers?
>>>>>>> Probably you should use the "device links". See [1][2] for the
>>>>>>> example.
>>>>>>>
>>>>>>> [1]
>>>>>>> https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [2]
>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/device_link.html
>>>>>>>
>>>>>>> Return EPROBE_DEFER instead of EINVAL if device_link_add() fails.
>>>>>>> And
>>>>>>> use of_find_device_by_node() to get the DFLL's device, see [3].
>>>>>>>
>>>>>>> [3]
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Will go thru and add...
>>>> Looks like I initially confused this case with getting orphaned clock.
>>>> I'm now seeing that the DFLL driver registers the clock and then
>>>> clk_get(dfll) should be returning EPROBE_DEFER until DFLL driver is
>>>> probed, hence everything should be fine as-is and there is no real need
>>>> for the 'device link'. Sorry for the confusion!
>>>>
>>>>>>>>> Sorry, I didn't follow the mail thread. Just regarding the DFLL
>>>>>>>>> part.
>>>>>>>>>
>>>>>>>>> As you know it, the DFLL clock is one of the CPU clock sources and
>>>>>>>>> integrated with DVFS control logic with the regulator. We will not
>>>>>>>>> switch
>>>>>>>>> CPU to other clock sources once we switched to DFLL. Because the
>>>>>>>>> CPU has
>>>>>>>>> been regulated by the DFLL HW with the DVFS table (CVB or OPP
>>>>>>>>> table
>>>>>>>>> you see
>>>>>>>>> in the driver.). We shouldn't reparent it to other sources with
>>>>>>>>> unknew
>>>>>>>>> freq/volt pair. That's not guaranteed to work. We allow
>>>>>>>>> switching to
>>>>>>>>> open-loop mode but different sources.
>>>>>>> Okay, then the CPUFreq driver will have to enforce DFLL freq to
>>>>>>> PLLP's
>>>>>>> rate before switching to PLLP in order to have a proper CPU voltage.
>>>>>> PLLP freq is safe to work for any CPU voltage. So no need to enforce
>>>>>> DFLL freq to PLLP rate before changing CCLK_G source to PLLP during
>>>>>> suspend
>>>>>>
>>>>> Sorry, please ignore my above comment. During suspend, need to change
>>>>> CCLK_G source to PLLP when dfll is in closed loop mode first and then
>>>>> dfll need to be set to open loop.
>>>> Okay.
>>>>
>>>>>>>>> And I don't exactly understand why we need to switch to PLLP in
>>>>>>>>> CPU
>>>>>>>>> idle
>>>>>>>>> driver. Just keep it on CL-DVFS mode all the time.
>>>>>>>>>
>>>>>>>>> In SC7 entry, the dfll suspend function moves it the open-loop
>>>>>>>>> mode. That's
>>>>>>>>> all. The sc7-entryfirmware will handle the rest of the sequence to
>>>>>>>>> turn off
>>>>>>>>> the CPU power.
>>>>>>>>>
>>>>>>>>> In SC7 resume, the warmboot code will handle the sequence to
>>>>>>>>> turn on
>>>>>>>>> regulator and power up the CPU cluster. And leave it on PLL_P.
>>>>>>>>> After
>>>>>>>>> resuming to the kernel, we re-init DFLL, restore the CPU clock
>>>>>>>>> policy (CPU
>>>>>>>>> runs on DFLL open-loop mode) and then moving to close-loop mode.
>>>>>>> The DFLL is re-inited after switching CCLK to DFLL parent during of
>>>>>>> the
>>>>>>> early clocks-state restoring by CaR driver. Hence instead of having
>>>>>>> odd
>>>>>>> hacks in the CaR driver, it is much nicer to have a proper
>>>>>>> suspend-resume sequencing of the device drivers. In this case
>>>>>>> CPUFreq
>>>>>>> driver is the driver that enables DFLL and switches CPU to that
>>>>>>> clock
>>>>>>> source, which means that this driver is also should be
>>>>>>> responsible for
>>>>>>> management of the DFLL's state during of suspend/resume process. If
>>>>>>> CPUFreq driver disables DFLL during suspend and re-enables it during
>>>>>>> resume, then looks like the CaR driver hacks around DFLL are not
>>>>>>> needed.
>>>>>>>
>>>>>>>>> The DFLL part looks good to me. BTW, change the patch subject to
>>>>>>>>> "Add
>>>>>>>>> suspend-resume support" seems more appropriate to me.
>>>>>>>>>
>>>>>>>> To clarify this, the sequences for DFLL use are as follows
>>>>>>>> (assuming
>>>>>>>> all
>>>>>>>> required DFLL hw configuration has been done)
>>>>>>>>
>>>>>>>> Switch to DFLL:
>>>>>>>> 0) Save current parent and frequency
>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>> 2) Enable DFLL
>>>>>>>> 3) Change cclk_g parent to DFLL
>>>>>>>> For OVR regulator:
>>>>>>>> 4) Change PWM output pin from tristate to output
>>>>>>>> 5) Enable DFLL PWM output
>>>>>>>> For I2C regulator:
>>>>>>>> 4) Enable DFLL I2C output
>>>>>>>> 6) Program DFLL to closed loop mode
>>>>>>>>
>>>>>>>> Switch away from DFLL:
>>>>>>>> 0) Change cclk_g parent to PLLP so the CPU frequency is ok for any
>>>>>>>> vdd_cpu voltage
>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>>
>>>>> I see during switch away from DFLL (suspend), cclk_g parent is not
>>>>> changed to PLLP before changing dfll to open loop mode.
>>>>>
>>>>> Will add this ...
>>>> The CPUFreq driver switches parent to PLLP during the probe, similar
>>>> should be done on suspend.
>>>>
>>>> I'm also wondering if it's always safe to switch to PLLP in the probe.
>>>> If CPU is running on a lower freq than PLLP, then some other more
>>>> appropriate intermediate parent should be selected.
>>>>
>>> CPU parents are PLL_X, PLL_P, and dfll. PLL_X always runs at higher rate
>>> so switching to PLL_P during CPUFreq probe prior to dfll clock enable
>>> should be safe.
>> AFAIK, PLLX could run at ~200MHz. There is also a divided output of PLLP
>> which CCLKG supports, the PLLP_OUT4.
>>
>> Probably, realistically, CPU is always running off a fast PLLX during
>> boot, but I'm wondering what may happen on KEXEC. I guess ideally
>> CPUFreq driver should also have a 'shutdown' callback to teardown DFLL
>> on a reboot, but likely that there are other clock-related problems as
>> well that may break KEXEC and thus it is not very important at the
>> moment.
>>
>> [snip]
>
> During bootup CPUG sources from PLL_X. By PLL_P source above I meant
> PLL_P_OUT4.
>
> As per clock policies, PLL_X is always used for high freq like >800Mhz
> and for low frequency it will be sourced from PLLP.
Alright, then please don't forget to pre-initialize PLLP_OUT4 rate to a
reasonable value using tegra_clk_init_table or assigned-clocks.
^ permalink raw reply
* Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks
From: Sowjanya Komatineni @ 2019-07-16 21:12 UTC (permalink / raw)
To: Dmitry Osipenko, Peter De Schrijver, Joseph Lo
Cc: thierry.reding, jonathanh, tglx, jason, marc.zyngier,
linus.walleij, stefan, mark.rutland, pgaikwad, sboyd, linux-clk,
linux-gpio, jckuo, talho, linux-tegra, linux-kernel, mperttunen,
spatra, robh+dt, devicetree
In-Reply-To: <27641e30-fdd1-e53a-206d-71e1f23343fd@gmail.com>
On 7/16/19 1:47 PM, Dmitry Osipenko wrote:
> 16.07.2019 22:26, Sowjanya Komatineni пишет:
>> On 7/16/19 11:43 AM, Dmitry Osipenko wrote:
>>> 16.07.2019 21:30, Sowjanya Komatineni пишет:
>>>> On 7/16/19 11:25 AM, Dmitry Osipenko wrote:
>>>>> 16.07.2019 21:19, Sowjanya Komatineni пишет:
>>>>>> On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:
>>>>>>> On 7/16/19 8:00 AM, Dmitry Osipenko wrote:
>>>>>>>> 16.07.2019 11:06, Peter De Schrijver пишет:
>>>>>>>>> On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo wrote:
>>>>>>>>>>> OK, Will add to CPUFreq driver...
>>>>>>>>>>>> The other thing that also need attention is that T124 CPUFreq
>>>>>>>>>>>> driver
>>>>>>>>>>>> implicitly relies on DFLL driver to be probed first, which is
>>>>>>>>>>>> icky.
>>>>>>>>>>>>
>>>>>>>>>>> Should I add check for successful dfll clk register explicitly in
>>>>>>>>>>> CPUFreq driver probe and defer till dfll clk registers?
>>>>>>>> Probably you should use the "device links". See [1][2] for the
>>>>>>>> example.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [2]
>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/device_link.html
>>>>>>>>
>>>>>>>> Return EPROBE_DEFER instead of EINVAL if device_link_add() fails.
>>>>>>>> And
>>>>>>>> use of_find_device_by_node() to get the DFLL's device, see [3].
>>>>>>>>
>>>>>>>> [3]
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Will go thru and add...
>>>>> Looks like I initially confused this case with getting orphaned clock.
>>>>> I'm now seeing that the DFLL driver registers the clock and then
>>>>> clk_get(dfll) should be returning EPROBE_DEFER until DFLL driver is
>>>>> probed, hence everything should be fine as-is and there is no real need
>>>>> for the 'device link'. Sorry for the confusion!
>>>>>
>>>>>>>>>> Sorry, I didn't follow the mail thread. Just regarding the DFLL
>>>>>>>>>> part.
>>>>>>>>>>
>>>>>>>>>> As you know it, the DFLL clock is one of the CPU clock sources and
>>>>>>>>>> integrated with DVFS control logic with the regulator. We will not
>>>>>>>>>> switch
>>>>>>>>>> CPU to other clock sources once we switched to DFLL. Because the
>>>>>>>>>> CPU has
>>>>>>>>>> been regulated by the DFLL HW with the DVFS table (CVB or OPP
>>>>>>>>>> table
>>>>>>>>>> you see
>>>>>>>>>> in the driver.). We shouldn't reparent it to other sources with
>>>>>>>>>> unknew
>>>>>>>>>> freq/volt pair. That's not guaranteed to work. We allow
>>>>>>>>>> switching to
>>>>>>>>>> open-loop mode but different sources.
>>>>>>>> Okay, then the CPUFreq driver will have to enforce DFLL freq to
>>>>>>>> PLLP's
>>>>>>>> rate before switching to PLLP in order to have a proper CPU voltage.
>>>>>>> PLLP freq is safe to work for any CPU voltage. So no need to enforce
>>>>>>> DFLL freq to PLLP rate before changing CCLK_G source to PLLP during
>>>>>>> suspend
>>>>>>>
>>>>>> Sorry, please ignore my above comment. During suspend, need to change
>>>>>> CCLK_G source to PLLP when dfll is in closed loop mode first and then
>>>>>> dfll need to be set to open loop.
>>>>> Okay.
>>>>>
>>>>>>>>>> And I don't exactly understand why we need to switch to PLLP in
>>>>>>>>>> CPU
>>>>>>>>>> idle
>>>>>>>>>> driver. Just keep it on CL-DVFS mode all the time.
>>>>>>>>>>
>>>>>>>>>> In SC7 entry, the dfll suspend function moves it the open-loop
>>>>>>>>>> mode. That's
>>>>>>>>>> all. The sc7-entryfirmware will handle the rest of the sequence to
>>>>>>>>>> turn off
>>>>>>>>>> the CPU power.
>>>>>>>>>>
>>>>>>>>>> In SC7 resume, the warmboot code will handle the sequence to
>>>>>>>>>> turn on
>>>>>>>>>> regulator and power up the CPU cluster. And leave it on PLL_P.
>>>>>>>>>> After
>>>>>>>>>> resuming to the kernel, we re-init DFLL, restore the CPU clock
>>>>>>>>>> policy (CPU
>>>>>>>>>> runs on DFLL open-loop mode) and then moving to close-loop mode.
>>>>>>>> The DFLL is re-inited after switching CCLK to DFLL parent during of
>>>>>>>> the
>>>>>>>> early clocks-state restoring by CaR driver. Hence instead of having
>>>>>>>> odd
>>>>>>>> hacks in the CaR driver, it is much nicer to have a proper
>>>>>>>> suspend-resume sequencing of the device drivers. In this case
>>>>>>>> CPUFreq
>>>>>>>> driver is the driver that enables DFLL and switches CPU to that
>>>>>>>> clock
>>>>>>>> source, which means that this driver is also should be
>>>>>>>> responsible for
>>>>>>>> management of the DFLL's state during of suspend/resume process. If
>>>>>>>> CPUFreq driver disables DFLL during suspend and re-enables it during
>>>>>>>> resume, then looks like the CaR driver hacks around DFLL are not
>>>>>>>> needed.
>>>>>>>>
>>>>>>>>>> The DFLL part looks good to me. BTW, change the patch subject to
>>>>>>>>>> "Add
>>>>>>>>>> suspend-resume support" seems more appropriate to me.
>>>>>>>>>>
>>>>>>>>> To clarify this, the sequences for DFLL use are as follows
>>>>>>>>> (assuming
>>>>>>>>> all
>>>>>>>>> required DFLL hw configuration has been done)
>>>>>>>>>
>>>>>>>>> Switch to DFLL:
>>>>>>>>> 0) Save current parent and frequency
>>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>>> 2) Enable DFLL
>>>>>>>>> 3) Change cclk_g parent to DFLL
>>>>>>>>> For OVR regulator:
>>>>>>>>> 4) Change PWM output pin from tristate to output
>>>>>>>>> 5) Enable DFLL PWM output
>>>>>>>>> For I2C regulator:
>>>>>>>>> 4) Enable DFLL I2C output
>>>>>>>>> 6) Program DFLL to closed loop mode
>>>>>>>>>
>>>>>>>>> Switch away from DFLL:
>>>>>>>>> 0) Change cclk_g parent to PLLP so the CPU frequency is ok for any
>>>>>>>>> vdd_cpu voltage
>>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>>>
>>>>>> I see during switch away from DFLL (suspend), cclk_g parent is not
>>>>>> changed to PLLP before changing dfll to open loop mode.
>>>>>>
>>>>>> Will add this ...
>>>>> The CPUFreq driver switches parent to PLLP during the probe, similar
>>>>> should be done on suspend.
>>>>>
>>>>> I'm also wondering if it's always safe to switch to PLLP in the probe.
>>>>> If CPU is running on a lower freq than PLLP, then some other more
>>>>> appropriate intermediate parent should be selected.
>>>>>
>>>> CPU parents are PLL_X, PLL_P, and dfll. PLL_X always runs at higher rate
>>>> so switching to PLL_P during CPUFreq probe prior to dfll clock enable
>>>> should be safe.
>>> AFAIK, PLLX could run at ~200MHz. There is also a divided output of PLLP
>>> which CCLKG supports, the PLLP_OUT4.
>>>
>>> Probably, realistically, CPU is always running off a fast PLLX during
>>> boot, but I'm wondering what may happen on KEXEC. I guess ideally
>>> CPUFreq driver should also have a 'shutdown' callback to teardown DFLL
>>> on a reboot, but likely that there are other clock-related problems as
>>> well that may break KEXEC and thus it is not very important at the
>>> moment.
>>>
>>> [snip]
>> During bootup CPUG sources from PLL_X. By PLL_P source above I meant
>> PLL_P_OUT4.
>>
>> As per clock policies, PLL_X is always used for high freq like >800Mhz
>> and for low frequency it will be sourced from PLLP.
> Alright, then please don't forget to pre-initialize PLLP_OUT4 rate to a
> reasonable value using tegra_clk_init_table or assigned-clocks.
PLLP_OUT4 rate update is not needed as it is safe to run at 408Mhz
because it is below fmax @ Vmin
^ permalink raw reply
* Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks
From: Dmitry Osipenko @ 2019-07-16 21:21 UTC (permalink / raw)
To: Sowjanya Komatineni, Peter De Schrijver, Joseph Lo
Cc: thierry.reding, jonathanh, tglx, jason, marc.zyngier,
linus.walleij, stefan, mark.rutland, pgaikwad, sboyd, linux-clk,
linux-gpio, jckuo, talho, linux-tegra, linux-kernel, mperttunen,
spatra, robh+dt, devicetree
In-Reply-To: <10c4b9a2-a857-d124-c22d-7fd71a473079@nvidia.com>
17.07.2019 0:12, Sowjanya Komatineni пишет:
>
> On 7/16/19 1:47 PM, Dmitry Osipenko wrote:
>> 16.07.2019 22:26, Sowjanya Komatineni пишет:
>>> On 7/16/19 11:43 AM, Dmitry Osipenko wrote:
>>>> 16.07.2019 21:30, Sowjanya Komatineni пишет:
>>>>> On 7/16/19 11:25 AM, Dmitry Osipenko wrote:
>>>>>> 16.07.2019 21:19, Sowjanya Komatineni пишет:
>>>>>>> On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:
>>>>>>>> On 7/16/19 8:00 AM, Dmitry Osipenko wrote:
>>>>>>>>> 16.07.2019 11:06, Peter De Schrijver пишет:
>>>>>>>>>> On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo wrote:
>>>>>>>>>>>> OK, Will add to CPUFreq driver...
>>>>>>>>>>>>> The other thing that also need attention is that T124 CPUFreq
>>>>>>>>>>>>> driver
>>>>>>>>>>>>> implicitly relies on DFLL driver to be probed first, which is
>>>>>>>>>>>>> icky.
>>>>>>>>>>>>>
>>>>>>>>>>>> Should I add check for successful dfll clk register
>>>>>>>>>>>> explicitly in
>>>>>>>>>>>> CPUFreq driver probe and defer till dfll clk registers?
>>>>>>>>> Probably you should use the "device links". See [1][2] for the
>>>>>>>>> example.
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [2]
>>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/device_link.html
>>>>>>>>>
>>>>>>>>> Return EPROBE_DEFER instead of EINVAL if device_link_add() fails.
>>>>>>>>> And
>>>>>>>>> use of_find_device_by_node() to get the DFLL's device, see [3].
>>>>>>>>>
>>>>>>>>> [3]
>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Will go thru and add...
>>>>>> Looks like I initially confused this case with getting orphaned
>>>>>> clock.
>>>>>> I'm now seeing that the DFLL driver registers the clock and then
>>>>>> clk_get(dfll) should be returning EPROBE_DEFER until DFLL driver is
>>>>>> probed, hence everything should be fine as-is and there is no real
>>>>>> need
>>>>>> for the 'device link'. Sorry for the confusion!
>>>>>>
>>>>>>>>>>> Sorry, I didn't follow the mail thread. Just regarding the DFLL
>>>>>>>>>>> part.
>>>>>>>>>>>
>>>>>>>>>>> As you know it, the DFLL clock is one of the CPU clock
>>>>>>>>>>> sources and
>>>>>>>>>>> integrated with DVFS control logic with the regulator. We
>>>>>>>>>>> will not
>>>>>>>>>>> switch
>>>>>>>>>>> CPU to other clock sources once we switched to DFLL. Because the
>>>>>>>>>>> CPU has
>>>>>>>>>>> been regulated by the DFLL HW with the DVFS table (CVB or OPP
>>>>>>>>>>> table
>>>>>>>>>>> you see
>>>>>>>>>>> in the driver.). We shouldn't reparent it to other sources with
>>>>>>>>>>> unknew
>>>>>>>>>>> freq/volt pair. That's not guaranteed to work. We allow
>>>>>>>>>>> switching to
>>>>>>>>>>> open-loop mode but different sources.
>>>>>>>>> Okay, then the CPUFreq driver will have to enforce DFLL freq to
>>>>>>>>> PLLP's
>>>>>>>>> rate before switching to PLLP in order to have a proper CPU
>>>>>>>>> voltage.
>>>>>>>> PLLP freq is safe to work for any CPU voltage. So no need to
>>>>>>>> enforce
>>>>>>>> DFLL freq to PLLP rate before changing CCLK_G source to PLLP during
>>>>>>>> suspend
>>>>>>>>
>>>>>>> Sorry, please ignore my above comment. During suspend, need to
>>>>>>> change
>>>>>>> CCLK_G source to PLLP when dfll is in closed loop mode first and
>>>>>>> then
>>>>>>> dfll need to be set to open loop.
>>>>>> Okay.
>>>>>>
>>>>>>>>>>> And I don't exactly understand why we need to switch to PLLP in
>>>>>>>>>>> CPU
>>>>>>>>>>> idle
>>>>>>>>>>> driver. Just keep it on CL-DVFS mode all the time.
>>>>>>>>>>>
>>>>>>>>>>> In SC7 entry, the dfll suspend function moves it the open-loop
>>>>>>>>>>> mode. That's
>>>>>>>>>>> all. The sc7-entryfirmware will handle the rest of the
>>>>>>>>>>> sequence to
>>>>>>>>>>> turn off
>>>>>>>>>>> the CPU power.
>>>>>>>>>>>
>>>>>>>>>>> In SC7 resume, the warmboot code will handle the sequence to
>>>>>>>>>>> turn on
>>>>>>>>>>> regulator and power up the CPU cluster. And leave it on PLL_P.
>>>>>>>>>>> After
>>>>>>>>>>> resuming to the kernel, we re-init DFLL, restore the CPU clock
>>>>>>>>>>> policy (CPU
>>>>>>>>>>> runs on DFLL open-loop mode) and then moving to close-loop mode.
>>>>>>>>> The DFLL is re-inited after switching CCLK to DFLL parent
>>>>>>>>> during of
>>>>>>>>> the
>>>>>>>>> early clocks-state restoring by CaR driver. Hence instead of
>>>>>>>>> having
>>>>>>>>> odd
>>>>>>>>> hacks in the CaR driver, it is much nicer to have a proper
>>>>>>>>> suspend-resume sequencing of the device drivers. In this case
>>>>>>>>> CPUFreq
>>>>>>>>> driver is the driver that enables DFLL and switches CPU to that
>>>>>>>>> clock
>>>>>>>>> source, which means that this driver is also should be
>>>>>>>>> responsible for
>>>>>>>>> management of the DFLL's state during of suspend/resume
>>>>>>>>> process. If
>>>>>>>>> CPUFreq driver disables DFLL during suspend and re-enables it
>>>>>>>>> during
>>>>>>>>> resume, then looks like the CaR driver hacks around DFLL are not
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>>>>> The DFLL part looks good to me. BTW, change the patch subject to
>>>>>>>>>>> "Add
>>>>>>>>>>> suspend-resume support" seems more appropriate to me.
>>>>>>>>>>>
>>>>>>>>>> To clarify this, the sequences for DFLL use are as follows
>>>>>>>>>> (assuming
>>>>>>>>>> all
>>>>>>>>>> required DFLL hw configuration has been done)
>>>>>>>>>>
>>>>>>>>>> Switch to DFLL:
>>>>>>>>>> 0) Save current parent and frequency
>>>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>>>> 2) Enable DFLL
>>>>>>>>>> 3) Change cclk_g parent to DFLL
>>>>>>>>>> For OVR regulator:
>>>>>>>>>> 4) Change PWM output pin from tristate to output
>>>>>>>>>> 5) Enable DFLL PWM output
>>>>>>>>>> For I2C regulator:
>>>>>>>>>> 4) Enable DFLL I2C output
>>>>>>>>>> 6) Program DFLL to closed loop mode
>>>>>>>>>>
>>>>>>>>>> Switch away from DFLL:
>>>>>>>>>> 0) Change cclk_g parent to PLLP so the CPU frequency is ok for
>>>>>>>>>> any
>>>>>>>>>> vdd_cpu voltage
>>>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>>>>
>>>>>>> I see during switch away from DFLL (suspend), cclk_g parent is not
>>>>>>> changed to PLLP before changing dfll to open loop mode.
>>>>>>>
>>>>>>> Will add this ...
>>>>>> The CPUFreq driver switches parent to PLLP during the probe, similar
>>>>>> should be done on suspend.
>>>>>>
>>>>>> I'm also wondering if it's always safe to switch to PLLP in the
>>>>>> probe.
>>>>>> If CPU is running on a lower freq than PLLP, then some other more
>>>>>> appropriate intermediate parent should be selected.
>>>>>>
>>>>> CPU parents are PLL_X, PLL_P, and dfll. PLL_X always runs at higher
>>>>> rate
>>>>> so switching to PLL_P during CPUFreq probe prior to dfll clock enable
>>>>> should be safe.
>>>> AFAIK, PLLX could run at ~200MHz. There is also a divided output of
>>>> PLLP
>>>> which CCLKG supports, the PLLP_OUT4.
>>>>
>>>> Probably, realistically, CPU is always running off a fast PLLX during
>>>> boot, but I'm wondering what may happen on KEXEC. I guess ideally
>>>> CPUFreq driver should also have a 'shutdown' callback to teardown DFLL
>>>> on a reboot, but likely that there are other clock-related problems as
>>>> well that may break KEXEC and thus it is not very important at the
>>>> moment.
>>>>
>>>> [snip]
>>> During bootup CPUG sources from PLL_X. By PLL_P source above I meant
>>> PLL_P_OUT4.
>>>
>>> As per clock policies, PLL_X is always used for high freq like >800Mhz
>>> and for low frequency it will be sourced from PLLP.
>> Alright, then please don't forget to pre-initialize PLLP_OUT4 rate to a
>> reasonable value using tegra_clk_init_table or assigned-clocks.
>
> PLLP_OUT4 rate update is not needed as it is safe to run at 408Mhz
> because it is below fmax @ Vmin
So even 204MHz CVB entries are having the same voltage as 408MHz,
correct? It's not instantly obvious to me from the DFLL driver's code
where the fmax @ Vmin is defined, I see that there is the min_millivolts
and frequency entries starting from 204MHZ defined per-table.
^ permalink raw reply
* Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks
From: Sowjanya Komatineni @ 2019-07-16 21:35 UTC (permalink / raw)
To: Dmitry Osipenko, Peter De Schrijver, Joseph Lo
Cc: thierry.reding, jonathanh, tglx, jason, marc.zyngier,
linus.walleij, stefan, mark.rutland, pgaikwad, sboyd, linux-clk,
linux-gpio, jckuo, talho, linux-tegra, linux-kernel, mperttunen,
spatra, robh+dt, devicetree
In-Reply-To: <fd8bad73-464b-54f1-be94-fe3ac8b23e6e@gmail.com>
On 7/16/19 2:21 PM, Dmitry Osipenko wrote:
> 17.07.2019 0:12, Sowjanya Komatineni пишет:
>> On 7/16/19 1:47 PM, Dmitry Osipenko wrote:
>>> 16.07.2019 22:26, Sowjanya Komatineni пишет:
>>>> On 7/16/19 11:43 AM, Dmitry Osipenko wrote:
>>>>> 16.07.2019 21:30, Sowjanya Komatineni пишет:
>>>>>> On 7/16/19 11:25 AM, Dmitry Osipenko wrote:
>>>>>>> 16.07.2019 21:19, Sowjanya Komatineni пишет:
>>>>>>>> On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:
>>>>>>>>> On 7/16/19 8:00 AM, Dmitry Osipenko wrote:
>>>>>>>>>> 16.07.2019 11:06, Peter De Schrijver пишет:
>>>>>>>>>>> On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo wrote:
>>>>>>>>>>>>> OK, Will add to CPUFreq driver...
>>>>>>>>>>>>>> The other thing that also need attention is that T124 CPUFreq
>>>>>>>>>>>>>> driver
>>>>>>>>>>>>>> implicitly relies on DFLL driver to be probed first, which is
>>>>>>>>>>>>>> icky.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Should I add check for successful dfll clk register
>>>>>>>>>>>>> explicitly in
>>>>>>>>>>>>> CPUFreq driver probe and defer till dfll clk registers?
>>>>>>>>>> Probably you should use the "device links". See [1][2] for the
>>>>>>>>>> example.
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>> https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [2]
>>>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/device_link.html
>>>>>>>>>>
>>>>>>>>>> Return EPROBE_DEFER instead of EINVAL if device_link_add() fails.
>>>>>>>>>> And
>>>>>>>>>> use of_find_device_by_node() to get the DFLL's device, see [3].
>>>>>>>>>>
>>>>>>>>>> [3]
>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Will go thru and add...
>>>>>>> Looks like I initially confused this case with getting orphaned
>>>>>>> clock.
>>>>>>> I'm now seeing that the DFLL driver registers the clock and then
>>>>>>> clk_get(dfll) should be returning EPROBE_DEFER until DFLL driver is
>>>>>>> probed, hence everything should be fine as-is and there is no real
>>>>>>> need
>>>>>>> for the 'device link'. Sorry for the confusion!
>>>>>>>
>>>>>>>>>>>> Sorry, I didn't follow the mail thread. Just regarding the DFLL
>>>>>>>>>>>> part.
>>>>>>>>>>>>
>>>>>>>>>>>> As you know it, the DFLL clock is one of the CPU clock
>>>>>>>>>>>> sources and
>>>>>>>>>>>> integrated with DVFS control logic with the regulator. We
>>>>>>>>>>>> will not
>>>>>>>>>>>> switch
>>>>>>>>>>>> CPU to other clock sources once we switched to DFLL. Because the
>>>>>>>>>>>> CPU has
>>>>>>>>>>>> been regulated by the DFLL HW with the DVFS table (CVB or OPP
>>>>>>>>>>>> table
>>>>>>>>>>>> you see
>>>>>>>>>>>> in the driver.). We shouldn't reparent it to other sources with
>>>>>>>>>>>> unknew
>>>>>>>>>>>> freq/volt pair. That's not guaranteed to work. We allow
>>>>>>>>>>>> switching to
>>>>>>>>>>>> open-loop mode but different sources.
>>>>>>>>>> Okay, then the CPUFreq driver will have to enforce DFLL freq to
>>>>>>>>>> PLLP's
>>>>>>>>>> rate before switching to PLLP in order to have a proper CPU
>>>>>>>>>> voltage.
>>>>>>>>> PLLP freq is safe to work for any CPU voltage. So no need to
>>>>>>>>> enforce
>>>>>>>>> DFLL freq to PLLP rate before changing CCLK_G source to PLLP during
>>>>>>>>> suspend
>>>>>>>>>
>>>>>>>> Sorry, please ignore my above comment. During suspend, need to
>>>>>>>> change
>>>>>>>> CCLK_G source to PLLP when dfll is in closed loop mode first and
>>>>>>>> then
>>>>>>>> dfll need to be set to open loop.
>>>>>>> Okay.
>>>>>>>
>>>>>>>>>>>> And I don't exactly understand why we need to switch to PLLP in
>>>>>>>>>>>> CPU
>>>>>>>>>>>> idle
>>>>>>>>>>>> driver. Just keep it on CL-DVFS mode all the time.
>>>>>>>>>>>>
>>>>>>>>>>>> In SC7 entry, the dfll suspend function moves it the open-loop
>>>>>>>>>>>> mode. That's
>>>>>>>>>>>> all. The sc7-entryfirmware will handle the rest of the
>>>>>>>>>>>> sequence to
>>>>>>>>>>>> turn off
>>>>>>>>>>>> the CPU power.
>>>>>>>>>>>>
>>>>>>>>>>>> In SC7 resume, the warmboot code will handle the sequence to
>>>>>>>>>>>> turn on
>>>>>>>>>>>> regulator and power up the CPU cluster. And leave it on PLL_P.
>>>>>>>>>>>> After
>>>>>>>>>>>> resuming to the kernel, we re-init DFLL, restore the CPU clock
>>>>>>>>>>>> policy (CPU
>>>>>>>>>>>> runs on DFLL open-loop mode) and then moving to close-loop mode.
>>>>>>>>>> The DFLL is re-inited after switching CCLK to DFLL parent
>>>>>>>>>> during of
>>>>>>>>>> the
>>>>>>>>>> early clocks-state restoring by CaR driver. Hence instead of
>>>>>>>>>> having
>>>>>>>>>> odd
>>>>>>>>>> hacks in the CaR driver, it is much nicer to have a proper
>>>>>>>>>> suspend-resume sequencing of the device drivers. In this case
>>>>>>>>>> CPUFreq
>>>>>>>>>> driver is the driver that enables DFLL and switches CPU to that
>>>>>>>>>> clock
>>>>>>>>>> source, which means that this driver is also should be
>>>>>>>>>> responsible for
>>>>>>>>>> management of the DFLL's state during of suspend/resume
>>>>>>>>>> process. If
>>>>>>>>>> CPUFreq driver disables DFLL during suspend and re-enables it
>>>>>>>>>> during
>>>>>>>>>> resume, then looks like the CaR driver hacks around DFLL are not
>>>>>>>>>> needed.
>>>>>>>>>>
>>>>>>>>>>>> The DFLL part looks good to me. BTW, change the patch subject to
>>>>>>>>>>>> "Add
>>>>>>>>>>>> suspend-resume support" seems more appropriate to me.
>>>>>>>>>>>>
>>>>>>>>>>> To clarify this, the sequences for DFLL use are as follows
>>>>>>>>>>> (assuming
>>>>>>>>>>> all
>>>>>>>>>>> required DFLL hw configuration has been done)
>>>>>>>>>>>
>>>>>>>>>>> Switch to DFLL:
>>>>>>>>>>> 0) Save current parent and frequency
>>>>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>>>>> 2) Enable DFLL
>>>>>>>>>>> 3) Change cclk_g parent to DFLL
>>>>>>>>>>> For OVR regulator:
>>>>>>>>>>> 4) Change PWM output pin from tristate to output
>>>>>>>>>>> 5) Enable DFLL PWM output
>>>>>>>>>>> For I2C regulator:
>>>>>>>>>>> 4) Enable DFLL I2C output
>>>>>>>>>>> 6) Program DFLL to closed loop mode
>>>>>>>>>>>
>>>>>>>>>>> Switch away from DFLL:
>>>>>>>>>>> 0) Change cclk_g parent to PLLP so the CPU frequency is ok for
>>>>>>>>>>> any
>>>>>>>>>>> vdd_cpu voltage
>>>>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>>>>>
>>>>>>>> I see during switch away from DFLL (suspend), cclk_g parent is not
>>>>>>>> changed to PLLP before changing dfll to open loop mode.
>>>>>>>>
>>>>>>>> Will add this ...
>>>>>>> The CPUFreq driver switches parent to PLLP during the probe, similar
>>>>>>> should be done on suspend.
>>>>>>>
>>>>>>> I'm also wondering if it's always safe to switch to PLLP in the
>>>>>>> probe.
>>>>>>> If CPU is running on a lower freq than PLLP, then some other more
>>>>>>> appropriate intermediate parent should be selected.
>>>>>>>
>>>>>> CPU parents are PLL_X, PLL_P, and dfll. PLL_X always runs at higher
>>>>>> rate
>>>>>> so switching to PLL_P during CPUFreq probe prior to dfll clock enable
>>>>>> should be safe.
>>>>> AFAIK, PLLX could run at ~200MHz. There is also a divided output of
>>>>> PLLP
>>>>> which CCLKG supports, the PLLP_OUT4.
>>>>>
>>>>> Probably, realistically, CPU is always running off a fast PLLX during
>>>>> boot, but I'm wondering what may happen on KEXEC. I guess ideally
>>>>> CPUFreq driver should also have a 'shutdown' callback to teardown DFLL
>>>>> on a reboot, but likely that there are other clock-related problems as
>>>>> well that may break KEXEC and thus it is not very important at the
>>>>> moment.
>>>>>
>>>>> [snip]
>>>> During bootup CPUG sources from PLL_X. By PLL_P source above I meant
>>>> PLL_P_OUT4.
>>>>
>>>> As per clock policies, PLL_X is always used for high freq like >800Mhz
>>>> and for low frequency it will be sourced from PLLP.
>>> Alright, then please don't forget to pre-initialize PLLP_OUT4 rate to a
>>> reasonable value using tegra_clk_init_table or assigned-clocks.
>> PLLP_OUT4 rate update is not needed as it is safe to run at 408Mhz
>> because it is below fmax @ Vmin
> So even 204MHz CVB entries are having the same voltage as 408MHz,
> correct? It's not instantly obvious to me from the DFLL driver's code
> where the fmax @ Vmin is defined, I see that there is the min_millivolts
> and frequency entries starting from 204MHZ defined per-table.
Yes at Vmin CPU Fmax is ~800Mhz. So anything below that will work at
Vmin voltage and PLLP max is 408Mhz.
^ permalink raw reply
* [PATCH 2/3 v3] dt-bindings: gpio: aspeed: Add SGPIO support
From: Hongwei Zhang @ 2019-07-16 21:48 UTC (permalink / raw)
To: Joel Stanley, Andrew Jeffery, Linus Walleij, devicetree
Cc: Hongwei Zhang, Rob Herring, Mark Rutland, Bartosz Golaszewski,
linux-aspeed, linux-kernel, linux-arm-kernel, linux-gpio
Add bindings to support SGPIO on AST2400 or AST2500.
Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
---
.../devicetree/bindings/gpio/sgpio-aspeed.txt | 55 ++++++++++++++++++++++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
diff --git a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
new file mode 100644
index 0000000..8c3a747
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
@@ -0,0 +1,55 @@
+Aspeed SGPIO controller Device Tree Bindings
+-------------------------------------------
+
+This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full
+featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to
+support the following options:
+- Support interrupt option for each input port and various interrupt
+ sensitivity option (level-high, level-low, edge-high, edge-low)
+- Support reset tolerance option for each output port
+- Directly connected to APB bus and its shift clock is from APB bus clock
+ divided by a programmable value.
+- Co-work with external signal-chained TTL components (74LV165/74LV595)
+
+
+Required properties:
+
+- compatible : Either "aspeed,ast2400-sgpio" or "aspeed,ast2500-sgpio"
+
+- #gpio-cells : Should be two
+ - First cell is the GPIO line number
+ - Second cell is used to specify optional
+ parameters (unused)
+
+- reg : Address and length of the register set for the device
+- gpio-controller : Marks the device node as a GPIO controller.
+- interrupts : Interrupt specifier (see interrupt bindings for
+ details)
+
+- interrupt-controller : Mark the GPIO controller as an interrupt-controller
+
+- nr-gpios : number of GPIO pins to serialise.
+ (should be multiple of 8, up to 80 pins; 0 if not used)
+
+- clocks : A phandle to the APB clock for SGPM clock division
+
+- bus-frequency : SGPM CLK frequency, derived from APB bus clock by a programmable devisor
+
+
+The sgpio and interrupt properties are further described in their respective bindings documentation:
+
+- Documentation/devicetree/bindings/sgpio/gpio.txt
+- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+ Example:
+ sgpio@1e780200 {
+ #gpio-cells = <2>;
+ compatible = "aspeed,ast2500-sgpio";
+ gpio-controller;
+ interrupts = <40>;
+ reg = <0x1e780200 0x0100>;
+ clocks = <&syscon ASPEED_CLK_APB>;
+ interrupt-controller;
+ nr-gpios = <8>;
+ bus-frequency = <12000000>;
+ };
--
2.7.4
Thanks Andrew, please see above v3 and inline comments at below.
--Hongwei
> From: Andrew Jeffery <andrew@aj.id.au>
> Sent: Sunday, July 14, 2019 10:25 PM
> To: Hongwei Zhang; Joel Stanley; Linus Walleij; devicetree@vger.kernel.org
> Cc: Rob Herring; Mark Rutland; Bartosz Golaszewski; linux-aspeed@lists.ozlabs.org; linux-
> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-gpio@vger.kernel.org
> Subject: Re: [PATCH 2/3 v2] dt-bindings: gpio: aspeed: Add SGPIO support
>
> Hello Hongwei,
>
> On Sat, 13 Jul 2019, at 05:44, Hongwei Zhang wrote:
> > Add bindings to support SGPIO on AST2400 or AST2500.
> >
> > Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
> > ---
> > .../devicetree/bindings/gpio/sgpio-aspeed.txt | 43 ++++++++++++++++++++++
> > 1 file changed, 43 insertions(+)
> > create mode 100755
> > Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> > b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> > new file mode 100755
> > index 0000000..3ae2b79
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> > @@ -0,0 +1,43 @@
> > +Aspeed SGPIO controller Device Tree Bindings
> > +-------------------------------------------
> > +
> > +Required properties:
> > +- compatible : Either "aspeed,ast2400-sgpio" or "aspeed,ast2500-sgpio"
> > +
> > +- #gpio-cells : Should be two
> > + - First cell is the GPIO line number
> > + - Second cell is used to specify optional
> > + parameters (unused)
> > +
> > +- reg : Address and length of the register set for the device
> > +- gpio-controller : Marks the device node as a GPIO controller.
> > +- interrupts : Interrupt specifier (see interrupt bindings for
> > + details)
> > +
> > +- interrupt-controller : Mark the GPIO controller as an
> > interrupt-controller
> > +
> > +- nr-gpios : number of GPIO pins to serialise. (should be multiple of
> > 8, up to 80 pins)
> > + if not specified, defaults to 80.
>
> This appears to be a statement about the driver implementation, but bindings documents are about
> describing hardware. Reading the datasheet it actually appears the ASPEED SGPIO hardware comes up
> in what is "technically" a forbidden state (equivalent to `nr-gpios = <0>;`), though the device is also
> disabled at this point, so it's probably moot. The point is the true default value from a hardware
> perspective is 0, not 80, so if we're going to talk about default values, 0 would be more appropriate.
> However:
>
> You've also listed nr-gpios under the "Required properties" header, but the description suggests it's
> optional. It's either one or the other, please lets be clear about it. On that front, lets make it nr-gpios
> *not* optional (i.e. make it
> required) thus force the specification of how many SGPIOs we want to emit on the bus. This value is
> coupled to the platform design, so I don't think there's ever a scenario where we want nr-gpios to take a
> default value.
>
Added some descriptions and updated nr-gpios, please see v3.
> > +
> > +- clocks : A phandle to the APB clock for SGPM clock
> > division
> > +
> > +- bus-frequency : SGPM CLK frequency, if not specified defaults to 1
> > MHz
>
> Again here with the default value - SGPM CLK period is derived from PCLK by the expression `period =
> PCLK * 2 *(GPIO254[31:16] + 1)`, where GPIO254's initialisation state is `GPIO254[31:16] = 0`, which
> gives a default SGPM bus frequency of PCLK / 2. This is likely not going to be 1MHz (more like ~12MHz).
>
> Lets just make the property required. That way we avoid any ambiguity about the bus frequency and
> thus don't need words about defaults that turn out to be about the driver, not about the hardware.
>
updated, please see v3.
> Finally, when updating patches in response to feedback, please send the full series again, and bump the
> series version number. That way people can review a coherent set of patches and not have to hunt
> around and (fail to) collate the correct combination. It makes it easier to say "Reviewed-by:" on your
> patches :)
>
> Cheers,
>
> Andrew
^ permalink raw reply related
* [PATCH] dt-bindings: pinctrl: stm32: Fix missing 'clocks' property in examples
From: Rob Herring @ 2019-07-16 21:56 UTC (permalink / raw)
To: Linus Walleij
Cc: devicetree, linux-arm-kernel, linux-kernel, Maxime Coquelin,
Alexandre Torgue, linux-gpio, linux-stm32
Now that examples are validated against the DT schema, an error with
required 'clocks' property missing is exposed:
Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.example.dt.yaml: \
pinctrl@40020000: gpio@0: 'clocks' is a required property
Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.example.dt.yaml: \
pinctrl@50020000: gpio@1000: 'clocks' is a required property
Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.example.dt.yaml: \
pinctrl@50020000: gpio@2000: 'clocks' is a required property
Add the missing 'clocks' properties to the examples to fix the errors.
Fixes: 2c9239c125f0 ("dt-bindings: pinctrl: Convert stm32 pinctrl bindings to json-schema")
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Signed-off-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
index 3ac5d2088e49..91d3e78b3395 100644
--- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
@@ -197,6 +197,7 @@ required:
examples:
- |
#include <dt-bindings/pinctrl/stm32-pinfunc.h>
+ #include <dt-bindings/mfd/stm32f4-rcc.h>
//Example 1
pinctrl@40020000 {
#address-cells = <1>;
@@ -210,6 +211,7 @@ examples:
#gpio-cells = <2>;
reg = <0x0 0x400>;
resets = <&reset_ahb1 0>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOA)>;
st,bank-name = "GPIOA";
};
};
@@ -227,6 +229,7 @@ examples:
#gpio-cells = <2>;
reg = <0x1000 0x400>;
resets = <&reset_ahb1 0>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOB)>;
st,bank-name = "GPIOB";
gpio-ranges = <&pinctrl 0 0 16>;
};
@@ -236,6 +239,7 @@ examples:
#gpio-cells = <2>;
reg = <0x2000 0x400>;
resets = <&reset_ahb1 0>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOC)>;
st,bank-name = "GPIOC";
ngpios = <5>;
gpio-ranges = <&pinctrl 0 16 3>,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks
From: Dmitry Osipenko @ 2019-07-16 22:00 UTC (permalink / raw)
To: Sowjanya Komatineni, Peter De Schrijver, Joseph Lo
Cc: thierry.reding, jonathanh, tglx, jason, marc.zyngier,
linus.walleij, stefan, mark.rutland, pgaikwad, sboyd, linux-clk,
linux-gpio, jckuo, talho, linux-tegra, linux-kernel, mperttunen,
spatra, robh+dt, devicetree
In-Reply-To: <0ee06d1a-310d-59f7-0aa6-b688b33447f5@nvidia.com>
17.07.2019 0:35, Sowjanya Komatineni пишет:
>
> On 7/16/19 2:21 PM, Dmitry Osipenko wrote:
>> 17.07.2019 0:12, Sowjanya Komatineni пишет:
>>> On 7/16/19 1:47 PM, Dmitry Osipenko wrote:
>>>> 16.07.2019 22:26, Sowjanya Komatineni пишет:
>>>>> On 7/16/19 11:43 AM, Dmitry Osipenko wrote:
>>>>>> 16.07.2019 21:30, Sowjanya Komatineni пишет:
>>>>>>> On 7/16/19 11:25 AM, Dmitry Osipenko wrote:
>>>>>>>> 16.07.2019 21:19, Sowjanya Komatineni пишет:
>>>>>>>>> On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:
>>>>>>>>>> On 7/16/19 8:00 AM, Dmitry Osipenko wrote:
>>>>>>>>>>> 16.07.2019 11:06, Peter De Schrijver пишет:
>>>>>>>>>>>> On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo wrote:
>>>>>>>>>>>>>> OK, Will add to CPUFreq driver...
>>>>>>>>>>>>>>> The other thing that also need attention is that T124
>>>>>>>>>>>>>>> CPUFreq
>>>>>>>>>>>>>>> driver
>>>>>>>>>>>>>>> implicitly relies on DFLL driver to be probed first,
>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>> icky.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Should I add check for successful dfll clk register
>>>>>>>>>>>>>> explicitly in
>>>>>>>>>>>>>> CPUFreq driver probe and defer till dfll clk registers?
>>>>>>>>>>> Probably you should use the "device links". See [1][2] for the
>>>>>>>>>>> example.
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>> https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [2]
>>>>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/device_link.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Return EPROBE_DEFER instead of EINVAL if device_link_add()
>>>>>>>>>>> fails.
>>>>>>>>>>> And
>>>>>>>>>>> use of_find_device_by_node() to get the DFLL's device, see [3].
>>>>>>>>>>>
>>>>>>>>>>> [3]
>>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Will go thru and add...
>>>>>>>> Looks like I initially confused this case with getting orphaned
>>>>>>>> clock.
>>>>>>>> I'm now seeing that the DFLL driver registers the clock and then
>>>>>>>> clk_get(dfll) should be returning EPROBE_DEFER until DFLL driver is
>>>>>>>> probed, hence everything should be fine as-is and there is no real
>>>>>>>> need
>>>>>>>> for the 'device link'. Sorry for the confusion!
>>>>>>>>
>>>>>>>>>>>>> Sorry, I didn't follow the mail thread. Just regarding the
>>>>>>>>>>>>> DFLL
>>>>>>>>>>>>> part.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As you know it, the DFLL clock is one of the CPU clock
>>>>>>>>>>>>> sources and
>>>>>>>>>>>>> integrated with DVFS control logic with the regulator. We
>>>>>>>>>>>>> will not
>>>>>>>>>>>>> switch
>>>>>>>>>>>>> CPU to other clock sources once we switched to DFLL.
>>>>>>>>>>>>> Because the
>>>>>>>>>>>>> CPU has
>>>>>>>>>>>>> been regulated by the DFLL HW with the DVFS table (CVB or OPP
>>>>>>>>>>>>> table
>>>>>>>>>>>>> you see
>>>>>>>>>>>>> in the driver.). We shouldn't reparent it to other sources
>>>>>>>>>>>>> with
>>>>>>>>>>>>> unknew
>>>>>>>>>>>>> freq/volt pair. That's not guaranteed to work. We allow
>>>>>>>>>>>>> switching to
>>>>>>>>>>>>> open-loop mode but different sources.
>>>>>>>>>>> Okay, then the CPUFreq driver will have to enforce DFLL freq to
>>>>>>>>>>> PLLP's
>>>>>>>>>>> rate before switching to PLLP in order to have a proper CPU
>>>>>>>>>>> voltage.
>>>>>>>>>> PLLP freq is safe to work for any CPU voltage. So no need to
>>>>>>>>>> enforce
>>>>>>>>>> DFLL freq to PLLP rate before changing CCLK_G source to PLLP
>>>>>>>>>> during
>>>>>>>>>> suspend
>>>>>>>>>>
>>>>>>>>> Sorry, please ignore my above comment. During suspend, need to
>>>>>>>>> change
>>>>>>>>> CCLK_G source to PLLP when dfll is in closed loop mode first and
>>>>>>>>> then
>>>>>>>>> dfll need to be set to open loop.
>>>>>>>> Okay.
>>>>>>>>
>>>>>>>>>>>>> And I don't exactly understand why we need to switch to
>>>>>>>>>>>>> PLLP in
>>>>>>>>>>>>> CPU
>>>>>>>>>>>>> idle
>>>>>>>>>>>>> driver. Just keep it on CL-DVFS mode all the time.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In SC7 entry, the dfll suspend function moves it the open-loop
>>>>>>>>>>>>> mode. That's
>>>>>>>>>>>>> all. The sc7-entryfirmware will handle the rest of the
>>>>>>>>>>>>> sequence to
>>>>>>>>>>>>> turn off
>>>>>>>>>>>>> the CPU power.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In SC7 resume, the warmboot code will handle the sequence to
>>>>>>>>>>>>> turn on
>>>>>>>>>>>>> regulator and power up the CPU cluster. And leave it on PLL_P.
>>>>>>>>>>>>> After
>>>>>>>>>>>>> resuming to the kernel, we re-init DFLL, restore the CPU clock
>>>>>>>>>>>>> policy (CPU
>>>>>>>>>>>>> runs on DFLL open-loop mode) and then moving to close-loop
>>>>>>>>>>>>> mode.
>>>>>>>>>>> The DFLL is re-inited after switching CCLK to DFLL parent
>>>>>>>>>>> during of
>>>>>>>>>>> the
>>>>>>>>>>> early clocks-state restoring by CaR driver. Hence instead of
>>>>>>>>>>> having
>>>>>>>>>>> odd
>>>>>>>>>>> hacks in the CaR driver, it is much nicer to have a proper
>>>>>>>>>>> suspend-resume sequencing of the device drivers. In this case
>>>>>>>>>>> CPUFreq
>>>>>>>>>>> driver is the driver that enables DFLL and switches CPU to that
>>>>>>>>>>> clock
>>>>>>>>>>> source, which means that this driver is also should be
>>>>>>>>>>> responsible for
>>>>>>>>>>> management of the DFLL's state during of suspend/resume
>>>>>>>>>>> process. If
>>>>>>>>>>> CPUFreq driver disables DFLL during suspend and re-enables it
>>>>>>>>>>> during
>>>>>>>>>>> resume, then looks like the CaR driver hacks around DFLL are not
>>>>>>>>>>> needed.
>>>>>>>>>>>
>>>>>>>>>>>>> The DFLL part looks good to me. BTW, change the patch
>>>>>>>>>>>>> subject to
>>>>>>>>>>>>> "Add
>>>>>>>>>>>>> suspend-resume support" seems more appropriate to me.
>>>>>>>>>>>>>
>>>>>>>>>>>> To clarify this, the sequences for DFLL use are as follows
>>>>>>>>>>>> (assuming
>>>>>>>>>>>> all
>>>>>>>>>>>> required DFLL hw configuration has been done)
>>>>>>>>>>>>
>>>>>>>>>>>> Switch to DFLL:
>>>>>>>>>>>> 0) Save current parent and frequency
>>>>>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>>>>>> 2) Enable DFLL
>>>>>>>>>>>> 3) Change cclk_g parent to DFLL
>>>>>>>>>>>> For OVR regulator:
>>>>>>>>>>>> 4) Change PWM output pin from tristate to output
>>>>>>>>>>>> 5) Enable DFLL PWM output
>>>>>>>>>>>> For I2C regulator:
>>>>>>>>>>>> 4) Enable DFLL I2C output
>>>>>>>>>>>> 6) Program DFLL to closed loop mode
>>>>>>>>>>>>
>>>>>>>>>>>> Switch away from DFLL:
>>>>>>>>>>>> 0) Change cclk_g parent to PLLP so the CPU frequency is ok for
>>>>>>>>>>>> any
>>>>>>>>>>>> vdd_cpu voltage
>>>>>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>>>>>>
>>>>>>>>> I see during switch away from DFLL (suspend), cclk_g parent is not
>>>>>>>>> changed to PLLP before changing dfll to open loop mode.
>>>>>>>>>
>>>>>>>>> Will add this ...
>>>>>>>> The CPUFreq driver switches parent to PLLP during the probe,
>>>>>>>> similar
>>>>>>>> should be done on suspend.
>>>>>>>>
>>>>>>>> I'm also wondering if it's always safe to switch to PLLP in the
>>>>>>>> probe.
>>>>>>>> If CPU is running on a lower freq than PLLP, then some other more
>>>>>>>> appropriate intermediate parent should be selected.
>>>>>>>>
>>>>>>> CPU parents are PLL_X, PLL_P, and dfll. PLL_X always runs at higher
>>>>>>> rate
>>>>>>> so switching to PLL_P during CPUFreq probe prior to dfll clock
>>>>>>> enable
>>>>>>> should be safe.
>>>>>> AFAIK, PLLX could run at ~200MHz. There is also a divided output of
>>>>>> PLLP
>>>>>> which CCLKG supports, the PLLP_OUT4.
>>>>>>
>>>>>> Probably, realistically, CPU is always running off a fast PLLX during
>>>>>> boot, but I'm wondering what may happen on KEXEC. I guess ideally
>>>>>> CPUFreq driver should also have a 'shutdown' callback to teardown
>>>>>> DFLL
>>>>>> on a reboot, but likely that there are other clock-related
>>>>>> problems as
>>>>>> well that may break KEXEC and thus it is not very important at the
>>>>>> moment.
>>>>>>
>>>>>> [snip]
>>>>> During bootup CPUG sources from PLL_X. By PLL_P source above I meant
>>>>> PLL_P_OUT4.
>>>>>
>>>>> As per clock policies, PLL_X is always used for high freq like >800Mhz
>>>>> and for low frequency it will be sourced from PLLP.
>>>> Alright, then please don't forget to pre-initialize PLLP_OUT4 rate to a
>>>> reasonable value using tegra_clk_init_table or assigned-clocks.
>>> PLLP_OUT4 rate update is not needed as it is safe to run at 408Mhz
>>> because it is below fmax @ Vmin
>> So even 204MHz CVB entries are having the same voltage as 408MHz,
>> correct? It's not instantly obvious to me from the DFLL driver's code
>> where the fmax @ Vmin is defined, I see that there is the min_millivolts
>> and frequency entries starting from 204MHZ defined per-table.
> Yes at Vmin CPU Fmax is ~800Mhz. So anything below that will work at
> Vmin voltage and PLLP max is 408Mhz.
Thank you for the clarification. It would be good to have that commented
in the code as well.
^ permalink raw reply
* Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks
From: Sowjanya Komatineni @ 2019-07-16 22:06 UTC (permalink / raw)
To: Dmitry Osipenko, Peter De Schrijver, Joseph Lo
Cc: thierry.reding, jonathanh, tglx, jason, marc.zyngier,
linus.walleij, stefan, mark.rutland, pgaikwad, sboyd, linux-clk,
linux-gpio, jckuo, talho, linux-tegra, linux-kernel, mperttunen,
spatra, robh+dt, devicetree
In-Reply-To: <cedfafd0-4114-0821-0c4b-efc17c213449@gmail.com>
On 7/16/19 3:00 PM, Dmitry Osipenko wrote:
> 17.07.2019 0:35, Sowjanya Komatineni пишет:
>> On 7/16/19 2:21 PM, Dmitry Osipenko wrote:
>>> 17.07.2019 0:12, Sowjanya Komatineni пишет:
>>>> On 7/16/19 1:47 PM, Dmitry Osipenko wrote:
>>>>> 16.07.2019 22:26, Sowjanya Komatineni пишет:
>>>>>> On 7/16/19 11:43 AM, Dmitry Osipenko wrote:
>>>>>>> 16.07.2019 21:30, Sowjanya Komatineni пишет:
>>>>>>>> On 7/16/19 11:25 AM, Dmitry Osipenko wrote:
>>>>>>>>> 16.07.2019 21:19, Sowjanya Komatineni пишет:
>>>>>>>>>> On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:
>>>>>>>>>>> On 7/16/19 8:00 AM, Dmitry Osipenko wrote:
>>>>>>>>>>>> 16.07.2019 11:06, Peter De Schrijver пишет:
>>>>>>>>>>>>> On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo wrote:
>>>>>>>>>>>>>>> OK, Will add to CPUFreq driver...
>>>>>>>>>>>>>>>> The other thing that also need attention is that T124
>>>>>>>>>>>>>>>> CPUFreq
>>>>>>>>>>>>>>>> driver
>>>>>>>>>>>>>>>> implicitly relies on DFLL driver to be probed first,
>>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>>> icky.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Should I add check for successful dfll clk register
>>>>>>>>>>>>>>> explicitly in
>>>>>>>>>>>>>>> CPUFreq driver probe and defer till dfll clk registers?
>>>>>>>>>>>> Probably you should use the "device links". See [1][2] for the
>>>>>>>>>>>> example.
>>>>>>>>>>>>
>>>>>>>>>>>> [1]
>>>>>>>>>>>> https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> [2]
>>>>>>>>>>>> https://www.kernel.org/doc/html/latest/driver-api/device_link.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Return EPROBE_DEFER instead of EINVAL if device_link_add()
>>>>>>>>>>>> fails.
>>>>>>>>>>>> And
>>>>>>>>>>>> use of_find_device_by_node() to get the DFLL's device, see [3].
>>>>>>>>>>>>
>>>>>>>>>>>> [3]
>>>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Will go thru and add...
>>>>>>>>> Looks like I initially confused this case with getting orphaned
>>>>>>>>> clock.
>>>>>>>>> I'm now seeing that the DFLL driver registers the clock and then
>>>>>>>>> clk_get(dfll) should be returning EPROBE_DEFER until DFLL driver is
>>>>>>>>> probed, hence everything should be fine as-is and there is no real
>>>>>>>>> need
>>>>>>>>> for the 'device link'. Sorry for the confusion!
>>>>>>>>>
>>>>>>>>>>>>>> Sorry, I didn't follow the mail thread. Just regarding the
>>>>>>>>>>>>>> DFLL
>>>>>>>>>>>>>> part.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As you know it, the DFLL clock is one of the CPU clock
>>>>>>>>>>>>>> sources and
>>>>>>>>>>>>>> integrated with DVFS control logic with the regulator. We
>>>>>>>>>>>>>> will not
>>>>>>>>>>>>>> switch
>>>>>>>>>>>>>> CPU to other clock sources once we switched to DFLL.
>>>>>>>>>>>>>> Because the
>>>>>>>>>>>>>> CPU has
>>>>>>>>>>>>>> been regulated by the DFLL HW with the DVFS table (CVB or OPP
>>>>>>>>>>>>>> table
>>>>>>>>>>>>>> you see
>>>>>>>>>>>>>> in the driver.). We shouldn't reparent it to other sources
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> unknew
>>>>>>>>>>>>>> freq/volt pair. That's not guaranteed to work. We allow
>>>>>>>>>>>>>> switching to
>>>>>>>>>>>>>> open-loop mode but different sources.
>>>>>>>>>>>> Okay, then the CPUFreq driver will have to enforce DFLL freq to
>>>>>>>>>>>> PLLP's
>>>>>>>>>>>> rate before switching to PLLP in order to have a proper CPU
>>>>>>>>>>>> voltage.
>>>>>>>>>>> PLLP freq is safe to work for any CPU voltage. So no need to
>>>>>>>>>>> enforce
>>>>>>>>>>> DFLL freq to PLLP rate before changing CCLK_G source to PLLP
>>>>>>>>>>> during
>>>>>>>>>>> suspend
>>>>>>>>>>>
>>>>>>>>>> Sorry, please ignore my above comment. During suspend, need to
>>>>>>>>>> change
>>>>>>>>>> CCLK_G source to PLLP when dfll is in closed loop mode first and
>>>>>>>>>> then
>>>>>>>>>> dfll need to be set to open loop.
>>>>>>>>> Okay.
>>>>>>>>>
>>>>>>>>>>>>>> And I don't exactly understand why we need to switch to
>>>>>>>>>>>>>> PLLP in
>>>>>>>>>>>>>> CPU
>>>>>>>>>>>>>> idle
>>>>>>>>>>>>>> driver. Just keep it on CL-DVFS mode all the time.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In SC7 entry, the dfll suspend function moves it the open-loop
>>>>>>>>>>>>>> mode. That's
>>>>>>>>>>>>>> all. The sc7-entryfirmware will handle the rest of the
>>>>>>>>>>>>>> sequence to
>>>>>>>>>>>>>> turn off
>>>>>>>>>>>>>> the CPU power.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In SC7 resume, the warmboot code will handle the sequence to
>>>>>>>>>>>>>> turn on
>>>>>>>>>>>>>> regulator and power up the CPU cluster. And leave it on PLL_P.
>>>>>>>>>>>>>> After
>>>>>>>>>>>>>> resuming to the kernel, we re-init DFLL, restore the CPU clock
>>>>>>>>>>>>>> policy (CPU
>>>>>>>>>>>>>> runs on DFLL open-loop mode) and then moving to close-loop
>>>>>>>>>>>>>> mode.
>>>>>>>>>>>> The DFLL is re-inited after switching CCLK to DFLL parent
>>>>>>>>>>>> during of
>>>>>>>>>>>> the
>>>>>>>>>>>> early clocks-state restoring by CaR driver. Hence instead of
>>>>>>>>>>>> having
>>>>>>>>>>>> odd
>>>>>>>>>>>> hacks in the CaR driver, it is much nicer to have a proper
>>>>>>>>>>>> suspend-resume sequencing of the device drivers. In this case
>>>>>>>>>>>> CPUFreq
>>>>>>>>>>>> driver is the driver that enables DFLL and switches CPU to that
>>>>>>>>>>>> clock
>>>>>>>>>>>> source, which means that this driver is also should be
>>>>>>>>>>>> responsible for
>>>>>>>>>>>> management of the DFLL's state during of suspend/resume
>>>>>>>>>>>> process. If
>>>>>>>>>>>> CPUFreq driver disables DFLL during suspend and re-enables it
>>>>>>>>>>>> during
>>>>>>>>>>>> resume, then looks like the CaR driver hacks around DFLL are not
>>>>>>>>>>>> needed.
>>>>>>>>>>>>
>>>>>>>>>>>>>> The DFLL part looks good to me. BTW, change the patch
>>>>>>>>>>>>>> subject to
>>>>>>>>>>>>>> "Add
>>>>>>>>>>>>>> suspend-resume support" seems more appropriate to me.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> To clarify this, the sequences for DFLL use are as follows
>>>>>>>>>>>>> (assuming
>>>>>>>>>>>>> all
>>>>>>>>>>>>> required DFLL hw configuration has been done)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Switch to DFLL:
>>>>>>>>>>>>> 0) Save current parent and frequency
>>>>>>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>>>>>>> 2) Enable DFLL
>>>>>>>>>>>>> 3) Change cclk_g parent to DFLL
>>>>>>>>>>>>> For OVR regulator:
>>>>>>>>>>>>> 4) Change PWM output pin from tristate to output
>>>>>>>>>>>>> 5) Enable DFLL PWM output
>>>>>>>>>>>>> For I2C regulator:
>>>>>>>>>>>>> 4) Enable DFLL I2C output
>>>>>>>>>>>>> 6) Program DFLL to closed loop mode
>>>>>>>>>>>>>
>>>>>>>>>>>>> Switch away from DFLL:
>>>>>>>>>>>>> 0) Change cclk_g parent to PLLP so the CPU frequency is ok for
>>>>>>>>>>>>> any
>>>>>>>>>>>>> vdd_cpu voltage
>>>>>>>>>>>>> 1) Program DFLL to open loop mode
>>>>>>>>>>>>>
>>>>>>>>>> I see during switch away from DFLL (suspend), cclk_g parent is not
>>>>>>>>>> changed to PLLP before changing dfll to open loop mode.
>>>>>>>>>>
>>>>>>>>>> Will add this ...
>>>>>>>>> The CPUFreq driver switches parent to PLLP during the probe,
>>>>>>>>> similar
>>>>>>>>> should be done on suspend.
>>>>>>>>>
>>>>>>>>> I'm also wondering if it's always safe to switch to PLLP in the
>>>>>>>>> probe.
>>>>>>>>> If CPU is running on a lower freq than PLLP, then some other more
>>>>>>>>> appropriate intermediate parent should be selected.
>>>>>>>>>
>>>>>>>> CPU parents are PLL_X, PLL_P, and dfll. PLL_X always runs at higher
>>>>>>>> rate
>>>>>>>> so switching to PLL_P during CPUFreq probe prior to dfll clock
>>>>>>>> enable
>>>>>>>> should be safe.
>>>>>>> AFAIK, PLLX could run at ~200MHz. There is also a divided output of
>>>>>>> PLLP
>>>>>>> which CCLKG supports, the PLLP_OUT4.
>>>>>>>
>>>>>>> Probably, realistically, CPU is always running off a fast PLLX during
>>>>>>> boot, but I'm wondering what may happen on KEXEC. I guess ideally
>>>>>>> CPUFreq driver should also have a 'shutdown' callback to teardown
>>>>>>> DFLL
>>>>>>> on a reboot, but likely that there are other clock-related
>>>>>>> problems as
>>>>>>> well that may break KEXEC and thus it is not very important at the
>>>>>>> moment.
>>>>>>>
>>>>>>> [snip]
>>>>>> During bootup CPUG sources from PLL_X. By PLL_P source above I meant
>>>>>> PLL_P_OUT4.
>>>>>>
>>>>>> As per clock policies, PLL_X is always used for high freq like >800Mhz
>>>>>> and for low frequency it will be sourced from PLLP.
>>>>> Alright, then please don't forget to pre-initialize PLLP_OUT4 rate to a
>>>>> reasonable value using tegra_clk_init_table or assigned-clocks.
>>>> PLLP_OUT4 rate update is not needed as it is safe to run at 408Mhz
>>>> because it is below fmax @ Vmin
>>> So even 204MHz CVB entries are having the same voltage as 408MHz,
>>> correct? It's not instantly obvious to me from the DFLL driver's code
>>> where the fmax @ Vmin is defined, I see that there is the min_millivolts
>>> and frequency entries starting from 204MHZ defined per-table.
>> Yes at Vmin CPU Fmax is ~800Mhz. So anything below that will work at
>> Vmin voltage and PLLP max is 408Mhz.
> Thank you for the clarification. It would be good to have that commented
> in the code as well.
OK, Will add...
^ permalink raw reply
* Re: [v5,2/2] Documentation: dt: binding: rtc: add binding for ftm alarm driver
From: Rob Herring @ 2019-07-16 22:32 UTC (permalink / raw)
To: Biwen Li
Cc: Alessandro Zummo, Alexandre Belloni, Yang-Leo Li,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM,
linux-kernel@vger.kernel.org, Xiaobo Xie, Jiafei Pan, Ran Wang,
Mark Rutland, devicetree
In-Reply-To: <20190716101655.47418-2-biwen.li@nxp.com>
On Tue, Jul 16, 2019 at 4:26 AM Biwen Li <biwen.li@nxp.com> wrote:
>
> The patch adds binding for ftm alarm driver
Bindings are for h/w, not drivers...
'dt-bindings: rtc: ...' for the subject prefix.
>
> Signed-off-by: Biwen Li <biwen.li@nxp.com>
> ---
> Change in v5:
> - None
>
> Change in v4:
> - add note about dts and kernel options
> - add aliases in example
>
> Change in v3:
> - remove reg-names property
> - correct cells number
>
> Change in v2:
> - replace ls1043a with ls1088a as example
> - add rcpm node and fsl,rcpm-wakeup property
>
>
> .../bindings/rtc/rtc-fsl-ftm-alarm.txt | 49 +++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> new file mode 100644
> index 000000000000..fb018065406c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
> @@ -0,0 +1,49 @@
> +Freescale FlexTimer Module (FTM) Alarm
> +
> +Note:
> +- The driver depends on RCPM driver
> + to wake up system in sleep.
> +- Need stop using RTC_HCTOSYS or use the DT aliases
> + to ensure the driver is not used as the primary RTC.
> + (Select DT aliases defaultly)
This is Linux specific and not relevant to the binding.
> +
> +Required properties:
> +- compatible : Should be "fsl,<chip>-ftm-alarm", the
> + supported chips include
> + "fsl,ls1012a-ftm-alarm"
> + "fsl,ls1021a-ftm-alarm"
> + "fsl,ls1028a-ftm-alarm"
> + "fsl,ls1043a-ftm-alarm"
> + "fsl,ls1046a-ftm-alarm"
> + "fsl,ls1088a-ftm-alarm"
> + "fsl,ls208xa-ftm-alarm"
> +- reg : Specifies base physical address and size of the register sets for the
> + FlexTimer Module and base physical address of IP Powerdown Exception Control
> + Register.
> +- interrupts : Should be the FlexTimer Module interrupt.
> +- fsl,rcpm-wakeup property and rcpm node : Please refer
> + Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> +
> +Optional properties:
> +- big-endian: If the host controller is big-endian mode, specify this property.
> + The default endian mode is little-endian.
> +
> +Example:
> +aliases {
> + ...
> + rtc1 = ftm_alarm0; /* Use flextimer alarm driver as /dev/rtc1 */
> + ...
> +};
Drop the aliases part. It's not going to work when this is converted
to DT schema and the comment is Linux specific.
> +
> +rcpm: rcpm@1e34040 {
> + compatible = "fsl,ls1088a-rcpm", "fsl,qoriq-rcpm-2.1+";
> + reg = <0x0 0x1e34040 0x0 0x18>;
> + fsl,#rcpm-wakeup-cells = <6>;
Before there are any users of this, either drop it if it is not
variable or the correct form would be '#fsl,rcpm-wakeup-cells'.
> +};
> +
> +ftm_alarm0: timer@2800000 {
> + compatible = "fsl,ls1088a-ftm-alarm";
> + reg = <0x0 0x2800000 0x0 0x10000>;
> + fsl,rcpm-wakeup = <&rcpm 0x0 0x0 0x0 0x0 0x4000 0x0>;
> + interrupts = <0 44 4>;
> +};
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] of/fdt: Make sure no-map does not remove already reserved regions
From: Stephen Boyd @ 2019-07-16 22:35 UTC (permalink / raw)
To: Nicolas Boichat, Rob Herring
Cc: Frank Rowand, devicetree, linux-kernel, Ian Campbell,
Grant Likely
In-Reply-To: <20190703050827.173284-1-drinkcat@chromium.org>
Quoting Nicolas Boichat (2019-07-02 22:08:27)
> If the device tree is incorrectly configured, and attempts to
> define a "no-map" reserved memory that overlaps with the kernel
> data/code, the kernel would crash quickly after boot, with no
> obvious clue about the nature of the issue.
>
> For example, this would happen if we have the kernel mapped at
> these addresses (from /proc/iomem):
> 40000000-41ffffff : System RAM
> 40080000-40dfffff : Kernel code
> 40e00000-411fffff : reserved
> 41200000-413e0fff : Kernel data
>
> And we declare a no-map shared-dma-pool region at a fixed address
> within that range:
> mem_reserved: mem_region {
> compatible = "shared-dma-pool";
> reg = <0 0x40000000 0 0x01A00000>;
> no-map;
> };
>
> To fix this, when removing memory regions at early boot (which is
> what "no-map" regions do), we need to make sure that the memory
> is not already reserved. If we do, __reserved_mem_reserve_reg
> will throw an error:
> [ 0.000000] OF: fdt: Reserved memory: failed to reserve memory
> for node 'mem_region': base 0x0000000040000000, size 26 MiB
> and the code that will try to use the region should also fail,
> later on.
>
> We do not do anything for non-"no-map" regions, as memblock
> explicitly allows reserved regions to overlap, and the commit
> that this fixes removed the check for that precise reason.
>
> Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap")
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> ---
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
^ permalink raw reply
* Re: [PATCH v3 2/4] of/platform: Add functional dependency link from DT bindings
From: Rob Herring @ 2019-07-16 22:41 UTC (permalink / raw)
To: Frank Rowand
Cc: Saravana Kannan, Mark Rutland, Greg Kroah-Hartman,
Rafael J. Wysocki, devicetree, linux-kernel@vger.kernel.org,
David Collins, Android Kernel Team
In-Reply-To: <9e75b3dd-380b-c868-728f-46379e53bc11@gmail.com>
On Mon, Jul 15, 2019 at 8:26 AM Frank Rowand <frowand.list@gmail.com> wrote:
>
> HiRob,
>
> Sorry for such a late reply...
>
>
> On 7/1/19 8:25 PM, Saravana Kannan wrote:
> > On Mon, Jul 1, 2019 at 6:32 PM Rob Herring <robh+dt@kernel.org> wrote:
> >>
> >> On Mon, Jul 1, 2019 at 6:48 PM Saravana Kannan <saravanak@google.com> wrote:
> >>>
> >>> Add device-links after the devices are created (but before they are
> >>> probed) by looking at common DT bindings like clocks and
> >>> interconnects.
> >>>
> >>> Automatically adding device-links for functional dependencies at the
> >>> framework level provides the following benefits:
> >>>
> >>> - Optimizes device probe order and avoids the useless work of
> >>> attempting probes of devices that will not probe successfully
> >>> (because their suppliers aren't present or haven't probed yet).
> >>>
> >>> For example, in a commonly available mobile SoC, registering just
> >>> one consumer device's driver at an initcall level earlier than the
> >>> supplier device's driver causes 11 failed probe attempts before the
> >>> consumer device probes successfully. This was with a kernel with all
> >>> the drivers statically compiled in. This problem gets a lot worse if
> >>> all the drivers are loaded as modules without direct symbol
> >>> dependencies.
> >>>
> >>> - Supplier devices like clock providers, interconnect providers, etc
> >>> need to keep the resources they provide active and at a particular
> >>> state(s) during boot up even if their current set of consumers don't
> >>> request the resource to be active. This is because the rest of the
> >>> consumers might not have probed yet and turning off the resource
> >>> before all the consumers have probed could lead to a hang or
> >>> undesired user experience.
> >>>
> >>> Some frameworks (Eg: regulator) handle this today by turning off
> >>> "unused" resources at late_initcall_sync and hoping all the devices
> >>> have probed by then. This is not a valid assumption for systems with
> >>> loadable modules. Other frameworks (Eg: clock) just don't handle
> >>> this due to the lack of a clear signal for when they can turn off
> >>> resources. This leads to downstream hacks to handle cases like this
> >>> that can easily be solved in the upstream kernel.
> >>>
> >>> By linking devices before they are probed, we give suppliers a clear
> >>> count of the number of dependent consumers. Once all of the
> >>> consumers are active, the suppliers can turn off the unused
> >>> resources without making assumptions about the number of consumers.
> >>>
> >>> By default we just add device-links to track "driver presence" (probe
> >>> succeeded) of the supplier device. If any other functionality provided
> >>> by device-links are needed, it is left to the consumer/supplier
> >>> devices to change the link when they probe.
> >>>
> >>> Signed-off-by: Saravana Kannan <saravanak@google.com>
> >>> ---
> >>> drivers/of/Kconfig | 9 ++++++++
> >>> drivers/of/platform.c | 52 +++++++++++++++++++++++++++++++++++++++++++
> >>> 2 files changed, 61 insertions(+)
> >>>
> >>> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> >>> index 37c2ccbefecd..7c7fa7394b4c 100644
> >>> --- a/drivers/of/Kconfig
> >>> +++ b/drivers/of/Kconfig
> >>> @@ -103,4 +103,13 @@ config OF_OVERLAY
> >>> config OF_NUMA
> >>> bool
> >>>
> >>> +config OF_DEVLINKS
> >>
> >> I'd prefer this not be a config option. After all, we want one kernel
> >> build that works for all platforms.
> >
> > We need a lot more changes before one kernel build can work for all
> > platforms. At least until then, I think we need this. Lot less chance
> > of breaking existing platforms before all the missing pieces are
> > created.
> >
> >> A kernel command line option to disable might be useful for debugging.
> >
> > Or we can have a command line to enable this for platforms that want
> > to use it and have it default off.
>
> Given the fragility of the current boot sequence (without this patch set)
> and the potential breakage of existing systems, I think that if we choose
> to accept this patch set that it should first bake in the -next tree for
> at least one major release cycle. Maybe even two major release cycles.
>
> -Frank
>
>
> >
> >>> + bool "Device links from DT bindings"
> >>> + help
> >>> + Common DT bindings like clocks, interconnects, etc represent a
> >>> + consumer device's dependency on suppliers devices. This option
> >>> + creates device links from these common bindings so that consumers are
> >>> + probed only after all their suppliers are active and suppliers can
> >>> + tell when all their consumers are active.
> >>> +
> >>> endif # OF
> >>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> >>> index 04ad312fd85b..a53717168aca 100644
> >>> --- a/drivers/of/platform.c
> >>> +++ b/drivers/of/platform.c
> >>> @@ -61,6 +61,57 @@ struct platform_device *of_find_device_by_node(struct device_node *np)
> >>> EXPORT_SYMBOL(of_find_device_by_node);
> >>>
> >>> #ifdef CONFIG_OF_ADDRESS
> >>> +static int of_link_binding(struct device *dev, char *binding, char *cell)
> >>
> >> Under CONFIG_OF_ADDRESS seems like a strange location.
> >
> > Yeah, but the rest of the file seems to be under this. So I'm not
> > touching that. I can probably move this function further down (close
> > to platform populate) if you want that.
> >>
> >>> +{
> >>> + struct of_phandle_args sup_args;
> >>> + struct platform_device *sup_dev;
> >>> + unsigned int i = 0, links = 0;
> >>> + u32 dl_flags = DL_FLAG_AUTOPROBE_CONSUMER;
> >>> +
> >>> + while (!of_parse_phandle_with_args(dev->of_node, binding, cell, i,
> >>> + &sup_args)) {
> >>> + i++;
> >>> + sup_dev = of_find_device_by_node(sup_args.np);
> >>> + if (!sup_dev)
> >>> + continue;
> >>> + if (device_link_add(dev, &sup_dev->dev, dl_flags))
> >>> + links++;
> >>> + put_device(&sup_dev->dev);
> >>> + }
> >>> + if (links < i)
> >>> + return -ENODEV;
> >>> + return 0;
> >>> +}
> >>> +
> >>> +/*
> >>> + * List of bindings and their cell names (use NULL if no cell names) from which
> >>> + * device links need to be created.
> >>> + */
> >>> +static char *link_bindings[] = {
> >>
> >> const
> >
> > Ack
> >
> >>
> >>> +#ifdef CONFIG_OF_DEVLINKS
> >>> + "clocks", "#clock-cells",
> >>> + "interconnects", "#interconnect-cells",
> >>
> >> Planning to add others?
> >
> > Not in this patch.
> >
> > Regulators are the other big missing piece that I'm aware of now but
> > they need a lot of discussion (see email from David and my reply).
> >
> > Not sure what other resources are shared where they can be "turned
> > off" and cause devices set up at boot to fail. For example, I don't
> > think interrupts need functional dependency tracking because they
> > aren't really turned off by consumer 1 in a way that breaks things for
> > consumer 2. Just masked and the consumer 2 can unmask and use it once
> > it probes.
> >
> > I'm only intimately familiar with clocks, interconnects and regulators
> > (to some extent). I'm open to adding other supplier categories in
> > future patches as I educate myself of those or if other people want to
> > add support for more categories.
> >
> > -Saravana
> >
> >>> +#endif
> >>> +};
> >>> +
> >>> +static int of_link_to_suppliers(struct device *dev)
> >>> +{
> >>> + unsigned int i = 0;
> >>> + bool done = true;
> >>> +
> >>> + if (unlikely(!dev->of_node))
> >>> + return 0;
> >>> +
> >>> + for (i = 0; i < ARRAY_SIZE(link_bindings) / 2; i++)
> >>> + if (of_link_binding(dev, link_bindings[i * 2],
> >>> + link_bindings[i * 2 + 1]))
> >>> + done = false;
> >>> +
> >>> + if (!done)
> >>> + return -ENODEV;
> >>> + return 0;
> >>> +}
> >>> +
> >>> /*
> >>> * The following routines scan a subtree and registers a device for
> >>> * each applicable node.
> >>> @@ -524,6 +575,7 @@ static int __init of_platform_default_populate_init(void)
> >>> if (!of_have_populated_dt())
> >>> return -ENODEV;
> >>>
> >>> + platform_bus_type.add_links = of_link_to_suppliers;
> >>> /*
> >>> * Handle certain compatibles explicitly, since we don't want to create
> >>> * platform_devices for every node in /reserved-memory with a
> >>> --
> >>> 2.22.0.410.gd8fdbe21b5-goog
> >>>
> >
>
^ permalink raw reply
* Re: [PATCH] of/fdt: Make sure no-map does not remove already reserved regions
From: Florian Fainelli @ 2019-07-16 22:46 UTC (permalink / raw)
To: Nicolas Boichat, Rob Herring
Cc: Frank Rowand, devicetree, linux-kernel, Ian Campbell,
Grant Likely, Stephen Boyd
In-Reply-To: <20190703050827.173284-1-drinkcat@chromium.org>
On 7/2/19 10:08 PM, Nicolas Boichat wrote:
> If the device tree is incorrectly configured, and attempts to
> define a "no-map" reserved memory that overlaps with the kernel
> data/code, the kernel would crash quickly after boot, with no
> obvious clue about the nature of the issue.
>
> For example, this would happen if we have the kernel mapped at
> these addresses (from /proc/iomem):
> 40000000-41ffffff : System RAM
> 40080000-40dfffff : Kernel code
> 40e00000-411fffff : reserved
> 41200000-413e0fff : Kernel data
>
> And we declare a no-map shared-dma-pool region at a fixed address
> within that range:
> mem_reserved: mem_region {
> compatible = "shared-dma-pool";
> reg = <0 0x40000000 0 0x01A00000>;
> no-map;
> };
>
> To fix this, when removing memory regions at early boot (which is
> what "no-map" regions do), we need to make sure that the memory
> is not already reserved. If we do, __reserved_mem_reserve_reg
> will throw an error:
> [ 0.000000] OF: fdt: Reserved memory: failed to reserve memory
> for node 'mem_region': base 0x0000000040000000, size 26 MiB
> and the code that will try to use the region should also fail,
> later on.
>
> We do not do anything for non-"no-map" regions, as memblock
> explicitly allows reserved regions to overlap, and the commit
> that this fixes removed the check for that precise reason.
>
> Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap")
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> ---
> drivers/of/fdt.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index cd17dc62a71980a..a1ded43fc332d0c 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -1138,8 +1138,16 @@ int __init __weak early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
> int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
> phys_addr_t size, bool nomap)
> {
> - if (nomap)
> + if (nomap) {
> + /*
> + * If the memory is already reserved (by another region), we
> + * should not allow it to be removed altogether.
> + */
> + if (memblock_is_region_reserved(base, size))
> + return -EBUSY;
> +
> return memblock_remove(base, size);
While you are it, the nomap argument (introduced with
e8d9d1f5485b52ec3c4d7af839e6914438f6c285) predates the introduction of
memblock_is_nomap() (bf3d3cc580f9960883ebf9ea05868f336d9491c2), so
should just remove memblock_remove() and use memblock_mark_nomap()
instead here.
--
Florian
^ permalink raw reply
* Re: [PATCH v3 2/4] of/platform: Add functional dependency link from DT bindings
From: Rob Herring @ 2019-07-16 22:56 UTC (permalink / raw)
To: Frank Rowand
Cc: Saravana Kannan, Mark Rutland, Greg Kroah-Hartman,
Rafael J. Wysocki,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, David Collins, Android Kernel Team
In-Reply-To: <3e340ff1-e842-2521-4344-da62802d472f@gmail.com>
On Mon, Jul 15, 2019 at 7:05 PM Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 7/15/19 11:40 AM, Saravana Kannan wrote:
> > Replying again because the previous email accidentally included HTML.
> >
> > Thanks for taking the time to reconsider the wording Frank. Your
> > intention was clear to me in the first email too.
> >
> > A kernel command line option can also completely disable this
> > functionality easily and cleanly. Can we pick that as an option? I've
> > an implementation of that in the v5 series I sent out last week.
>
> Yes, Rob suggested a command line option for debugging, and I am fine with
> that. But even with that, I would like a lot of testing so that we have a
> chance of finding systems that have trouble with the changes and could
> potentially be fixed before impacting a large number of users.
Leaving it in -next for more than a cycle will not help. There's some
number of users who test linux-next. Then there's more that test -rc
kernels. Then there's more that test final releases and/or stable
kernels. Probably, the more stable the h/w, the more it tends to be
latter groups. (I don't get reports of breaking PowerMacs with the
changes sitting in linux-next.)
My main worry about this being off by default is it won't get tested.
I'm not sure there's enough interest to drive folks to turn it on and
test. Maybe it needs to be on until we see breakage.
Rob
^ permalink raw reply
* Re: [PATCH] of/fdt: Make sure no-map does not remove already reserved regions
From: Rob Herring @ 2019-07-16 23:12 UTC (permalink / raw)
To: Florian Fainelli, KarimAllah Ahmed, Nicolas Boichat
Cc: Frank Rowand, devicetree, linux-kernel@vger.kernel.org,
Ian Campbell, Grant Likely, Stephen Boyd
In-Reply-To: <815a8414-bfbe-c693-3208-1580779815ec@gmail.com>
On Tue, Jul 16, 2019 at 4:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 7/2/19 10:08 PM, Nicolas Boichat wrote:
> > If the device tree is incorrectly configured, and attempts to
> > define a "no-map" reserved memory that overlaps with the kernel
> > data/code, the kernel would crash quickly after boot, with no
> > obvious clue about the nature of the issue.
> >
> > For example, this would happen if we have the kernel mapped at
> > these addresses (from /proc/iomem):
> > 40000000-41ffffff : System RAM
> > 40080000-40dfffff : Kernel code
> > 40e00000-411fffff : reserved
> > 41200000-413e0fff : Kernel data
> >
> > And we declare a no-map shared-dma-pool region at a fixed address
> > within that range:
> > mem_reserved: mem_region {
> > compatible = "shared-dma-pool";
> > reg = <0 0x40000000 0 0x01A00000>;
> > no-map;
> > };
> >
> > To fix this, when removing memory regions at early boot (which is
> > what "no-map" regions do), we need to make sure that the memory
> > is not already reserved. If we do, __reserved_mem_reserve_reg
> > will throw an error:
> > [ 0.000000] OF: fdt: Reserved memory: failed to reserve memory
> > for node 'mem_region': base 0x0000000040000000, size 26 MiB
> > and the code that will try to use the region should also fail,
> > later on.
> >
> > We do not do anything for non-"no-map" regions, as memblock
> > explicitly allows reserved regions to overlap, and the commit
> > that this fixes removed the check for that precise reason.
> >
> > Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap")
> > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > ---
> > drivers/of/fdt.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index cd17dc62a71980a..a1ded43fc332d0c 100644
> > --- a/drivers/of/fdt.c
> > +++ b/drivers/of/fdt.c
> > @@ -1138,8 +1138,16 @@ int __init __weak early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
> > int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
> > phys_addr_t size, bool nomap)
> > {
> > - if (nomap)
> > + if (nomap) {
> > + /*
> > + * If the memory is already reserved (by another region), we
> > + * should not allow it to be removed altogether.
> > + */
> > + if (memblock_is_region_reserved(base, size))
> > + return -EBUSY;
> > +
> > return memblock_remove(base, size);
>
> While you are it, the nomap argument (introduced with
> e8d9d1f5485b52ec3c4d7af839e6914438f6c285) predates the introduction of
> memblock_is_nomap() (bf3d3cc580f9960883ebf9ea05868f336d9491c2), so
> should just remove memblock_remove() and use memblock_mark_nomap()
> instead here.
Perhaps like this patch[1]? Though the reasoning is different and the
commit message here is more thorough, so can I get a combined patch.
However, I don't under how handling a misconfigured DT and aligned
with EFI are the same patch. What's considered valid for EFI is not
for DT regions?
Rob
[1] https://patchwork.ozlabs.org/patch/1131232/
^ permalink raw reply
* Re: [PATCH v4, 23/33] drm/mediatek: add ovl0/ovl_2l0 usecase
From: Ryan Case @ 2019-07-16 23:13 UTC (permalink / raw)
To: yongqiang.niu
Cc: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger, David Airlie,
Daniel Vetter, Mark Rutland, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <1562625253-29254-24-git-send-email-yongqiang.niu@mediatek.com>
On Mon, Jul 8, 2019 at 3:35 PM <yongqiang.niu@mediatek.com> wrote:
>
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add ovl0/ovl_2l0 usecase
> in ovl->ovl_2l0 direct link usecase:
> 1. the crtc support layer number will 4+2
> 2. ovl_2l0 background color input select ovl0 when crtc init
> and disable it when crtc finish
> 3. config ovl_2l0 layer, if crtc config layer number is
> bigger than ovl0 support layers(max is 4)
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 38 +++++++++++++++++++++++++++++++--
> 1 file changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 5eac376..9ee9ce2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -282,6 +282,15 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
>
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
> + enum mtk_ddp_comp_id prev;
> +
> + if (i > 0)
> + prev = mtk_crtc->ddp_comp[i - 1]->id;
> + else
> + prev = DDP_COMPONENT_ID_MAX;
> +
> + if (prev == DDP_COMPONENT_OVL0)
> + mtk_ddp_comp_bgclr_in_on(comp);
>
> mtk_ddp_comp_config(comp, width, height, vrefresh, bpc);
> mtk_ddp_comp_start(comp);
> @@ -291,9 +300,18 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
> for (i = 0; i < mtk_crtc->layer_nr; i++) {
> struct drm_plane *plane = &mtk_crtc->planes[i];
> struct mtk_plane_state *plane_state;
> + struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> + unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
> + unsigned int local_layer;
>
> plane_state = to_mtk_plane_state(plane->state);
> - mtk_ddp_comp_layer_config(mtk_crtc->ddp_comp[0], i,
> +
> + if (i >= comp_layer_nr) {
> + comp = mtk_crtc->ddp_comp[1];
> + local_layer = i - comp_layer_nr;
> + } else
> + local_layer = i;
> + mtk_ddp_comp_layer_config(comp , local_layer,
> plane_state);
There is an extra space after comp.
This whole loop is essentially identical to the one found in
mtk_crtc_ddp_config below. It would be nice to either move that loop
to a dedicated function called from both spots or allow
mtk_crtc_ddp_config to be called from here.
> }
>
> @@ -319,6 +337,7 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
> mtk_crtc->ddp_comp[i]->id);
> mtk_disp_mutex_disable(mtk_crtc->mutex);
> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> + mtk_ddp_comp_bgclr_in_off(mtk_crtc->ddp_comp[i]);
> mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
> mtk_crtc->mmsys_reg_data,
> mtk_crtc->ddp_comp[i]->id,
> @@ -339,6 +358,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> unsigned int i;
> + unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
> + unsigned int local_layer;
>
> /*
> * TODO: instead of updating the registers here, we should prepare
> @@ -361,7 +382,14 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> plane_state = to_mtk_plane_state(plane->state);
>
> if (plane_state->pending.config) {
> - mtk_ddp_comp_layer_config(comp, i, plane_state);
> + if (i >= comp_layer_nr) {
> + comp = mtk_crtc->ddp_comp[1];
> + local_layer = i - comp_layer_nr;
> + } else
> + local_layer = i;
> +
> + mtk_ddp_comp_layer_config(comp, local_layer,
> + plane_state);
> plane_state->pending.config = false;
> }
> }
> @@ -592,6 +620,12 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> }
>
> mtk_crtc->layer_nr = mtk_ddp_comp_layer_nr(mtk_crtc->ddp_comp[0]);
> + if (mtk_crtc->ddp_comp_nr > 1) {
> + struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[1];
> +
> + if (comp->funcs->bgclr_in_on)
> + mtk_crtc->layer_nr += mtk_ddp_comp_layer_nr(comp);
> + }
> mtk_crtc->planes = devm_kcalloc(dev, mtk_crtc->layer_nr,
> sizeof(struct drm_plane),
> GFP_KERNEL);
> --
> 1.8.1.1.dirty
>
^ permalink raw reply
* Re: [PATCH] of/fdt: Make sure no-map does not remove already reserved regions
From: Florian Fainelli @ 2019-07-16 23:17 UTC (permalink / raw)
To: Rob Herring, KarimAllah Ahmed, Nicolas Boichat
Cc: Frank Rowand, devicetree, linux-kernel@vger.kernel.org,
Ian Campbell, Grant Likely, Stephen Boyd
In-Reply-To: <CAL_JsqLETdazfnz5EU0Qw4TVVBhWmzk12Z5zYMo5Hm2ACPXh1w@mail.gmail.com>
On 7/16/19 4:12 PM, Rob Herring wrote:
> On Tue, Jul 16, 2019 at 4:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> On 7/2/19 10:08 PM, Nicolas Boichat wrote:
>>> If the device tree is incorrectly configured, and attempts to
>>> define a "no-map" reserved memory that overlaps with the kernel
>>> data/code, the kernel would crash quickly after boot, with no
>>> obvious clue about the nature of the issue.
>>>
>>> For example, this would happen if we have the kernel mapped at
>>> these addresses (from /proc/iomem):
>>> 40000000-41ffffff : System RAM
>>> 40080000-40dfffff : Kernel code
>>> 40e00000-411fffff : reserved
>>> 41200000-413e0fff : Kernel data
>>>
>>> And we declare a no-map shared-dma-pool region at a fixed address
>>> within that range:
>>> mem_reserved: mem_region {
>>> compatible = "shared-dma-pool";
>>> reg = <0 0x40000000 0 0x01A00000>;
>>> no-map;
>>> };
>>>
>>> To fix this, when removing memory regions at early boot (which is
>>> what "no-map" regions do), we need to make sure that the memory
>>> is not already reserved. If we do, __reserved_mem_reserve_reg
>>> will throw an error:
>>> [ 0.000000] OF: fdt: Reserved memory: failed to reserve memory
>>> for node 'mem_region': base 0x0000000040000000, size 26 MiB
>>> and the code that will try to use the region should also fail,
>>> later on.
>>>
>>> We do not do anything for non-"no-map" regions, as memblock
>>> explicitly allows reserved regions to overlap, and the commit
>>> that this fixes removed the check for that precise reason.
>>>
>>> Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap")
>>> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>>> ---
>>> drivers/of/fdt.c | 10 +++++++++-
>>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>>> index cd17dc62a71980a..a1ded43fc332d0c 100644
>>> --- a/drivers/of/fdt.c
>>> +++ b/drivers/of/fdt.c
>>> @@ -1138,8 +1138,16 @@ int __init __weak early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
>>> int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
>>> phys_addr_t size, bool nomap)
>>> {
>>> - if (nomap)
>>> + if (nomap) {
>>> + /*
>>> + * If the memory is already reserved (by another region), we
>>> + * should not allow it to be removed altogether.
>>> + */
>>> + if (memblock_is_region_reserved(base, size))
>>> + return -EBUSY;
>>> +
>>> return memblock_remove(base, size);
>>
>> While you are it, the nomap argument (introduced with
>> e8d9d1f5485b52ec3c4d7af839e6914438f6c285) predates the introduction of
>> memblock_is_nomap() (bf3d3cc580f9960883ebf9ea05868f336d9491c2), so
>> should just remove memblock_remove() and use memblock_mark_nomap()
>> instead here.
>
> Perhaps like this patch[1]? Though the reasoning is different and the
> commit message here is more thorough, so can I get a combined patch.
>From a quick reading it does look like memblock_isolate_range(), as
called by memblock_setclr_flag() should be able to detect this region
was already reserved, though I have not tried it.
> However, I don't under how handling a misconfigured DT and aligned
> with EFI are the same patch. What's considered valid for EFI is not
> for DT regions?
That I don't know how to answer.
--
Florian
^ permalink raw reply
* Re: [PATCH 4/6] irqchip/irq-pruss-intc: Add helper functions to configure internal mapping
From: Suman Anna @ 2019-07-16 23:29 UTC (permalink / raw)
To: David Lechner, Marc Zyngier, Rob Herring, Thomas Gleixner,
Jason Cooper
Cc: devicetree, Grygorii Strashko, Tony Lindgren, Sekhar Nori,
linux-kernel, Andrew F. Davis, Lokesh Vutla, Murali Karicheri,
linux-omap, linux-arm-kernel, Roger Quadros
In-Reply-To: <9aa5acd8-81bf-10dc-5a86-cea2acd1132b@lechnology.com>
Hi David,
On 7/10/19 10:10 PM, David Lechner wrote:
> On 7/7/19 10:52 PM, Suman Anna wrote:
>> The PRUSS INTC receives a number of system input interrupt source events
>> and supports individual control configuration and hardware
>> prioritization.
>> These input events can be mapped to some output host interrupts through 2
>> levels of many-to-one mapping i.e. events to channel mapping and channels
>> to host interrupts.
>>
>> This mapping information is provided through the PRU firmware that is
>> loaded onto a PRU core/s or through the device tree node of the PRU
>
Thanks for the thorough review and alternate solutions/suggestions.
> What will the device tree bindings for this look like?
They would be as in the below patch you already figured.
>
> Looking back at Rob's comment on the initial series [1], I still think
> that increasing the #interrupt-cells sounds like a reasonable solution.
>
> [1]: https://patchwork.kernel.org/patch/10697705/#22375155
So, there are couple of reasons why I did not use an extended
#interrupt-cells:
1. There is only one irq descriptor associated with each event, and the
usage of events is typically per application. And the descriptor mapping
is done once. We can have two different applications use the same event
with different mappings. So we want this programming done at
application's usage of PRU (so done when a consumer driver acquires a
PRU processor(s) which are treated as an exclusive resource). All the
different application properties that you saw in [1] are configured at
the time of acquiring a PRU and reset when they release a PRU.
2. The configuration is performed by Linux for all host interrupts and
channels, and this was primarily done to save the very limited IRAM
space for those needed by the PRUs. From firmware's point of view, this
was offloaded to the ARM OS driver/infrastructure, but in general it is
a design by contract between a PRU client driver and its firmware. Also,
the DT binding semantics using interrupts property and request_irq()
typically limits these to interrupts only being requested by MPU, and so
will leave out those needed by PRUs.
>
>
>
>> application. The mapping is configured by the PRU remoteproc driver, and
>> is setup before the PRU core is started and cleaned up after the PRU core
>> is stopped. This event mapping configuration logic is optimized to
>> program
>> the Channel Map Registers (CMRx) and Host-Interrupt Map Registers (HMRx)
>> only when a new program is being loaded/started and simply disables the
>> same events and interrupt channels without zeroing out the corresponding
>> map registers when stopping a PRU.
>>
>> Add two helper functions: pruss_intc_configure() &
>> pruss_intc_unconfigure()
>> that the PRU remoteproc driver can use to configure the PRUSS INTC.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> drivers/irqchip/irq-pruss-intc.c | 258 ++++++++++++++++++++++++-
>> include/linux/irqchip/irq-pruss-intc.h | 33 ++++
>> 2 files changed, 289 insertions(+), 2 deletions(-)
>> create mode 100644 include/linux/irqchip/irq-pruss-intc.h
>>
>> diff --git a/drivers/irqchip/irq-pruss-intc.c
>> b/drivers/irqchip/irq-pruss-intc.c
>> index 142d01b434e0..8118c2a2ac43 100644
>> --- a/drivers/irqchip/irq-pruss-intc.c
>> +++ b/drivers/irqchip/irq-pruss-intc.c
>> @@ -9,6 +9,7 @@
>> #include <linux/irq.h>
>> #include <linux/irqchip/chained_irq.h>
>> +#include <linux/irqchip/irq-pruss-intc.h>
>> #include <linux/irqdomain.h>
>> #include <linux/module.h>
>> #include <linux/of_device.h>
>> @@ -24,8 +25,8 @@
>> /* minimum starting host interrupt number for MPU */
>> #define MIN_PRU_HOST_INT 2
>> -/* maximum number of system events */
>> -#define MAX_PRU_SYS_EVENTS 64
>> +/* maximum number of host interrupts */
>> +#define MAX_PRU_HOST_INT 10
>> /* PRU_ICSS_INTC registers */
>> #define PRU_INTC_REVID 0x0000
>> @@ -57,15 +58,29 @@
>> #define PRU_INTC_HINLR(x) (0x1100 + (x) * 4)
>> #define PRU_INTC_HIER 0x1500
>> +/* CMR register bit-field macros */
>> +#define CMR_EVT_MAP_MASK 0xf
>> +#define CMR_EVT_MAP_BITS 8
>> +#define CMR_EVT_PER_REG 4
>> +
>> +/* HMR register bit-field macros */
>> +#define HMR_CH_MAP_MASK 0xf
>> +#define HMR_CH_MAP_BITS 8
>> +#define HMR_CH_PER_REG 4
>> +
>> /* HIPIR register bit-fields */
>> #define INTC_HIPIR_NONE_HINT 0x80000000
>> +/* use -1 to mark unassigned events and channels */
>> +#define FREE -1
>
> It could be helpful to have this macro in the public header.
Yes, I can rename it and move it, and I can reuse it in the parsing
logic within the PRU remoteproc driver as well.
>
>> +
>> /**
>> * struct pruss_intc - PRUSS interrupt controller structure
>> * @irqs: kernel irq numbers corresponding to PRUSS host interrupts
>> * @base: base virtual address of INTC register space
>> * @irqchip: irq chip for this interrupt controller
>> * @domain: irq domain for this interrupt controller
>> + * @config_map: stored INTC configuration mapping data
>> * @lock: mutex to serialize access to INTC
>> * @host_mask: indicate which HOST IRQs are enabled
>> * @shared_intr: bit-map denoting if the MPU host interrupt is shared
>> @@ -76,6 +91,7 @@ struct pruss_intc {
>> void __iomem *base;
>> struct irq_chip *irqchip;
>> struct irq_domain *domain;
>> + struct pruss_intc_config config_map;
>> struct mutex lock; /* PRUSS INTC lock */
>> u32 host_mask;
>> u16 shared_intr;
>> @@ -107,6 +123,238 @@ static int pruss_intc_check_write(struct
>> pruss_intc *intc, unsigned int reg,
>> return 0;
>> }
>> +static struct pruss_intc *to_pruss_intc(struct device *pru_dev)
>> +{
>> + struct device_node *np;
>> + struct platform_device *pdev;
>> + struct device *pruss_dev = pru_dev->parent;
>> + struct pruss_intc *intc = ERR_PTR(-ENODEV);
>> +
>> + np = of_get_child_by_name(pruss_dev->of_node,
>> "interrupt-controller");
>> + if (!np) {
>> + dev_err(pruss_dev, "pruss does not have an
>> interrupt-controller node\n");
>> + return intc;
>> + }
>> +
>> + pdev = of_find_device_by_node(np);
>> + if (!pdev) {
>> + dev_err(pruss_dev, "no associated platform device\n");
>> + goto out;
>> + }
>> +
>> + intc = platform_get_drvdata(pdev);
>> + if (!intc) {
>> + dev_err(pruss_dev, "pruss intc device probe failed?\n");
>> + intc = ERR_PTR(-EINVAL);
>> + }
>> +
>> +out:
>> + of_node_put(np);
>> + return intc;
>> +}
>> +
>> +/**
>> + * pruss_intc_configure() - configure the PRUSS INTC
>> + * @dev: pru device pointer
>> + * @intc_config: PRU core-specific INTC configuration
>> + *
>> + * Configures the PRUSS INTC with the provided configuration from
>> + * a PRU core. Any existing event to channel mappings or channel to
>> + * host interrupt mappings are checked to make sure there are no
>> + * conflicting configuration between both the PRU cores. The function
>> + * is intended to be used only by the PRU remoteproc driver.
>> + *
>> + * Returns 0 on success, or a suitable error code otherwise
>> + */
>> +int pruss_intc_configure(struct device *dev,
>
> It seems like this would be easier to use if it took an IRQ number
> or struct irq_data * as a parameter instead of struct device *. My
> line of thinking is that callers of this function will already be
> calling some variant of request_irq() so they will already have
> this info. It would cut out the pointer acrobatics in to_pruss_intc.
These API are actually not seen by PRU client drivers, but is only
limited to the PRU remoteproc driver. The INTC configuration is managed
per PRU core and in sync with the life-cycle of the PRU load/start and stop.
As I mentioned above, we need to manage the configuration for events
generating interrupts to non Linux ARM host as well.
>
>
>> + struct pruss_intc_config *intc_config)
>> +{
>> + struct pruss_intc *intc;
>> + int i, idx, ret;
>> + s8 ch, host;
>> + u64 sysevt_mask = 0;
>> + u32 ch_mask = 0;
>> + u32 host_mask = 0;
>> + u32 val;
>> +
>> + intc = to_pruss_intc(dev);
>> + if (IS_ERR(intc))
>> + return PTR_ERR(intc);
>> +
>> + mutex_lock(&intc->lock);
>> +
>> + /*
>> + * configure channel map registers - each register holds map info
>> + * for 4 events, with each event occupying the lower nibble in
>> + * a register byte address in little-endian fashion
>> + */
>> + for (i = 0; i < ARRAY_SIZE(intc_config->sysev_to_ch); i++) {
>> + ch = intc_config->sysev_to_ch[i];
>> + if (ch < 0)
>> + continue;
>> +
>> + /* check if sysevent already assigned */
>> + if (intc->config_map.sysev_to_ch[i] != FREE) {
>> + dev_err(dev, "event %d (req. channel %d) already assigned
>> to channel %d\n",
>> + i, ch, intc->config_map.sysev_to_ch[i]);
>> + ret = -EEXIST;
>> + goto unlock;
>
> If we fail here, shouldn't we unwind any previous mappings made?
> Otherwise, if we try to map the same event again, it will show as
> in use, even though it is not in use.
Yeah, I will fix up the unwind logic. I intended for the callers to
invoke the unconfigure upon failures, but even that has some unneeded
operations, so it is better to unwind the operations here for a cleaner
style.
>
>> + }
>> +
>> + intc->config_map.sysev_to_ch[i] = ch;
>> +
>> + idx = i / CMR_EVT_PER_REG;
>> + val = pruss_intc_read_reg(intc, PRU_INTC_CMR(idx));
>> + val &= ~(CMR_EVT_MAP_MASK <<
>> + ((i % CMR_EVT_PER_REG) * CMR_EVT_MAP_BITS));
>> + val |= ch << ((i % CMR_EVT_PER_REG) * CMR_EVT_MAP_BITS);
>> + pruss_intc_write_reg(intc, PRU_INTC_CMR(idx), val);
>> + sysevt_mask |= BIT_ULL(i);
>> + ch_mask |= BIT(ch);
>> +
>> + dev_dbg(dev, "SYSEV%d -> CH%d (CMR%d 0x%08x)\n", i, ch, idx,
>> + pruss_intc_read_reg(intc, PRU_INTC_CMR(idx)));
>> + }
>> +
>> + /*
>> + * set host map registers - each register holds map info for
>> + * 4 channels, with each channel occupying the lower nibble in
>> + * a register byte address in little-endian fashion
>> + */
>> + for (i = 0; i < ARRAY_SIZE(intc_config->ch_to_host); i++) {
>> + host = intc_config->ch_to_host[i];
>> + if (host < 0)
>> + continue;
>> +
>> + /* check if channel already assigned */
>> + if (intc->config_map.ch_to_host[i] != FREE) {
>> + dev_err(dev, "channel %d (req. intr_no %d) already
>> assigned to intr_no %d\n",
>> + i, host, intc->config_map.ch_to_host[i]);
>> + ret = -EEXIST;
>> + goto unlock;
>
> Same comment about unwinding here and below.
Yep, will fix this up as well in the next version.
>
>> + }
>> +
>> + /* check if host intr is already in use by other PRU */
>
> It seems like there would be use cases where someone might want to map
> multiple PRU system events, and therefore multiple channels, to a single
> host interrupt.
Yes, that is in general supported but for a given PRU. The idea here was
to partition the host events separately between two PRUs and this is
done to simplify the life-cycle per host event and their mappings
between two different PRUs potentially running two different unrelated
co-operative applications.
>
>> + if (intc->host_mask & (1U << host)) {
>> + dev_err(dev, "%s: host intr %d already in use\n",
>> + __func__, host);
>> + ret = -EEXIST;
>> + goto unlock;
>> + }
>> +
>
> --snip--
>
>> diff --git a/include/linux/irqchip/irq-pruss-intc.h
>> b/include/linux/irqchip/irq-pruss-intc.h
>> new file mode 100644
>> index 000000000000..f1f1bb150100
>> --- /dev/null
>> +++ b/include/linux/irqchip/irq-pruss-intc.h
>> @@ -0,0 +1,33 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * PRU-ICSS sub-system private interfaces
>> + *
>> + * Copyright (C) 2019 Texas Instruments Incorporated -
>> http://www.ti.com/
>> + * Suman Anna <s-anna@ti.com>
>> + */
>> +
>> +#ifndef __LINUX_IRQ_PRUSS_INTC_H
>> +#define __LINUX_IRQ_PRUSS_INTC_H
>> +
>> +/* maximum number of system events */
>> +#define MAX_PRU_SYS_EVENTS 64
>> +
>> +/* maximum number of interrupt channels */
>> +#define MAX_PRU_CHANNELS 10
>> +
>> +/**
>> + * struct pruss_intc_config - INTC configuration info
>> + * @sysev_to_ch: system events to channel mapping information
>> + * @ch_to_host: interrupt channel to host interrupt information
>> + */
>> +struct pruss_intc_config {
>> + s8 sysev_to_ch[MAX_PRU_SYS_EVENTS];
>> + s8 ch_to_host[MAX_PRU_CHANNELS];
>> +};
>> +
>> +int pruss_intc_configure(struct device *dev,
>> + struct pruss_intc_config *intc_config);
>> +int pruss_intc_unconfigure(struct device *dev,
>> + struct pruss_intc_config *intc_config);
>> +
>> +#endif /* __LINUX_IRQ_PRUSS_INTC_H */
>>
>
> FYI, on AM18xx, events 0 to 31 can be muxed via CFGCHIP3[3].PRUSSEVTSEL
> so an additional bit of information will be needed in this struct for
> the mux selection. I don't see a probably with adding that later though.
Yeah, there are different input pinmux'ing options controlling different
number of input events on different SoCs. On AM18xx it is a SoC-level
CHIPCFG register, and on other SoCs, it is a PRUSS CFG register
(Standard mode vs MII mode) both of which are registers outside of the
INTC module. I see these again as an application-level configuration,
and this is what the last bullet item in the feature list in my
cover-letter is about.
I did think about adding a separate property to INTC node to configure a
default value at INTC probe time, and then allow it to be overwritten as
per a PRU application need. The latter is going to be needed anyway, so
I dropped the idea of a default configuration, and leave it at POR values.
regards
Suman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 02/11] of/platform: Add functional dependency link from DT bindings
From: Rob Herring @ 2019-07-16 23:43 UTC (permalink / raw)
To: Saravana Kannan
Cc: Mark Rutland, Greg Kroah-Hartman, Rafael J. Wysocki, Frank Rowand,
Jonathan Corbet, devicetree, linux-kernel@vger.kernel.org,
David Collins, Android Kernel Team, Linux Doc Mailing List
In-Reply-To: <20190712235245.202558-3-saravanak@google.com>
On Fri, Jul 12, 2019 at 5:52 PM Saravana Kannan <saravanak@google.com> wrote:
>
> Add device-links after the devices are created (but before they are
> probed) by looking at common DT bindings like clocks and
> interconnects.
>
> Automatically adding device-links for functional dependencies at the
> framework level provides the following benefits:
>
> - Optimizes device probe order and avoids the useless work of
> attempting probes of devices that will not probe successfully
> (because their suppliers aren't present or haven't probed yet).
>
> For example, in a commonly available mobile SoC, registering just
> one consumer device's driver at an initcall level earlier than the
> supplier device's driver causes 11 failed probe attempts before the
> consumer device probes successfully. This was with a kernel with all
> the drivers statically compiled in. This problem gets a lot worse if
> all the drivers are loaded as modules without direct symbol
> dependencies.
>
> - Supplier devices like clock providers, interconnect providers, etc
> need to keep the resources they provide active and at a particular
> state(s) during boot up even if their current set of consumers don't
> request the resource to be active. This is because the rest of the
> consumers might not have probed yet and turning off the resource
> before all the consumers have probed could lead to a hang or
> undesired user experience.
>
> Some frameworks (Eg: regulator) handle this today by turning off
> "unused" resources at late_initcall_sync and hoping all the devices
> have probed by then. This is not a valid assumption for systems with
> loadable modules. Other frameworks (Eg: clock) just don't handle
> this due to the lack of a clear signal for when they can turn off
> resources. This leads to downstream hacks to handle cases like this
> that can easily be solved in the upstream kernel.
>
> By linking devices before they are probed, we give suppliers a clear
> count of the number of dependent consumers. Once all of the
> consumers are active, the suppliers can turn off the unused
> resources without making assumptions about the number of consumers.
>
> By default we just add device-links to track "driver presence" (probe
> succeeded) of the supplier device. If any other functionality provided
> by device-links are needed, it is left to the consumer/supplier
> devices to change the link when they probe.
>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---
> .../admin-guide/kernel-parameters.txt | 5 ++
> drivers/of/platform.c | 57 +++++++++++++++++++
> 2 files changed, 62 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 138f6664b2e2..109b4310844f 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -3141,6 +3141,11 @@
> This can be set from sysctl after boot.
> See Documentation/sysctl/vm.txt for details.
>
> + of_devlink [KNL] Make device links from common DT bindings. Useful
> + for optimizing probe order and making sure resources
> + aren't turned off before the consumer devices have
> + probed.
> +
> ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
> See Documentation/debugging-via-ohci1394.txt for more
> info.
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 04ad312fd85b..0930f9f89571 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -509,6 +509,62 @@ int of_platform_default_populate(struct device_node *root,
> }
> EXPORT_SYMBOL_GPL(of_platform_default_populate);
>
> +static int of_link_binding(struct device *dev,
> + const char *binding, const char *cell)
> +{
> + struct of_phandle_args sup_args;
> + struct platform_device *sup_dev;
> + unsigned int i = 0, links = 0;
> + u32 dl_flags = DL_FLAG_AUTOPROBE_CONSUMER;
> +
> + while (!of_parse_phandle_with_args(dev->of_node, binding, cell, i,
> + &sup_args)) {
> + i++;
> + sup_dev = of_find_device_by_node(sup_args.np);
> + of_node_put(sup_args.np);
> + if (!sup_dev)
> + continue;
> + if (device_link_add(dev, &sup_dev->dev, dl_flags))
> + links++;
> + put_device(&sup_dev->dev);
> + }
> + if (links < i)
> + return -ENODEV;
> + return 0;
> +}
> +
> +static bool of_devlink;
> +core_param(of_devlink, of_devlink, bool, 0);
> +
> +/*
> + * List of bindings and their cell names (use NULL if no cell names) from which
> + * device links need to be created.
> + */
> +static const char * const link_bindings[] = {
> + "clocks", "#clock-cells",
> + "interconnects", "#interconnect-cells",
> +};
> +
> +static int of_link_to_suppliers(struct device *dev)
> +{
> + unsigned int i = 0;
> + bool done = true;
> +
> + if (!of_devlink)
> + return 0;
> + if (unlikely(!dev->of_node))
> + return 0;
> +
> + for (i = 0; i < ARRAY_SIZE(link_bindings) / 2; i++)
> + if (of_link_binding(dev, link_bindings[i * 2],
> + link_bindings[i * 2 + 1]))
> + done = false;
Given the pending addition of regulators I think this should be
structured a bit differently so that we abstract out the matching and
phandle look-up so there's a clean separation of binding specifics.
It's kind of messy with 2 patterns to parse already and if we added a
3rd? I would iterate over the properties as you do for regulators in
both cases and for each property call a binding specific match
function. The common pattern can of course be a common function. Let
me know if that makes sense. If not I can try to flesh it out some
more.
Rob
^ 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