Bump. I saw your email in Sibi's patch series. His patch series is
just one use case/user of this feature. This patch series is useful in
general. Do plan to Ack this? Or thoughts on my earlier response?
Thanks,
Saravana
On Fri, Jun 28, 2019 at 1:26 PM Saravana Kannan wrote:
>
> On Thu, Jun 27,
On Thu, Jun 27, 2019 at 11:49 PM Viresh Kumar wrote:
>
> On 26-06-19, 11:10, Saravana Kannan wrote:
> > On Tue, Jun 25, 2019 at 11:32 PM Viresh Kumar
> > wrote:
>
> > > So, when a CPU changes frequency, we must change the performance state
> > > of PM domain and change frequency/bw of the cache
On 26-06-19, 11:10, Saravana Kannan wrote:
> On Tue, Jun 25, 2019 at 11:32 PM Viresh Kumar wrote:
> > So, when a CPU changes frequency, we must change the performance state
> > of PM domain and change frequency/bw of the cache synchronously.
>
> I mean, it's going to be changed when we get the C
On Tue, Jun 25, 2019 at 11:32 PM Viresh Kumar wrote:
>
> On 24-06-19, 22:29, Saravana Kannan wrote:
> > No, the CPUs will be the "parent" and the cache will be the "child".
> > CPU is a special case when it comes to the actual software (not DT) as
> > we'll need the devfreq governor to look at all
On 24-06-19, 22:29, Saravana Kannan wrote:
> No, the CPUs will be the "parent" and the cache will be the "child".
> CPU is a special case when it comes to the actual software (not DT) as
> we'll need the devfreq governor to look at all the CPUfreq policies to
> decide the cache frequency (max of al
On Mon, Jun 24, 2019 at 10:22 PM Viresh Kumar wrote:
>
> On 24-06-19, 22:00, Saravana Kannan wrote:
> > All of the cases above are some real world scenarios I've come across.
> > CPU and L2/L3 on ARM systems are a good example of (2) but the passive
> > governor doesn't work with CPUs yet. But I p
On 24-06-19, 22:00, Saravana Kannan wrote:
> All of the cases above are some real world scenarios I've come across.
> CPU and L2/L3 on ARM systems are a good example of (2) but the passive
> governor doesn't work with CPUs yet. But I plan to work on that later
> as that's not related to this patch
On Mon, Jun 24, 2019 at 9:11 PM Viresh Kumar wrote:
>
> On 24-06-19, 15:17, Saravana Kannan wrote:
> > Here's an example. This can't be done today, but can be done with this
> > change.
> >
> > In arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi you have something
> > like this with the following c
On 24-06-19, 15:17, Saravana Kannan wrote:
> Here's an example. This can't be done today, but can be done with this change.
>
> In arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi you have something
> like this with the following changes:
>
> bus_g2d_400: bus0 {
> compatible
On Mon, Jun 24, 2019 at 2:43 AM Viresh Kumar wrote:
>
> On 21-06-19, 17:34, Saravana Kannan wrote:
> > The devfreq passive governor scales the frequency of a "child" device
> > based on the current frequency of a "parent" device (not parent/child in
> > the sense of device hierarchy). As of today,
On 21-06-19, 17:34, Saravana Kannan wrote:
> The devfreq passive governor scales the frequency of a "child" device
> based on the current frequency of a "parent" device (not parent/child in
> the sense of device hierarchy). As of today, the passive governor
> requires one of the following to work c
The devfreq passive governor scales the frequency of a "child" device
based on the current frequency of a "parent" device (not parent/child in
the sense of device hierarchy). As of today, the passive governor
requires one of the following to work correctly:
1. The parent and child device have the s
12 matches
Mail list logo
