Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-25 Thread Qais Yousef
On 06/24/20 11:29, Doug Anderson wrote: > Hi, > > On Wed, Jun 24, 2020 at 10:55 AM Joel Fernandes wrote: > > > > On Wed, Jun 24, 2020 at 1:52 PM Qais Yousef wrote: > > > > > > On 06/24/20 13:35, Joel Fernandes wrote: > > > > > > [...] > > > > > > > > Doing the in-kernel opt-out via API should

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-24 Thread Doug Anderson
Hi, On Wed, Jun 24, 2020 at 10:55 AM Joel Fernandes wrote: > > On Wed, Jun 24, 2020 at 1:52 PM Qais Yousef wrote: > > > > On 06/24/20 13:35, Joel Fernandes wrote: > > > > [...] > > > > > > Doing the in-kernel opt-out via API should be fine, I think. But this > > > > will > > > > need to be

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-24 Thread Joel Fernandes
On Wed, Jun 24, 2020 at 1:52 PM Qais Yousef wrote: > > On 06/24/20 13:35, Joel Fernandes wrote: > > [...] > > > > Doing the in-kernel opt-out via API should be fine, I think. But this will > > > need to be discussed in the wider circle. It will already clash with this > > > for > > > example > >

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-24 Thread Qais Yousef
On 06/24/20 13:35, Joel Fernandes wrote: [...] > > Doing the in-kernel opt-out via API should be fine, I think. But this will > > need to be discussed in the wider circle. It will already clash with this > > for > > example > > > >

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-24 Thread Joel Fernandes
On Wed, Jun 24, 2020 at 12:55 PM Qais Yousef wrote: > > On 06/24/20 11:49, Joel Fernandes wrote: > > On Tue, Jun 23, 2020 at 12:40 PM Qais Yousef wrote: > > > > > > On 06/22/20 11:21, Doug Anderson wrote: > > > > > > [...] > > > > > > > > If you propose something that will help the discussion. I

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-24 Thread Qais Yousef
On 06/24/20 18:01, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 05:40:21PM +0100, Qais Yousef wrote: > > On 06/22/20 11:21, Doug Anderson wrote: > > > > [...] > > > > > > If you propose something that will help the discussion. I think based > > > > on the > > > > same approach Peter has

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-24 Thread Qais Yousef
On 06/24/20 11:49, Joel Fernandes wrote: > On Tue, Jun 23, 2020 at 12:40 PM Qais Yousef wrote: > > > > On 06/22/20 11:21, Doug Anderson wrote: > > > > [...] > > > > > > If you propose something that will help the discussion. I think based > > > > on the > > > > same approach Peter has taken to

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-24 Thread Peter Zijlstra
On Tue, Jun 23, 2020 at 05:40:21PM +0100, Qais Yousef wrote: > On 06/22/20 11:21, Doug Anderson wrote: > > [...] > > > > If you propose something that will help the discussion. I think based on > > > the > > > same approach Peter has taken to prevent random RT priorities. In uclamp > > > case

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-24 Thread Peter Zijlstra
On Thu, Jun 18, 2020 at 02:18:23PM -0700, Doug Anderson wrote: > Hi, > > On Fri, Jun 12, 2020 at 5:52 AM Qais Yousef wrote: > > > > On 06/10/20 15:18, Douglas Anderson wrote: > > > + struct sched_attr sched_attr = { > > > + .sched_policy = SCHED_FIFO, > > > +

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-24 Thread Joel Fernandes
On Tue, Jun 23, 2020 at 12:40 PM Qais Yousef wrote: > > On 06/22/20 11:21, Doug Anderson wrote: > > [...] > > > > If you propose something that will help the discussion. I think based on > > > the > > > same approach Peter has taken to prevent random RT priorities. In uclamp > > > case > > > I

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-23 Thread Qais Yousef
On 06/22/20 11:21, Doug Anderson wrote: [...] > > If you propose something that will help the discussion. I think based on the > > same approach Peter has taken to prevent random RT priorities. In uclamp > > case > > I think we just want to allow driver to opt RT tasks out of the default > >

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-23 Thread Qais Yousef
On 06/22/20 11:19, Doug Anderson wrote: [...] > > Hmm I thought OEMs who ship stuff that are based on Chrome OS would have to > > do > > the final tuning here, which would be based on the recommendation of the SoC > > vendor. And I'm being overly generic here to think not only SoC from Intel >

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-22 Thread Doug Anderson
Hi, On Fri, Jun 19, 2020 at 8:38 AM Qais Yousef wrote: > > On 06/18/20 14:18, Doug Anderson wrote: > > Hi, > > > > On Fri, Jun 12, 2020 at 5:52 AM Qais Yousef wrote: > > > > > > On 06/10/20 15:18, Douglas Anderson wrote: > > > > The cros_ec_spi driver is realtime priority so that it doesn't get

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-22 Thread Doug Anderson
Hi, On Fri, Jun 19, 2020 at 8:31 AM Qais Yousef wrote: > > Hi Doug, > > On 06/18/20 14:31, Doug Anderson wrote: > > Hi, > > > > On Fri, Jun 12, 2020 at 5:34 AM Qais Yousef wrote: > > > > > > On 06/12/20 10:24, Quentin Perret wrote: > > > > +CC Qais [FYI] > > > > > > Thanks for the CC. > > > > >

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-19 Thread Qais Yousef
On 06/18/20 14:18, Doug Anderson wrote: > Hi, > > On Fri, Jun 12, 2020 at 5:52 AM Qais Yousef wrote: > > > > On 06/10/20 15:18, Douglas Anderson wrote: > > > The cros_ec_spi driver is realtime priority so that it doesn't get > > > preempted by other taks while it's talking to the EC but overall

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-19 Thread Qais Yousef
Hi Doug, On 06/18/20 14:31, Doug Anderson wrote: > Hi, > > On Fri, Jun 12, 2020 at 5:34 AM Qais Yousef wrote: > > > > On 06/12/20 10:24, Quentin Perret wrote: > > > +CC Qais [FYI] > > > > Thanks for the CC. > > > > > > > > On Thursday 11 Jun 2020 at 10:48:40 (-0700), Doug Anderson wrote: > > >

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-18 Thread Doug Anderson
Hi, On Fri, Jun 12, 2020 at 5:34 AM Qais Yousef wrote: > > On 06/12/20 10:24, Quentin Perret wrote: > > +CC Qais [FYI] > > Thanks for the CC. > > > > > On Thursday 11 Jun 2020 at 10:48:40 (-0700), Doug Anderson wrote: > > > Hrm. I guess my first instinct is to say that we still want this > > >

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-18 Thread Doug Anderson
Hi, On Fri, Jun 12, 2020 at 5:52 AM Qais Yousef wrote: > > On 06/10/20 15:18, Douglas Anderson wrote: > > The cros_ec_spi driver is realtime priority so that it doesn't get > > preempted by other taks while it's talking to the EC but overall it > > really doesn't need lots of compute power.

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-12 Thread Qais Yousef
On 06/12/20 14:47, Quentin Perret wrote: [...] > > > > somehow measure whether or not the task is making its deadlines and > > > > boost the CPU frequency up if deadlines are not being met. I'm sure > > > > there are fancier ways. > > > > You need to use SCHED_DEADLINE then :) > > Well, not

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-12 Thread Quentin Perret
On Friday 12 Jun 2020 at 13:34:48 (+0100), Qais Yousef wrote: > > On Thursday 11 Jun 2020 at 10:48:40 (-0700), Doug Anderson wrote: > > > I'm not totally a fan, but I'm definitely not an expert in this area > > > (I've also only read the patch description and not the patch or the > > > whole

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-12 Thread Qais Yousef
On 06/10/20 15:18, Douglas Anderson wrote: > The cros_ec_spi driver is realtime priority so that it doesn't get > preempted by other taks while it's talking to the EC but overall it > really doesn't need lots of compute power. Unfortunately, by default, > the kernel assumes that all realtime

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-12 Thread Qais Yousef
On 06/12/20 10:24, Quentin Perret wrote: > +CC Qais [FYI] Thanks for the CC. > > On Thursday 11 Jun 2020 at 10:48:40 (-0700), Doug Anderson wrote: > > Hrm. I guess my first instinct is to say that we still want this > > patch even if we have something that is applied more globally. > > Fair

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-12 Thread Quentin Perret
+CC Qais [FYI] On Thursday 11 Jun 2020 at 10:48:40 (-0700), Doug Anderson wrote: > Hrm. I guess my first instinct is to say that we still want this > patch even if we have something that is applied more globally. Fair enough. > Specifically it sounds as if the patch you point at is suggesting

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-11 Thread Doug Anderson
Hi, On Thu, Jun 11, 2020 at 4:03 AM Quentin Perret wrote: > > Hi Doug, > > On Wednesday 10 Jun 2020 at 15:18:43 (-0700), Douglas Anderson wrote: > > The cros_ec_spi driver is realtime priority so that it doesn't get > > preempted by other taks while it's talking to the EC but overall it > >

Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-11 Thread Quentin Perret
Hi Doug, On Wednesday 10 Jun 2020 at 15:18:43 (-0700), Douglas Anderson wrote: > The cros_ec_spi driver is realtime priority so that it doesn't get > preempted by other taks while it's talking to the EC but overall it > really doesn't need lots of compute power. Unfortunately, by default, > the

[PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq

2020-06-10 Thread Douglas Anderson
The cros_ec_spi driver is realtime priority so that it doesn't get preempted by other taks while it's talking to the EC but overall it really doesn't need lots of compute power. Unfortunately, by default, the kernel assumes that all realtime tasks should cause the cpufreq to jump to max and burn