From: Prashant Gaikwad <pgaikwad@nvidia.com> To: linux-arm-kernel@lists.infradead.org Subject: Re: Device tree binding for DVFS table Date: Fri, 13 Jul 2012 18:42:14 +0000 [thread overview] Message-ID: <50006935.2080606@nvidia.com> (raw) In-Reply-To: <4FFE4DD0.7020407@nvidia.com> Hi, On Thursday 12 July 2012 09:38 AM, Prashant Gaikwad wrote: > On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote: >> On 07/11/2012 07:56 AM, Prashant Gaikwad wrote: >>> Hi, >>> >>> I am working on DT binding for Tegra DVFS. <snip> >>> compatible = "nvidia,tegra30-dvfs-table"; >>> reg_id =<&sm0>; >>> #address-cells =<1>; >>> #size-cells =<0>; >>> voltage-array =<750 775 800 825 850 875 900 925 950 975 >>> 1000 1025 1050 1100 1125>; >> The SOC is really characterized at all these voltages? > > Not really, but different processes of single SoC are characterized > for different voltages and this array covers all those voltages. > >>> }; >>> >>> device { >>> dvfs =<&cpu-dvfs-table>; >>> frequency-table@102 { >>> reg =<0x102>; >>> frequencies =<314 314 314 456 456 456 608 608 >>> 608 >>> 760 817 817 912 1000>; >> I don't see the point of repeating frequencies. >>> }; >>> frequency-table@002 { >>> reg =<0x002>; >>> frequencies =<598 598 750 750 893 893 1000>; >>> }; >> How do you determine the voltage for a frequency on table 2? >> >> I'd expect a single property with freq/volt pairs or 2 properties for >> freq and voltage where there is a 1:1 relationship (freq N uses >> voltage N). > > > How this will work: > > voltage-array =<750 775 800 825 850 875 900 925 950 975 1000 1025 > 1050 1100 1125> > frequencies-1 =<314 314 314 456 456 456 608 608 608 760 817 817 > 912 1000>; > frequencies-2 =<598 598 750 750 893 893 1000>; > > > Freq and voltage has 1:1 relationship but as single voltage table is > used for different processes we have more entries in voltage table > than freq table. > Frequency table 1 is mapped till 1100mV while frequency table 2 is > mapped till 900mV only, it maintains 1:1 relationship. > > About repeating frequencies, operating voltage for a frequency would > be the highest one mapped in the table. > For example, in frequency table 2 operating voltage for 750MHz would > be 825mV while for 893MHz it would be 875mV. Unmapped entries could be > replaced with 0 to make reading better. > > Advantage it provides is single voltage table used for multiple > frequency tables, as can be observed from above tables, operating > voltage for 314MHz in freq table 1 is 800mV while there is no > frequency in table 2 at that voltage. > > I know this makes reading difficult but it provides flexibility, > > I hope it explains the implementation. > Does this explanation help? Regards, Prashant G >> Rob >> >>> }; >>> >>> Thanks& Regards, >>> Prashant G >>> >>> _______________________________________________ >>> linux-arm-kernel mailing list >>> linux-arm-kernel@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> >
WARNING: multiple messages have this Message-ID (diff)
From: pgaikwad@nvidia.com (Prashant Gaikwad) To: linux-arm-kernel@lists.infradead.org Subject: Device tree binding for DVFS table Date: Sat, 14 Jul 2012 00:00:14 +0530 [thread overview] Message-ID: <50006935.2080606@nvidia.com> (raw) In-Reply-To: <4FFE4DD0.7020407@nvidia.com> Hi, On Thursday 12 July 2012 09:38 AM, Prashant Gaikwad wrote: > On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote: >> On 07/11/2012 07:56 AM, Prashant Gaikwad wrote: >>> Hi, >>> >>> I am working on DT binding for Tegra DVFS. <snip> >>> compatible = "nvidia,tegra30-dvfs-table"; >>> reg_id =<&sm0>; >>> #address-cells =<1>; >>> #size-cells =<0>; >>> voltage-array =<750 775 800 825 850 875 900 925 950 975 >>> 1000 1025 1050 1100 1125>; >> The SOC is really characterized at all these voltages? > > Not really, but different processes of single SoC are characterized > for different voltages and this array covers all those voltages. > >>> }; >>> >>> device { >>> dvfs =<&cpu-dvfs-table>; >>> frequency-table at 102 { >>> reg =<0x102>; >>> frequencies =<314 314 314 456 456 456 608 608 >>> 608 >>> 760 817 817 912 1000>; >> I don't see the point of repeating frequencies. >>> }; >>> frequency-table at 002 { >>> reg =<0x002>; >>> frequencies =<598 598 750 750 893 893 1000>; >>> }; >> How do you determine the voltage for a frequency on table 2? >> >> I'd expect a single property with freq/volt pairs or 2 properties for >> freq and voltage where there is a 1:1 relationship (freq N uses >> voltage N). > > > How this will work: > > voltage-array =<750 775 800 825 850 875 900 925 950 975 1000 1025 > 1050 1100 1125> > frequencies-1 =<314 314 314 456 456 456 608 608 608 760 817 817 > 912 1000>; > frequencies-2 =<598 598 750 750 893 893 1000>; > > > Freq and voltage has 1:1 relationship but as single voltage table is > used for different processes we have more entries in voltage table > than freq table. > Frequency table 1 is mapped till 1100mV while frequency table 2 is > mapped till 900mV only, it maintains 1:1 relationship. > > About repeating frequencies, operating voltage for a frequency would > be the highest one mapped in the table. > For example, in frequency table 2 operating voltage for 750MHz would > be 825mV while for 893MHz it would be 875mV. Unmapped entries could be > replaced with 0 to make reading better. > > Advantage it provides is single voltage table used for multiple > frequency tables, as can be observed from above tables, operating > voltage for 314MHz in freq table 1 is 800mV while there is no > frequency in table 2 at that voltage. > > I know this makes reading difficult but it provides flexibility, > > I hope it explains the implementation. > Does this explanation help? Regards, Prashant G >> Rob >> >>> }; >>> >>> Thanks& Regards, >>> Prashant G >>> >>> _______________________________________________ >>> linux-arm-kernel mailing list >>> linux-arm-kernel at lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> >
next prev parent reply other threads:[~2012-07-13 18:42 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-11 12:56 Device tree binding for DVFS table Prashant Gaikwad 2012-07-11 13:08 ` Prashant Gaikwad 2012-07-11 14:03 ` Rob Herring 2012-07-11 14:03 ` Rob Herring 2012-07-11 14:44 ` Mark Brown 2012-07-11 14:44 ` Mark Brown 2012-07-11 20:04 ` Mike Turquette 2012-07-11 20:04 ` Mike Turquette 2012-07-12 4:14 ` Prashant Gaikwad 2012-07-12 4:26 ` Prashant Gaikwad 2012-07-12 14:10 ` Peter De Schrijver 2012-07-12 14:10 ` Peter De Schrijver 2012-07-12 17:10 ` Mike Turquette 2012-07-12 17:10 ` Mike Turquette 2012-07-12 17:15 ` Mark Brown 2012-07-12 17:15 ` Mark Brown 2012-07-13 10:34 ` Peter De Schrijver 2012-07-13 10:34 ` Peter De Schrijver 2012-07-13 17:25 ` Mike Turquette 2012-07-13 17:25 ` Mike Turquette 2012-07-12 4:17 ` Prashant Gaikwad 2012-07-12 4:29 ` Prashant Gaikwad 2012-07-12 15:23 ` Mark Brown 2012-07-12 15:23 ` Mark Brown 2012-07-12 17:01 ` Mike Turquette 2012-07-12 17:01 ` Mike Turquette 2012-07-12 8:19 ` Peter De Schrijver 2012-07-12 8:19 ` Peter De Schrijver 2012-07-12 4:08 ` Prashant Gaikwad 2012-07-12 4:20 ` Prashant Gaikwad 2012-07-13 18:30 ` Prashant Gaikwad [this message] 2012-07-13 18:42 ` Prashant Gaikwad 2012-07-15 21:40 ` Mark Brown 2012-07-15 21:40 ` Mark Brown 2012-07-15 23:42 ` Rob Herring 2012-07-15 23:42 ` Rob Herring 2012-07-16 18:36 ` Turquette, Mike 2012-07-16 18:36 ` Turquette, Mike 2012-07-17 12:37 ` Prashant Gaikwad 2012-07-17 12:49 ` Prashant Gaikwad 2012-07-17 13:20 ` Mark Brown 2012-07-17 13:20 ` Mark Brown 2012-07-17 14:22 ` Prashant Gaikwad 2012-07-17 14:34 ` Prashant Gaikwad 2012-07-17 14:37 ` Mark Brown 2012-07-17 14:37 ` Mark Brown 2012-07-18 12:46 ` Prashant Gaikwad 2012-07-18 12:58 ` Prashant Gaikwad 2012-07-18 21:19 ` Mark Brown 2012-07-18 21:19 ` Mark Brown 2012-07-18 17:08 ` Shawn Guo 2012-07-18 17:08 ` Shawn Guo 2012-07-11 13:08 함명주 2012-07-11 13:08 ` 함명주 2012-07-11 13:49 ` Peter De Schrijver 2012-07-11 13:49 ` Peter De Schrijver 2012-07-11 13:49 ` Peter De Schrijver 2012-07-11 13:49 ` Peter De Schrijver 2012-07-12 4:22 ` Prashant Gaikwad 2012-07-12 4:34 ` Prashant Gaikwad
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=50006935.2080606@nvidia.com \ --to=pgaikwad@nvidia.com \ --cc=linux-arm-kernel@lists.infradead.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: linkBe 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.