From: Matthias Kaehlcke <mka@chromium.org>
To: "Gaël PORTAY" <gael.portay@collabora.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org,
Derek Basehore <dbasehore@chromium.org>,
Heiko Stuebner <heiko@sntech.de>,
linux-pm@vger.kernel.org, Brian Norris <briannorris@chromium.org>,
Douglas Anderson <dianders@chromium.org>,
linux-kernel@vger.kernel.org,
Chanwoo Choi <cw00.choi@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Rob Herring <robh+dt@kernel.org>,
Klaus Goger <klaus.goger@theobroma-systems.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
linux-rockchip@lists.infradead.org, Randy Li <ayaka@soulik.info>,
kernel@collabora.com, linux-arm-kernel@lists.infradead.org,
Lin Huang <hl@rock-chips.com>
Subject: Re: [PATCH v2 3/5] devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.
Date: Tue, 26 Mar 2019 17:24:41 -0700 [thread overview]
Message-ID: <20190327002441.GB112750@google.com> (raw)
In-Reply-To: <20190322124525.ge5thq4a7c6ufcra@archlinux.localdomain>
On Fri, Mar 22, 2019 at 08:45:26AM -0400, Gaël PORTAY wrote:
> Hi Matthias,
>
> On Thu, Mar 21, 2019 at 05:01:07PM -0700, Matthias Kaehlcke wrote:
> > > ...
> > >
> > > So, for a reason that I ignore, if we try to save unecessary calls to
> > > ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD (odt_enable has not changed since
> > > last call), we get stalled in the call to ROCKCHIP_SIP_CONFIG_SET_RAGE
> > > that follows. The function arm_smccc_smc never returns and the device
> > > hard hang.
> >
> > Thanks for giving it a try!
> >
> > Did your code ensure to perform the SMC call for the first frequency
> > change? If not the problem could be that the DDR PD timings and ODT
> > resistors are not properly configured for the new frequency.
> >
>
> The DRAM_ODT_PD SMC call is supposed to be performed before the
> DRAM_SET_RATE; unless someone else is doing the set_rate.
However earlier the call wasn't done at all, and that didn't cause
problems.
> Does the ODT resistors should be configured for every existing
> frequency?
I don't have any background here. My initial assumption would be that
it should be enough to re-configure them when the frequency passes the
threshold in either direction.
Anyway, IIUC there shouldn't be more than 5 frequency changes per
second (polling_ms = 200), and likely no all of them would pass the
threshold, so it seems limiting the calls (if possible) would be a
micro-optimization and is probably not worth the hassle :)
Thanks
Matthias
WARNING: multiple messages have this Message-ID (diff)
From: Matthias Kaehlcke <mka@chromium.org>
To: "Gaël PORTAY" <gael.portay@collabora.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org,
Derek Basehore <dbasehore@chromium.org>,
Heiko Stuebner <heiko@sntech.de>,
linux-pm@vger.kernel.org, Brian Norris <briannorris@chromium.org>,
Douglas Anderson <dianders@chromium.org>,
linux-kernel@vger.kernel.org,
Chanwoo Choi <cw00.choi@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Rob Herring <robh+dt@kernel.org>,
Klaus Goger <klaus.goger@theobroma-systems.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
linux-rockchip@lists.infradead.org, Randy Li <ayaka@soulik.info>,
kernel@collabora.com, linux-arm-kernel@lists.infradead.org,
Lin Huang <hl@rock-chips.com>
Subject: Re: [PATCH v2 3/5] devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.
Date: Tue, 26 Mar 2019 17:24:41 -0700 [thread overview]
Message-ID: <20190327002441.GB112750@google.com> (raw)
In-Reply-To: <20190322124525.ge5thq4a7c6ufcra@archlinux.localdomain>
On Fri, Mar 22, 2019 at 08:45:26AM -0400, Gaël PORTAY wrote:
> Hi Matthias,
>
> On Thu, Mar 21, 2019 at 05:01:07PM -0700, Matthias Kaehlcke wrote:
> > > ...
> > >
> > > So, for a reason that I ignore, if we try to save unecessary calls to
> > > ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD (odt_enable has not changed since
> > > last call), we get stalled in the call to ROCKCHIP_SIP_CONFIG_SET_RAGE
> > > that follows. The function arm_smccc_smc never returns and the device
> > > hard hang.
> >
> > Thanks for giving it a try!
> >
> > Did your code ensure to perform the SMC call for the first frequency
> > change? If not the problem could be that the DDR PD timings and ODT
> > resistors are not properly configured for the new frequency.
> >
>
> The DRAM_ODT_PD SMC call is supposed to be performed before the
> DRAM_SET_RATE; unless someone else is doing the set_rate.
However earlier the call wasn't done at all, and that didn't cause
problems.
> Does the ODT resistors should be configured for every existing
> frequency?
I don't have any background here. My initial assumption would be that
it should be enough to re-configure them when the frequency passes the
threshold in either direction.
Anyway, IIUC there shouldn't be more than 5 frequency changes per
second (polling_ms = 200), and likely no all of them would pass the
threshold, so it seems limiting the calls (if possible) would be a
micro-optimization and is probably not worth the hassle :)
Thanks
Matthias
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-03-27 0:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-19 18:13 [PATCH v2 0/5] Add support for drm/rockchip to dynamically control the DDR frequency Gaël PORTAY
2019-03-19 18:13 ` Gaël PORTAY
2019-03-19 18:13 ` [PATCH v2 1/5] devfreq: rockchip-dfi: Move GRF definitions to a common place Gaël PORTAY
2019-03-19 18:13 ` Gaël PORTAY
2019-03-19 18:13 ` [PATCH v2 2/5] dt-bindings: devfreq: rk3399_dmc: Add rockchip, pmu phandle Gaël PORTAY
2019-03-19 18:13 ` Gaël PORTAY
2019-03-19 18:13 ` [PATCH v2 3/5] devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A Gaël PORTAY
2019-03-19 18:13 ` Gaël PORTAY
2019-03-20 0:33 ` Matthias Kaehlcke
2019-03-20 0:33 ` Matthias Kaehlcke
2019-03-20 21:50 ` Gaël PORTAY
2019-03-20 21:50 ` Gaël PORTAY
2019-03-20 22:02 ` Matthias Kaehlcke
2019-03-20 22:02 ` Matthias Kaehlcke
2019-03-21 23:10 ` Gaël PORTAY
2019-03-21 23:10 ` Gaël PORTAY
2019-03-22 0:01 ` Matthias Kaehlcke
2019-03-22 0:01 ` Matthias Kaehlcke
2019-03-22 12:45 ` Gaël PORTAY
2019-03-22 12:45 ` Gaël PORTAY
2019-03-27 0:24 ` Matthias Kaehlcke [this message]
2019-03-27 0:24 ` Matthias Kaehlcke
2019-03-19 18:13 ` [PATCH v2 4/5] arm64: dts: rk3399: Add dfi and dmc nodes Gaël PORTAY
2019-03-19 18:13 ` Gaël PORTAY
2019-03-19 18:13 ` [PATCH v2 5/5] arm64: dts: rockchip: Enable dmc and dfi nodes on gru Gaël PORTAY
2019-03-19 18:13 ` Gaël PORTAY
2019-03-20 5:05 ` Chanwoo Choi
2019-03-20 5:05 ` Chanwoo Choi
2019-03-20 18:35 ` Gaël PORTAY
2019-03-20 18:35 ` Gaël PORTAY
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=20190327002441.GB112750@google.com \
--to=mka@chromium.org \
--cc=ayaka@soulik.info \
--cc=briannorris@chromium.org \
--cc=cw00.choi@samsung.com \
--cc=dbasehore@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=enric.balletbo@collabora.com \
--cc=gael.portay@collabora.com \
--cc=heiko@sntech.de \
--cc=hl@rock-chips.com \
--cc=kernel@collabora.com \
--cc=klaus.goger@theobroma-systems.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=myungjoo.ham@samsung.com \
--cc=robh+dt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.