Quoting Nishanth Menon (2014-03-10 12:25:43)
> On 03/10/2014 01:01 PM, Mark Brown wrote:
> > On Mon, Mar 10, 2014 at 12:41:05PM -0500, Nishanth Menon wrote:
> >
> >> The only other options are:
> >> a) Abstract it at a higher level at "user drivers", since they are
> >> aware of the sequencing
Quoting Nishanth Menon (2014-03-10 12:25:43)
On 03/10/2014 01:01 PM, Mark Brown wrote:
On Mon, Mar 10, 2014 at 12:41:05PM -0500, Nishanth Menon wrote:
The only other options are:
a) Abstract it at a higher level at user drivers, since they are
aware of the sequencing needs - but this
On 03/10/2014 01:01 PM, Mark Brown wrote:
> On Mon, Mar 10, 2014 at 12:41:05PM -0500, Nishanth Menon wrote:
>
>> The only other options are:
>> a) Abstract it at a higher level at "user drivers", since they are
>> aware of the sequencing needs - but this partially defeats the
>> purpose, unless
On Mon, Mar 10, 2014 at 12:41:05PM -0500, Nishanth Menon wrote:
> The only other options are:
> a) Abstract it at a higher level at "user drivers", since they are
> aware of the sequencing needs - but this partially defeats the
> purpose, unless ofcourse, we do a tricky implementation such as:
>
On 03/10/2014 12:22 PM, Mark Brown wrote:
> On Mon, Mar 10, 2014 at 12:11:44PM -0500, Nishanth Menon wrote:
>> On 03/02/2014 09:54 PM, Mark Brown wrote:
>>> On Mon, Feb 24, 2014 at 08:38:07AM -0600, Nishanth Menon wrote:
>
Intent here is to allow drivers such as cpufreq-cpu0 to be reused on
On Mon, Mar 10, 2014 at 12:11:44PM -0500, Nishanth Menon wrote:
> On 03/02/2014 09:54 PM, Mark Brown wrote:
> > On Mon, Feb 24, 2014 at 08:38:07AM -0600, Nishanth Menon wrote:
> >> Intent here is to allow drivers such as cpufreq-cpu0 to be reused on
> >> platforms such as TI's OMAP derivatives,
On 03/02/2014 09:54 PM, Mark Brown wrote:
> On Mon, Feb 24, 2014 at 08:38:07AM -0600, Nishanth Menon wrote:
>
>> Intent here is to allow drivers such as cpufreq-cpu0 to be reused on
>> platforms such as TI's OMAP derivatives, and other SoCs which differ
>> only by the sequence involved in voltage
On 03/02/2014 09:54 PM, Mark Brown wrote:
On Mon, Feb 24, 2014 at 08:38:07AM -0600, Nishanth Menon wrote:
Intent here is to allow drivers such as cpufreq-cpu0 to be reused on
platforms such as TI's OMAP derivatives, and other SoCs which differ
only by the sequence involved in voltage scale
On Mon, Mar 10, 2014 at 12:11:44PM -0500, Nishanth Menon wrote:
On 03/02/2014 09:54 PM, Mark Brown wrote:
On Mon, Feb 24, 2014 at 08:38:07AM -0600, Nishanth Menon wrote:
Intent here is to allow drivers such as cpufreq-cpu0 to be reused on
platforms such as TI's OMAP derivatives, and other
On 03/10/2014 12:22 PM, Mark Brown wrote:
On Mon, Mar 10, 2014 at 12:11:44PM -0500, Nishanth Menon wrote:
On 03/02/2014 09:54 PM, Mark Brown wrote:
On Mon, Feb 24, 2014 at 08:38:07AM -0600, Nishanth Menon wrote:
Intent here is to allow drivers such as cpufreq-cpu0 to be reused on
platforms
On Mon, Mar 10, 2014 at 12:41:05PM -0500, Nishanth Menon wrote:
The only other options are:
a) Abstract it at a higher level at user drivers, since they are
aware of the sequencing needs - but this partially defeats the
purpose, unless ofcourse, we do a tricky implementation such as:
clk a,
On 03/10/2014 01:01 PM, Mark Brown wrote:
On Mon, Mar 10, 2014 at 12:41:05PM -0500, Nishanth Menon wrote:
The only other options are:
a) Abstract it at a higher level at user drivers, since they are
aware of the sequencing needs - but this partially defeats the
purpose, unless ofcourse, we
On Mon, Feb 24, 2014 at 08:38:07AM -0600, Nishanth Menon wrote:
> Intent here is to allow drivers such as cpufreq-cpu0 to be reused on
> platforms such as TI's OMAP derivatives, and other SoCs which differ
> only by the sequence involved in voltage scale operations. So, this
> patch provides a
On Mon, Feb 24, 2014 at 08:38:07AM -0600, Nishanth Menon wrote:
Intent here is to allow drivers such as cpufreq-cpu0 to be reused on
platforms such as TI's OMAP derivatives, and other SoCs which differ
only by the sequence involved in voltage scale operations. So, this
patch provides a
On 02/23/2014 07:58 PM, Mark Brown wrote:
> On Tue, Feb 18, 2014 at 02:32:20PM -0600, Nishanth Menon wrote:
>
>> The current regulator model provides the basic building blocks for the
>> transitions, however SoC drivers specific to each of these devices, be
>> it cpufreq/devfreq have to replicate
On 02/23/2014 07:58 PM, Mark Brown wrote:
On Tue, Feb 18, 2014 at 02:32:20PM -0600, Nishanth Menon wrote:
The current regulator model provides the basic building blocks for the
transitions, however SoC drivers specific to each of these devices, be
it cpufreq/devfreq have to replicate the
On Tue, Feb 18, 2014 at 02:32:20PM -0600, Nishanth Menon wrote:
> The current regulator model provides the basic building blocks for the
> transitions, however SoC drivers specific to each of these devices, be
> it cpufreq/devfreq have to replicate the logic for functionality.
> To simply the
On Tue, Feb 18, 2014 at 02:32:20PM -0600, Nishanth Menon wrote:
The current regulator model provides the basic building blocks for the
transitions, however SoC drivers specific to each of these devices, be
it cpufreq/devfreq have to replicate the logic for functionality.
To simply the logic,
Many SoCs have basic concepts of voltage rails supplying a specific
SoC device. These voltage rails may be as simple as a single regulator
or complex to be three or more regulators that are transitioned in
tandem with respect to clock changes. In some cases, they may tend
to use custom frameworks
Many SoCs have basic concepts of voltage rails supplying a specific
SoC device. These voltage rails may be as simple as a single regulator
or complex to be three or more regulators that are transitioned in
tandem with respect to clock changes. In some cases, they may tend
to use custom frameworks
20 matches
Mail list logo
