All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suman Anna <s-anna@ti.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Lokesh Vutla <lokeshvutla@ti.com>,
	linux-remoteproc <linux-remoteproc@vger.kernel.org>,
	<devicetree@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] remoteproc: k3-r5: Adjust TCM sizes in Split-mode on J7200 SoCs
Date: Mon, 30 Nov 2020 09:47:46 -0600	[thread overview]
Message-ID: <823f82d5-f100-23ed-8f29-73ec8b19ffd7@ti.com> (raw)
In-Reply-To: <CANLsYkwztm1hwXMGO-7025YdaEk=ttLMVmM2A8hRYyyrWpR7fQ@mail.gmail.com>

On 11/23/20 6:55 PM, Mathieu Poirier wrote:
> On Mon, 23 Nov 2020 at 16:51, Mathieu Poirier
> <mathieu.poirier@linaro.org> wrote:
>>
>> Good afternoon Suman,
>>
>> On Wed, Nov 18, 2020 at 07:05:31PM -0600, Suman Anna wrote:
>>> The J7200 SoCs have a revised R5FSS IP that adds a unique feature w.r.t
>>> TCM sizing. Each R5F core in a cluster typically has 32 KB each of ATCM
>>> and BTCM, with only the Core0 TCMs usable in LockStep mode. This revised
>>> IP however doubles the total available TCM in LockStep mode by making the
>>> Core1 TCM visible immediately after the corresponding Core0 TCM.
>>>
>>> The R5F DT nodes on the J7200 SoCs define double (64 KB) the normal TCM
>>> size (32 KB) for R5F Core0 for each of ATCM and BTCM to represent the
>>> above. This increased TCM memory is only usable in LockStep-mode, and
>>> has to be adjusted to the normal 32 KB size in Split mode. Enhance the
>>> TI K3 R5F remoteproc for this logic through a new function. The adjustment
>>> is a no-op on prior SoCs and relies on the correct DTS node sizes in
>>> LockStep-mode on applicable SoCs.
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> ---
>>>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 43 ++++++++++++++++++++++++
>>>  1 file changed, 43 insertions(+)
>>>
>>> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
>>> index 66a32dcdd7d0..62b5a4c29456 100644
>>> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
>>> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
>>> @@ -71,9 +71,11 @@ enum cluster_mode {
>>>
>>>  /**
>>>   * struct k3_r5_soc_data - match data to handle SoC variations
>>> + * @tcm_is_double: flag to denote the larger unified TCMs in certain modes
>>>   * @tcm_ecc_autoinit: flag to denote the auto-initialization of TCMs for ECC
>>>   */
>>>  struct k3_r5_soc_data {
>>> +     bool tcm_is_double;
>>>       bool tcm_ecc_autoinit;
>>>  };
>>>
>>> @@ -886,6 +888,43 @@ static void k3_r5_reserved_mem_exit(struct k3_r5_rproc *kproc)
>>>       of_reserved_mem_device_release(kproc->dev);
>>>  }
>>>
>>> +/*
>>> + * Each R5F core within a typical R5FSS instance has a total of 64 KB of TCMs,
>>> + * split equally into two 32 KB banks between ATCM and BTCM. The TCMs from both
>>> + * cores are usable in Split-mode, but only the Core0 TCMs can be used in
>>> + * LockStep-mode. The newer revisions of the R5FSS IP maximizes these TCMs by
>>> + * leveraging the Core1 TCMs as well in certain modes where they would have
>>> + * otherwise been unusable (Eg: LockStep-mode on J7200 SoCs). This is done by
>>> + * making a Core1 TCM visible immediately after the corresponding Core0 TCM.
>>> + * The SoC memory map uses the larger 64 KB sizes for the Core0 TCMs, and the
>>> + * dts representation reflects this increased size on supported SoCs. The Core0
>>> + * TCM sizes therefore have to be adjusted to only half the original size in
>>> + * Split mode.
>>> + */
>>> +static void k3_r5_adjust_tcm_sizes(struct k3_r5_rproc *kproc)
>>> +{
>>> +     struct k3_r5_cluster *cluster = kproc->cluster;
>>> +     struct k3_r5_core *core = kproc->core;
>>> +     struct device *cdev = core->dev;
>>> +     struct k3_r5_core *core0;
>>> +
>>> +     if (cluster->mode == CLUSTER_MODE_LOCKSTEP ||
>>> +         !cluster->soc_data->tcm_is_double)
>>> +             return;
>>
>> Shouldn't this be:
>>
>>         if (cluster->mode == CLUSTER_MODE_SPLIT ||
>>             !cluster->soc_data->tcm_is_double)
>>                 return;
>>
>> If am wrong then I'm pretty sure other people will be confused and a comment is
>> warranted.
>>
> 
> Forget the above, I misread the context.  The memories are already set
> to 64KB so there is nothing to do if in lockstep mode.

Yep, thanks for the review. The comments above the function has all the details.

regards
Suman

> 
>>> +
>>> +     core0 = list_first_entry(&cluster->cores, struct k3_r5_core, elem);
>>> +     if (core == core0) {
>>> +             WARN_ON(core->mem[0].size != SZ_64K);
>>> +             WARN_ON(core->mem[1].size != SZ_64K);
>>> +
>>> +             core->mem[0].size /= 2;
>>> +             core->mem[1].size /= 2;
>>> +
>>> +             dev_dbg(cdev, "adjusted TCM sizes, ATCM = 0x%zx BTCM = 0x%zx\n",
>>> +                     core->mem[0].size, core->mem[1].size);
>>> +     }
>>> +}
>>> +
>>>  static int k3_r5_cluster_rproc_init(struct platform_device *pdev)
>>>  {
>>>       struct k3_r5_cluster *cluster = platform_get_drvdata(pdev);
>>> @@ -933,6 +972,8 @@ static int k3_r5_cluster_rproc_init(struct platform_device *pdev)
>>>                       goto err_config;
>>>               }
>>>
>>> +             k3_r5_adjust_tcm_sizes(kproc);
>>> +
>>>               ret = k3_r5_reserved_mem_init(kproc);
>>>               if (ret) {
>>>                       dev_err(dev, "reserved memory init failed, ret = %d\n",
>>> @@ -1407,10 +1448,12 @@ static int k3_r5_probe(struct platform_device *pdev)
>>>  }
>>>
>>>  static const struct k3_r5_soc_data am65_j721e_soc_data = {
>>> +     .tcm_is_double = false,
>>>       .tcm_ecc_autoinit = false,
>>>  };
>>>
>>>  static const struct k3_r5_soc_data j7200_soc_data = {
>>> +     .tcm_is_double = true,
>>>       .tcm_ecc_autoinit = true,
>>
>> With the above and for the set:
>>
>> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>>
>>>  };
>>>
>>> --
>>> 2.28.0
>>>


WARNING: multiple messages have this Message-ID (diff)
From: Suman Anna <s-anna@ti.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: devicetree@vger.kernel.org, Lokesh Vutla <lokeshvutla@ti.com>,
	linux-remoteproc <linux-remoteproc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 3/3] remoteproc: k3-r5: Adjust TCM sizes in Split-mode on J7200 SoCs
Date: Mon, 30 Nov 2020 09:47:46 -0600	[thread overview]
Message-ID: <823f82d5-f100-23ed-8f29-73ec8b19ffd7@ti.com> (raw)
In-Reply-To: <CANLsYkwztm1hwXMGO-7025YdaEk=ttLMVmM2A8hRYyyrWpR7fQ@mail.gmail.com>

On 11/23/20 6:55 PM, Mathieu Poirier wrote:
> On Mon, 23 Nov 2020 at 16:51, Mathieu Poirier
> <mathieu.poirier@linaro.org> wrote:
>>
>> Good afternoon Suman,
>>
>> On Wed, Nov 18, 2020 at 07:05:31PM -0600, Suman Anna wrote:
>>> The J7200 SoCs have a revised R5FSS IP that adds a unique feature w.r.t
>>> TCM sizing. Each R5F core in a cluster typically has 32 KB each of ATCM
>>> and BTCM, with only the Core0 TCMs usable in LockStep mode. This revised
>>> IP however doubles the total available TCM in LockStep mode by making the
>>> Core1 TCM visible immediately after the corresponding Core0 TCM.
>>>
>>> The R5F DT nodes on the J7200 SoCs define double (64 KB) the normal TCM
>>> size (32 KB) for R5F Core0 for each of ATCM and BTCM to represent the
>>> above. This increased TCM memory is only usable in LockStep-mode, and
>>> has to be adjusted to the normal 32 KB size in Split mode. Enhance the
>>> TI K3 R5F remoteproc for this logic through a new function. The adjustment
>>> is a no-op on prior SoCs and relies on the correct DTS node sizes in
>>> LockStep-mode on applicable SoCs.
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> ---
>>>  drivers/remoteproc/ti_k3_r5_remoteproc.c | 43 ++++++++++++++++++++++++
>>>  1 file changed, 43 insertions(+)
>>>
>>> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
>>> index 66a32dcdd7d0..62b5a4c29456 100644
>>> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
>>> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
>>> @@ -71,9 +71,11 @@ enum cluster_mode {
>>>
>>>  /**
>>>   * struct k3_r5_soc_data - match data to handle SoC variations
>>> + * @tcm_is_double: flag to denote the larger unified TCMs in certain modes
>>>   * @tcm_ecc_autoinit: flag to denote the auto-initialization of TCMs for ECC
>>>   */
>>>  struct k3_r5_soc_data {
>>> +     bool tcm_is_double;
>>>       bool tcm_ecc_autoinit;
>>>  };
>>>
>>> @@ -886,6 +888,43 @@ static void k3_r5_reserved_mem_exit(struct k3_r5_rproc *kproc)
>>>       of_reserved_mem_device_release(kproc->dev);
>>>  }
>>>
>>> +/*
>>> + * Each R5F core within a typical R5FSS instance has a total of 64 KB of TCMs,
>>> + * split equally into two 32 KB banks between ATCM and BTCM. The TCMs from both
>>> + * cores are usable in Split-mode, but only the Core0 TCMs can be used in
>>> + * LockStep-mode. The newer revisions of the R5FSS IP maximizes these TCMs by
>>> + * leveraging the Core1 TCMs as well in certain modes where they would have
>>> + * otherwise been unusable (Eg: LockStep-mode on J7200 SoCs). This is done by
>>> + * making a Core1 TCM visible immediately after the corresponding Core0 TCM.
>>> + * The SoC memory map uses the larger 64 KB sizes for the Core0 TCMs, and the
>>> + * dts representation reflects this increased size on supported SoCs. The Core0
>>> + * TCM sizes therefore have to be adjusted to only half the original size in
>>> + * Split mode.
>>> + */
>>> +static void k3_r5_adjust_tcm_sizes(struct k3_r5_rproc *kproc)
>>> +{
>>> +     struct k3_r5_cluster *cluster = kproc->cluster;
>>> +     struct k3_r5_core *core = kproc->core;
>>> +     struct device *cdev = core->dev;
>>> +     struct k3_r5_core *core0;
>>> +
>>> +     if (cluster->mode == CLUSTER_MODE_LOCKSTEP ||
>>> +         !cluster->soc_data->tcm_is_double)
>>> +             return;
>>
>> Shouldn't this be:
>>
>>         if (cluster->mode == CLUSTER_MODE_SPLIT ||
>>             !cluster->soc_data->tcm_is_double)
>>                 return;
>>
>> If am wrong then I'm pretty sure other people will be confused and a comment is
>> warranted.
>>
> 
> Forget the above, I misread the context.  The memories are already set
> to 64KB so there is nothing to do if in lockstep mode.

Yep, thanks for the review. The comments above the function has all the details.

regards
Suman

> 
>>> +
>>> +     core0 = list_first_entry(&cluster->cores, struct k3_r5_core, elem);
>>> +     if (core == core0) {
>>> +             WARN_ON(core->mem[0].size != SZ_64K);
>>> +             WARN_ON(core->mem[1].size != SZ_64K);
>>> +
>>> +             core->mem[0].size /= 2;
>>> +             core->mem[1].size /= 2;
>>> +
>>> +             dev_dbg(cdev, "adjusted TCM sizes, ATCM = 0x%zx BTCM = 0x%zx\n",
>>> +                     core->mem[0].size, core->mem[1].size);
>>> +     }
>>> +}
>>> +
>>>  static int k3_r5_cluster_rproc_init(struct platform_device *pdev)
>>>  {
>>>       struct k3_r5_cluster *cluster = platform_get_drvdata(pdev);
>>> @@ -933,6 +972,8 @@ static int k3_r5_cluster_rproc_init(struct platform_device *pdev)
>>>                       goto err_config;
>>>               }
>>>
>>> +             k3_r5_adjust_tcm_sizes(kproc);
>>> +
>>>               ret = k3_r5_reserved_mem_init(kproc);
>>>               if (ret) {
>>>                       dev_err(dev, "reserved memory init failed, ret = %d\n",
>>> @@ -1407,10 +1448,12 @@ static int k3_r5_probe(struct platform_device *pdev)
>>>  }
>>>
>>>  static const struct k3_r5_soc_data am65_j721e_soc_data = {
>>> +     .tcm_is_double = false,
>>>       .tcm_ecc_autoinit = false,
>>>  };
>>>
>>>  static const struct k3_r5_soc_data j7200_soc_data = {
>>> +     .tcm_is_double = true,
>>>       .tcm_ecc_autoinit = true,
>>
>> With the above and for the set:
>>
>> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>>
>>>  };
>>>
>>> --
>>> 2.28.0
>>>


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-11-30 15:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19  1:05 [PATCH 0/3] TI K3 R5F remoteproc support on J7200 SoCs Suman Anna
2020-11-19  1:05 ` Suman Anna
2020-11-19  1:05 ` [PATCH 1/3] dt-bindings: remoteproc: k3-r5f: Update bindings for " Suman Anna
2020-11-19  1:05   ` Suman Anna
2020-11-19  1:05 ` [PATCH 2/3] remoteproc: k3-r5: Extend support to R5F clusters on " Suman Anna
2020-11-19  1:05   ` Suman Anna
2020-11-19  1:05 ` [PATCH 3/3] remoteproc: k3-r5: Adjust TCM sizes in Split-mode " Suman Anna
2020-11-19  1:05   ` Suman Anna
2020-11-23 23:51   ` Mathieu Poirier
2020-11-23 23:51     ` Mathieu Poirier
2020-11-24  0:55     ` Mathieu Poirier
2020-11-24  0:55       ` Mathieu Poirier
2020-11-30 15:47       ` Suman Anna [this message]
2020-11-30 15:47         ` Suman Anna
2020-11-26 17:40 ` [PATCH 0/3] TI K3 R5F remoteproc support " patchwork-bot+linux-remoteproc

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=823f82d5-f100-23ed-8f29-73ec8b19ffd7@ti.com \
    --to=s-anna@ti.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=robh+dt@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.