linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Elder <elder@linaro.org>
To: Konrad Dybcio <konrad.dybcio@linaro.org>,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com
Cc: andersson@kernel.org, agross@kernel.org, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, elder@kernel.org,
	linux-arm-msm@vger.kernel.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Luca Weiss <luca.weiss@fairphone.com>
Subject: Re: [PATCH net-next 2/2] net: ipa: add IPA v4.7 support
Date: Fri, 30 Dec 2022 11:28:01 -0600	[thread overview]
Message-ID: <20b2f7c3-6481-eabf-7c46-f5f38d258c62@linaro.org> (raw)
In-Reply-To: <48bef9dd-b71c-b6aa-e853-1cf821e88b50@linaro.org>

On 12/10/22 3:31 AM, Konrad Dybcio wrote:
> 
> 
> On 9.12.2022 21:22, Alex Elder wrote:
>> On 12/8/22 3:22 PM, Konrad Dybcio wrote:
>>>
>>>
>>> On 8.12.2022 22:15, Alex Elder wrote:
>>>> Add the necessary register and data definitions needed for IPA v4.7,
>>>> which is found on the SM6350 SoC.
>>>>
>>>> Co-developed-by: Luca Weiss <luca.weiss@fairphone.com>
>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>> Signed-off-by: Alex Elder <elder@linaro.org>
>>>> ---
>>> [...]

I'm finally getting back to this...  I'm about to send an
update to net-next to address your comment.  But before
doing that I'm going to explain my thinking on it.

>>>> +
>>>> +/* Memory configuration data for an SoC having IPA v4.7 */
>>>> +static const struct ipa_mem_data ipa_mem_data = {
>>>> +    .local_count    = ARRAY_SIZE(ipa_mem_local_data),
>>>> +    .local        = ipa_mem_local_data,
>>>> +    .imem_addr    = 0x146a9000,
>>>> +    .imem_size    = 0x00002000,
>>> Should probably be
>>>
>>> 0x146a8000
>>> 0x00003000

The IMEM memory region is a distinct from main memory, but
is "local" to certain parts of the SoC and is used for
specific things for faster access.  The size and location
of this region differs per-SoC.  Previously I believed this
to be the same for a given version of IPA, and as such the
range was defined in the "config data".  But I now know
that is not the case, and during this release cycle I
intend to get that fixed.

Anyway, for a given SoC, the whole IMEM region is used
by different entities.  For SM7550, for example, it is
divided into 6 parts of various sizes (100KB, 24KB, 32KB,
8KB, 8KB, and 4KB).  For IPA on this SoC, the offset is
0x146a9000, with size 0x2000.  Hence the range defined
above.

>>> with an appropriate change in dt to reserve that region.
>>>
>>> Qualcomm does:
>>> ipa@... { qcom,additional-mapping = <0x146a8000 0x146a8000 0x2000>; };
>>>
>>> which covers 0x146a8000-0x146a9fff
>>>
>>> plus
>>>
>>> imem@.. { reg = <0x146aa000 0x1000>; };
>>>
>>> which in total gives us 0x146a8000-0x146aafff
>>
>> Can you tell me where you found this information?
> [1], [2]

Following the first link, I see that this Sony device (which uses
IPA v4.7) uses MSM7225 as its SoC.  I am not able to verify the
values shown in the DTS file elsewhere, so in this case, that DTS
file is my best source for information.

The first link defines the IPA portion of IMEM at offset
0x146a8000, size 0x2000.  That's what I'll use here instead.

The other region you mention (in the second link) appears to
be a distinct part, which follows the part set aside for IPA
to use.  For SM7550, that part is "shared" and immediately
follows the IPA part, with size 0x1000.  So I believe that
is what the qcom,msm-imem@146aa000 is defining in the second
link you supply.

>>> That would also mean all of your writes are kind of skewed, unless
>>> you already applied some offsets to them.

Luca tested the code the way I defined it initially and found
it worked.  It's possible the part of IMEM defined by my patch
was just not used for it's intended purpose during his testing
and therefore he saw no obvious problems.

My plan is to patch "ipa_data-v4.7.c" to change the IMEM region
to have offset 0x146a8000, size 0x2000, as you suggested.  I will
supply this to Luca for testing (actually I think he already did),
and we'll go with that as the final location for the IPA portion
of IMEM for IPA v4.7.

Later (sometime soon) the definition of this IPA IMEM area will
get done differently--not defined in the "config data" files and
instead defined in DTS.  There is already an imem node available
(for example imem@146a5000 in "sc7280.dtsi"), so the fix *might*
involve using that.

					-Alex

>> This region is used by the modem, but must be set up
>> by the AP.
>>
>>> (IMEM on 6350 starts at 0x14680000 and is 0x2e000 long, as per
>>> the bootloader memory map)
>>
>> On SM7250 (sorry, I don't know about 7225, or 6350 for that matter),
>> the IMEM starts at 0x14680000 and has length 0x2c000.  However that
>> memory is used by multiple entities.  The portion set aside for IPA
>> starts at 0x146a9000 and has size 0x2000.
>>
> Not sure how 7250 relates to 6350, but I don't think there's much
> overlap..
> 
> 
> Konrad
> 
> [1] https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.9.12.r1/arch/arm64/boot/dts/qcom/lagoon.dtsi#L3698-L3707
> 
> [2] https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.9.12.r1/arch/arm64/boot/dts/qcom/lagoon.dtsi#L1004-L1045
>>                      -Alex
>>
>>> Konrad
>>


  parent reply	other threads:[~2022-12-30 17:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08 21:15 [PATCH net-next 0/2] net: ipa: enable IPA v4.7 support Alex Elder
2022-12-08 21:15 ` [PATCH net-next 1/2] dt-bindings: net: qcom,ipa: Add SM6350 compatible Alex Elder
2022-12-09  8:24   ` Krzysztof Kozlowski
2022-12-30 20:50   ` Caleb Connolly
2022-12-08 21:15 ` [PATCH net-next 2/2] net: ipa: add IPA v4.7 support Alex Elder
2022-12-08 21:22   ` Konrad Dybcio
2022-12-09 20:22     ` Alex Elder
2022-12-10  9:31       ` Konrad Dybcio
2022-12-12 23:54         ` Jakub Kicinski
2022-12-13  1:11           ` Alex Elder
2022-12-30 17:28         ` Alex Elder [this message]
2022-12-30 23:53           ` Alex Elder
2022-12-13  0:00 ` [PATCH net-next 0/2] net: ipa: enable " patchwork-bot+netdevbpf

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=20b2f7c3-6481-eabf-7c46-f5f38d258c62@linaro.org \
    --to=elder@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=elder@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.weiss@fairphone.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).