On 8/20/2013 10:03 PM, Russ Dill wrote:
> On Sun, Aug 18, 2013 at 10:49 PM, Gururaja Hebbar
> <gururaja.hebbar@xxxxxx> wrote:
>>
>> On 8/15/2013 4:04 AM, Russ Dill wrote:
>>> On Wed, Aug 14, 2013 at 3:18 AM, Gururaja Hebbar <gururaja.hebbar@xxxxxx> 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!
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
