All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russ Dill <Russ.Dill@ti.com>
To: Gururaja Hebbar <gururaja.hebbar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>,
	devicetree@vger.kernel.org,
	Devicetree Discuss <devicetree-discuss@lists.ozlabs.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support
Date: Tue, 20 Aug 2013 09:33:19 -0700	[thread overview]
Message-ID: <CA+Bv8XaPU6N3KztAPFZb8OMMg8Tc+Kv5hf1Utz7QS=NCRdO3Rg@mail.gmail.com> (raw)
In-Reply-To: <5211B201.2000401@ti.com>

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.
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.

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?

Thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Russ.Dill@ti.com (Russ Dill)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support
Date: Tue, 20 Aug 2013 09:33:19 -0700	[thread overview]
Message-ID: <CA+Bv8XaPU6N3KztAPFZb8OMMg8Tc+Kv5hf1Utz7QS=NCRdO3Rg@mail.gmail.com> (raw)
In-Reply-To: <5211B201.2000401@ti.com>

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.
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.

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?

Thanks!

  reply	other threads:[~2013-08-20 16:33 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-13 22:20 [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support Russ Dill
2013-08-13 22:20 ` Russ Dill
2013-08-13 22:20 ` [PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support Russ Dill
2013-08-13 22:20   ` Russ Dill
2013-08-14 10:18   ` Gururaja Hebbar
2013-08-14 10:18     ` Gururaja Hebbar
2013-08-14 22:34     ` Russ Dill
2013-08-14 22:34       ` Russ Dill
2013-08-16  7:16       ` Gururaja Hebbar
2013-08-16  7:16         ` Gururaja Hebbar
2013-08-19  5:49       ` Gururaja Hebbar
2013-08-19  5:49         ` Gururaja Hebbar
2013-08-20 16:33         ` Russ Dill [this message]
2013-08-20 16:33           ` Russ Dill
2013-08-21  8:29           ` Gururaja Hebbar
2013-08-21  8:29             ` Gururaja Hebbar
2013-08-13 22:20 ` [PATCH v4 2/4] ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone Russ Dill
2013-08-13 22:20   ` Russ Dill
2013-08-14  8:59   ` Gururaja Hebbar
2013-08-14  8:59     ` Gururaja Hebbar
2013-08-14 22:21     ` Russ Dill
2013-08-14 22:21       ` Russ Dill
2013-08-13 22:20 ` [PATCH v4 3/4] ARM: dts: add AM33XX vdd core opp50 suspend for AM335X GP EVM Russ Dill
2013-08-13 22:20   ` Russ Dill
2013-08-13 22:20 ` [PATCH v4 4/4] ARM: dts: AM33XX vdd core opp50 suspend for EVM-SK Russ Dill
2013-08-13 22:20   ` Russ Dill
2013-08-14 13:38 ` [PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support Jan Lübbe
2013-08-14 13:38   ` Jan Lübbe
2013-08-14 22:21   ` Russ Dill
2013-08-14 22:21     ` Russ Dill
2013-08-15  8:00     ` Jan Lübbe
2013-08-15  8:00       ` Jan Lübbe
2013-08-27 22:44     ` Kevin Hilman
2013-08-27 22:44       ` Kevin Hilman
2013-08-28  1:05       ` Russ Dill
2013-08-28  1:05         ` Russ Dill
2013-08-29 11:05         ` Mark Brown
2013-08-29 11:05           ` Mark Brown
2013-08-29 15:29           ` Kevin Hilman
2013-08-29 15:29             ` Kevin Hilman
2013-08-29 15:49             ` Mark Brown
2013-08-29 15:49               ` Mark Brown
2013-08-29 16:31               ` Russ Dill
2013-08-29 16:31                 ` Russ Dill
2013-08-29 17:30                 ` Mark Brown
2013-08-29 17:30                   ` Mark Brown
2013-08-29 17:47                   ` Russ Dill
2013-08-29 17:47                     ` Russ Dill
2013-08-29 18:03                     ` Mark Brown
2013-08-29 18:03                       ` Mark Brown
2013-08-29 18:28                       ` Russ Dill
2013-08-29 18:28                         ` Russ Dill
2013-08-29 15:42           ` Russ Dill
2013-08-29 15:42             ` Russ Dill
2013-08-29 18:01             ` Mark Brown
2013-08-29 18:01               ` Mark Brown
2013-08-29 18:25               ` Russ Dill
2013-08-29 18:25                 ` Russ Dill
2013-08-29 19:10                 ` Mark Brown
2013-08-29 19:10                   ` Mark Brown
2013-09-03 14:06                   ` Russ Dill
2013-09-03 14:06                     ` Russ Dill
2013-09-03 14:39                     ` Mark Brown
2013-09-03 14:39                       ` Mark Brown
2013-08-29 15:17         ` Kevin Hilman
2013-08-29 15:17           ` Kevin Hilman
2013-08-29 16:10           ` Russ Dill
2013-08-29 16:10             ` Russ Dill
2013-08-29 19:11             ` Kevin Hilman
2013-08-29 19:11               ` Kevin Hilman
2013-08-29 20:09               ` Vaibhav Bedia
2013-08-29 20:09                 ` Vaibhav Bedia
2013-08-29 21:33                 ` Kevin Hilman
2013-08-29 21:33                   ` Kevin Hilman
2013-08-30  0:25                   ` Russ Dill
2013-08-30  0:25                     ` Russ Dill
2013-08-30 16:06                     ` Kevin Hilman
2013-08-30 16:06                       ` Kevin Hilman
2013-09-03 18:55                       ` Russ Dill
2013-09-03 18:55                         ` Russ Dill
2013-09-03 19:07                         ` Kevin Hilman
2013-09-03 19:07                           ` Kevin Hilman
2013-08-30 17:57                   ` Vaibhav Bedia
2013-08-30 17:57                     ` Vaibhav Bedia

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='CA+Bv8XaPU6N3KztAPFZb8OMMg8Tc+Kv5hf1Utz7QS=NCRdO3Rg@mail.gmail.com' \
    --to=russ.dill@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gururaja.hebbar@ti.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.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: link
Be 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.