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>,
Rob Herring <robh+dt@kernel.org>,
linux-kernel@vger.kernel.org,
Chanwoo Choi <cw00.choi@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Klaus Goger <klaus.goger@theobroma-systems.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: Wed, 20 Mar 2019 15:02:23 -0700 [thread overview]
Message-ID: <20190320220223.GP112750@google.com> (raw)
In-Reply-To: <20190320215013.43zgvyn5frnb3yud@archlinux.localdomain>
Hi Gaël,
On Wed, Mar 20, 2019 at 05:50:13PM -0400, Gaël PORTAY wrote:
> Hi Matthias,
>
> On Tue, Mar 19, 2019 at 05:33:52PM -0700, Matthias Kaehlcke wrote:
> > ...
> > > @@ -95,6 +103,19 @@ static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
> > >
> > > mutex_lock(&dmcfreq->lock);
> > >
> > > + if (target_rate >= dmcfreq->odt_dis_freq)
> > > + odt_enable = true;
> > > +
> > > + /*
> > > + * This makes a SMC call to the TF-A to set the DDR PD (power-down)
> > > + * timings and to enable or disable the ODT (on-die termination)
> > > + * resistors.
> > > + */
> > > + arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, dmcfreq->odt_pd_arg0,
> > > + dmcfreq->odt_pd_arg1,
> > > + ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD,
> > > + odt_enable, 0, 0, 0, &res);
> >
> > Is it necessary/desirable to make this call for every frequency
> > change? IIUC it should be only needed when odt_enable changes and the
> > driver could track the state. If the DDR frequency doesn't change too
> > often and the overhead of the call is small it shouldn't be really
> > important though.
> >
>
> I will test your solution first to make sure there is no regression to
> run that call for frequency change only.
If there is no frequency change the function returns at the
beginning. My suggestion was to only do the call when 'odt_enable'
changes, i.e. when a change (up or down) passes the 'odt_dis_freq'
threshold.
> Also, the call takes around 300us.
Thanks for the info!
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: Wed, 20 Mar 2019 15:02:23 -0700 [thread overview]
Message-ID: <20190320220223.GP112750@google.com> (raw)
In-Reply-To: <20190320215013.43zgvyn5frnb3yud@archlinux.localdomain>
Hi Gaël,
On Wed, Mar 20, 2019 at 05:50:13PM -0400, Gaël PORTAY wrote:
> Hi Matthias,
>
> On Tue, Mar 19, 2019 at 05:33:52PM -0700, Matthias Kaehlcke wrote:
> > ...
> > > @@ -95,6 +103,19 @@ static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
> > >
> > > mutex_lock(&dmcfreq->lock);
> > >
> > > + if (target_rate >= dmcfreq->odt_dis_freq)
> > > + odt_enable = true;
> > > +
> > > + /*
> > > + * This makes a SMC call to the TF-A to set the DDR PD (power-down)
> > > + * timings and to enable or disable the ODT (on-die termination)
> > > + * resistors.
> > > + */
> > > + arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, dmcfreq->odt_pd_arg0,
> > > + dmcfreq->odt_pd_arg1,
> > > + ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD,
> > > + odt_enable, 0, 0, 0, &res);
> >
> > Is it necessary/desirable to make this call for every frequency
> > change? IIUC it should be only needed when odt_enable changes and the
> > driver could track the state. If the DDR frequency doesn't change too
> > often and the overhead of the call is small it shouldn't be really
> > important though.
> >
>
> I will test your solution first to make sure there is no regression to
> run that call for frequency change only.
If there is no frequency change the function returns at the
beginning. My suggestion was to only do the call when 'odt_enable'
changes, i.e. when a change (up or down) passes the 'odt_dis_freq'
threshold.
> Also, the call takes around 300us.
Thanks for the info!
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-20 22:02 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 [this message]
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
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=20190320220223.GP112750@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.