On Tue, Sep 3, 2013 at 11:55 AM, Russ Dill wrote:
> On Fri, Aug 30, 2013 at 9:06 AM, Kevin Hilman wrote:
>> Well, I was thinking of something much dumber.
>>
>> I was thinking about just _carefully_ writing a single, self-contained C
>> function, with all of its data on the stack (and consts as #
On Fri, Aug 30, 2013 at 9:06 AM, Kevin Hilman wrote:
> Well, I was thinking of something much dumber.
>
> I was thinking about just _carefully_ writing a single, self-contained C
> function, with all of its data on the stack (and consts as #defines).
> Think of it is a step up in readability from
On Tue, Sep 03, 2013 at 07:06:01AM -0700, Russ Dill wrote:
> On Thu, Aug 29, 2013 at 12:10 PM, Mark Brown wrote:
> > I was thinking about the majority of regulators where setting a voltage
> > would be a single bitfield update (plus ramp delay, which is going to
> > need to be accounted for in th
On Thu, Aug 29, 2013 at 12:10 PM, Mark Brown wrote:
> On Thu, Aug 29, 2013 at 11:25:43AM -0700, Russ Dill wrote:
>> On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown wrote:
>
>> > Making it write only seems to be a mistake - like I said in my other
>> > mail I'd expect you'd want bitfield updates here
On Thu, Aug 29, 2013 at 5:33 PM, Kevin Hilman wrote:
[...]
>>>
>>> Maybe I'm getting confused, but the more you talk about the linux and
>>> the firmware doing the same code, the more I think the firmware is
>>> (trying) to do too much. If this is going to be understandable (and
>>> maintainable)
Russ Dill writes:
> On Thu, Aug 29, 2013 at 2:33 PM, Kevin Hilman wrote:
>> Vaibhav Bedia writes:
> [snip]
>>> Morevoer, all the suggestions on how to keep the code in Linux working
>>> around the complications due to the main memory not being accessible
>>> will need to be replicated on the no
On Thu, Aug 29, 2013 at 2:33 PM, Kevin Hilman wrote:
> Vaibhav Bedia writes:
[snip]
>> Morevoer, all the suggestions on how to keep the code in Linux working
>> around the complications due to the main memory not being accessible
>> will need to be replicated on the non-Linux s/w stacks and that'
Vaibhav Bedia writes:
> On Thu, Aug 29, 2013 at 3:11 PM, Kevin Hilman wrote:
> [...]
>
> First of all, apologies for jumping in here. Now that i am not
> actively involved in AM335x/AM437x stuff i wasn't actively following
> all the discussion here.
No apologies needed, I was hoping you would j
On Thu, Aug 29, 2013 at 3:11 PM, Kevin Hilman wrote:
[...]
First of all, apologies for jumping in here. Now that i am not
actively involved in
AM335x/AM437x stuff i wasn't actively following all the discussion here.
Looking at the lists now i just wanted to mention a few things so that we can
ag
Russ Dill writes:
> On Thu, Aug 29, 2013 at 8:17 AM, Kevin Hilman wrote:
>> Russ Dill writes:
>>
>>> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman wrote:
[+Mark Brown for regulator suspend sequence ideas]
Russ Dill writes:
> On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe
On Thu, Aug 29, 2013 at 11:25:43AM -0700, Russ Dill wrote:
> On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown wrote:
> > Making it write only seems to be a mistake - like I said in my other
> > mail I'd expect you'd want bitfield updates here. The read and modify
> > could be done earlier by Linux t
On Thu, Aug 29, 2013 at 11:03 AM, Mark Brown wrote:
> On Thu, Aug 29, 2013 at 10:47:04AM -0700, Russ Dill wrote:
>> On Thu, Aug 29, 2013 at 10:30 AM, Mark Brown wrote:
>
>> > So this is done from cpuidle rather than system suspend.
>
>> It is done for system suspend. It isn't possible to do this
On Thu, Aug 29, 2013 at 11:01 AM, Mark Brown wrote:
> On Thu, Aug 29, 2013 at 08:42:11AM -0700, Russ Dill wrote:
>
>> The path I'm taking in this patchset is to just put the board specific
>> I2C sequences necessary for the CM3 coprocessor to write out into the
>> devicetree. I've made it as gener
On Thu, Aug 29, 2013 at 10:47:04AM -0700, Russ Dill wrote:
> On Thu, Aug 29, 2013 at 10:30 AM, Mark Brown wrote:
> > So this is done from cpuidle rather than system suspend.
> It is done for system suspend. It isn't possible to do this in a
> cpuidle use case as the memory controller would need
On Thu, Aug 29, 2013 at 08:42:11AM -0700, Russ Dill wrote:
> The path I'm taking in this patchset is to just put the board specific
> I2C sequences necessary for the CM3 coprocessor to write out into the
> devicetree. I've made it as generic as I can so that other platforms
> with similar issues c
On Thu, Aug 29, 2013 at 10:30 AM, Mark Brown wrote:
> On Thu, Aug 29, 2013 at 09:31:55AM -0700, Russ Dill wrote:
>> On Thu, Aug 29, 2013 at 8:49 AM, Mark Brown wrote:
>
>> > Why does it have to happen this late and are the sequences definitely
>> > fixed ones not ones that could depend on the sys
On Thu, Aug 29, 2013 at 09:31:55AM -0700, Russ Dill wrote:
> On Thu, Aug 29, 2013 at 8:49 AM, Mark Brown wrote:
> > Why does it have to happen this late and are the sequences definitely
> > fixed ones not ones that could depend on the system state at the time
> > we suspend? It'd help to know wh
On Thu, Aug 29, 2013 at 8:49 AM, Mark Brown wrote:
> On Thu, Aug 29, 2013 at 08:29:37AM -0700, Kevin Hilman wrote:
>> On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown wrote:
>
>> > Someone is going to have to walk me through the context for me to fully
>> > understand what this is all about - what's t
On Thu, Aug 29, 2013 at 8:17 AM, Kevin Hilman wrote:
> Russ Dill writes:
>
>> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman wrote:
>>> [+Mark Brown for regulator suspend sequence ideas]
>>>
>>> Russ Dill writes:
>>>
On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe wrote:
> On Tue, 2013-08-1
On Thu, Aug 29, 2013 at 08:29:37AM -0700, Kevin Hilman wrote:
> On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown wrote:
> > Someone is going to have to walk me through the context for me to fully
> > understand what this is all about - what's the problem?
> The basic problem is how to have low-level
On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown wrote:
> On Tue, Aug 27, 2013 at 06:05:34PM -0700, Russ Dill wrote:
>> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman wrote:
>
>> > The framework already has a concept of suspend voltage, suspend mode
>> > etc. Maybe it needs some generalizing so low-le
On Thu, Aug 29, 2013 at 4:05 AM, Mark Brown wrote:
> On Tue, Aug 27, 2013 at 06:05:34PM -0700, Russ Dill wrote:
>> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman wrote:
>
>> > The framework already has a concept of suspend voltage, suspend mode
>> > etc. Maybe it needs some generalizing so low-le
Russ Dill writes:
> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman wrote:
>> [+Mark Brown for regulator suspend sequence ideas]
>>
>> Russ Dill writes:
>>
>>> On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe wrote:
On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote:
> [snip]
Shouldn't the T
On Tue, Aug 27, 2013 at 06:05:34PM -0700, Russ Dill wrote:
> On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman wrote:
> > The framework already has a concept of suspend voltage, suspend mode
> > etc. Maybe it needs some generalizing so low-level platform code could
> > query the framework for the se
On Tue, Aug 27, 2013 at 3:44 PM, Kevin Hilman wrote:
> [+Mark Brown for regulator suspend sequence ideas]
>
> Russ Dill writes:
>
>> On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe wrote:
>>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote:
[snip]
>>> Shouldn't the TPS driver know how to generate
[+Mark Brown for regulator suspend sequence ideas]
Russ Dill writes:
> On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe wrote:
>> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote:
>>> The purpose and method of executing these sequences is left up to each
>>> platform. In the case of the am33xx, the
On Wed, 2013-08-14 at 15:21 -0700, Russ Dill wrote:
> > The CM3 driver needs to figure out where the core regulator is connected
> > using using either DT or the regulator framework and ask the TPS (via a
> > new interface) for register writes for sleep/wake sequences. Then those
> > sequences will
On Wed, Aug 14, 2013 at 6:38 AM, Jan Lübbe wrote:
> On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote:
>> The purpose and method of executing these sequences is left up to each
>> platform. In the case of the am33xx, the CM3 firmware writes out the
>> simple I2C sequences.
>>
>> Each sequence is
On Tue, 2013-08-13 at 15:20 -0700, Russ Dill wrote:
> The purpose and method of executing these sequences is left up to each
> platform. In the case of the am33xx, the CM3 firmware writes out the
> simple I2C sequences.
>
> Each sequence is a series of I2C write commands. The first byte is the
> l
This is v4 of the OPP50 (VDD CORE 0.95V during suspend) patch set.
Adjusting voltages to this lower operating point during suspend saves
additional power. This operating point can only be reached when SDRAM is
in self refresh and certain DPLLs have been put into bypass mode. This
means that the co
30 matches
Mail list logo
