On 19-10-20, 14:36, Nicola Mazzucato wrote:
> Hi Viresh,
>
>
> On 10/19/20 10:46 AM, Viresh Kumar wrote:
> > On 19-10-20, 09:50, Nicola Mazzucato wrote:
> >> Hi Viresh,
> >>
> >> thank you for your suggestion on using 'opp-shared'.
> >> I think it could work for most of the cases we explained
Hi Viresh,
On 10/19/20 10:46 AM, Viresh Kumar wrote:
> On 19-10-20, 09:50, Nicola Mazzucato wrote:
>> Hi Viresh,
>>
>> thank you for your suggestion on using 'opp-shared'.
>> I think it could work for most of the cases we explained earlier.
>>
>> Summarising, there are two parts of this entire
On 19-10-20, 09:50, Nicola Mazzucato wrote:
> Hi Viresh,
>
> thank you for your suggestion on using 'opp-shared'.
> I think it could work for most of the cases we explained earlier.
>
> Summarising, there are two parts of this entire proposal:
> 1) where/how to get the information: now we are
Hi Viresh,
thank you for your suggestion on using 'opp-shared'.
I think it could work for most of the cases we explained earlier.
Summarising, there are two parts of this entire proposal:
1) where/how to get the information: now we are focusing on taking advantage of
'opp-shared' within an empty
Hi Rafael,
Sorry in advance for the long writing. I hope it makes sense.
On Thursday 15 Oct 2020 at 17:56:56 (+0200), Rafael J. Wysocki wrote:
> On Tue, Oct 13, 2020 at 2:39 PM Ionela Voinescu
> wrote:
> >
> > Hi Rafael,
> >
> > On Tuesday 13 Oct 2020 at 13:53:37 (+0200), Rafael J. Wysocki
On Tue, Oct 13, 2020 at 2:39 PM Ionela Voinescu wrote:
>
> Hi Rafael,
>
> On Tuesday 13 Oct 2020 at 13:53:37 (+0200), Rafael J. Wysocki wrote:
> > On Tue, Oct 13, 2020 at 12:01 AM Ionela Voinescu
> > wrote:
> > >
> > > Hey Lukasz,
> > >
> > > I think after all this discussion (in our own way of
On 13-10-20, 14:53, Lukasz Luba wrote:
> I've started wondering based on the OPP code if this is a good solution.
> We would end up with one (?) instance of opp_table and list of devices
> pinned to it, in: opp_table->dev_list
> It can be seen e.g. in function dev_pm_opp_get_sharing_cpus(),
>
On 10/14/20 5:25 AM, Viresh Kumar wrote:
On 12-10-20, 18:18, Lukasz Luba wrote:
On 10/12/20 5:52 PM, Ionela Voinescu wrote:
On Monday 12 Oct 2020 at 16:49:30 (+0100), Sudeep Holla wrote:
On Fri, Oct 09, 2020 at 11:09:21AM +0530, Viresh Kumar wrote:
- I wonder if we can keep using that
On 12-10-20, 18:18, Lukasz Luba wrote:
> On 10/12/20 5:52 PM, Ionela Voinescu wrote:
> > On Monday 12 Oct 2020 at 16:49:30 (+0100), Sudeep Holla wrote:
> > > On Fri, Oct 09, 2020 at 11:09:21AM +0530, Viresh Kumar wrote:
> > > > - I wonder if we can keep using that instead of creating new bindings
Hi Viresh,
On 10/9/20 6:39 AM, Viresh Kumar wrote:
Oh yes, I get it now. Finally. Thanks for helping me out :)
So if I can say all this stuff in simple terms, this is what it will
be like:
- We don't want software aggregation of frequencies and so we need to
have per-cpu policies even
Hi Rafael,
On Tuesday 13 Oct 2020 at 13:53:37 (+0200), Rafael J. Wysocki wrote:
> On Tue, Oct 13, 2020 at 12:01 AM Ionela Voinescu
> wrote:
> >
> > Hey Lukasz,
> >
> > I think after all this discussion (in our own way of describing things)
> > we agree on how the current cpufreq based FIE
On Tue, Oct 13, 2020 at 12:01 AM Ionela Voinescu
wrote:
>
> Hey Lukasz,
>
> I think after all this discussion (in our own way of describing things)
> we agree on how the current cpufreq based FIE implementation is affected
> in systems that use hardware coordination.
>
> What we don't agree on is
Hey Lukasz,
I think after all this discussion (in our own way of describing things)
we agree on how the current cpufreq based FIE implementation is affected
in systems that use hardware coordination.
What we don't agree on is the location where that implementation (that
uses the new mask and
On 10/12/20 5:30 PM, Ionela Voinescu wrote:
Hi Lukasz,
On Monday 12 Oct 2020 at 14:48:20 (+0100), Lukasz Luba wrote:
On 10/12/20 11:59 AM, Ionela Voinescu wrote:
On Monday 12 Oct 2020 at 11:22:57 (+0100), Lukasz Luba wrote:
[..]
I thought about it and looked for other platforms' DT to
On 10/12/20 5:52 PM, Ionela Voinescu wrote:
On Monday 12 Oct 2020 at 16:49:30 (+0100), Sudeep Holla wrote:
On Fri, Oct 09, 2020 at 11:09:21AM +0530, Viresh Kumar wrote:
On 08-10-20, 17:00, Nicola Mazzucato wrote:
On 10/8/20 4:03 PM, Ionela Voinescu wrote:
Hi Viresh,
On Thursday 08 Oct
On Monday 12 Oct 2020 at 16:49:30 (+0100), Sudeep Holla wrote:
> On Fri, Oct 09, 2020 at 11:09:21AM +0530, Viresh Kumar wrote:
> > On 08-10-20, 17:00, Nicola Mazzucato wrote:
> > > On 10/8/20 4:03 PM, Ionela Voinescu wrote:
> > > > Hi Viresh,
> > > >
> > > > On Thursday 08 Oct 2020 at 16:32:41
Hi Lukasz,
On Monday 12 Oct 2020 at 14:48:20 (+0100), Lukasz Luba wrote:
>
>
> On 10/12/20 11:59 AM, Ionela Voinescu wrote:
> > On Monday 12 Oct 2020 at 11:22:57 (+0100), Lukasz Luba wrote:
> > [..]
> > > > > I thought about it and looked for other platforms' DT to see if can
> > > > > reuse
>
On Thu, Oct 08, 2020 at 05:57:23PM +0200, Rafael J. Wysocki wrote:
> On Thu, Oct 8, 2020 at 5:03 PM Ionela Voinescu
> wrote:
[...]
>
> >The PSD domains (ACPI) and the new DT binding will tell
> >which CPUs are actually in the same clock domain for whomever is
> >interested, despite
On Mon, Oct 12, 2020 at 11:22:57AM +0100, Lukasz Luba wrote:
[...]
>
> True, the SCMI clock does not support discovery of clock tree:
> (from 4.6.1 Clock management protocol background)
> 'The protocol does not cover discovery of the clock tree, which must be
> described through firmware tables
On Fri, Oct 09, 2020 at 09:01:41AM -0500, Rob Herring wrote:
> On Fri, Oct 09, 2020 at 12:10:03PM +0100, Nicola Mazzucato wrote:
> > Hi Viresh, I'm glad it helped.
> >
> > Please find below my reply.
> >
> > On 10/9/20 6:39 AM, Viresh Kumar wrote:
> > > On 08-10-20, 17:00, Nicola Mazzucato wrote:
On Fri, Oct 09, 2020 at 11:09:21AM +0530, Viresh Kumar wrote:
> On 08-10-20, 17:00, Nicola Mazzucato wrote:
> > On 10/8/20 4:03 PM, Ionela Voinescu wrote:
> > > Hi Viresh,
> > >
> > > On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote:
> > >> On 07-10-20, 13:58, Nicola Mazzucato
+Stephen for clock issues
On Mon, Oct 12, 2020 at 5:23 AM Lukasz Luba wrote:
>
> Hi Rob,
>
> On 10/9/20 3:01 PM, Rob Herring wrote:
> > On Fri, Oct 09, 2020 at 12:10:03PM +0100, Nicola Mazzucato wrote:
> >> Hi Viresh, I'm glad it helped.
> >>
> >> Please find below my reply.
> >>
> >> On 10/9/20
On 10/12/20 11:59 AM, Ionela Voinescu wrote:
On Monday 12 Oct 2020 at 11:22:57 (+0100), Lukasz Luba wrote:
[..]
I thought about it and looked for other platforms' DT to see if can reuse
existing opp information. Unfortunately I don't think it is optimal. The reason
being that, because cpus
On 10/12/20 11:50 AM, Rafael J. Wysocki wrote:
On Mon, Oct 12, 2020 at 12:23 PM Lukasz Luba wrote:
Hi Rob,
On 10/9/20 3:01 PM, Rob Herring wrote:
On Fri, Oct 09, 2020 at 12:10:03PM +0100, Nicola Mazzucato wrote:
Hi Viresh, I'm glad it helped.
Please find below my reply.
On 10/9/20
On Monday 12 Oct 2020 at 11:22:57 (+0100), Lukasz Luba wrote:
[..]
> > > I thought about it and looked for other platforms' DT to see if can reuse
> > > existing opp information. Unfortunately I don't think it is optimal. The
> > > reason
> > > being that, because cpus have the same opp table it
On Mon, Oct 12, 2020 at 12:23 PM Lukasz Luba wrote:
>
> Hi Rob,
>
> On 10/9/20 3:01 PM, Rob Herring wrote:
> > On Fri, Oct 09, 2020 at 12:10:03PM +0100, Nicola Mazzucato wrote:
> >> Hi Viresh, I'm glad it helped.
> >>
> >> Please find below my reply.
> >>
> >> On 10/9/20 6:39 AM, Viresh Kumar
Hi Rob,
On 10/9/20 3:01 PM, Rob Herring wrote:
On Fri, Oct 09, 2020 at 12:10:03PM +0100, Nicola Mazzucato wrote:
Hi Viresh, I'm glad it helped.
Please find below my reply.
On 10/9/20 6:39 AM, Viresh Kumar wrote:
On 08-10-20, 17:00, Nicola Mazzucato wrote:
On 10/8/20 4:03 PM, Ionela
On 09-10-20, 16:28, Nicola Mazzucato wrote:
> @Viresh
> I am sorry I misread your reply earlier thus I did not pay attention on that
> property.
> And yes, it is exactly as how you have described :)
> In the case 1 (different opps, different clk) and case 2 (same opps, different
> clk) we provide
Hi Viresh and Rob,
first of all, thanks once again for looking into this!
On 10/9/20 3:01 PM, Rob Herring wrote:
> On Fri, Oct 09, 2020 at 12:10:03PM +0100, Nicola Mazzucato wrote:
>> Hi Viresh, I'm glad it helped.
>>
>> Please find below my reply.
>>
>> On 10/9/20 6:39 AM, Viresh Kumar wrote:
On Fri, Oct 09, 2020 at 12:10:03PM +0100, Nicola Mazzucato wrote:
> Hi Viresh, I'm glad it helped.
>
> Please find below my reply.
>
> On 10/9/20 6:39 AM, Viresh Kumar wrote:
> > On 08-10-20, 17:00, Nicola Mazzucato wrote:
> >> On 10/8/20 4:03 PM, Ionela Voinescu wrote:
> >>> Hi Viresh,
> >>>
>
On 09-10-20, 12:10, Nicola Mazzucato wrote:
> I thought about it and looked for other platforms' DT to see if can reuse
> existing opp information. Unfortunately I don't think it is optimal. The
> reason
> being that, because cpus have the same opp table it does not necessarily mean
> that they
Hi Viresh, I'm glad it helped.
Please find below my reply.
On 10/9/20 6:39 AM, Viresh Kumar wrote:
> On 08-10-20, 17:00, Nicola Mazzucato wrote:
>> On 10/8/20 4:03 PM, Ionela Voinescu wrote:
>>> Hi Viresh,
>>>
>>> On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote:
On 07-10-20,
On 08-10-20, 17:00, Nicola Mazzucato wrote:
> On 10/8/20 4:03 PM, Ionela Voinescu wrote:
> > Hi Viresh,
> >
> > On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote:
> >> On 07-10-20, 13:58, Nicola Mazzucato wrote:
> >>> Hi Viresh,
> >>>
> >>> performance controls is what is exposed by
Hi Rafael,
On Thursday 08 Oct 2020 at 17:57:23 (+0200), Rafael J. Wysocki wrote:
> On Thu, Oct 8, 2020 at 5:03 PM Ionela Voinescu
> wrote:
> >
> > Hi Viresh,
> >
> > On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote:
> > > On 07-10-20, 13:58, Nicola Mazzucato wrote:
> > > > Hi
Hi Viresh and Ionela,
@Viresh, I am sorry it's still not crystal clear, please find an example below.
@Ionela, thanks for adding more details.
On 10/8/20 4:03 PM, Ionela Voinescu wrote:
> Hi Viresh,
>
> On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote:
>> On 07-10-20, 13:58,
On Thu, Oct 8, 2020 at 5:03 PM Ionela Voinescu wrote:
>
> Hi Viresh,
>
> On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote:
> > On 07-10-20, 13:58, Nicola Mazzucato wrote:
> > > Hi Viresh,
> > >
> > > performance controls is what is exposed by the firmware through a
> > > protocol
Hi Viresh,
On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote:
> On 07-10-20, 13:58, Nicola Mazzucato wrote:
> > Hi Viresh,
> >
> > performance controls is what is exposed by the firmware through a protocol
> > that
> > is not capable of describing hardware (say SCMI). For example,
On 07-10-20, 13:58, Nicola Mazzucato wrote:
> Hi Viresh,
>
> performance controls is what is exposed by the firmware through a protocol
> that
> is not capable of describing hardware (say SCMI). For example, the firmware
> can
> tell that the platform has N controls, but it can't say to which
Hi Viresh,
performance controls is what is exposed by the firmware through a protocol that
is not capable of describing hardware (say SCMI). For example, the firmware can
tell that the platform has N controls, but it can't say to which hardware they
are "wired" to. This is done in dt, where, for
On 24-09-20, 10:53, Nicola Mazzucato wrote:
> I am seeking some feedback/comments on the following approach.
>
> Intro:
> Info of performance depency for cpus will be beneficial for systems
> where f/w description of the CPU performance control domain is different
> from the clock domain, e.g.
I am seeking some feedback/comments on the following approach.
Intro:
Info of performance depency for cpus will be beneficial for systems
where f/w description of the CPU performance control domain is different
from the clock domain, e.g. per-CPU control with multiple CPUs sharing
clock, and
41 matches
Mail list logo
