* Re: [PATCH v1 37/50] ARM: dts: exynos: change parent and rate of bus_fsys in Exynos5422
From: Krzysztof Kozlowski @ 2019-07-17 10:25 UTC (permalink / raw)
To: Lukasz Luba
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <20190715124417.4787-38-l.luba@partner.samsung.com>
On Mon, 15 Jul 2019 at 14:45, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>
> The FSYS bus OPP table has been aligned to the new parent rate. This patch
> sets the proper parent and picks the init frequency before the devfreq
> governor starts working. It sets also parent rate (DPLL to 1200MHz).
1. I see what the patch is doing, but please write why you are doing
this. What problem are you solving here?
2. Commit title is wrong - it is not Exynos 5422 but Odroid XU3/XU4
family of boards.
>
> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> ---
> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
> index d460041f716c..6a82dd175b8a 100644
> --- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
> @@ -72,6 +72,11 @@
>
> &bus_fsys {
> devfreq = <&bus_wcore>;
> + assigned-clocks = <&clock CLK_MOUT_ACLK200_FSYS>,
> + <&clock CLK_DOUT_ACLK200_FSYS>,
> + <&clock CLK_FOUT_DPLL>;
> + assigned-clock-parents = <&clock CLK_MOUT_SCLK_DPLL>;
> + assigned-clock-rates = <0>, <240000000>,<1200000000>;
Here and in all other patches:
I am not entirely sure that this should be here. It looks like
property of the SoC. Do we expect that buses will be configured to
different clock rates between different boards? Since the OPP tables
are shared (they are property of the SoC, not board) then I would
assume that default frequency is shared as well.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 1/3] dt-bindings: Add Vendor prefix for Einfochips
From: Aisheng Dong @ 2019-07-17 10:26 UTC (permalink / raw)
To: Manivannan Sadhasivam, shawnguo@kernel.org,
s.hauer@pengutronix.de, robh+dt@kernel.org
Cc: kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Darshak Patel, Kinjan Patel,
Prajose John
In-Reply-To: <20190717061039.9271-2-manivannan.sadhasivam@linaro.org>
> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Sent: Wednesday, July 17, 2019 2:11 PM
>
> Add devicetree vendor prefix for Einfochips.
>
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
^ permalink raw reply
* Re: [PATCH v1 26/50] ARM: dts: exynos: align NOC100 bus OPPs in Exynos5420
From: Lukasz Luba @ 2019-07-17 10:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <CAJKOXPc3qsM5Xe5JViDZXYfes+_veb-KX3fnZjpkUCrphBcu-Q@mail.gmail.com>
On 7/17/19 12:10 PM, Krzysztof Kozlowski wrote:
> On Mon, 15 Jul 2019 at 14:44, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>>
>> The NOC100 has a parent which clock rate is set tot 400MHz. The OPPs which
>> are not possible to set are removed and new one is added.
>
> I think it is just NOC bus... or are there more of such and this is 100 MHz one?
Yes, there is a bus NOC100 with a dedicated clock tree in the HW (with
3 muxes and one divider), which makes possible to take different PLL as
a source then WCORE have, divide the rate from it and even switch for a
while to alternative stable PLL (on the 2nd mux to SPLL (after a
divider)) to wait for main PLL rate change stability delay. Max rate is
limited to 100MHz for this NOC100 bus.
Regards,
Lukasz
>
> Best regards,
> Krzysztof
>
>
^ permalink raw reply
* RE: [PATCH 2/3] dt-bindings: arm: Document i.MX8QXP AI_ML board binding
From: Aisheng Dong @ 2019-07-17 10:28 UTC (permalink / raw)
To: Manivannan Sadhasivam, shawnguo@kernel.org,
s.hauer@pengutronix.de, robh+dt@kernel.org
Cc: kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Darshak Patel, Kinjan Patel,
Prajose John
In-Reply-To: <20190717061039.9271-3-manivannan.sadhasivam@linaro.org>
> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Sent: Wednesday, July 17, 2019 2:11 PM
>
> Document devicetree binding of i.MX8QXP AI_ML board from Einfochips.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
^ permalink raw reply
* Re: [PATCH v1 27/50] ARM: dts: exynos: align bus_wcore OPPs in Exynos5420
From: Lukasz Luba @ 2019-07-17 10:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <CAJKOXPfFZL8q9hM1vPsLq+Qxe-gMz4c8j0jgFKfdf5qs68MTmA@mail.gmail.com>
On 7/17/19 12:15 PM, Krzysztof Kozlowski wrote:
> On Mon, 15 Jul 2019 at 14:44, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>>
>> This is the most important bus in the Exynos5x SoC. The whole communication
>> inside SoC does through that bus (apart from direct requests from CCI to
>> DRAM controller). It is also modeled as a master bus in devfreq framework.
>> It is also the only one OPP table throughout other buses which has voltage
>> values. The devfreq software controls the speed of that bus and other
>> buses. The other buses follows the rate of the master. There is only one
>> regulator. The old lowest OPP had pair 925mV, 84MHz which is enough for
>
> s/lowest/slowest/
OK
>
>> this frequency. However, due to the fact that the other buses follows the
>> WCORE bus by taking the OPP from their table with the same id, e.g. opp02,
>> the children frequency should be stable with the set voltage.
>> It could cause random faults very hard to debug.
>> Thus, the patch removes the lowest OPP to make other buses' lowest OPPs
>
> s/lowest/slowest/
OK
>
>> working. The new lowest OPP has voltage high enough for buses working up
>> to 333MHz. It also changes the frequencies of the OPPs to align them to
>> PLL value such that it is possible to set them using only a divider without
>> reprogramming OPP.
>
> Reprogramming OPP? What is it?
Mistake, should be PLL. Thanks for that.
>
>> Reprogramming the PLL was not set, so the real frequency
>
> I understood from the previous that reprogramming the OPP (PLL?) was
> happening... Please rephrase entire sentence.
Yes, I will rewrite it when I will combine these patches into one.
Regards,
Lukasz
>
> BR,
> Krzysztof
>
>> values were not the one from the OPP table, which could confuse the
>> governor algorithms which relay on OPP speed values making the system to
>> behave weird.
>>
>> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
>> ---
>> arch/arm/boot/dts/exynos5420.dtsi | 12 ++++--------
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>> index f8c36ff0d4c3..a355c76af5a5 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -1107,22 +1107,18 @@
>> compatible = "operating-points-v2";
>>
>> opp00 {
>> - opp-hz = /bits/ 64 <84000000>;
>> - opp-microvolt = <925000>;
>> + opp-hz = /bits/ 64 <150000000>;
>> + opp-microvolt = <950000>;
>> };
>> opp01 {
>> - opp-hz = /bits/ 64 <111000000>;
>> + opp-hz = /bits/ 64 <200000000>;
>> opp-microvolt = <950000>;
>> };
>> opp02 {
>> - opp-hz = /bits/ 64 <222000000>;
>> + opp-hz = /bits/ 64 <300000000>;
>> opp-microvolt = <950000>;
>> };
>> opp03 {
>> - opp-hz = /bits/ 64 <333000000>;
>> - opp-microvolt = <950000>;
>> - };
>> - opp04 {
>> opp-hz = /bits/ 64 <400000000>;
>> opp-microvolt = <987500>;
>> };
>> --
>> 2.17.1
>>
>
>
^ permalink raw reply
* Re: [PATCH v1 31/50] ARM: dts: exynos: align lowest OPP in bus_jpeg in Exynos5420
From: Krzysztof Kozlowski @ 2019-07-17 10:30 UTC (permalink / raw)
To: Lukasz Luba
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <20190715124417.4787-32-l.luba@partner.samsung.com>
On Mon, 15 Jul 2019 at 14:45, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>
> Make the lowest OPP frequency possible to set using a clock divider keeping
> in mind the master clock rate.
As in previous patch - lowest->slowest. I think OPPs are not
associated with the height or altitude but speed (slow/fast). You
could also add "frequency" which would make it also correct and
specific but slightly longer in title.
Best regards,
Krzysztof
>
> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index f2e2e77a86d6..0be799f843dc 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -1250,7 +1250,7 @@
> compatible = "operating-points-v2";
>
> opp00 {
> - opp-hz = /bits/ 64 <75000000>;
> + opp-hz = /bits/ 64 <100000000>;
> };
> opp01 {
> opp-hz = /bits/ 64 <150000000>;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v3 0/6] Introduce Bandwidth OPPs for interconnect paths
From: Viresh Kumar @ 2019-07-17 10:32 UTC (permalink / raw)
To: Saravana Kannan
Cc: Georgi Djakov, Rob Herring, Mark Rutland, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael J. Wysocki, vincent.guittot,
seansw, daidavid1, Rajendra Nayak, sibis, bjorn.andersson,
evgreen, kernel-team, linux-pm, devicetree, linux-kernel
In-Reply-To: <20190703011020.151615-1-saravanak@google.com>
On 02-07-19, 18:10, Saravana Kannan wrote:
> Interconnects and interconnect paths quantify their performance levels in
> terms of bandwidth and not in terms of frequency. So similar to how we have
> frequency based OPP tables in DT and in the OPP framework, we need
> bandwidth OPP table support in the OPP framework and in DT. Since there can
> be more than one interconnect path used by a device, we also need a way to
> assign a bandwidth OPP table to an interconnect path.
>
> This patch series:
> - Adds opp-peak-KBps and opp-avg-KBps properties to OPP DT bindings
> - Adds interconnect-opp-table property to interconnect DT bindings
> - Adds OPP helper functions for bandwidth OPP tables
> - Adds icc_get_opp_table() to get the OPP table for an interconnect path
>
> So with the DT bindings added in this patch series, the DT for a GPU
> that does bandwidth voting from GPU to Cache and GPU to DDR would look
> something like this:
>
> gpu_cache_opp_table: gpu_cache_opp_table {
> compatible = "operating-points-v2";
>
> gpu_cache_3000: opp-3000 {
> opp-peak-KBps = <3000>;
> opp-avg-KBps = <1000>;
> };
> gpu_cache_6000: opp-6000 {
> opp-peak-KBps = <6000>;
> opp-avg-KBps = <2000>;
> };
> gpu_cache_9000: opp-9000 {
> opp-peak-KBps = <9000>;
> opp-avg-KBps = <9000>;
> };
> };
>
> gpu_ddr_opp_table: gpu_ddr_opp_table {
> compatible = "operating-points-v2";
>
> gpu_ddr_1525: opp-1525 {
> opp-peak-KBps = <1525>;
> opp-avg-KBps = <452>;
> };
> gpu_ddr_3051: opp-3051 {
> opp-peak-KBps = <3051>;
> opp-avg-KBps = <915>;
> };
> gpu_ddr_7500: opp-7500 {
> opp-peak-KBps = <7500>;
> opp-avg-KBps = <3000>;
> };
> };
Who is going to use the above tables and how ? These are the maximum
BW available over these paths, right ?
> gpu_opp_table: gpu_opp_table {
> compatible = "operating-points-v2";
> opp-shared;
>
> opp-200000000 {
> opp-hz = /bits/ 64 <200000000>;
> };
> opp-400000000 {
> opp-hz = /bits/ 64 <400000000>;
> };
> };
Shouldn't this link back to the above tables via required-opp, etc ?
How will we know how much BW is required by the GPU device for all the
paths ?
> gpu@7864000 {
> ...
> operating-points-v2 = <&gpu_opp_table>, <&gpu_cache_opp_table>, <&gpu_ddr_opp_table>;
> interconnects = <&mmnoc MASTER_GPU_1 &bimc SLAVE_SYSTEM_CACHE>,
> <&mmnoc MASTER_GPU_1 &bimc SLAVE_DDR>;
> interconnect-names = "gpu-cache", "gpu-mem";
> interconnect-opp-table = <&gpu_cache_opp_table>, <&gpu_ddr_opp_table>
> };
--
viresh
^ permalink raw reply
* Re: [PATCH v1 30/50] ARM: dts: exynos: add bus_isp266 into Exynos5800
From: Krzysztof Kozlowski @ 2019-07-17 10:33 UTC (permalink / raw)
To: Lukasz Luba
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <20190715124417.4787-31-l.luba@partner.samsung.com>
On Mon, 15 Jul 2019 at 14:45, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>
> The Exynos5420 SoC had one clock for two lines while Exynos5422/5800 have
> dedicated clock tree for the ACLK266_ISP. The max frequency is 300MHz so
> it shares the OPP table with bus_gen. The bus is added here and is enabled
> in .dts file for proper board.
Squash it with 48 please.
BR,
Krzysztof
>
> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> ---
> arch/arm/boot/dts/exynos5800.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5800.dtsi b/arch/arm/boot/dts/exynos5800.dtsi
> index 57d3b319fd65..3b9200db43b6 100644
> --- a/arch/arm/boot/dts/exynos5800.dtsi
> +++ b/arch/arm/boot/dts/exynos5800.dtsi
> @@ -131,3 +131,13 @@
> &mfc {
> compatible = "samsung,mfc-v8";
> };
> +
> +&soc {
> + bus_isp266: bus_isp266 {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DOUT_ACLK266_ISP>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_gen_opp_table>;
> + status = "disabled";
> + };
> +};
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v1 33/50] ARM: dts: exynos: set parent clocks to UARTs in Exynos5420
From: Krzysztof Kozlowski @ 2019-07-17 10:35 UTC (permalink / raw)
To: Lukasz Luba
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <20190715124417.4787-34-l.luba@partner.samsung.com>
On Mon, 15 Jul 2019 at 14:45, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>
> Change the parents of UART clocks to the CPLL which has 666MHz.
> The UARTs' dividers use /10 rate so they would have 66.6MHz.
Write also the state before to show what is being fixed (I assume
previous frequency was not best choice).
BR,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 26/50] ARM: dts: exynos: align NOC100 bus OPPs in Exynos5420
From: Krzysztof Kozlowski @ 2019-07-17 10:38 UTC (permalink / raw)
To: Lukasz Luba
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <8ed83c77-57f7-78a4-e437-714cfc7b5c58@partner.samsung.com>
On Wed, 17 Jul 2019 at 12:27, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>
>
> On 7/17/19 12:10 PM, Krzysztof Kozlowski wrote:
> > On Mon, 15 Jul 2019 at 14:44, Lukasz Luba <l.luba@partner.samsung.com> wrote:
> >>
> >> The NOC100 has a parent which clock rate is set tot 400MHz. The OPPs which
> >> are not possible to set are removed and new one is added.
> >
> > I think it is just NOC bus... or are there more of such and this is 100 MHz one?
> Yes, there is a bus NOC100 with a dedicated clock tree in the HW (with
> 3 muxes and one divider), which makes possible to take different PLL as
> a source then WCORE have, divide the rate from it and even switch for a
> while to alternative stable PLL (on the 2nd mux to SPLL (after a
> divider)) to wait for main PLL rate change stability delay. Max rate is
> limited to 100MHz for this NOC100 bus.
I think we misunderstood each other. I am saying, that the bus is
called "NOC" in the DTSI. Not NOC100. So unless there are more of
NOCs, stick to existing name NOC, even if it is not the most accurate.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 37/50] ARM: dts: exynos: change parent and rate of bus_fsys in Exynos5422
From: Lukasz Luba @ 2019-07-17 10:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <CAJKOXPfrGgAczQ-=1aE453RpJ9BN10ZDmFcrEMPkNyF6GcGtNA@mail.gmail.com>
On 7/17/19 12:25 PM, Krzysztof Kozlowski wrote:
> On Mon, 15 Jul 2019 at 14:45, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>>
>> The FSYS bus OPP table has been aligned to the new parent rate. This patch
>> sets the proper parent and picks the init frequency before the devfreq
>> governor starts working. It sets also parent rate (DPLL to 1200MHz).
>
> 1. I see what the patch is doing, but please write why you are doing
> this. What problem are you solving here?
> 2. Commit title is wrong - it is not Exynos 5422 but Odroid XU3/XU4
> family of boards.
OK, I will rewrite it when during the work on squashing the patches.
>
>>
>> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
>> ---
>> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
>> index d460041f716c..6a82dd175b8a 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
>> @@ -72,6 +72,11 @@
>>
>> &bus_fsys {
>> devfreq = <&bus_wcore>;
>> + assigned-clocks = <&clock CLK_MOUT_ACLK200_FSYS>,
>> + <&clock CLK_DOUT_ACLK200_FSYS>,
>> + <&clock CLK_FOUT_DPLL>;
>> + assigned-clock-parents = <&clock CLK_MOUT_SCLK_DPLL>;
>> + assigned-clock-rates = <0>, <240000000>,<1200000000>;
>
> Here and in all other patches:
> I am not entirely sure that this should be here. It looks like
> property of the SoC. Do we expect that buses will be configured to
> different clock rates between different boards? Since the OPP tables
> are shared (they are property of the SoC, not board) then I would
> assume that default frequency is shared as well.
These clocks they all relay on some bootloader configuration. It depends
which version of the bootloader you have, then you might get different
default configuration in the clocks. The pattern of changing the parent
or even rate is known in the DT files (or I am missing something).
When you grep for it, you get 168 hits (38 for exynos*):
git grep -n "assigned-clock-rates" ./arch/arm/boot/dts/ | wc -l
Regards,
Lukasz
>
> Best regards,
> Krzysztof
>
>
^ permalink raw reply
* RE: [PATCH 3/3] arm64: dts: freescale: Add support for i.MX8QXP AI_ML board
From: Aisheng Dong @ 2019-07-17 10:40 UTC (permalink / raw)
To: Manivannan Sadhasivam, shawnguo@kernel.org,
s.hauer@pengutronix.de, robh+dt@kernel.org
Cc: devicetree@vger.kernel.org, Kinjan Patel,
linux-kernel@vger.kernel.org, Darshak Patel, dl-linux-imx,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org, Prajose John
In-Reply-To: <20190717061039.9271-4-manivannan.sadhasivam@linaro.org>
> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Sent: Wednesday, July 17, 2019 2:11 PM
>
> Add support for i.MX8QXP AI_ML board from Einfochips. This board is one of
> the Consumer Edition boards of the 96Boards family based on i.MX8QXP SoC
> from NXP/Freescale.
>
> The initial support includes following peripherals which are tested and known
> to be working:
>
> 1. Debug serial via UART2
> 2. uSD
> 3. WiFi
> 4. Ethernet
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
The patch looks good to me. Only a few nitpicks below.
Otherwise,
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Dong Aisheng
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../boot/dts/freescale/imx8qxp-ai_ml.dts | 249 ++++++++++++++++++
> 2 files changed, 250 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile
> b/arch/arm64/boot/dts/freescale/Makefile
> index 0bd122f60549..bd8460549d1a 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -24,4 +24,5 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8qxp-ai_ml.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8qxp-mek.dtb diff --git
> a/arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts
> b/arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts
> new file mode 100644
> index 000000000000..dcd36e57d916
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts
> @@ -0,0 +1,249 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2018 Einfochips
> + * Copyright 2019 Linaro Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "imx8qxp.dtsi"
> +
> +/ {
> + model = "Einfochips i.MX8QXP AI_ML";
> + compatible = "einfochips,imx8qxp-ai_ml", "fsl,imx8qxp";
> +
> + aliases {
> + serial1 = &adma_lpuart1;
> + serial2 = &adma_lpuart2;
> + serial3 = &adma_lpuart3;
> + };
> +
> + chosen {
> + stdout-path = &adma_lpuart2;
> + };
> +
> + memory@80000000 {
> + device_type = "memory";
> + reg = <0x00000000 0x80000000 0 0x80000000>;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_leds>;
> +
> + user_led1 {
> + label = "green:user1";
> + gpios = <&lsio_gpio4 16 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + };
> +
> + user_led2 {
> + label = "green:user2";
> + gpios = <&lsio_gpio0 6 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "none";
> + };
> +
> + user_led3 {
> + label = "green:user3";
> + gpios = <&lsio_gpio0 7 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "mmc1";
> + default-state = "off";
> + };
> +
> + user_led4 {
> + label = "green:user4";
> + gpios = <&lsio_gpio4 21 GPIO_ACTIVE_HIGH>;
> + panic-indicator;
> + linux,default-trigger = "none";
> + };
> +
> + wlan_active_led {
> + label = "yellow:wlan";
> + gpios = <&lsio_gpio4 17 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "phy0tx";
> + default-state = "off";
> + };
> +
> + bt_active_led {
> + label = "blue:bt";
> + gpios = <&lsio_gpio4 18 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "hci0-power";
> + default-state = "off";
> + };
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_wifi_reg_on>;
> + reset-gpios = <&lsio_gpio3 24 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +/* BT */
> +&adma_lpuart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart0>;
> + uart-has-rtscts;
> + status = "okay";
> +};
> +
> +/* LS-I2C0 */
Typo?
> +&adma_lpuart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart1>;
> + status = "okay";
> +};
> +
> +/* Debug */
> +&adma_lpuart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart2>;
> + status = "okay";
> +};
> +
> +/* PCI-E */
A bit confusing for the comments...
> +&adma_lpuart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart3>;
> + status = "okay";
> +};
> +
> +&fec1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_fec1>;
> + phy-mode = "rgmii-id";
> + phy-handle = <ðphy0>;
> + fsl,magic-packet;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + };
> + };
> +};
> +
> +/* WiFi */
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + bus-width = <4>;
> + no-sd;
> + non-removable;
> + mmc-pwrseq = <&sdio_pwrseq>;
> + #address-cells = <1>;
> + #size-cells = <0>;
Nitpick: we usually put this two properties at the first place.
> + status = "okay";
> +
> + brcmf: wifi@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + };
> +};
> +
> +/* SD */
> +&usdhc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc2>;
> + bus-width = <4>;
> + cd-gpios = <&lsio_gpio4 22 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl_fec1: fec1grp {
> + fsl,pins = <
> + IMX8QXP_ENET0_MDC_CONN_ENET0_MDC
> 0x06000020
> + IMX8QXP_ENET0_MDIO_CONN_ENET0_MDIO
> 0x06000020
> + IMX8QXP_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL
> 0x06000020
> + IMX8QXP_ENET0_RGMII_TXC_CONN_ENET0_RGMII_TXC
> 0x06000020
> + IMX8QXP_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0
> 0x06000020
> + IMX8QXP_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1
> 0x06000020
> + IMX8QXP_ENET0_RGMII_TXD2_CONN_ENET0_RGMII_TXD2
> 0x06000020
> + IMX8QXP_ENET0_RGMII_TXD3_CONN_ENET0_RGMII_TXD3
> 0x06000020
> + IMX8QXP_ENET0_RGMII_RXC_CONN_ENET0_RGMII_RXC
> 0x06000020
> + IMX8QXP_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL
> 0x06000020
> + IMX8QXP_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0
> 0x06000020
> + IMX8QXP_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1
> 0x06000020
> + IMX8QXP_ENET0_RGMII_RXD2_CONN_ENET0_RGMII_RXD2
> 0x06000020
> + IMX8QXP_ENET0_RGMII_RXD3_CONN_ENET0_RGMII_RXD3
> 0x06000020
> + >;
> + };
> +
> + pinctrl_leds: ledsgrp{
> + fsl,pins = <
> + IMX8QXP_ESAI0_TX2_RX3_LSIO_GPIO0_IO06
> 0x00000021
> + IMX8QXP_ESAI0_TX3_RX2_LSIO_GPIO0_IO07
> 0x00000021
> + IMX8QXP_EMMC0_DATA7_LSIO_GPIO4_IO16
> 0x00000021
> + IMX8QXP_USDHC1_WP_LSIO_GPIO4_IO21
> 0x00000021
> + IMX8QXP_EMMC0_STROBE_LSIO_GPIO4_IO17
> 0x00000021
> + IMX8QXP_EMMC0_RESET_B_LSIO_GPIO4_IO18
> 0x00000021
> + >;
> + };
> +
> + pinctrl_lpuart0: lpuart0grp {
> + fsl,pins = <
> + IMX8QXP_UART0_RX_ADMA_UART0_RX
> 0X06000020
> + IMX8QXP_UART0_TX_ADMA_UART0_TX
> 0X06000020
> + IMX8QXP_FLEXCAN0_TX_ADMA_UART0_CTS_B
> 0x06000020
> + IMX8QXP_FLEXCAN0_RX_ADMA_UART0_RTS_B
> 0x06000020
> + >;
> + };
> +
> + pinctrl_lpuart1: lpuart1grp {
> + fsl,pins = <
> + IMX8QXP_UART1_RX_ADMA_UART1_RX
> 0X06000020
> + IMX8QXP_UART1_TX_ADMA_UART1_TX
> 0X06000020
> + >;
> + };
> +
> + pinctrl_lpuart2: lpuart2grp {
> + fsl,pins = <
> + IMX8QXP_UART2_RX_ADMA_UART2_RX
> 0X06000020
> + IMX8QXP_UART2_TX_ADMA_UART2_TX
> 0X06000020
> + >;
> + };
> +
> + pinctrl_lpuart3: lpuart3grp {
> + fsl,pins = <
> + IMX8QXP_FLEXCAN2_RX_ADMA_UART3_RX
> 0X06000020
> + IMX8QXP_FLEXCAN2_TX_ADMA_UART3_TX
> 0X06000020
> + >;
> + };
> +
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK
> 0x06000041
> + IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD
> 0x00000021
> + IMX8QXP_EMMC0_DATA0_CONN_EMMC0_DATA0
> 0x00000021
> + IMX8QXP_EMMC0_DATA1_CONN_EMMC0_DATA1
> 0x00000021
> + IMX8QXP_EMMC0_DATA2_CONN_EMMC0_DATA2
> 0x00000021
> + IMX8QXP_EMMC0_DATA3_CONN_EMMC0_DATA3
> 0x00000021
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK
> 0x06000041
> + IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD
> 0x00000021
> + IMX8QXP_USDHC1_DATA0_CONN_USDHC1_DATA0
> 0x00000021
> + IMX8QXP_USDHC1_DATA1_CONN_USDHC1_DATA1
> 0x00000021
> + IMX8QXP_USDHC1_DATA2_CONN_USDHC1_DATA2
> 0x00000021
> + IMX8QXP_USDHC1_DATA3_CONN_USDHC1_DATA3
> 0x00000021
> + IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT
> 0x00000021
> + IMX8QXP_USDHC1_CD_B_LSIO_GPIO4_IO22
> 0x00000021
> + >;
> + };
> +
> + pinctrl_wifi_reg_on: wifiregongrp {
> + fsl,pins = <
> + IMX8QXP_QSPI0B_SS1_B_LSIO_GPIO3_IO24
> 0x00000021
> + >;
> + };
> +};
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH v1 26/50] ARM: dts: exynos: align NOC100 bus OPPs in Exynos5420
From: Lukasz Luba @ 2019-07-17 10:41 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <CAJKOXPdMUV6JP0R4kj=cFKd7QUdrtMXtSm4S9pfF77zvKu4v1g@mail.gmail.com>
On 7/17/19 12:38 PM, Krzysztof Kozlowski wrote:
> On Wed, 17 Jul 2019 at 12:27, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>>
>>
>> On 7/17/19 12:10 PM, Krzysztof Kozlowski wrote:
>>> On Mon, 15 Jul 2019 at 14:44, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>>>>
>>>> The NOC100 has a parent which clock rate is set tot 400MHz. The OPPs which
>>>> are not possible to set are removed and new one is added.
>>>
>>> I think it is just NOC bus... or are there more of such and this is 100 MHz one?
>> Yes, there is a bus NOC100 with a dedicated clock tree in the HW (with
>> 3 muxes and one divider), which makes possible to take different PLL as
>> a source then WCORE have, divide the rate from it and even switch for a
>> while to alternative stable PLL (on the 2nd mux to SPLL (after a
>> divider)) to wait for main PLL rate change stability delay. Max rate is
>> limited to 100MHz for this NOC100 bus.
>
> I think we misunderstood each other. I am saying, that the bus is
> called "NOC" in the DTSI. Not NOC100. So unless there are more of
> NOCs, stick to existing name NOC, even if it is not the most accurate.
OK, got it, thanks!
Lukasz
>
> Best regards,
> Krzysztof
>
>
^ permalink raw reply
* Re: [PATCH v3 1/2] ARM: dts: Add ZII support for ZII i.MX7 RMU2 board
From: Shawn Guo @ 2019-07-17 10:42 UTC (permalink / raw)
To: Andrey Smirnov
Cc: linux-arm-kernel, Fabio Estevam, Rob Herring, Chris Healy,
Lucas Stach, Bob Langer, Liang Pan, linux-kernel, devicetree
In-Reply-To: <20190624183044.30240-1-andrew.smirnov@gmail.com>
On Mon, Jun 24, 2019 at 11:30:43AM -0700, Andrey Smirnov wrote:
> Add support for ZII's i.MX7 based Remote Modem Unit 2 (RMU2) board.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Bob Langer <Bob.Langer@zii.aero>
> Cc: Liang Pan <Liang.Pan@zii.aero>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: devicetree@vger.kernel.org
Applied both, thanks.
^ permalink raw reply
* Re: [PATCH v1 37/50] ARM: dts: exynos: change parent and rate of bus_fsys in Exynos5422
From: Krzysztof Kozlowski @ 2019-07-17 10:45 UTC (permalink / raw)
To: Lukasz Luba
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <2fe2e840-f4b2-773b-7d92-4ffb8502d4e6@partner.samsung.com>
On Wed, 17 Jul 2019 at 12:39, Lukasz Luba <l.luba@partner.samsung.com> wrote:
> >>
> >> &bus_fsys {
> >> devfreq = <&bus_wcore>;
> >> + assigned-clocks = <&clock CLK_MOUT_ACLK200_FSYS>,
> >> + <&clock CLK_DOUT_ACLK200_FSYS>,
> >> + <&clock CLK_FOUT_DPLL>;
> >> + assigned-clock-parents = <&clock CLK_MOUT_SCLK_DPLL>;
> >> + assigned-clock-rates = <0>, <240000000>,<1200000000>;
> >
> > Here and in all other patches:
> > I am not entirely sure that this should be here. It looks like
> > property of the SoC. Do we expect that buses will be configured to
> > different clock rates between different boards? Since the OPP tables
> > are shared (they are property of the SoC, not board) then I would
> > assume that default frequency is shared as well.
> These clocks they all relay on some bootloader configuration. It depends
> which version of the bootloader you have, then you might get different
> default configuration in the clocks.
I do not agree here. This configuration is not dependent on
bootloader. Although one bootloader might set the clocks to X and
other to Y, but still you provide here valid configuration setting
them, e.g. to Y (or to Z). What bootloader set before does not matter
because you always override it.
> The pattern of changing the parent
> or even rate is known in the DT files (or I am missing something).
> When you grep for it, you get 168 hits (38 for exynos*):
> git grep -n "assigned-clock-rates" ./arch/arm/boot/dts/ | wc -l
Yeah, and if you grep per type you got:
DTSI: 114
DTS: 54
so what do you want to say?
My thinking is that all the boards have buses configured to the same
initial frequency. I am not questioning the use of
assigned-clock-rates at all. Just the place...
BR,
Krzysztof
^ permalink raw reply
* Re: [v3 2/2] dt-bindings: nand: Add Cadence NAND controller driver
From: Piotr Sroka @ 2019-07-17 10:58 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Boris Brezillon, Richard Weinberger,
linux-kernel, Marek Vasut, linux-mtd, BrianNorris,
David Woodhouse
In-Reply-To: <20190709144853.GA23699@bogus>
The 07/09/2019 08:48, Rob Herring wrote:
>EXTERNAL MAIL
>
>
>On Fri, Jun 14, 2019 at 04:13:01PM +0100, Piotr Sroka wrote:
>> Signed-off-by: Piotr Sroka <piotrs@cadence.com>
>> ---
>> Changes for v3:
>> - add unit suffix for board_delay
>> - move child description to proper place
>> - remove prefix cadence_ for reg and sdma fields
>> Changes for v2:
>> - remove chip dependends parameters from dts bindings
>> - add names for register ranges in dts bindings
>> - add generic bindings to describe NAND chip representation
>> ---
>> .../bindings/mtd/cadence-nand-controller.txt | 51 ++++++++++++++++++++++
>> 1 file changed, 51 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt b/Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt
>> new file mode 100644
>> index 000000000000..e485b87075bd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt
>> @@ -0,0 +1,51 @@
>> +* Cadence NAND controller
>> +
>> +Required properties:
>> + - compatible : "cdns,hpnfc"
>
>Only 1 version of h/w features and bugs?
>
At the moment, yes.
>'hp-nfc' would be a bit more readable IMO.
>
I will replace it.
>> + - reg : Contains two entries, each of which is a tuple consisting of a
>> + physical address and length. The first entry is the address and
>> + length of the controller register set. The second entry is the
>> + address and length of the Slave DMA data port.
>> + - reg-names: should contain "reg" and "sdma"
>> + - interrupts : The interrupt number.
>> + - clocks: phandle of the controller core clock (nf_clk).
>> +
>> +Optional properties:
>> + - dmas: shall reference DMA channel associated to the NAND controller
>> + - cdns,board-delay_ps : Estimated Board delay. The value includes the total
>
>s/_/-/
>
>> + round trip delay for the signals and is used for deciding on values
>> + associated with data read capture. The example formula for SDR mode is
>> + the following:
>> + board_delay = RE#PAD_delay + PCB trace to device + PCB trace from device
>> + + DQ PAD delay
>> +
>> +Children nodes represent the available NAND chips.
>
>Child nodes...
>
>> +
>> +Required properties of NAND chips:
>> + - reg: shall contain the native Chip Select ids from 0 to max supported by
>> + the cadence nand flash controller
>> +
>> +
>> +See Documentation/devicetree/bindings/mtd/nand.txt for more details on
>> +generic bindings.
>> +
>> +Example:
>> +
>> +nand_controller: nand-controller @60000000 {
>
>remove space ^
>
>> +
>> + compatible = "cdns,hpnfc";
>> + reg = <0x60000000 0x10000>, <0x80000000 0x10000>;
>> + reg-names = "reg", "sdma";
>> + clocks = <&nf_clk>;
>> + cdns,board-delay_ps = <4830>;
>> + interrupts = <2 0>;
>> + nand@0 {
>> + reg = <0>;
>> + label = "nand-1";
>> + };
>> + nand@1 {
>> + reg = <1>;
>> + label = "nand-2";
>> + };
>> +
>> +};
>> --
>> 2.15.0
>>
Thanks
Piotr
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v1 37/50] ARM: dts: exynos: change parent and rate of bus_fsys in Exynos5422
From: Lukasz Luba @ 2019-07-17 11:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <CAJKOXPd3gm7no-0TnPmgFg+X3FgdiM6ov5rtzFSM6hKEdEzRCg@mail.gmail.com>
On 7/17/19 12:45 PM, Krzysztof Kozlowski wrote:
> On Wed, 17 Jul 2019 at 12:39, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>>>>
>>>> &bus_fsys {
>>>> devfreq = <&bus_wcore>;
>>>> + assigned-clocks = <&clock CLK_MOUT_ACLK200_FSYS>,
>>>> + <&clock CLK_DOUT_ACLK200_FSYS>,
>>>> + <&clock CLK_FOUT_DPLL>;
>>>> + assigned-clock-parents = <&clock CLK_MOUT_SCLK_DPLL>;
>>>> + assigned-clock-rates = <0>, <240000000>,<1200000000>;
>>>
>>> Here and in all other patches:
>>> I am not entirely sure that this should be here. It looks like
>>> property of the SoC. Do we expect that buses will be configured to
>>> different clock rates between different boards? Since the OPP tables
>>> are shared (they are property of the SoC, not board) then I would
>>> assume that default frequency is shared as well.
>> These clocks they all relay on some bootloader configuration. It depends
>> which version of the bootloader you have, then you might get different
>> default configuration in the clocks.
>
> I do not agree here. This configuration is not dependent on
> bootloader. Although one bootloader might set the clocks to X and
> other to Y, but still you provide here valid configuration setting
> them, e.g. to Y (or to Z). What bootloader set before does not matter
> because you always override it.
This exactly the patch set is aim to do: overwrite any bootloader
configuration which could be wrong set after boot.
I don't know for how long it is left in such
'bootloader-default-clock-settings' but it is not accurate
configuration. The pattern in the DT to change the clock rates is
there.
>
>> The pattern of changing the parent
>> or even rate is known in the DT files (or I am missing something).
>> When you grep for it, you get 168 hits (38 for exynos*):
>> git grep -n "assigned-clock-rates" ./arch/arm/boot/dts/ | wc -l
>
> Yeah, and if you grep per type you got:
> DTSI: 114
> DTS: 54
> so what do you want to say?
Thus, It could be changed in DT.
>
> My thinking is that all the boards have buses configured to the same
> initial frequency. I am not questioning the use of
> assigned-clock-rates at all. Just the place...
It is not only 'initial frequency' as you name it. It has three changes:
- re-parent to proper PLL
- changing this PLL rate
- change the OPPs frequency values to integer values derived from PLL
The initial frequencies will be changed by devfreq governor using OPP
tables and the load after the whole system boots.
Regards,
Lukasz
>
> BR,
> Krzysztof
>
>
^ permalink raw reply
* Re: [PATCH v1 37/50] ARM: dts: exynos: change parent and rate of bus_fsys in Exynos5422
From: Krzysztof Kozlowski @ 2019-07-17 11:11 UTC (permalink / raw)
To: Lukasz Luba
Cc: devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc@vger.kernel.org, linux-clk, mturquette, sboyd,
Bartłomiej Żołnierkiewicz, kgene, mark.rutland,
robh+dt, Chanwoo Choi, kyungmin.park, Andrzej Hajda,
Marek Szyprowski, s.nawrocki, myungjoo.ham
In-Reply-To: <518c26ca-4254-056c-d6d0-ae1b4b63709c@partner.samsung.com>
On Wed, 17 Jul 2019 at 13:06, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>
>
>
> On 7/17/19 12:45 PM, Krzysztof Kozlowski wrote:
> > On Wed, 17 Jul 2019 at 12:39, Lukasz Luba <l.luba@partner.samsung.com> wrote:
> >>>>
> >>>> &bus_fsys {
> >>>> devfreq = <&bus_wcore>;
> >>>> + assigned-clocks = <&clock CLK_MOUT_ACLK200_FSYS>,
> >>>> + <&clock CLK_DOUT_ACLK200_FSYS>,
> >>>> + <&clock CLK_FOUT_DPLL>;
> >>>> + assigned-clock-parents = <&clock CLK_MOUT_SCLK_DPLL>;
> >>>> + assigned-clock-rates = <0>, <240000000>,<1200000000>;
> >>>
> >>> Here and in all other patches:
> >>> I am not entirely sure that this should be here. It looks like
> >>> property of the SoC. Do we expect that buses will be configured to
> >>> different clock rates between different boards? Since the OPP tables
> >>> are shared (they are property of the SoC, not board) then I would
> >>> assume that default frequency is shared as well.
> >> These clocks they all relay on some bootloader configuration. It depends
> >> which version of the bootloader you have, then you might get different
> >> default configuration in the clocks.
> >
> > I do not agree here. This configuration is not dependent on
> > bootloader. Although one bootloader might set the clocks to X and
> > other to Y, but still you provide here valid configuration setting
> > them, e.g. to Y (or to Z). What bootloader set before does not matter
> > because you always override it.
> This exactly the patch set is aim to do: overwrite any bootloader
> configuration which could be wrong set after boot.
> I don't know for how long it is left in such
> 'bootloader-default-clock-settings' but it is not accurate
> configuration. The pattern in the DT to change the clock rates is
> there.
Still it is not the answer to my concerns and questions.
> >
> >> The pattern of changing the parent
> >> or even rate is known in the DT files (or I am missing something).
> >> When you grep for it, you get 168 hits (38 for exynos*):
> >> git grep -n "assigned-clock-rates" ./arch/arm/boot/dts/ | wc -l
> >
> > Yeah, and if you grep per type you got:
> > DTSI: 114
> > DTS: 54
> > so what do you want to say?
> Thus, It could be changed in DT.
Of course, why not. But how this relevant to my question?
> > My thinking is that all the boards have buses configured to the same
> > initial frequency. I am not questioning the use of
> > assigned-clock-rates at all. Just the place...
> It is not only 'initial frequency' as you name it. It has three changes:
> - re-parent to proper PLL
> - changing this PLL rate
> - change the OPPs frequency values to integer values derived from PLL
>
> The initial frequencies will be changed by devfreq governor using OPP
> tables and the load after the whole system boots.
I simplified with "initial frequency" but it does not matter. Let me
try to raise my concerns again, different wording:
All this looks like property of the SoC, not the board, because:
1. the OPPs are already properties of the SoC, not the board (XU3 Lite
is kind of exception but in fact it uses different flavor of
Exynos5422 SoC which we do not model here as separate DTSI),
2. I expect all boards to have the same properties.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: freescale: Add support for i.MX8QXP AI_ML board
From: Manivannan Sadhasivam @ 2019-07-17 11:34 UTC (permalink / raw)
To: Aisheng Dong
Cc: shawnguo@kernel.org, s.hauer@pengutronix.de, robh+dt@kernel.org,
kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Darshak Patel, Kinjan Patel,
Prajose John
In-Reply-To: <AM0PR04MB42116A61D7E32E6BA36D1CBA80C90@AM0PR04MB4211.eurprd04.prod.outlook.com>
Hi Dong,
On Wed, Jul 17, 2019 at 10:40:10AM +0000, Aisheng Dong wrote:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > Sent: Wednesday, July 17, 2019 2:11 PM
> >
> > Add support for i.MX8QXP AI_ML board from Einfochips. This board is one of
> > the Consumer Edition boards of the 96Boards family based on i.MX8QXP SoC
> > from NXP/Freescale.
> >
> > The initial support includes following peripherals which are tested and known
> > to be working:
> >
> > 1. Debug serial via UART2
> > 2. uSD
> > 3. WiFi
> > 4. Ethernet
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>
> The patch looks good to me. Only a few nitpicks below.
> Otherwise,
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
>
> Regards
> Dong Aisheng
>
Thanks for the review!
> > ---
> > arch/arm64/boot/dts/freescale/Makefile | 1 +
> > .../boot/dts/freescale/imx8qxp-ai_ml.dts | 249 ++++++++++++++++++
> > 2 files changed, 250 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts
> >
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile
> > b/arch/arm64/boot/dts/freescale/Makefile
> > index 0bd122f60549..bd8460549d1a 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -24,4 +24,5 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
> > +dtb-$(CONFIG_ARCH_MXC) += imx8qxp-ai_ml.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8qxp-mek.dtb diff --git
> > a/arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts
> > b/arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts
> > new file mode 100644
> > index 000000000000..dcd36e57d916
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts
> > @@ -0,0 +1,249 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2018 Einfochips
> > + * Copyright 2019 Linaro Ltd.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "imx8qxp.dtsi"
> > +
> > +/ {
> > + model = "Einfochips i.MX8QXP AI_ML";
> > + compatible = "einfochips,imx8qxp-ai_ml", "fsl,imx8qxp";
> > +
> > + aliases {
> > + serial1 = &adma_lpuart1;
> > + serial2 = &adma_lpuart2;
> > + serial3 = &adma_lpuart3;
> > + };
> > +
> > + chosen {
> > + stdout-path = &adma_lpuart2;
> > + };
> > +
> > + memory@80000000 {
> > + device_type = "memory";
> > + reg = <0x00000000 0x80000000 0 0x80000000>;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_leds>;
> > +
> > + user_led1 {
> > + label = "green:user1";
> > + gpios = <&lsio_gpio4 16 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "heartbeat";
> > + };
> > +
> > + user_led2 {
> > + label = "green:user2";
> > + gpios = <&lsio_gpio0 6 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "none";
> > + };
> > +
> > + user_led3 {
> > + label = "green:user3";
> > + gpios = <&lsio_gpio0 7 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "mmc1";
> > + default-state = "off";
> > + };
> > +
> > + user_led4 {
> > + label = "green:user4";
> > + gpios = <&lsio_gpio4 21 GPIO_ACTIVE_HIGH>;
> > + panic-indicator;
> > + linux,default-trigger = "none";
> > + };
> > +
> > + wlan_active_led {
> > + label = "yellow:wlan";
> > + gpios = <&lsio_gpio4 17 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "phy0tx";
> > + default-state = "off";
> > + };
> > +
> > + bt_active_led {
> > + label = "blue:bt";
> > + gpios = <&lsio_gpio4 18 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "hci0-power";
> > + default-state = "off";
> > + };
> > + };
> > +
> > + sdio_pwrseq: sdio-pwrseq {
> > + compatible = "mmc-pwrseq-simple";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_wifi_reg_on>;
> > + reset-gpios = <&lsio_gpio3 24 GPIO_ACTIVE_LOW>;
> > + };
> > +};
> > +
> > +/* BT */
> > +&adma_lpuart0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lpuart0>;
> > + uart-has-rtscts;
> > + status = "okay";
> > +};
> > +
> > +/* LS-I2C0 */
>
> Typo?
>
Ah, yes. It should be LS-UART0, will fix it.
> > +&adma_lpuart1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lpuart1>;
> > + status = "okay";
> > +};
> > +
> > +/* Debug */
> > +&adma_lpuart2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lpuart2>;
> > + status = "okay";
> > +};
> > +
> > +/* PCI-E */
>
> A bit confusing for the comments...
>
Hmm. How about, "PCI-E UART"?
> > +&adma_lpuart3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_lpuart3>;
> > + status = "okay";
> > +};
> > +
> > +&fec1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_fec1>;
> > + phy-mode = "rgmii-id";
> > + phy-handle = <ðphy0>;
> > + fsl,magic-packet;
> > + status = "okay";
> > +
> > + mdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ethphy0: ethernet-phy@0 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <0>;
> > + };
> > + };
> > +};
> > +
> > +/* WiFi */
> > +&usdhc1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usdhc1>;
> > + bus-width = <4>;
> > + no-sd;
> > + non-removable;
> > + mmc-pwrseq = <&sdio_pwrseq>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
> Nitpick: we usually put this two properties at the first place.
>
Okay.
Thanks,
Mani
> > + status = "okay";
> > +
> > + brcmf: wifi@1 {
> > + reg = <1>;
> > + compatible = "brcm,bcm4329-fmac";
> > + };
> > +};
> > +
> > +/* SD */
> > +&usdhc2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usdhc2>;
> > + bus-width = <4>;
> > + cd-gpios = <&lsio_gpio4 22 GPIO_ACTIVE_LOW>;
> > + status = "okay";
> > +};
> > +
> > +&iomuxc {
> > + pinctrl_fec1: fec1grp {
> > + fsl,pins = <
> > + IMX8QXP_ENET0_MDC_CONN_ENET0_MDC
> > 0x06000020
> > + IMX8QXP_ENET0_MDIO_CONN_ENET0_MDIO
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_TXC_CONN_ENET0_RGMII_TXC
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_TXD2_CONN_ENET0_RGMII_TXD2
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_TXD3_CONN_ENET0_RGMII_TXD3
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_RXC_CONN_ENET0_RGMII_RXC
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_RXD2_CONN_ENET0_RGMII_RXD2
> > 0x06000020
> > + IMX8QXP_ENET0_RGMII_RXD3_CONN_ENET0_RGMII_RXD3
> > 0x06000020
> > + >;
> > + };
> > +
> > + pinctrl_leds: ledsgrp{
> > + fsl,pins = <
> > + IMX8QXP_ESAI0_TX2_RX3_LSIO_GPIO0_IO06
> > 0x00000021
> > + IMX8QXP_ESAI0_TX3_RX2_LSIO_GPIO0_IO07
> > 0x00000021
> > + IMX8QXP_EMMC0_DATA7_LSIO_GPIO4_IO16
> > 0x00000021
> > + IMX8QXP_USDHC1_WP_LSIO_GPIO4_IO21
> > 0x00000021
> > + IMX8QXP_EMMC0_STROBE_LSIO_GPIO4_IO17
> > 0x00000021
> > + IMX8QXP_EMMC0_RESET_B_LSIO_GPIO4_IO18
> > 0x00000021
> > + >;
> > + };
> > +
> > + pinctrl_lpuart0: lpuart0grp {
> > + fsl,pins = <
> > + IMX8QXP_UART0_RX_ADMA_UART0_RX
> > 0X06000020
> > + IMX8QXP_UART0_TX_ADMA_UART0_TX
> > 0X06000020
> > + IMX8QXP_FLEXCAN0_TX_ADMA_UART0_CTS_B
> > 0x06000020
> > + IMX8QXP_FLEXCAN0_RX_ADMA_UART0_RTS_B
> > 0x06000020
> > + >;
> > + };
> > +
> > + pinctrl_lpuart1: lpuart1grp {
> > + fsl,pins = <
> > + IMX8QXP_UART1_RX_ADMA_UART1_RX
> > 0X06000020
> > + IMX8QXP_UART1_TX_ADMA_UART1_TX
> > 0X06000020
> > + >;
> > + };
> > +
> > + pinctrl_lpuart2: lpuart2grp {
> > + fsl,pins = <
> > + IMX8QXP_UART2_RX_ADMA_UART2_RX
> > 0X06000020
> > + IMX8QXP_UART2_TX_ADMA_UART2_TX
> > 0X06000020
> > + >;
> > + };
> > +
> > + pinctrl_lpuart3: lpuart3grp {
> > + fsl,pins = <
> > + IMX8QXP_FLEXCAN2_RX_ADMA_UART3_RX
> > 0X06000020
> > + IMX8QXP_FLEXCAN2_TX_ADMA_UART3_TX
> > 0X06000020
> > + >;
> > + };
> > +
> > + pinctrl_usdhc1: usdhc1grp {
> > + fsl,pins = <
> > + IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK
> > 0x06000041
> > + IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD
> > 0x00000021
> > + IMX8QXP_EMMC0_DATA0_CONN_EMMC0_DATA0
> > 0x00000021
> > + IMX8QXP_EMMC0_DATA1_CONN_EMMC0_DATA1
> > 0x00000021
> > + IMX8QXP_EMMC0_DATA2_CONN_EMMC0_DATA2
> > 0x00000021
> > + IMX8QXP_EMMC0_DATA3_CONN_EMMC0_DATA3
> > 0x00000021
> > + >;
> > + };
> > +
> > + pinctrl_usdhc2: usdhc2grp {
> > + fsl,pins = <
> > + IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK
> > 0x06000041
> > + IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD
> > 0x00000021
> > + IMX8QXP_USDHC1_DATA0_CONN_USDHC1_DATA0
> > 0x00000021
> > + IMX8QXP_USDHC1_DATA1_CONN_USDHC1_DATA1
> > 0x00000021
> > + IMX8QXP_USDHC1_DATA2_CONN_USDHC1_DATA2
> > 0x00000021
> > + IMX8QXP_USDHC1_DATA3_CONN_USDHC1_DATA3
> > 0x00000021
> > + IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT
> > 0x00000021
> > + IMX8QXP_USDHC1_CD_B_LSIO_GPIO4_IO22
> > 0x00000021
> > + >;
> > + };
> > +
> > + pinctrl_wifi_reg_on: wifiregongrp {
> > + fsl,pins = <
> > + IMX8QXP_QSPI0B_SS1_B_LSIO_GPIO3_IO24
> > 0x00000021
> > + >;
> > + };
> > +};
> > --
> > 2.17.1
>
^ permalink raw reply
* Re: [PATCH 2/5] drivers: spi: core: Add optional stall delay between cs_change transfers
From: Ardelean, Alexandru @ 2019-07-17 11:37 UTC (permalink / raw)
To: broonie@kernel.org, jic23@jic23.retrosnub.co.uk
Cc: linux-spi@vger.kernel.org, Hennerich, Michael,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org
In-Reply-To: <20190709141228.GC14859@sirena.co.uk>
On Tue, 2019-07-09 at 15:12 +0100, Mark Brown wrote:
> On Wed, Jun 26, 2019 at 07:34:38PM +0100, Jonathan Cameron wrote:
> > On Tue, 25 Jun 2019 16:13:25 +0300
> > Alexandru Ardelean <alexandru.ardelean@analog.com> wrote:
> >
> > > Some devices like the ADIS16460 IMU require a stall period between
> > > transfers, i.e. between when the CS is de-asserted and re-asserted. The
> > > default value of 10us is not enough. This change makes the delay
> > > configurable for when the next CS change goes active.
>
> This looks like cs_change_delay.
>
> As documented in SubmittingPatches please send patches to the
> maintainers for the code you would like to change. The normal kernel
> workflow is that people apply patches from their inboxes, if they aren't
> copied they are likely to not see the patch at all and it is much more
> difficult to apply patches.
Ack.
[Sorry for the late reply; I'm balancing other stuff as well and terrible at it]
I'll probably update my practice to also include maintainers via --cc to `git send-email`.
Up until now, I would send emails to lists [as much as possible] and try to not include people directly.
My assumption was that the list is enough.
I'm still adjusting to how things get done in the various Linux kernel subsystems/subgroups.
^ permalink raw reply
* [PATCH 0/4][V2] iio: imu: Add support for the ADIS16460 IMU
From: Alexandru Ardelean @ 2019-07-17 11:51 UTC (permalink / raw)
To: linux-iio, linux-spi, devicetree, linux-kernel
Cc: jic23, robh+dt, mark.rutland, broonie, Alexandru Ardelean
This changeset adds support for the ADIS16460.
Support for this chip, requires changes in both IIO & SPI, in order to
support configurable/longer CS change delays.
The default CS change delay is 10 uS, while the ADIS16460 requires a
minimum of 16 uS. In order to accomodate this, the SPI transfer struct
requires a `cs_change_delay_usecs` parameter that is used when `cs_change`
is set.
The ADIS library also requires a small update to support the new SPI
`cs_change_delay_usecs`, and after that, support for ADIS16460 is added,
since all the required parts for operating the chip are in the kernel.
Changelog v1 -> v2:
* for SPI:
* renamed `cs_change_stall_delay_us` -> `cs_change_delay_usecs`
initial recommendation was `cs_change_delay`, but decided to name this
`cs_change_delay_usecs`, since the convention for these delays seems
to add the `_usecs` suffix
* for ADIS lib:
* renamed `stall_delay` -> `cs_change_delay`
* removed some assignments of `cs_change_delay`
where `cs_change` is not set
* for ADIS16460 driver:
* fixed license
* adjusted to new `cs_change_delay[_usecs]`
Alexandru Ardelean (4):
drivers: spi: core: Add optional stall delay between cs_change
transfers
iio: imu: adis: Add support for SPI transfer cs_change_stall_delay_us
iio: imu: Add support for the ADIS16460 IMU
dt-bindings: iio: imu: add bindings for ADIS16460
.../bindings/iio/imu/adi,adis16460.yaml | 53 ++
MAINTAINERS | 8 +
drivers/iio/imu/Kconfig | 12 +
drivers/iio/imu/Makefile | 1 +
drivers/iio/imu/adis.c | 6 +
drivers/iio/imu/adis16460.c | 489 ++++++++++++++++++
drivers/spi/spi.c | 3 +-
include/linux/iio/imu/adis.h | 2 +
include/linux/spi/spi.h | 3 +
9 files changed, 576 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
create mode 100644 drivers/iio/imu/adis16460.c
--
2.20.1
^ permalink raw reply
* [PATCH 1/4][V2] drivers: spi: core: Add optional delay between cs_change transfers
From: Alexandru Ardelean @ 2019-07-17 11:51 UTC (permalink / raw)
To: linux-iio, linux-spi, devicetree, linux-kernel
Cc: jic23, robh+dt, mark.rutland, broonie, Alexandru Ardelean,
Michael Hennerich
In-Reply-To: <20190717115109.15168-1-alexandru.ardelean@analog.com>
Some devices like the ADIS16460 IMU require a stall period between
transfers, i.e. between when the CS is de-asserted and re-asserted. The
default value of 10us is not enough. This change makes the delay
configurable for when the next CS change goes active.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/spi/spi.c | 3 ++-
include/linux/spi/spi.h | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 5e75944ad5d1..02fd00bcaace 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1163,7 +1163,8 @@ static int spi_transfer_one_message(struct spi_controller *ctlr,
keep_cs = true;
} else {
spi_set_cs(msg->spi, false);
- udelay(10);
+ udelay(xfer->cs_change_delay_usecs ?
+ xfer->cs_change_delay_usecs : 10);
spi_set_cs(msg->spi, true);
}
}
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 053abd22ad31..c884b3b94841 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -734,6 +734,8 @@ extern void spi_res_release(struct spi_controller *ctlr,
* transfer. If 0 the default (from @spi_device) is used.
* @bits_per_word: select a bits_per_word other than the device default
* for this transfer. If 0 the default (from @spi_device) is used.
+ * @cs_change_delay_usecs: microseconds to delay between cs_change
+ * transfers.
* @cs_change: affects chipselect after this transfer completes
* @delay_usecs: microseconds to delay after this transfer before
* (optionally) changing the chipselect status, then starting
@@ -823,6 +825,7 @@ struct spi_transfer {
#define SPI_NBITS_QUAD 0x04 /* 4bits transfer */
u8 bits_per_word;
u8 word_delay_usecs;
+ u8 cs_change_delay_usecs;
u16 delay_usecs;
u32 speed_hz;
u16 word_delay;
--
2.20.1
^ permalink raw reply related
* [PATCH 2/4][V2] iio: imu: adis: Add support for SPI transfer cs_change_delay_usecs
From: Alexandru Ardelean @ 2019-07-17 11:51 UTC (permalink / raw)
To: linux-iio, linux-spi, devicetree, linux-kernel
Cc: jic23, robh+dt, mark.rutland, broonie, Alexandru Ardelean,
Michael Hennerich
In-Reply-To: <20190717115109.15168-1-alexandru.ardelean@analog.com>
The ADIS16460 requires a higher delay before the next transfer. Since the
SPI framework supports configuring the delay before the next transfer, this
driver will become the first user of it.
The support for this functionality in ADIS16460 requires an addition to the
ADIS lib to support the `cs_change_stall_delay_us` functionality in SPI.
Not all transfers set `cs_change` to 1. Only those that do, have the
`cs_change_delay` assigned.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/imu/adis.c | 6 ++++++
include/linux/iio/imu/adis.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/iio/imu/adis.c b/drivers/iio/imu/adis.c
index c771ae6803a9..6fdb6f4cebd4 100644
--- a/drivers/iio/imu/adis.c
+++ b/drivers/iio/imu/adis.c
@@ -40,18 +40,21 @@ int adis_write_reg(struct adis *adis, unsigned int reg,
.len = 2,
.cs_change = 1,
.delay_usecs = adis->data->write_delay,
+ .cs_change_delay_usecs = adis->data->cs_change_delay,
}, {
.tx_buf = adis->tx + 2,
.bits_per_word = 8,
.len = 2,
.cs_change = 1,
.delay_usecs = adis->data->write_delay,
+ .cs_change_delay_usecs = adis->data->cs_change_delay,
}, {
.tx_buf = adis->tx + 4,
.bits_per_word = 8,
.len = 2,
.cs_change = 1,
.delay_usecs = adis->data->write_delay,
+ .cs_change_delay_usecs = adis->data->cs_change_delay,
}, {
.tx_buf = adis->tx + 6,
.bits_per_word = 8,
@@ -134,12 +137,14 @@ int adis_read_reg(struct adis *adis, unsigned int reg,
.len = 2,
.cs_change = 1,
.delay_usecs = adis->data->write_delay,
+ .cs_change_delay_usecs = adis->data->cs_change_delay,
}, {
.tx_buf = adis->tx + 2,
.bits_per_word = 8,
.len = 2,
.cs_change = 1,
.delay_usecs = adis->data->read_delay,
+ .cs_change_delay_usecs = adis->data->cs_change_delay,
}, {
.tx_buf = adis->tx + 4,
.rx_buf = adis->rx,
@@ -147,6 +152,7 @@ int adis_read_reg(struct adis *adis, unsigned int reg,
.len = 2,
.cs_change = 1,
.delay_usecs = adis->data->read_delay,
+ .cs_change_delay_usecs = adis->data->cs_change_delay,
}, {
.rx_buf = adis->rx + 2,
.bits_per_word = 8,
diff --git a/include/linux/iio/imu/adis.h b/include/linux/iio/imu/adis.h
index 469a493f7ae0..fd884b45ed45 100644
--- a/include/linux/iio/imu/adis.h
+++ b/include/linux/iio/imu/adis.h
@@ -27,6 +27,7 @@ struct adis_burst;
* struct adis_data - ADIS chip variant specific data
* @read_delay: SPI delay for read operations in us
* @write_delay: SPI delay for write operations in us
+ * @cs_change_delay: SPI delay between CS changes in us
* @glob_cmd_reg: Register address of the GLOB_CMD register
* @msc_ctrl_reg: Register address of the MSC_CTRL register
* @diag_stat_reg: Register address of the DIAG_STAT register
@@ -36,6 +37,7 @@ struct adis_burst;
struct adis_data {
unsigned int read_delay;
unsigned int write_delay;
+ unsigned int cs_change_delay;
unsigned int glob_cmd_reg;
unsigned int msc_ctrl_reg;
--
2.20.1
^ permalink raw reply related
* [PATCH 3/4][V2] iio: imu: Add support for the ADIS16460 IMU
From: Alexandru Ardelean @ 2019-07-17 11:51 UTC (permalink / raw)
To: linux-iio, linux-spi, devicetree, linux-kernel
Cc: jic23, robh+dt, mark.rutland, broonie, Alexandru Ardelean,
Dragos Bogdan, Michael Hennerich
In-Reply-To: <20190717115109.15168-1-alexandru.ardelean@analog.com>
The ADIS16460 device is a complete inertial system that includes a triaxial
gyroscope and a triaxial accelerometer. It's more simplified design than
that of the ADIS16480, and does not offer the triaxial magnetometers &
pressure sensors. It does also have a temperature sensor (like the
ADIS16480).
Since it is part of the ADIS16XXX family, it re-uses parts of the ADIS
library.
Naturally, the register map is different and much more simplified than the
ADIS16480 subfamily, so it cannot be integrated into that driver. A major
difference is that the registers are not paged.
One thing that is particularly special about it, is that it requires a
higher delay between CS changes (i.e. when CS goes up, the spec recommends
that it be brought down after a minimum of 16 uS).
Other ADIS chips require (via spec) a minimum of 2 uS between CS changes.
The kernel's 10 uS default should be fine for those other chips; they
haven't been tested with lower CS change delays yet.
Datasheet:
https://www.analog.com/media/en/technical-documentation/data-sheets/adis16460.pdf
Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
MAINTAINERS | 7 +
drivers/iio/imu/Kconfig | 12 +
drivers/iio/imu/Makefile | 1 +
drivers/iio/imu/adis16460.c | 489 ++++++++++++++++++++++++++++++++++++
4 files changed, 509 insertions(+)
create mode 100644 drivers/iio/imu/adis16460.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ad498428b38c..8e679504c087 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -937,6 +937,13 @@ L: linux-iio@vger.kernel.org
F: include/linux/iio/imu/adis.h
F: drivers/iio/imu/adis.c
+ANALOG DEVICES INC ADIS16460 DRIVER
+M: Dragos Bogdan <dragos.bogdan@analog.com>
+S: Supported
+L: linux-iio@vger.kernel.org
+W: http://ez.analog.com/community/linux-device-drivers
+F: drivers/iio/imu/adis16460.c
+
ANALOG DEVICES INC ADP5061 DRIVER
M: Stefan Popa <stefan.popa@analog.com>
L: linux-pm@vger.kernel.org
diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
index 156630a21696..f048d0d757b1 100644
--- a/drivers/iio/imu/Kconfig
+++ b/drivers/iio/imu/Kconfig
@@ -16,6 +16,18 @@ config ADIS16400
adis16365, adis16400 and adis16405 triaxial inertial sensors
(adis16400 series also have magnetometers).
+config ADIS16460
+ tristate "Analog Devices ADIS16460 and similar IMU driver"
+ depends on SPI
+ select IIO_ADIS_LIB
+ select IIO_ADIS_LIB_BUFFER if IIO_BUFFER
+ help
+ Say yes here to build support for Analog Devices ADIS16460 inertial
+ sensor.
+
+ To compile this driver as a module, choose M here: the module will be
+ called adis16460.
+
config ADIS16480
tristate "Analog Devices ADIS16480 and similar IMU driver"
depends on SPI
diff --git a/drivers/iio/imu/Makefile b/drivers/iio/imu/Makefile
index 9e452fce1aaf..4a6958865504 100644
--- a/drivers/iio/imu/Makefile
+++ b/drivers/iio/imu/Makefile
@@ -5,6 +5,7 @@
# When adding new entries keep the list in alphabetical order
obj-$(CONFIG_ADIS16400) += adis16400.o
+obj-$(CONFIG_ADIS16460) += adis16460.o
obj-$(CONFIG_ADIS16480) += adis16480.o
adis_lib-y += adis.o
diff --git a/drivers/iio/imu/adis16460.c b/drivers/iio/imu/adis16460.c
new file mode 100644
index 000000000000..db713cba75a2
--- /dev/null
+++ b/drivers/iio/imu/adis16460.c
@@ -0,0 +1,489 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * ADIS16460 IMU driver
+ *
+ * Copyright 2019 Analog Devices Inc.
+ */
+
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/spi/spi.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/imu/adis.h>
+
+#include <linux/debugfs.h>
+
+#define ADIS16460_REG_FLASH_CNT 0x00
+#define ADIS16460_REG_DIAG_STAT 0x02
+#define ADIS16460_REG_X_GYRO_LOW 0x04
+#define ADIS16460_REG_X_GYRO_OUT 0x06
+#define ADIS16460_REG_Y_GYRO_LOW 0x08
+#define ADIS16460_REG_Y_GYRO_OUT 0x0A
+#define ADIS16460_REG_Z_GYRO_LOW 0x0C
+#define ADIS16460_REG_Z_GYRO_OUT 0x0E
+#define ADIS16460_REG_X_ACCL_LOW 0x10
+#define ADIS16460_REG_X_ACCL_OUT 0x12
+#define ADIS16460_REG_Y_ACCL_LOW 0x14
+#define ADIS16460_REG_Y_ACCL_OUT 0x16
+#define ADIS16460_REG_Z_ACCL_LOW 0x18
+#define ADIS16460_REG_Z_ACCL_OUT 0x1A
+#define ADIS16460_REG_SMPL_CNTR 0x1C
+#define ADIS16460_REG_TEMP_OUT 0x1E
+#define ADIS16460_REG_X_DELT_ANG 0x24
+#define ADIS16460_REG_Y_DELT_ANG 0x26
+#define ADIS16460_REG_Z_DELT_ANG 0x28
+#define ADIS16460_REG_X_DELT_VEL 0x2A
+#define ADIS16460_REG_Y_DELT_VEL 0x2C
+#define ADIS16460_REG_Z_DELT_VEL 0x2E
+#define ADIS16460_REG_MSC_CTRL 0x32
+#define ADIS16460_REG_SYNC_SCAL 0x34
+#define ADIS16460_REG_DEC_RATE 0x36
+#define ADIS16460_REG_FLTR_CTRL 0x38
+#define ADIS16460_REG_GLOB_CMD 0x3E
+#define ADIS16460_REG_X_GYRO_OFF 0x40
+#define ADIS16460_REG_Y_GYRO_OFF 0x42
+#define ADIS16460_REG_Z_GYRO_OFF 0x44
+#define ADIS16460_REG_X_ACCL_OFF 0x46
+#define ADIS16460_REG_Y_ACCL_OFF 0x48
+#define ADIS16460_REG_Z_ACCL_OFF 0x4A
+#define ADIS16460_REG_LOT_ID1 0x52
+#define ADIS16460_REG_LOT_ID2 0x54
+#define ADIS16460_REG_PROD_ID 0x56
+#define ADIS16460_REG_SERIAL_NUM 0x58
+#define ADIS16460_REG_CAL_SGNTR 0x60
+#define ADIS16460_REG_CAL_CRC 0x62
+#define ADIS16460_REG_CODE_SGNTR 0x64
+#define ADIS16460_REG_CODE_CRC 0x66
+
+struct adis16460_chip_info {
+ unsigned int num_channels;
+ const struct iio_chan_spec *channels;
+ unsigned int gyro_max_val;
+ unsigned int gyro_max_scale;
+ unsigned int accel_max_val;
+ unsigned int accel_max_scale;
+};
+
+struct adis16460 {
+ const struct adis16460_chip_info *chip_info;
+ struct adis adis;
+};
+
+#ifdef CONFIG_DEBUG_FS
+
+static int adis16460_show_serial_number(void *arg, u64 *val)
+{
+ struct adis16460 *adis16460 = arg;
+ u16 serial;
+ int ret;
+
+ ret = adis_read_reg_16(&adis16460->adis, ADIS16460_REG_SERIAL_NUM,
+ &serial);
+ if (ret < 0)
+ return ret;
+
+ *val = serial;
+
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(adis16460_serial_number_fops,
+ adis16460_show_serial_number, NULL, "0x%.4llx\n");
+
+static int adis16460_show_product_id(void *arg, u64 *val)
+{
+ struct adis16460 *adis16460 = arg;
+ u16 prod_id;
+ int ret;
+
+ ret = adis_read_reg_16(&adis16460->adis, ADIS16460_REG_PROD_ID,
+ &prod_id);
+ if (ret < 0)
+ return ret;
+
+ *val = prod_id;
+
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(adis16460_product_id_fops,
+ adis16460_show_product_id, NULL, "%llu\n");
+
+static int adis16460_show_flash_count(void *arg, u64 *val)
+{
+ struct adis16460 *adis16460 = arg;
+ u32 flash_count;
+ int ret;
+
+ ret = adis_read_reg_32(&adis16460->adis, ADIS16460_REG_FLASH_CNT,
+ &flash_count);
+ if (ret < 0)
+ return ret;
+
+ *val = flash_count;
+
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(adis16460_flash_count_fops,
+ adis16460_show_flash_count, NULL, "%lld\n");
+
+static int adis16460_debugfs_init(struct iio_dev *indio_dev)
+{
+ struct adis16460 *adis16460 = iio_priv(indio_dev);
+
+ debugfs_create_file("serial_number", 0400, indio_dev->debugfs_dentry,
+ adis16460, &adis16460_serial_number_fops);
+ debugfs_create_file("product_id", 0400, indio_dev->debugfs_dentry,
+ adis16460, &adis16460_product_id_fops);
+ debugfs_create_file("flash_count", 0400, indio_dev->debugfs_dentry,
+ adis16460, &adis16460_flash_count_fops);
+
+ return 0;
+}
+
+#else
+
+static int adis16460_debugfs_init(struct iio_dev *indio_dev)
+{
+ return 0;
+}
+
+#endif
+
+static int adis16460_set_freq(struct iio_dev *indio_dev, int val, int val2)
+{
+ struct adis16460 *st = iio_priv(indio_dev);
+ unsigned int t;
+
+ t = val * 1000 + val2 / 1000;
+ if (t <= 0)
+ return -EINVAL;
+
+ t = 2048000 / t;
+ if (t > 2048)
+ t = 2048;
+
+ if (t != 0)
+ t--;
+
+ return adis_write_reg_16(&st->adis, ADIS16460_REG_DEC_RATE, t);
+}
+
+static int adis16460_get_freq(struct iio_dev *indio_dev, int *val, int *val2)
+{
+ struct adis16460 *st = iio_priv(indio_dev);
+ uint16_t t;
+ int ret;
+ unsigned int freq;
+
+ ret = adis_read_reg_16(&st->adis, ADIS16460_REG_DEC_RATE, &t);
+ if (ret < 0)
+ return ret;
+
+ freq = 2048000 / (t + 1);
+ *val = freq / 1000;
+ *val2 = (freq % 1000) * 1000;
+
+ return IIO_VAL_INT_PLUS_MICRO;
+}
+
+static int adis16460_read_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan, int *val, int *val2, long info)
+{
+ struct adis16460 *st = iio_priv(indio_dev);
+
+ switch (info) {
+ case IIO_CHAN_INFO_RAW:
+ return adis_single_conversion(indio_dev, chan, 0, val);
+ case IIO_CHAN_INFO_SCALE:
+ switch (chan->type) {
+ case IIO_ANGL_VEL:
+ *val = st->chip_info->gyro_max_scale;
+ *val2 = st->chip_info->gyro_max_val;
+ return IIO_VAL_FRACTIONAL;
+ case IIO_ACCEL:
+ *val = st->chip_info->accel_max_scale;
+ *val2 = st->chip_info->accel_max_val;
+ return IIO_VAL_FRACTIONAL;
+ case IIO_TEMP:
+ *val = 50; /* 50 milli degrees Celsius/LSB */
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+ case IIO_CHAN_INFO_OFFSET:
+ *val = 500; /* 25 degrees Celsius = 0x0000 */
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ return adis16460_get_freq(indio_dev, val, val2);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int adis16460_write_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan, int val, int val2, long info)
+{
+ switch (info) {
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ return adis16460_set_freq(indio_dev, val, val2);
+ default:
+ return -EINVAL;
+ }
+}
+
+enum {
+ ADIS16460_SCAN_GYRO_X,
+ ADIS16460_SCAN_GYRO_Y,
+ ADIS16460_SCAN_GYRO_Z,
+ ADIS16460_SCAN_ACCEL_X,
+ ADIS16460_SCAN_ACCEL_Y,
+ ADIS16460_SCAN_ACCEL_Z,
+ ADIS16460_SCAN_TEMP,
+};
+
+#define ADIS16460_MOD_CHANNEL(_type, _mod, _address, _si, _bits) \
+ { \
+ .type = (_type), \
+ .modified = 1, \
+ .channel2 = (_mod), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ), \
+ .address = (_address), \
+ .scan_index = (_si), \
+ .scan_type = { \
+ .sign = 's', \
+ .realbits = (_bits), \
+ .storagebits = (_bits), \
+ .endianness = IIO_BE, \
+ }, \
+ }
+
+#define ADIS16460_GYRO_CHANNEL(_mod) \
+ ADIS16460_MOD_CHANNEL(IIO_ANGL_VEL, IIO_MOD_ ## _mod, \
+ ADIS16460_REG_ ## _mod ## _GYRO_LOW, ADIS16460_SCAN_GYRO_ ## _mod, \
+ 32)
+
+#define ADIS16460_ACCEL_CHANNEL(_mod) \
+ ADIS16460_MOD_CHANNEL(IIO_ACCEL, IIO_MOD_ ## _mod, \
+ ADIS16460_REG_ ## _mod ## _ACCL_LOW, ADIS16460_SCAN_ACCEL_ ## _mod, \
+ 32)
+
+#define ADIS16460_TEMP_CHANNEL() { \
+ .type = IIO_TEMP, \
+ .indexed = 1, \
+ .channel = 0, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE) | \
+ BIT(IIO_CHAN_INFO_OFFSET), \
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ), \
+ .address = ADIS16460_REG_TEMP_OUT, \
+ .scan_index = ADIS16460_SCAN_TEMP, \
+ .scan_type = { \
+ .sign = 's', \
+ .realbits = 16, \
+ .storagebits = 16, \
+ .endianness = IIO_BE, \
+ }, \
+ }
+
+static const struct iio_chan_spec adis16460_channels[] = {
+ ADIS16460_GYRO_CHANNEL(X),
+ ADIS16460_GYRO_CHANNEL(Y),
+ ADIS16460_GYRO_CHANNEL(Z),
+ ADIS16460_ACCEL_CHANNEL(X),
+ ADIS16460_ACCEL_CHANNEL(Y),
+ ADIS16460_ACCEL_CHANNEL(Z),
+ ADIS16460_TEMP_CHANNEL(),
+ IIO_CHAN_SOFT_TIMESTAMP(7)
+};
+
+static const struct adis16460_chip_info adis16460_chip_info = {
+ .channels = adis16460_channels,
+ .num_channels = ARRAY_SIZE(adis16460_channels),
+ /*
+ * storing the value in rad/degree and the scale in degree
+ * gives us the result in rad and better precession than
+ * storing the scale directly in rad.
+ */
+ .gyro_max_val = IIO_RAD_TO_DEGREE(200 << 16),
+ .gyro_max_scale = 1,
+ .accel_max_val = IIO_M_S_2_TO_G(20000 << 16),
+ .accel_max_scale = 5,
+};
+
+static const struct iio_info adis16460_info = {
+ .read_raw = &adis16460_read_raw,
+ .write_raw = &adis16460_write_raw,
+ .update_scan_mode = adis_update_scan_mode,
+ .debugfs_reg_access = adis_debugfs_reg_access,
+};
+
+static int adis16460_enable_irq(struct adis *adis, bool enable)
+{
+ /*
+ * There is no way to gate the data-ready signal internally inside the
+ * ADIS16460 :(
+ */
+ if (enable)
+ enable_irq(adis->spi->irq);
+ else
+ disable_irq(adis->spi->irq);
+
+ return 0;
+}
+
+static int adis16460_initial_setup(struct iio_dev *indio_dev)
+{
+ struct adis16460 *st = iio_priv(indio_dev);
+ uint16_t prod_id;
+ unsigned int device_id;
+ int ret;
+
+ adis_reset(&st->adis);
+ msleep(222);
+
+ ret = adis_write_reg_16(&st->adis, ADIS16460_REG_GLOB_CMD, BIT(1));
+ if (ret)
+ return ret;
+ msleep(75);
+
+ ret = adis_check_status(&st->adis);
+ if (ret)
+ return ret;
+
+ ret = adis_read_reg_16(&st->adis, ADIS16460_REG_PROD_ID, &prod_id);
+ if (ret)
+ return ret;
+
+ ret = sscanf(indio_dev->name, "adis%u\n", &device_id);
+ if (ret != 1)
+ return -EINVAL;
+
+ if (prod_id != device_id)
+ dev_warn(&indio_dev->dev, "Device ID(%u) and product ID(%u) do not match.",
+ device_id, prod_id);
+
+ return 0;
+}
+
+#define ADIS16460_DIAG_STAT_IN_CLK_OOS 7
+#define ADIS16460_DIAG_STAT_FLASH_MEM 6
+#define ADIS16460_DIAG_STAT_SELF_TEST 5
+#define ADIS16460_DIAG_STAT_OVERRANGE 4
+#define ADIS16460_DIAG_STAT_SPI_COMM 3
+#define ADIS16460_DIAG_STAT_FLASH_UPT 2
+
+static const char * const adis16460_status_error_msgs[] = {
+ [ADIS16460_DIAG_STAT_IN_CLK_OOS] = "Input clock out of sync",
+ [ADIS16460_DIAG_STAT_FLASH_MEM] = "Flash memory failure",
+ [ADIS16460_DIAG_STAT_SELF_TEST] = "Self test diagnostic failure",
+ [ADIS16460_DIAG_STAT_OVERRANGE] = "Sensor overrange",
+ [ADIS16460_DIAG_STAT_SPI_COMM] = "SPI communication failure",
+ [ADIS16460_DIAG_STAT_FLASH_UPT] = "Flash update failure",
+};
+
+static const struct adis_data adis16460_data = {
+ .diag_stat_reg = ADIS16460_REG_DIAG_STAT,
+ .glob_cmd_reg = ADIS16460_REG_GLOB_CMD,
+ .has_paging = false,
+ .read_delay = 5,
+ .write_delay = 5,
+ .cs_change_delay = 16,
+ .status_error_msgs = adis16460_status_error_msgs,
+ .status_error_mask = BIT(ADIS16460_DIAG_STAT_IN_CLK_OOS) |
+ BIT(ADIS16460_DIAG_STAT_FLASH_MEM) |
+ BIT(ADIS16460_DIAG_STAT_SELF_TEST) |
+ BIT(ADIS16460_DIAG_STAT_OVERRANGE) |
+ BIT(ADIS16460_DIAG_STAT_SPI_COMM) |
+ BIT(ADIS16460_DIAG_STAT_FLASH_UPT),
+ .enable_irq = adis16460_enable_irq,
+};
+
+static int adis16460_probe(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev;
+ struct adis16460 *st;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
+ if (indio_dev == NULL)
+ return -ENOMEM;
+
+ spi_set_drvdata(spi, indio_dev);
+
+ st = iio_priv(indio_dev);
+
+ st->chip_info = &adis16460_chip_info;
+ indio_dev->dev.parent = &spi->dev;
+ indio_dev->name = spi_get_device_id(spi)->name;
+ indio_dev->channels = st->chip_info->channels;
+ indio_dev->num_channels = st->chip_info->num_channels;
+ indio_dev->info = &adis16460_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ ret = adis_init(&st->adis, indio_dev, spi, &adis16460_data);
+ if (ret)
+ return ret;
+
+ ret = adis_setup_buffer_and_trigger(&st->adis, indio_dev, NULL);
+ if (ret)
+ return ret;
+
+ adis16460_enable_irq(&st->adis, 0);
+
+ ret = adis16460_initial_setup(indio_dev);
+ if (ret)
+ goto error_cleanup_buffer;
+
+ ret = iio_device_register(indio_dev);
+ if (ret)
+ goto error_cleanup_buffer;
+
+ adis16460_debugfs_init(indio_dev);
+
+ return 0;
+
+error_cleanup_buffer:
+ adis_cleanup_buffer_and_trigger(&st->adis, indio_dev);
+ return ret;
+}
+
+static int adis16460_remove(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev = spi_get_drvdata(spi);
+ struct adis16460 *st = iio_priv(indio_dev);
+
+ iio_device_unregister(indio_dev);
+
+ adis_cleanup_buffer_and_trigger(&st->adis, indio_dev);
+
+ return 0;
+}
+
+static const struct spi_device_id adis16460_ids[] = {
+ { "adis16460", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(spi, adis16460_id);
+
+static const struct of_device_id adis16460_of_match[] = {
+ { .compatible = "adi,adis16460" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, adis16460_of_match);
+
+static struct spi_driver adis16460_driver = {
+ .driver = {
+ .name = "adis16460",
+ .of_match_table = adis16460_of_match,
+ },
+ .id_table = adis16460_ids,
+ .probe = adis16460_probe,
+ .remove = adis16460_remove,
+};
+module_spi_driver(adis16460_driver);
+
+MODULE_AUTHOR("Dragos Bogdan <dragos.bogdan@analog.com>");
+MODULE_DESCRIPTION("Analog Devices ADIS16460 IMU driver");
+MODULE_LICENSE("GPL");
--
2.20.1
^ permalink raw reply related
* [PATCH 4/4][V2] dt-bindings: iio: imu: add bindings for ADIS16460
From: Alexandru Ardelean @ 2019-07-17 11:51 UTC (permalink / raw)
To: linux-iio, linux-spi, devicetree, linux-kernel
Cc: jic23, robh+dt, mark.rutland, broonie, Alexandru Ardelean
In-Reply-To: <20190717115109.15168-1-alexandru.ardelean@analog.com>
This change adds device-tree bindings for the ADIS16460.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
.../bindings/iio/imu/adi,adis16460.yaml | 53 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
new file mode 100644
index 000000000000..0c53009ba7d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/imu/adi,adis16460.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADIS16460 and similar IMUs
+
+maintainers:
+ - Dragos Bogdan <dragos.bogdan@analog.com>
+
+description: |
+ Analog Devices ADIS16460 and similar IMUs
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ADIS16460.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,adis16460
+
+ reg:
+ maxItems: 1
+
+ spi-cpha: true
+
+ spi-cpol: true
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imu@0 {
+ compatible = "adi,adis16460";
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ spi-cpol;
+ spi-cpha;
+ interrupt-parent = <&gpio0>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e679504c087..c44fbe8e91e9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -943,6 +943,7 @@ S: Supported
L: linux-iio@vger.kernel.org
W: http://ez.analog.com/community/linux-device-drivers
F: drivers/iio/imu/adis16460.c
+F: Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
ANALOG DEVICES INC ADP5061 DRIVER
M: Stefan Popa <stefan.popa@analog.com>
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox