linux-kernel - [PATCH v2 0/2] Exynos5422: fix bus related OPPs for Odroid XU3/XU4/HC1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 19 Dec 2019 11:51:28 +0100
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-pm@...r.kernel.org
Cc:     Marek Szyprowski <m.szyprowski@...sung.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Kamil Konieczny <k.konieczny@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>
Subject: [PATCH v2 0/2] Exynos5422: fix bus related OPPs for Odroid
 XU3/XU4/HC1

Dear All,

Currently the only Exynos5422-based boards that support bus frequency
scaling are Hardkernel's Odroid XU3/XU4/HC1. The recent changes in the
devfreq framework revealed that some operating points for the defined
busses cannot be applied, because the rates defined in the OPPs cannot
be derived from the top PLL clocks (due to lack of common integer
dividers). This issue has been first noticed by Lukasz Luba in:
https://lkml.org/lkml/2019/7/15/276

To use the rates currently defined in the OPPs, one would need to change
the rate and the topology of the top PLL clocks. The best place for such
operation is the bootloader, because later when kernel boots, more and
more devices (like UART, MMC, and so on) are enabled and get the clocks
from those top PLLs. Changing the rate of the clock for the already
enabled/operating device is very tricky.

To avoid that issue I've decided to keep the current top PLL clocks
configuration prepared by the bootloader on Odroid XU3/XU4/HC1 boards and
adjust the OPPs for it. This means that the bus related OPPs are board
dependant, so I've moved the to the respective DTS files. For other
boards (for example Peach Pi/Pit Chromebooks), slightly different OPPs
might need to be defined due to different clock topology and top PLLs
rates configured by their bootloader.

The provided approach is probably the simplest fix to let all busses
operate on the highest possible speeds, which match the configuration
applied initially by the bootloader.

Best regards
Marek Szyprowski
Samsung R&D Institute Poland

Changelog:

v2:
- removed incorrect 'opp-shared' property from bus_fsys_apb_opp_table
- renamed dmc opp table to opp_table17
- added tags

v1: https://patchwork.kernel.org/cover/11302803/
- initial version

Patch summary:

Marek Szyprowski (2):
  ARM: dts: exynos: Move bus related OPPs to the boards DTS
  ARM: dts: exynos: Adjust bus related OPPs to the values correct for
    Odroids

 arch/arm/boot/dts/exynos5420.dtsi             | 259 -----------------
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 275 +++++++++++++++++-
 2 files changed, 274 insertions(+), 260 deletions(-)

-- 
2.17.1