linux-samsung-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Kamil Konieczny <k.konieczny@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>
Subject: [PATCH v2 0/2] Exynos5422: fix bus related OPPs for Odroid XU3/XU4/HC1
Date: Thu, 19 Dec 2019 11:51:28 +0100	[thread overview]
Message-ID: <20191219105130.29394-1-m.szyprowski@samsung.com> (raw)
In-Reply-To: CGME20191219105135eucas1p1f11713cb6c1583524ca8af0ba6a7e145@eucas1p1.samsung.com

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


       reply	other threads:[~2019-12-19 10:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20191219105135eucas1p1f11713cb6c1583524ca8af0ba6a7e145@eucas1p1.samsung.com>
2019-12-19 10:51 ` Marek Szyprowski [this message]
     [not found]   ` <CGME20191219105136eucas1p1edadfa2fba7f15ec03f0eec7570809ce@eucas1p1.samsung.com>
2019-12-19 10:51     ` [PATCH v2 1/2] ARM: dts: exynos: Move bus related OPPs to the boards DTS Marek Szyprowski
2019-12-19 20:24       ` Krzysztof Kozlowski
     [not found]   ` <CGME20191219105136eucas1p1d57974e96a166308b4a692d1783936f8@eucas1p1.samsung.com>
2019-12-19 10:51     ` [PATCH v2 2/2] ARM: dts: exynos: Adjust bus related OPPs to the values correct for Odroids Marek Szyprowski
2019-12-19 20:24       ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191219105130.29394-1-m.szyprowski@samsung.com \
    --to=m.szyprowski@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=cw00.choi@samsung.com \
    --cc=k.konieczny@samsung.com \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).