Re: [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support

[Gururaja Hebbar <gururaja.hebbar@ti.com>]

On 8/20/2013 10:03 PM, Russ Dill wrote:
> On Sun, Aug 18, 2013 at 10:49 PM, Gururaja Hebbar
> <gururaja.hebbar@ti.com> wrote:
>>
>> On 8/15/2013 4:04 AM, Russ Dill wrote:
>>> On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@ti.com> wrote:
>>>> On 8/14/2013 3:50 AM, Russ Dill wrote:
>>>>> Changes since v1:
>>>>> * Rebased onto new am335x PM branch
>>>>> * Changed to use 5th param register
>>
>>>>
>>
>> [snip]
>> [snip]
>>
>>>>> +
>>>>> +     wkup_m3_reset_data_pos();
>>>>> +     if (am33xx_i2c_sleep_sequence) {
>>>>> +             pos = wkup_m3_copy_data(am33xx_i2c_sleep_sequence,
>>>>> +                                             i2c_sleep_sequence_sz);
>>>>
>>>> Why do we need to copy this data (same constant data) on every iteration?
>>>
>>> Because the CM3 firmware is reset after each suspend/resume cycle. The
>>> firmware reset handler reinitializes the DMEM.
>>
>> Well in that why can't the i2c payload be copied to UMEM?
>>
>> Thanks & regards
>> Gururaja
>>
> 
> I've given this some thought, and gone back and forth a bit. UMEM is a
> bit more complicated because the linker decides what should go where.

but linker doesn't know about the copy and the location we are doing at
runtime.

> Also, it may be that in the future, either the PM for am335x or am43xx
> will be writing different sequences depending on the suspend
> mode/options.

still these info will be coming from DT and can be copied to UMEM. only
issue could be space.

> 
> Is there a specific aspect of copying the data each suspend cycle that
> you are trying to fix? Is it just that the data could only be copied
> once? Or is it the latency of the copy?

Copy latency on every iterations is what worries me. it will surely add
a delay for suspend.

> 
> Thanks!
>