| Message ID | 20230125094513.155063-5-krzysztof.kozlowski@linaro.org |
|---|---|
| State | Accepted |
| Commit | adf8238ef403190ffc1e60c0cfe3ea284b401314 |
| Headers | show |
| Series | [1/9] ARM: dts: exynos: correct HDMI phy compatible in Exynos4 | expand |
On 03/02/2023 12:51, Marek Szyprowski wrote: > On 03.02.2023 12:46, Krzysztof Kozlowski wrote: >> On 03/02/2023 12:45, Marek Szyprowski wrote: >>> On 29.01.2023 11:42, Krzysztof Kozlowski wrote: >>>> On 25/01/2023 10:45, Krzysztof Kozlowski wrote: >>>>> The soc node is supposed to have only device nodes with MMIO addresses, >>>>> as reported by dtc W=1: >>>>> >>>>> exynos4412.dtsi:407.20-413.5: >>>>> Warning (simple_bus_reg): /soc/bus-acp: missing or empty reg/ranges property >>>>> >>>>> and dtbs_check: >>>>> >>>>> exynos4412-i9300.dtb: soc: bus-acp: >>>>> {'compatible': ['samsung,exynos-bus'], 'clocks': [[7, 456]], 'clock-names': ['bus'], 'operating-points-v2': [[132]], 'status': ['okay'], 'devfreq': [[117]]} should not be valid under {'type': 'object'} >>>>> >>>>> Move the bus nodes and their OPP tables out of SoC to fix this. >>>>> Re-order them alphabetically while moving and put some of the OPP tables >>>>> in device nodes (if they are not shared). >>>>> >>>> Applied. >>> I don't have a good news. It looks that this change is responsible for >>> breaking boards that were rock-stable so far, like Odroid U3. I didn't >>> manage to analyze what exactly causes the issue, but it looks that the >>> exynos-bus devfreq driver somehow depends on the order of the nodes: >>> >>> (before) >>> >>> # dmesg | grep exynos-bus >>> [ 6.415266] exynos-bus: new bus device registered: soc:bus-dmc >>> (100000 KHz ~ 400000 KHz) >>> [ 6.422717] exynos-bus: new bus device registered: soc:bus-acp >>> (100000 KHz ~ 267000 KHz) >>> [ 6.454323] exynos-bus: new bus device registered: soc:bus-c2c >>> (100000 KHz ~ 400000 KHz) >>> [ 6.489944] exynos-bus: new bus device registered: soc:bus-leftbus >>> (100000 KHz ~ 200000 KHz) >>> [ 6.493990] exynos-bus: new bus device registered: soc:bus-rightbus >>> (100000 KHz ~ 200000 KHz) >>> [ 6.494612] exynos-bus: new bus device registered: soc:bus-display >>> (160000 KHz ~ 200000 KHz) >>> [ 6.494932] exynos-bus: new bus device registered: soc:bus-fsys >>> (100000 KHz ~ 134000 KHz) >>> [ 6.495246] exynos-bus: new bus device registered: soc:bus-peri ( >>> 50000 KHz ~ 100000 KHz) >>> [ 6.495577] exynos-bus: new bus device registered: soc:bus-mfc >>> (100000 KHz ~ 200000 KHz) >>> >>> (after) >>> >>> # dmesg | grep exynos-bus >>> >>> [ 6.082032] exynos-bus: new bus device registered: bus-dmc (100000 >>> KHz ~ 400000 KHz) >>> [ 6.122726] exynos-bus: new bus device registered: bus-leftbus >>> (100000 KHz ~ 200000 KHz) >>> [ 6.146705] exynos-bus: new bus device registered: bus-mfc (100000 >>> KHz ~ 200000 KHz) >>> [ 6.181632] exynos-bus: new bus device registered: bus-peri ( 50000 >>> KHz ~ 100000 KHz) >>> [ 6.204770] exynos-bus: new bus device registered: bus-rightbus >>> (100000 KHz ~ 200000 KHz) >>> [ 6.211087] exynos-bus: new bus device registered: bus-acp (100000 >>> KHz ~ 267000 KHz) >>> [ 6.216936] exynos-bus: new bus device registered: bus-c2c (100000 >>> KHz ~ 400000 KHz) >>> [ 6.225748] exynos-bus: new bus device registered: bus-display >>> (160000 KHz ~ 200000 KHz) >>> [ 6.242978] exynos-bus: new bus device registered: bus-fsys (100000 >>> KHz ~ 134000 KHz) >>> >>> This is definitely a driver bug, but so far it worked fine, so this is a >>> regression that need to be addressed somehow... >> >> Thanks for checking, but what is exactly the bug? The devices registered >> - just with different name. > > The bug is that the board fails to boot from time to time, freezing > after registering PPMU counters... My U3 with and without this patch, reports several warnings: iommu_group_do_set_platform_dma() exynos_iommu_domain_free() clk_core_enable() and finally: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: and keeps stalling. At least on next-20230203. Except all these (which anyway make board unbootable) look fine around PMU and exynos-bus. Best regards, Krzysztof
On 03.02.2023 22:12, Krzysztof Kozlowski wrote: > On 03/02/2023 21:34, Krzysztof Kozlowski wrote: >> On 03/02/2023 12:51, Marek Szyprowski wrote: >>> On 03.02.2023 12:46, Krzysztof Kozlowski wrote: >>>> On 03/02/2023 12:45, Marek Szyprowski wrote: >>>>> On 29.01.2023 11:42, Krzysztof Kozlowski wrote: >>>>>> On 25/01/2023 10:45, Krzysztof Kozlowski wrote: >>>>>>> The soc node is supposed to have only device nodes with MMIO addresses, >>>>>>> as reported by dtc W=1: >>>>>>> >>>>>>> exynos4412.dtsi:407.20-413.5: >>>>>>> Warning (simple_bus_reg): /soc/bus-acp: missing or empty reg/ranges property >>>>>>> >>>>>>> and dtbs_check: >>>>>>> >>>>>>> exynos4412-i9300.dtb: soc: bus-acp: >>>>>>> {'compatible': ['samsung,exynos-bus'], 'clocks': [[7, 456]], 'clock-names': ['bus'], 'operating-points-v2': [[132]], 'status': ['okay'], 'devfreq': [[117]]} should not be valid under {'type': 'object'} >>>>>>> >>>>>>> Move the bus nodes and their OPP tables out of SoC to fix this. >>>>>>> Re-order them alphabetically while moving and put some of the OPP tables >>>>>>> in device nodes (if they are not shared). >>>>>>> >>>>>> Applied. >>>>> I don't have a good news. It looks that this change is responsible for >>>>> breaking boards that were rock-stable so far, like Odroid U3. I didn't >>>>> manage to analyze what exactly causes the issue, but it looks that the >>>>> exynos-bus devfreq driver somehow depends on the order of the nodes: >>>>> >>>>> (before) >>>>> >>>>> # dmesg | grep exynos-bus >>>>> [ 6.415266] exynos-bus: new bus device registered: soc:bus-dmc >>>>> (100000 KHz ~ 400000 KHz) >>>>> [ 6.422717] exynos-bus: new bus device registered: soc:bus-acp >>>>> (100000 KHz ~ 267000 KHz) >>>>> [ 6.454323] exynos-bus: new bus device registered: soc:bus-c2c >>>>> (100000 KHz ~ 400000 KHz) >>>>> [ 6.489944] exynos-bus: new bus device registered: soc:bus-leftbus >>>>> (100000 KHz ~ 200000 KHz) >>>>> [ 6.493990] exynos-bus: new bus device registered: soc:bus-rightbus >>>>> (100000 KHz ~ 200000 KHz) >>>>> [ 6.494612] exynos-bus: new bus device registered: soc:bus-display >>>>> (160000 KHz ~ 200000 KHz) >>>>> [ 6.494932] exynos-bus: new bus device registered: soc:bus-fsys >>>>> (100000 KHz ~ 134000 KHz) >>>>> [ 6.495246] exynos-bus: new bus device registered: soc:bus-peri ( >>>>> 50000 KHz ~ 100000 KHz) >>>>> [ 6.495577] exynos-bus: new bus device registered: soc:bus-mfc >>>>> (100000 KHz ~ 200000 KHz) >>>>> >>>>> (after) >>>>> >>>>> # dmesg | grep exynos-bus >>>>> >>>>> [ 6.082032] exynos-bus: new bus device registered: bus-dmc (100000 >>>>> KHz ~ 400000 KHz) >>>>> [ 6.122726] exynos-bus: new bus device registered: bus-leftbus >>>>> (100000 KHz ~ 200000 KHz) >>>>> [ 6.146705] exynos-bus: new bus device registered: bus-mfc (100000 >>>>> KHz ~ 200000 KHz) >>>>> [ 6.181632] exynos-bus: new bus device registered: bus-peri ( 50000 >>>>> KHz ~ 100000 KHz) >>>>> [ 6.204770] exynos-bus: new bus device registered: bus-rightbus >>>>> (100000 KHz ~ 200000 KHz) >>>>> [ 6.211087] exynos-bus: new bus device registered: bus-acp (100000 >>>>> KHz ~ 267000 KHz) >>>>> [ 6.216936] exynos-bus: new bus device registered: bus-c2c (100000 >>>>> KHz ~ 400000 KHz) >>>>> [ 6.225748] exynos-bus: new bus device registered: bus-display >>>>> (160000 KHz ~ 200000 KHz) >>>>> [ 6.242978] exynos-bus: new bus device registered: bus-fsys (100000 >>>>> KHz ~ 134000 KHz) >>>>> >>>>> This is definitely a driver bug, but so far it worked fine, so this is a >>>>> regression that need to be addressed somehow... >>>> Thanks for checking, but what is exactly the bug? The devices registered >>>> - just with different name. >>> The bug is that the board fails to boot from time to time, freezing >>> after registering PPMU counters... >> My U3 with and without this patch, reports several warnings: >> iommu_group_do_set_platform_dma() >> exynos_iommu_domain_free() >> clk_core_enable() >> >> and finally: >> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: >> >> and keeps stalling. >> >> At least on next-20230203. Except all these (which anyway make board >> unbootable) look fine around PMU and exynos-bus. > I also booted few times my next/dt branch (with this patch) and no > problems. How reproducible is the issue you experience? IOMMU needs a fixup, that has been merged today: https://lore.kernel.org/all/20230123093102.12392-1-m.szyprowski@samsung.com/ I was initially convinced that this freeze is somehow related to this IOMMU fixup, but it turned out that the devfreq is a source of the problems. The freeze happens here about 1 of 10 boots, usually with kernel compiled from multi_v7_defconfig, while loading the PPMU modules. It happens on your next/dt branch too. Best regards
On 06.02.2023 17:12, Krzysztof Kozlowski wrote: > On 03/02/2023 23:50, Marek Szyprowski wrote: >> On 03.02.2023 22:12, Krzysztof Kozlowski wrote: >>> On 03/02/2023 21:34, Krzysztof Kozlowski wrote: >>>> On 03/02/2023 12:51, Marek Szyprowski wrote: >>>>> On 03.02.2023 12:46, Krzysztof Kozlowski wrote: >>>>>> On 03/02/2023 12:45, Marek Szyprowski wrote: >>>>>>> On 29.01.2023 11:42, Krzysztof Kozlowski wrote: >>>>>>>> On 25/01/2023 10:45, Krzysztof Kozlowski wrote: >>>>>>>>> The soc node is supposed to have only device nodes with MMIO addresses, >>>>>>>>> as reported by dtc W=1: >>>>>>>>> >>>>>>>>> exynos4412.dtsi:407.20-413.5: >>>>>>>>> Warning (simple_bus_reg): /soc/bus-acp: missing or empty reg/ranges property >>>>>>>>> >>>>>>>>> and dtbs_check: >>>>>>>>> >>>>>>>>> exynos4412-i9300.dtb: soc: bus-acp: >>>>>>>>> {'compatible': ['samsung,exynos-bus'], 'clocks': [[7, 456]], 'clock-names': ['bus'], 'operating-points-v2': [[132]], 'status': ['okay'], 'devfreq': [[117]]} should not be valid under {'type': 'object'} >>>>>>>>> >>>>>>>>> Move the bus nodes and their OPP tables out of SoC to fix this. >>>>>>>>> Re-order them alphabetically while moving and put some of the OPP tables >>>>>>>>> in device nodes (if they are not shared). >>>>>>>>> >>>>>>>> Applied. >>>>>>> I don't have a good news. It looks that this change is responsible for >>>>>>> breaking boards that were rock-stable so far, like Odroid U3. I didn't >>>>>>> manage to analyze what exactly causes the issue, but it looks that the >>>>>>> exynos-bus devfreq driver somehow depends on the order of the nodes: >>>>>>> >>>>>>> (before) >>>>>>> >>>>>>> # dmesg | grep exynos-bus >>>>>>> [ 6.415266] exynos-bus: new bus device registered: soc:bus-dmc >>>>>>> (100000 KHz ~ 400000 KHz) >>>>>>> [ 6.422717] exynos-bus: new bus device registered: soc:bus-acp >>>>>>> (100000 KHz ~ 267000 KHz) >>>>>>> [ 6.454323] exynos-bus: new bus device registered: soc:bus-c2c >>>>>>> (100000 KHz ~ 400000 KHz) >>>>>>> [ 6.489944] exynos-bus: new bus device registered: soc:bus-leftbus >>>>>>> (100000 KHz ~ 200000 KHz) >>>>>>> [ 6.493990] exynos-bus: new bus device registered: soc:bus-rightbus >>>>>>> (100000 KHz ~ 200000 KHz) >>>>>>> [ 6.494612] exynos-bus: new bus device registered: soc:bus-display >>>>>>> (160000 KHz ~ 200000 KHz) >>>>>>> [ 6.494932] exynos-bus: new bus device registered: soc:bus-fsys >>>>>>> (100000 KHz ~ 134000 KHz) >>>>>>> [ 6.495246] exynos-bus: new bus device registered: soc:bus-peri ( >>>>>>> 50000 KHz ~ 100000 KHz) >>>>>>> [ 6.495577] exynos-bus: new bus device registered: soc:bus-mfc >>>>>>> (100000 KHz ~ 200000 KHz) >>>>>>> >>>>>>> (after) >>>>>>> >>>>>>> # dmesg | grep exynos-bus >>>>>>> >>>>>>> [ 6.082032] exynos-bus: new bus device registered: bus-dmc (100000 >>>>>>> KHz ~ 400000 KHz) >>>>>>> [ 6.122726] exynos-bus: new bus device registered: bus-leftbus >>>>>>> (100000 KHz ~ 200000 KHz) >>>>>>> [ 6.146705] exynos-bus: new bus device registered: bus-mfc (100000 >>>>>>> KHz ~ 200000 KHz) >>>>>>> [ 6.181632] exynos-bus: new bus device registered: bus-peri ( 50000 >>>>>>> KHz ~ 100000 KHz) >>>>>>> [ 6.204770] exynos-bus: new bus device registered: bus-rightbus >>>>>>> (100000 KHz ~ 200000 KHz) >>>>>>> [ 6.211087] exynos-bus: new bus device registered: bus-acp (100000 >>>>>>> KHz ~ 267000 KHz) >>>>>>> [ 6.216936] exynos-bus: new bus device registered: bus-c2c (100000 >>>>>>> KHz ~ 400000 KHz) >>>>>>> [ 6.225748] exynos-bus: new bus device registered: bus-display >>>>>>> (160000 KHz ~ 200000 KHz) >>>>>>> [ 6.242978] exynos-bus: new bus device registered: bus-fsys (100000 >>>>>>> KHz ~ 134000 KHz) >>>>>>> >>>>>>> This is definitely a driver bug, but so far it worked fine, so this is a >>>>>>> regression that need to be addressed somehow... >>>>>> Thanks for checking, but what is exactly the bug? The devices registered >>>>>> - just with different name. >>>>> The bug is that the board fails to boot from time to time, freezing >>>>> after registering PPMU counters... >>>> My U3 with and without this patch, reports several warnings: >>>> iommu_group_do_set_platform_dma() >>>> exynos_iommu_domain_free() >>>> clk_core_enable() >>>> >>>> and finally: >>>> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: >>>> >>>> and keeps stalling. >>>> >>>> At least on next-20230203. Except all these (which anyway make board >>>> unbootable) look fine around PMU and exynos-bus. >>> I also booted few times my next/dt branch (with this patch) and no >>> problems. How reproducible is the issue you experience? >> IOMMU needs a fixup, that has been merged today: >> >> https://lore.kernel.org/all/20230123093102.12392-1-m.szyprowski@samsung.com/ >> >> I was initially convinced that this freeze is somehow related to this >> IOMMU fixup, but it turned out that the devfreq is a source of the problems. >> >> The freeze happens here about 1 of 10 boots, usually with kernel >> compiled from multi_v7_defconfig, while loading the PPMU modules. It >> happens on your next/dt branch too. > I was able to reproduce it easily with multi_v7. Then I commented out > dmc bus which fixed the issue. Then I commented out acp and c2c buses > (children/passive) which also fixed the issue. Then I uncommented > everything and went back to next/dt - exactly the same as it was failing > - and since then I cannot reproduce it. I triple checked, but now my > multi_v7 on U3 on next/dt boots perfectly fine. Every time. This issue still happens from time to time. I quick workaround to fix it is to add: MODULE_SOFTDEP("pre: exynos_ppmu"); to the exynos-bus driver. Is it acceptable solution? Best regards
On 24/03/2023 18:07, Marek Szyprowski wrote: > On 06.02.2023 17:12, Krzysztof Kozlowski wrote: >> On 03/02/2023 23:50, Marek Szyprowski wrote: >>> On 03.02.2023 22:12, Krzysztof Kozlowski wrote: >>>> On 03/02/2023 21:34, Krzysztof Kozlowski wrote: >>>>> On 03/02/2023 12:51, Marek Szyprowski wrote: >>>>>> On 03.02.2023 12:46, Krzysztof Kozlowski wrote: >>>>>>> On 03/02/2023 12:45, Marek Szyprowski wrote: >>>>>>>> On 29.01.2023 11:42, Krzysztof Kozlowski wrote: >>>>>>>>> On 25/01/2023 10:45, Krzysztof Kozlowski wrote: >>>>>>>>>> The soc node is supposed to have only device nodes with MMIO addresses, >>>>>>>>>> as reported by dtc W=1: >>>>>>>>>> >>>>>>>>>> exynos4412.dtsi:407.20-413.5: >>>>>>>>>> Warning (simple_bus_reg): /soc/bus-acp: missing or empty reg/ranges property >>>>>>>>>> >>>>>>>>>> and dtbs_check: >>>>>>>>>> >>>>>>>>>> exynos4412-i9300.dtb: soc: bus-acp: >>>>>>>>>> {'compatible': ['samsung,exynos-bus'], 'clocks': [[7, 456]], 'clock-names': ['bus'], 'operating-points-v2': [[132]], 'status': ['okay'], 'devfreq': [[117]]} should not be valid under {'type': 'object'} >>>>>>>>>> >>>>>>>>>> Move the bus nodes and their OPP tables out of SoC to fix this. >>>>>>>>>> Re-order them alphabetically while moving and put some of the OPP tables >>>>>>>>>> in device nodes (if they are not shared). >>>>>>>>>> >>>>>>>>> Applied. >>>>>>>> I don't have a good news. It looks that this change is responsible for >>>>>>>> breaking boards that were rock-stable so far, like Odroid U3. I didn't >>>>>>>> manage to analyze what exactly causes the issue, but it looks that the >>>>>>>> exynos-bus devfreq driver somehow depends on the order of the nodes: >>>>>>>> >>>>>>>> (before) >>>>>>>> >>>>>>>> # dmesg | grep exynos-bus >>>>>>>> [ 6.415266] exynos-bus: new bus device registered: soc:bus-dmc >>>>>>>> (100000 KHz ~ 400000 KHz) >>>>>>>> [ 6.422717] exynos-bus: new bus device registered: soc:bus-acp >>>>>>>> (100000 KHz ~ 267000 KHz) >>>>>>>> [ 6.454323] exynos-bus: new bus device registered: soc:bus-c2c >>>>>>>> (100000 KHz ~ 400000 KHz) >>>>>>>> [ 6.489944] exynos-bus: new bus device registered: soc:bus-leftbus >>>>>>>> (100000 KHz ~ 200000 KHz) >>>>>>>> [ 6.493990] exynos-bus: new bus device registered: soc:bus-rightbus >>>>>>>> (100000 KHz ~ 200000 KHz) >>>>>>>> [ 6.494612] exynos-bus: new bus device registered: soc:bus-display >>>>>>>> (160000 KHz ~ 200000 KHz) >>>>>>>> [ 6.494932] exynos-bus: new bus device registered: soc:bus-fsys >>>>>>>> (100000 KHz ~ 134000 KHz) >>>>>>>> [ 6.495246] exynos-bus: new bus device registered: soc:bus-peri ( >>>>>>>> 50000 KHz ~ 100000 KHz) >>>>>>>> [ 6.495577] exynos-bus: new bus device registered: soc:bus-mfc >>>>>>>> (100000 KHz ~ 200000 KHz) >>>>>>>> >>>>>>>> (after) >>>>>>>> >>>>>>>> # dmesg | grep exynos-bus >>>>>>>> >>>>>>>> [ 6.082032] exynos-bus: new bus device registered: bus-dmc (100000 >>>>>>>> KHz ~ 400000 KHz) >>>>>>>> [ 6.122726] exynos-bus: new bus device registered: bus-leftbus >>>>>>>> (100000 KHz ~ 200000 KHz) >>>>>>>> [ 6.146705] exynos-bus: new bus device registered: bus-mfc (100000 >>>>>>>> KHz ~ 200000 KHz) >>>>>>>> [ 6.181632] exynos-bus: new bus device registered: bus-peri ( 50000 >>>>>>>> KHz ~ 100000 KHz) >>>>>>>> [ 6.204770] exynos-bus: new bus device registered: bus-rightbus >>>>>>>> (100000 KHz ~ 200000 KHz) >>>>>>>> [ 6.211087] exynos-bus: new bus device registered: bus-acp (100000 >>>>>>>> KHz ~ 267000 KHz) >>>>>>>> [ 6.216936] exynos-bus: new bus device registered: bus-c2c (100000 >>>>>>>> KHz ~ 400000 KHz) >>>>>>>> [ 6.225748] exynos-bus: new bus device registered: bus-display >>>>>>>> (160000 KHz ~ 200000 KHz) >>>>>>>> [ 6.242978] exynos-bus: new bus device registered: bus-fsys (100000 >>>>>>>> KHz ~ 134000 KHz) >>>>>>>> >>>>>>>> This is definitely a driver bug, but so far it worked fine, so this is a >>>>>>>> regression that need to be addressed somehow... >>>>>>> Thanks for checking, but what is exactly the bug? The devices registered >>>>>>> - just with different name. >>>>>> The bug is that the board fails to boot from time to time, freezing >>>>>> after registering PPMU counters... >>>>> My U3 with and without this patch, reports several warnings: >>>>> iommu_group_do_set_platform_dma() >>>>> exynos_iommu_domain_free() >>>>> clk_core_enable() >>>>> >>>>> and finally: >>>>> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: >>>>> >>>>> and keeps stalling. >>>>> >>>>> At least on next-20230203. Except all these (which anyway make board >>>>> unbootable) look fine around PMU and exynos-bus. >>>> I also booted few times my next/dt branch (with this patch) and no >>>> problems. How reproducible is the issue you experience? >>> IOMMU needs a fixup, that has been merged today: >>> >>> https://lore.kernel.org/all/20230123093102.12392-1-m.szyprowski@samsung.com/ >>> >>> I was initially convinced that this freeze is somehow related to this >>> IOMMU fixup, but it turned out that the devfreq is a source of the problems. >>> >>> The freeze happens here about 1 of 10 boots, usually with kernel >>> compiled from multi_v7_defconfig, while loading the PPMU modules. It >>> happens on your next/dt branch too. >> I was able to reproduce it easily with multi_v7. Then I commented out >> dmc bus which fixed the issue. Then I commented out acp and c2c buses >> (children/passive) which also fixed the issue. Then I uncommented >> everything and went back to next/dt - exactly the same as it was failing >> - and since then I cannot reproduce it. I triple checked, but now my >> multi_v7 on U3 on next/dt boots perfectly fine. Every time. > > This issue still happens from time to time. I quick workaround to fix it > is to add: > > MODULE_SOFTDEP("pre: exynos_ppmu"); > > to the exynos-bus driver. Is it acceptable solution? I initially thought it might be caused by deferred probe, but it happens even in successful boot. I guess we can go with this workaround because I really do not have other idea. Best regards, Krzysztof
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi index c02865ff0761..f34c7400475b 100644 --- a/arch/arm/boot/dts/exynos4412.dtsi +++ b/arch/arm/boot/dts/exynos4412.dtsi @@ -31,6 +31,134 @@ aliases { mshc0 = &mshc_0; }; + bus_acp: bus-acp { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_DIV_ACP>; + clock-names = "bus"; + operating-points-v2 = <&bus_acp_opp_table>; + status = "disabled"; + + bus_acp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + }; + opp-134000000 { + opp-hz = /bits/ 64 <134000000>; + }; + opp-160000000 { + opp-hz = /bits/ 64 <160000000>; + }; + opp-267000000 { + opp-hz = /bits/ 64 <267000000>; + }; + }; + }; + + bus_c2c: bus-c2c { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_DIV_C2C>; + clock-names = "bus"; + operating-points-v2 = <&bus_dmc_opp_table>; + status = "disabled"; + }; + + bus_dmc: bus-dmc { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_DIV_DMC>; + clock-names = "bus"; + operating-points-v2 = <&bus_dmc_opp_table>; + samsung,data-clock-ratio = <4>; + #interconnect-cells = <0>; + status = "disabled"; + }; + + bus_display: bus-display { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_ACLK160>; + clock-names = "bus"; + operating-points-v2 = <&bus_display_opp_table>; + interconnects = <&bus_leftbus &bus_dmc>; + #interconnect-cells = <0>; + status = "disabled"; + + bus_display_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-160000000 { + opp-hz = /bits/ 64 <160000000>; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + }; + }; + }; + + bus_fsys: bus-fsys { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_ACLK133>; + clock-names = "bus"; + operating-points-v2 = <&bus_fsys_opp_table>; + status = "disabled"; + + bus_fsys_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + }; + opp-134000000 { + opp-hz = /bits/ 64 <134000000>; + }; + }; + }; + + bus_leftbus: bus-leftbus { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_DIV_GDL>; + clock-names = "bus"; + operating-points-v2 = <&bus_leftbus_opp_table>; + interconnects = <&bus_dmc>; + #interconnect-cells = <0>; + status = "disabled"; + }; + + bus_mfc: bus-mfc { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_SCLK_MFC>; + clock-names = "bus"; + operating-points-v2 = <&bus_leftbus_opp_table>; + status = "disabled"; + }; + + bus_peri: bus-peri { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_ACLK100>; + clock-names = "bus"; + operating-points-v2 = <&bus_peri_opp_table>; + status = "disabled"; + + bus_peri_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-50000000 { + opp-hz = /bits/ 64 <50000000>; + }; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + }; + }; + }; + + bus_rightbus: bus-rightbus { + compatible = "samsung,exynos-bus"; + clocks = <&clock CLK_DIV_GDR>; + clock-names = "bus"; + operating-points-v2 = <&bus_leftbus_opp_table>; + status = "disabled"; + }; + cpus { #address-cells = <1>; #size-cells = <0>; @@ -171,6 +299,53 @@ cpu0_opp_1500: opp-1500000000 { }; }; + bus_dmc_opp_table: opp-table-1 { + compatible = "operating-points-v2"; + + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <900000>; + }; + opp-134000000 { + opp-hz = /bits/ 64 <134000000>; + opp-microvolt = <900000>; + }; + opp-160000000 { + opp-hz = /bits/ 64 <160000000>; + opp-microvolt = <900000>; + }; + opp-267000000 { + opp-hz = /bits/ 64 <267000000>; + opp-microvolt = <950000>; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <1050000>; + opp-suspend; + }; + }; + + bus_leftbus_opp_table: opp-table-2 { + compatible = "operating-points-v2"; + + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <900000>; + }; + opp-134000000 { + opp-hz = /bits/ 64 <134000000>; + opp-microvolt = <925000>; + }; + opp-160000000 { + opp-hz = /bits/ 64 <160000000>; + opp-microvolt = <950000>; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <1000000>; + opp-suspend; + }; + }; soc: soc { @@ -393,182 +568,6 @@ sysmmu_fimc_lite1: sysmmu@123c0000 { <&isp_clock CLK_ISP_FIMC_LITE1>; #iommu-cells = <0>; }; - - bus_dmc: bus-dmc { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_DIV_DMC>; - clock-names = "bus"; - operating-points-v2 = <&bus_dmc_opp_table>; - samsung,data-clock-ratio = <4>; - #interconnect-cells = <0>; - status = "disabled"; - }; - - bus_acp: bus-acp { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_DIV_ACP>; - clock-names = "bus"; - operating-points-v2 = <&bus_acp_opp_table>; - status = "disabled"; - }; - - bus_c2c: bus-c2c { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_DIV_C2C>; - clock-names = "bus"; - operating-points-v2 = <&bus_dmc_opp_table>; - status = "disabled"; - }; - - bus_dmc_opp_table: opp-table-1 { - compatible = "operating-points-v2"; - - opp-100000000 { - opp-hz = /bits/ 64 <100000000>; - opp-microvolt = <900000>; - }; - opp-134000000 { - opp-hz = /bits/ 64 <134000000>; - opp-microvolt = <900000>; - }; - opp-160000000 { - opp-hz = /bits/ 64 <160000000>; - opp-microvolt = <900000>; - }; - opp-267000000 { - opp-hz = /bits/ 64 <267000000>; - opp-microvolt = <950000>; - }; - opp-400000000 { - opp-hz = /bits/ 64 <400000000>; - opp-microvolt = <1050000>; - opp-suspend; - }; - }; - - bus_acp_opp_table: opp-table-2 { - compatible = "operating-points-v2"; - - opp-100000000 { - opp-hz = /bits/ 64 <100000000>; - }; - opp-134000000 { - opp-hz = /bits/ 64 <134000000>; - }; - opp-160000000 { - opp-hz = /bits/ 64 <160000000>; - }; - opp-267000000 { - opp-hz = /bits/ 64 <267000000>; - }; - }; - - bus_leftbus: bus-leftbus { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_DIV_GDL>; - clock-names = "bus"; - operating-points-v2 = <&bus_leftbus_opp_table>; - interconnects = <&bus_dmc>; - #interconnect-cells = <0>; - status = "disabled"; - }; - - bus_rightbus: bus-rightbus { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_DIV_GDR>; - clock-names = "bus"; - operating-points-v2 = <&bus_leftbus_opp_table>; - status = "disabled"; - }; - - bus_display: bus-display { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_ACLK160>; - clock-names = "bus"; - operating-points-v2 = <&bus_display_opp_table>; - interconnects = <&bus_leftbus &bus_dmc>; - #interconnect-cells = <0>; - status = "disabled"; - }; - - bus_fsys: bus-fsys { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_ACLK133>; - clock-names = "bus"; - operating-points-v2 = <&bus_fsys_opp_table>; - status = "disabled"; - }; - - bus_peri: bus-peri { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_ACLK100>; - clock-names = "bus"; - operating-points-v2 = <&bus_peri_opp_table>; - status = "disabled"; - }; - - bus_mfc: bus-mfc { - compatible = "samsung,exynos-bus"; - clocks = <&clock CLK_SCLK_MFC>; - clock-names = "bus"; - operating-points-v2 = <&bus_leftbus_opp_table>; - status = "disabled"; - }; - - bus_leftbus_opp_table: opp-table-3 { - compatible = "operating-points-v2"; - - opp-100000000 { - opp-hz = /bits/ 64 <100000000>; - opp-microvolt = <900000>; - }; - opp-134000000 { - opp-hz = /bits/ 64 <134000000>; - opp-microvolt = <925000>; - }; - opp-160000000 { - opp-hz = /bits/ 64 <160000000>; - opp-microvolt = <950000>; - }; - opp-200000000 { - opp-hz = /bits/ 64 <200000000>; - opp-microvolt = <1000000>; - opp-suspend; - }; - }; - - bus_display_opp_table: opp-table-4 { - compatible = "operating-points-v2"; - - opp-160000000 { - opp-hz = /bits/ 64 <160000000>; - }; - opp-200000000 { - opp-hz = /bits/ 64 <200000000>; - }; - }; - - bus_fsys_opp_table: opp-table-5 { - compatible = "operating-points-v2"; - - opp-100000000 { - opp-hz = /bits/ 64 <100000000>; - }; - opp-134000000 { - opp-hz = /bits/ 64 <134000000>; - }; - }; - - bus_peri_opp_table: opp-table-6 { - compatible = "operating-points-v2"; - - opp-50000000 { - opp-hz = /bits/ 64 <50000000>; - }; - opp-100000000 { - opp-hz = /bits/ 64 <100000000>; - }; - }; }; };
The soc node is supposed to have only device nodes with MMIO addresses, as reported by dtc W=1: exynos4412.dtsi:407.20-413.5: Warning (simple_bus_reg): /soc/bus-acp: missing or empty reg/ranges property and dtbs_check: exynos4412-i9300.dtb: soc: bus-acp: {'compatible': ['samsung,exynos-bus'], 'clocks': [[7, 456]], 'clock-names': ['bus'], 'operating-points-v2': [[132]], 'status': ['okay'], 'devfreq': [[117]]} should not be valid under {'type': 'object'} Move the bus nodes and their OPP tables out of SoC to fix this. Re-order them alphabetically while moving and put some of the OPP tables in device nodes (if they are not shared). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> --- arch/arm/boot/dts/exynos4412.dtsi | 351 +++++++++++++++--------------- 1 file changed, 175 insertions(+), 176 deletions(-)