| Message ID | ad16cfb9b6f5efb85149458d5f5a1abf43fa027c.1548133311.git.saiprakash.ranjan@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add coresight support for SDM845 and MSM8996 | expand |
Hi Sai, On 01/22/2019 01:37 PM, Sai Prakash Ranjan wrote: > Add coresight components found on Qualcomm SDM845 SoC. > > Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> > Sorry, but I hadn't noticed the PID override strings below. Please find the question. > --- > Depends on AOSS QMP side channel patches and AMBA bus pclk change > by Bjorn Andersson [1][2]. > Also depends on patch ("arm64: dts: qcom: sdm845: Increase address > and size cells for soc") [3]. > > [1] https://lore.kernel.org/lkml/20190106080915.4493-1-bjorn.andersson@linaro.org/ > [2] https://lore.kernel.org/lkml/20190106080915.4493-7-bjorn.andersson@linaro.org/ > [3] https://lore.kernel.org/lkml/20190117042940.25487-2-bjorn.andersson@linaro.org/ [...] }; > + > + etr@6048000 { > + compatible = "arm,coresight-tmc", "arm,primecell"; > + reg = <0 0x06048000 0 0x1000>; > + > + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; > + arm,scatter-gather; > + > + in-ports { > + port { > + etr_in: endpoint { > + remote-endpoint = > + <&replicator_out>; > + }; > + }; > + }; > + }; > + > + /* > + * On QCOM SDM845, we bypass the normal AMBA bus discovery > + * method by forcing the peripheral ID because of the wrong > + * value read from ETM PID registers. > + */ What is the value read back from the ETM PIDx registers ? Do they provide inconsistent or incompatible value w.r.t the ETM/Coresight architecture ? If it is an unsupported CPU with proper values, you must add them to the table in etm4x driver. > + etm@7040000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + arm,primecell-periphid = <0x000bb95d> > + reg = <0 0x07040000 0 0x1000>; > + > + cpu = <&CPU0>; > + You seem to be specifying the PID of A53 ETM all over, while at least one of your cores is ETMv4.2 (from the other patch) and A53 is not ETMv4.2. As above, it would be good to add the PID to the table. Suzuki
Hi Suzuki, Thanks for looking into this. Please find my response inline. On 1/22/2019 7:30 PM, Suzuki K Poulose wrote: > Hi Sai, > > On 01/22/2019 01:37 PM, Sai Prakash Ranjan wrote: >> Add coresight components found on Qualcomm SDM845 SoC. >> >> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> >> > > Sorry, but I hadn't noticed the PID override strings below. Please > find the question. > [..] >> + /* >> + * On QCOM SDM845, we bypass the normal AMBA bus discovery >> + * method by forcing the peripheral ID because of the wrong >> + * value read from ETM PID registers. >> + */ > > What is the value read back from the ETM PIDx registers ? Do they > provide inconsistent or incompatible value w.r.t the ETM/Coresight > architecture ? If it is an unsupported CPU with proper values, > you must add them to the table in etm4x driver. > The values read from ETM PIDx registers are actually inconsistent and is different for some ETMs. Below are the PIDs read for SDM845: [ 5.996448] resname=etm@7040000 pid=001bb803 [ 6.052891] resname=etm@7140000 pid=001bb803 <snip> .. (Same pid=001bb803 for etm@7240000 to etm@7540000 but differs for other 2 cpus as shown below) [ 6.266687] resname=etm@7640000 pid=001bb802 [ 6.329171] resname=etm@7740000 pid=001bb802 This is the case for MSM8996 also as shown below where PID value is not correct and has to be hardcoded. For MSM8996: resname=etm@3b40000 pid=102f0205 >> + etm@7040000 { >> + compatible = "arm,coresight-etm4x", "arm,primecell"; >> + arm,primecell-periphid = <0x000bb95d> > + reg >> = <0 0x07040000 0 0x1000>; >> + >> + cpu = <&CPU0>; >> + > > You seem to be specifying the PID of A53 ETM all over, while at least > one of your cores is ETMv4.2 (from the other patch) and A53 is not > ETMv4.2. As above, it would be good to add the PID to the table. > As explained in above comment, PID values read are not correct. Please let me know if I am not clear. Thanks, Sai
Hi Sai, On 01/22/2019 03:02 PM, Sai Prakash Ranjan wrote: > Hi Suzuki, > > Thanks for looking into this. Please find my response inline. > > On 1/22/2019 7:30 PM, Suzuki K Poulose wrote: >> Hi Sai, >> >> On 01/22/2019 01:37 PM, Sai Prakash Ranjan wrote: >>> Add coresight components found on Qualcomm SDM845 SoC. >>> >>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> >>> >> >> Sorry, but I hadn't noticed the PID override strings below. Please >> find the question. >> > [..] > >>> + /* >>> + * On QCOM SDM845, we bypass the normal AMBA bus discovery >>> + * method by forcing the peripheral ID because of the wrong >>> + * value read from ETM PID registers. >>> + */ >> >> What is the value read back from the ETM PIDx registers ? Do they >> provide inconsistent or incompatible value w.r.t the ETM/Coresight >> architecture ? If it is an unsupported CPU with proper values, >> you must add them to the table in etm4x driver. >> > > The values read from ETM PIDx registers are actually inconsistent > and is different for some ETMs. By inconsistent, I meant the registers provides values which are not the same on two different CPUs of the *same type*. And it is expected that two different CPU/ETM implementations will have different PIDs. > > Below are the PIDs read for SDM845: > > [ 5.996448] resname=etm@7040000 pid=001bb803 > [ 6.052891] resname=etm@7140000 pid=001bb803 > > <snip> .. (Same pid=001bb803 for etm@7240000 to etm@7540000 but differs > for other 2 cpus as shown below) > > [ 6.266687] resname=etm@7640000 pid=001bb802 > [ 6.329171] resname=etm@7740000 pid=001bb802 > > This is the case for MSM8996 also as shown below where PID > value is not correct and has to be hardcoded. They differ because they are two different types of CPU cores (and thus different ETM PIDs). What does the Register descriptions say for the Cores ? To me it looks like there are two different types of Qualcomm Cores with their respective ETMs which are missing in the ETM4x driver and we are trying to "make the ETM" work by faking it as something else, which is not nice. I would rather prefer to add the appropriate masks and the expected value for these two different ETM implementations and be done with it, instead of faking it in all the DTs where these cores appear. > > For MSM8996: > > resname=etm@3b40000 pid=102f0205 I don't know what CPUs the MSM8996 have. If they don't have A53, you must add the actual PIDs to the table once and for all. > >>> + etm@7040000 { >>> + compatible = "arm,coresight-etm4x", "arm,primecell"; >>> + arm,primecell-periphid = <0x000bb95d> > + reg >>> = <0 0x07040000 0 0x1000>; >>> + >>> + cpu = <&CPU0>; >>> + >> >> You seem to be specifying the PID of A53 ETM all over, while at least >> one of your cores is ETMv4.2 (from the other patch) and A53 is not >> ETMv4.2. As above, it would be good to add the PID to the table. >> > > As explained in above comment, PID values read are not correct. Please > let me know if I am not clear. There is no measure for "correctness" here. If the ETM exposes different PID than what you expect from the TRM, then we could think of overriding it. Otherwise please add the PIDs to the table. Cheers Suzuki
Hi Suzuki, On 1/22/2019 9:38 PM, Suzuki K Poulose wrote: > > By inconsistent, I meant the registers provides values which are not > the same on two different CPUs of the *same type*. And it is expected > that two different CPU/ETM implementations will have different PIDs. > SDM845 has 4 Kryo 385 Gold (ARM A75) + 4 Kryo 385 Silver (ARM A55), so the PID values should be same for 4 ETMs atleast. But here one pid value(001bb803) is same for 6 ETMs and other one for 2 ETMs(001bb802) which seems odd and hence the doubt if these pids are even valid ones. >> >> Below are the PIDs read for SDM845: >> >> [ 5.996448] resname=etm@7040000 pid=001bb803 >> [ 6.052891] resname=etm@7140000 pid=001bb803 >> >> <snip> .. (Same pid=001bb803 for etm@7240000 to etm@7540000 but differs >> for other 2 cpus as shown below) >> >> [ 6.266687] resname=etm@7640000 pid=001bb802 >> [ 6.329171] resname=etm@7740000 pid=001bb802 >> >> This is the case for MSM8996 also as shown below where PID >> value is not correct and has to be hardcoded. > > They differ because they are two different types of CPU cores (and thus > different ETM PIDs). What does the Register descriptions say for > the Cores ? > > To me it looks like there are two different types of Qualcomm > Cores with their respective ETMs which are missing in the ETM4x > driver and we are trying to "make the ETM" work by faking it as > something else, which is not nice. I would rather prefer > to add the appropriate masks and the expected value for these > two different ETM implementations and be done with it, instead > of faking it in all the DTs where these cores appear. > ETM4x driver does not have entries for A55 and A75. Could you please let me know the PIDs for these CPUs so that we can compare? >> >> For MSM8996: >> >> resname=etm@3b40000 pid=102f0205 > > I don't know what CPUs the MSM8996 have. If they don't have A53, you > must add the actual PIDs to the table once and for all. > But again, this PID is some invalid value. And does not correspond to any of the ARM CPU cores and would be MSM8996 specific. MSM8996 has 2+2 Kryo cores which are not ARM derivative as SDM845 if I am right. >> >>>> + etm@7040000 { >>>> + compatible = "arm,coresight-etm4x", "arm,primecell"; >>>> + arm,primecell-periphid = <0x000bb95d> > + >>>> reg = <0 0x07040000 0 0x1000>; >>>> + >>>> + cpu = <&CPU0>; >>>> + >>> >>> You seem to be specifying the PID of A53 ETM all over, while at least >>> one of your cores is ETMv4.2 (from the other patch) and A53 is not >>> ETMv4.2. As above, it would be good to add the PID to the table. >>> >> >> As explained in above comment, PID values read are not correct. Please >> let me know if I am not clear. > > There is no measure for "correctness" here. If the ETM exposes different > PID than what you expect from the TRM, then we could think of overriding > it. Otherwise please add the PIDs to the table. > This is exactly the case, ETM PID registers are exposing some invalid value and hence we override in DT. Thanks, Sai
Hi Sai, On 01/22/2019 04:48 PM, Sai Prakash Ranjan wrote: > Hi Suzuki, > > On 1/22/2019 9:38 PM, Suzuki K Poulose wrote: >> >> By inconsistent, I meant the registers provides values which are not >> the same on two different CPUs of the *same type*. And it is expected >> that two different CPU/ETM implementations will have different PIDs. >> > > SDM845 has 4 Kryo 385 Gold (ARM A75) + 4 Kryo 385 Silver (ARM A55), > so the PID values should be same for 4 ETMs atleast. But here one > pid value(001bb803) is same for 6 ETMs and other one for 2 > ETMs(001bb802) which seems odd and hence the doubt if these pids > are even valid ones. Have you checked other SoCs with A55 for the ETM PID ? The drivers usually only care about PID0[7-0], PID1[7-0], PID2[3-0] and ignores the other fields that may change over revisions of the core. So, in your case the ETM ID could be treated as 0xbb802 and 0xbb803. > >>> >>> Below are the PIDs read for SDM845: >>> >>> [ 5.996448] resname=etm@7040000 pid=001bb803 >>> [ 6.052891] resname=etm@7140000 pid=001bb803 >>> >>> <snip> .. (Same pid=001bb803 for etm@7240000 to etm@7540000 but differs >>> for other 2 cpus as shown below) So thats 4 CPUs with 0x1bb803. >>> >>> [ 6.266687] resname=etm@7640000 pid=001bb802 >>> [ 6.329171] resname=etm@7740000 pid=001bb802 >>> >>> This is the case for MSM8996 also as shown below where PID >>> value is not correct and has to be hardcoded. >> >> They differ because they are two different types of CPU cores (and >> thus different ETM PIDs). What does the Register descriptions say for >> the Cores ? >> >> To me it looks like there are two different types of Qualcomm >> Cores with their respective ETMs which are missing in the ETM4x >> driver and we are trying to "make the ETM" work by faking it as >> something else, which is not nice. I would rather prefer >> to add the appropriate masks and the expected value for these >> two different ETM implementations and be done with it, instead >> of faking it in all the DTs where these cores appear. >> > > ETM4x driver does not have entries for A55 and A75. Could you please > let me know the PIDs for these CPUs so that we can compare? FWIW, here is the PID list: A75: 0xB_BD_0A A55: 0xB_BD_05 Btw, I am not sure if the ETM has been changed/tuned for the Cores in SDM845. Please could you get this clarified internally within your organisation ? > >>> >>> For MSM8996: >>> >>> resname=etm@3b40000 pid=102f0205 >> >> I don't know what CPUs the MSM8996 have. If they don't have A53, you >> must add the actual PIDs to the table once and for all. >> > > But again, this PID is some invalid value. And does not correspond > to any of the ARM CPU cores and would be MSM8996 specific. > MSM8996 has 2+2 Kryo cores which are not ARM derivative as SDM845 > if I am right. As long as the JEP106 coding standard is followed and is indicated in the appropriate fields (PIDR2[3]), we should be fine. In the case above: PID of the ETM is 0xf0205, implies JEP106 code[6:0] of the designer is 0x70 and ETM part number is : 0x205, which makes sense to me. > >>> >>>>> + etm@7040000 { >>>>> + compatible = "arm,coresight-etm4x", "arm,primecell"; >>>>> + arm,primecell-periphid = <0x000bb95d> > + reg = <0 >>>>> 0x07040000 0 0x1000>; >>>>> + >>>>> + cpu = <&CPU0>; >>>>> + >>>> >>>> You seem to be specifying the PID of A53 ETM all over, while at least >>>> one of your cores is ETMv4.2 (from the other patch) and A53 is not >>>> ETMv4.2. As above, it would be good to add the PID to the table. >>>> >>> >>> As explained in above comment, PID values read are not correct. >>> Please let me know if I am not clear. >> >> There is no measure for "correctness" here. If the ETM exposes different >> PID than what you expect from the TRM, then we could think of overriding >> it. Otherwise please add the PIDs to the table. >> > > This is exactly the case, ETM PID registers are exposing some invalid > value and hence we override in DT. It would be good to have this clarified. I will check with the internal teams here for any details. Thanks Suzuki
Hi Suzuki, On 1/23/2019 1:42 AM, Suzuki K Poulose wrote: > Hi Sai, > > On 01/22/2019 04:48 PM, Sai Prakash Ranjan wrote: >> Hi Suzuki, >> [..] >> >> SDM845 has 4 Kryo 385 Gold (ARM A75) + 4 Kryo 385 Silver (ARM A55), >> so the PID values should be same for 4 ETMs atleast. But here one >> pid value(001bb803) is same for 6 ETMs and other one for 2 >> ETMs(001bb802) which seems odd and hence the doubt if these pids >> are even valid ones. > > Have you checked other SoCs with A55 for the ETM PID ? The drivers > usually only care about PID0[7-0], PID1[7-0], PID2[3-0] and ignores > the other fields that may change over revisions of the core. So, in your > case the ETM ID could be treated as 0xbb802 and 0xbb803. > Very sorry to have mislead you here. I checked again today on SDM845 and as you said 4 ETMs based on A75 has 0xbb803 and other 4 ETMs based on A55 has 0Xbb803. I wrongly mentioned it as 6 and 2. [ 6.688809] resname=etm@7040000 pid = 0x1bb803 [ 6.694957] [ 6.694957] resname=etm@7140000 pid = 0x1bb803 [ 6.701135] [ 6.701135] resname=etm@7240000 pid = 0x1bb803 [ 6.707256] [ 6.707256] resname=etm@7340000 pid = 0x1bb803 [ 6.713454] [ 6.713454] resname=etm@7440000 pid = 0x1bb802 [ 6.719621] [ 6.719621] resname=etm@7540000 pid = 0x1bb802 [ 6.725814] [ 6.725814] resname=etm@7640000 pid = 0x1bb802 [ 6.731971] [ 6.731971] resname=etm@7740000 pid = 0x1bb802 So is it ok to add these to table as below in etm4x driver with the following comment since these do not exactly match A75 and A55 PIDs which you provided? Or any other way you prefer? @@ -1079,6 +1079,10 @@ static const struct amba_id etm4_ids[] = { ETM4x_AMBA_ID(0x000bb95a), /* Cortex-A72 */ ETM4x_AMBA_ID(0x000bb959), /* Cortex-A73 */ ETM4x_AMBA_ID(0x000bb9da), /* Cortex-A35 */ + ETM4x_AMBA_ID(0x000f0211), /* Qualcomm Kryo */ + ETM4x_AMBA_ID(0x000f0205), /* Qualcomm Kryo */ + ETM4x_AMBA_ID(0x000bb803), /* Qualcomm Kryo 385 Cortex-A75 */ + ETM4x_AMBA_ID(0x000bb802), /* Qualcomm Kryo 385 Cortex-A55 */ {}, }; For msm8996, cpu debug module pid returned is same as ETM which is causing the probe failure for cpu debug coresight module as shown in below logs. For this case, I tried adding these ids to cpu debug driver, but it splits some errors (coresight-cpu-debug: probe of 3840000.etm failed with error -16) since the ids are same. Can we override for this case or there is something else we can do here? [ 5.480629] resname=debug@3810000 pid = 0x102f0211 [ 5.480920] OF: graph: no port node found in /soc/debug@3810000 [ 5.513214] coresight-etm4x: probe of 3810000.debug failed with error -22 [ 5.524362] [ 5.524362] resname=debug@3910000 pid = 0x102f0211 [ 5.524888] OF: graph: no port node found in /soc/debug@3910000 [ 5.537586] coresight-etm4x: probe of 3910000.debug failed with error -22 [ 5.541481] [ 5.549643] resname=debug@3a10000 pid = 0x102f0205 [ 5.580990] OF: graph: no port node found in /soc/debug@3a10000 [ 5.586817] coresight-etm4x: probe of 3a10000.debug failed with error -22 [ 5.592082] [ 5.592629] resname=debug@3b10000 pid = 0x102f0205 [ 5.604922] OF: graph: no port node found in /soc/debug@3b10000 [ 5.611234] coresight-etm4x: probe of 3b10000.debug failed with error -22 Thanks, Sai
On Wed, 23 Jan 2019 at 05:12, Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote: > > Hi Suzuki, > > On 1/23/2019 1:42 AM, Suzuki K Poulose wrote: > > Hi Sai, > > > > On 01/22/2019 04:48 PM, Sai Prakash Ranjan wrote: > >> Hi Suzuki, > >> > [..] > >> > >> SDM845 has 4 Kryo 385 Gold (ARM A75) + 4 Kryo 385 Silver (ARM A55), > >> so the PID values should be same for 4 ETMs atleast. But here one > >> pid value(001bb803) is same for 6 ETMs and other one for 2 > >> ETMs(001bb802) which seems odd and hence the doubt if these pids > >> are even valid ones. > > > > Have you checked other SoCs with A55 for the ETM PID ? The drivers > > usually only care about PID0[7-0], PID1[7-0], PID2[3-0] and ignores > > the other fields that may change over revisions of the core. So, in your > > case the ETM ID could be treated as 0xbb802 and 0xbb803. > > > > Very sorry to have mislead you here. I checked again today on SDM845 and > as you said 4 ETMs based on A75 has 0xbb803 and other 4 ETMs based on > A55 has 0Xbb803. I wrongly mentioned it as 6 and 2. > > [ 6.688809] resname=etm@7040000 pid = 0x1bb803 > [ 6.694957] > [ 6.694957] resname=etm@7140000 pid = 0x1bb803 > [ 6.701135] > [ 6.701135] resname=etm@7240000 pid = 0x1bb803 > [ 6.707256] > [ 6.707256] resname=etm@7340000 pid = 0x1bb803 > [ 6.713454] > [ 6.713454] resname=etm@7440000 pid = 0x1bb802 > [ 6.719621] > [ 6.719621] resname=etm@7540000 pid = 0x1bb802 > [ 6.725814] > [ 6.725814] resname=etm@7640000 pid = 0x1bb802 > [ 6.731971] > [ 6.731971] resname=etm@7740000 pid = 0x1bb802 > Ok, so that makes sense. > So is it ok to add these to table as below in etm4x driver with the > following comment since these do not exactly match A75 and A55 PIDs > which you provided? Or any other way you prefer? That depends on whether the ETMs have been modified at all, something Suzuki has asked to be clarified. If ETMs have been modified then we need to understand how they differ from the driver's implementation. If the implementations are the same: > > @@ -1079,6 +1079,10 @@ static const struct amba_id etm4_ids[] = { > ETM4x_AMBA_ID(0x000bb95a), /* Cortex-A72 */ > ETM4x_AMBA_ID(0x000bb959), /* Cortex-A73 */ > ETM4x_AMBA_ID(0x000bb9da), /* Cortex-A35 */ > + ETM4x_AMBA_ID(0x000f0211), /* Qualcomm Kryo */ > + ETM4x_AMBA_ID(0x000f0205), /* Qualcomm Kryo */ What version of the Kryo CPU? And the above will need to be in a separate patch with the modifications to address the problem you mentionned below. > + ETM4x_AMBA_ID(0x000bb803), /* Qualcomm Kryo 385 > Cortex-A75 */ > + ETM4x_AMBA_ID(0x000bb802), /* Qualcomm Kryo 385 > Cortex-A55 */ Please add them in chronological order. > {}, > }; > > For msm8996, cpu debug module pid returned is same as ETM > which is causing the probe failure for cpu debug coresight module > as shown in below logs. > For this case, I tried adding these ids to cpu debug driver, but it > splits some errors (coresight-cpu-debug: probe of 3840000.etm failed > with error -16) since the ids are same. Can we override for this case > or there is something else we can do here? That is another problem. See this patchset [1] from Mike Leach for a description of the problem and how to fix it. [1]. https://lkml.org/lkml/2018/12/7/784 > > [ 5.480629] resname=debug@3810000 pid = 0x102f0211 > [ 5.480920] OF: graph: no port node found in /soc/debug@3810000 > [ 5.513214] coresight-etm4x: probe of 3810000.debug failed with error -22 > [ 5.524362] > [ 5.524362] resname=debug@3910000 pid = 0x102f0211 > [ 5.524888] OF: graph: no port node found in /soc/debug@3910000 > [ 5.537586] coresight-etm4x: probe of 3910000.debug failed with error -22 > [ 5.541481] > [ 5.549643] resname=debug@3a10000 pid = 0x102f0205 > [ 5.580990] OF: graph: no port node found in /soc/debug@3a10000 > [ 5.586817] coresight-etm4x: probe of 3a10000.debug failed with error -22 > [ 5.592082] > [ 5.592629] resname=debug@3b10000 pid = 0x102f0205 > [ 5.604922] OF: graph: no port node found in /soc/debug@3b10000 > [ 5.611234] coresight-etm4x: probe of 3b10000.debug failed with error -22 > > > Thanks, > Sai > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation
Hi Mathieu, On 1/24/2019 12:44 AM, Mathieu Poirier wrote: > On Wed, 23 Jan 2019 at 05:12, Sai Prakash Ranjan > <saiprakash.ranjan@codeaurora.org> wrote: > > That depends on whether the ETMs have been modified at all, something > Suzuki has asked to be clarified. If ETMs have been modified then we > need to understand how they differ from the driver's implementation. We had asked hardware team for clarification regarding this. Let me poke them again. As for the driver, downstream implementation also uses the same driver, so I am not sure what do you mean by differing from the driver's implementation. > If the implementations are the same: > >> >> @@ -1079,6 +1079,10 @@ static const struct amba_id etm4_ids[] = { >> ETM4x_AMBA_ID(0x000bb95a), /* Cortex-A72 */ >> ETM4x_AMBA_ID(0x000bb959), /* Cortex-A73 */ >> ETM4x_AMBA_ID(0x000bb9da), /* Cortex-A35 */ >> + ETM4x_AMBA_ID(0x000f0211), /* Qualcomm Kryo */ >> + ETM4x_AMBA_ID(0x000f0205), /* Qualcomm Kryo */ > > What version of the Kryo CPU? And the above will need to be in a > separate patch with the modifications to address the problem you > mentionned below. > There is no Kryo version for MSM8996 (its only given as Kryo), MSM8998 onwards we have Kryo versions like Kryo 280 and so on. Hence I skipped for this one and added the version for SDM845. >> + ETM4x_AMBA_ID(0x000bb803), /* Qualcomm Kryo 385 >> Cortex-A75 */ >> + ETM4x_AMBA_ID(0x000bb802), /* Qualcomm Kryo 385 >> Cortex-A55 */ > > Please add them in chronological order. > Sure, will do it. >> {}, >> }; >> >> For msm8996, cpu debug module pid returned is same as ETM >> which is causing the probe failure for cpu debug coresight module >> as shown in below logs. >> For this case, I tried adding these ids to cpu debug driver, but it >> splits some errors (coresight-cpu-debug: probe of 3840000.etm failed >> with error -16) since the ids are same. Can we override for this case >> or there is something else we can do here? > > That is another problem. See this patchset [1] from Mike Leach for a > description of the problem and how to fix it. > > [1]. https://lkml.org/lkml/2018/12/7/784 > Thanks a lot for this link. I will check this out. - Sai
Hi Sai, On 23/01/2019 12:11, Sai Prakash Ranjan wrote: > Hi Suzuki, > > On 1/23/2019 1:42 AM, Suzuki K Poulose wrote: >> Hi Sai, >> >> On 01/22/2019 04:48 PM, Sai Prakash Ranjan wrote: >>> Hi Suzuki, >>> > [..] >>> >>> SDM845 has 4 Kryo 385 Gold (ARM A75) + 4 Kryo 385 Silver (ARM A55), >>> so the PID values should be same for 4 ETMs atleast. But here one >>> pid value(001bb803) is same for 6 ETMs and other one for 2 >>> ETMs(001bb802) which seems odd and hence the doubt if these pids >>> are even valid ones. >> >> Have you checked other SoCs with A55 for the ETM PID ? The drivers >> usually only care about PID0[7-0], PID1[7-0], PID2[3-0] and ignores >> the other fields that may change over revisions of the core. So, in your >> case the ETM ID could be treated as 0xbb802 and 0xbb803. >> > > Very sorry to have mislead you here. I checked again today on SDM845 and > as you said 4 ETMs based on A75 has 0xbb803 and other 4 ETMs based on > A55 has 0Xbb803. I wrongly mentioned it as 6 and 2. > > [ 6.688809] resname=etm@7040000 pid = 0x1bb803 > [ 6.694957] > [ 6.694957] resname=etm@7140000 pid = 0x1bb803 > [ 6.701135] > [ 6.701135] resname=etm@7240000 pid = 0x1bb803 > [ 6.707256] > [ 6.707256] resname=etm@7340000 pid = 0x1bb803 > [ 6.713454] > [ 6.713454] resname=etm@7440000 pid = 0x1bb802 > [ 6.719621] > [ 6.719621] resname=etm@7540000 pid = 0x1bb802 > [ 6.725814] > [ 6.725814] resname=etm@7640000 pid = 0x1bb802 > [ 6.731971] > [ 6.731971] resname=etm@7740000 pid = 0x1bb802 > > So is it ok to add these to table as below in etm4x driver with the > following comment since these do not exactly match A75 and A55 PIDs > which you provided? Or any other way you prefer? > > @@ -1079,6 +1079,10 @@ static const struct amba_id etm4_ids[] = { > ETM4x_AMBA_ID(0x000bb95a), /* Cortex-A72 */ > ETM4x_AMBA_ID(0x000bb959), /* Cortex-A73 */ > ETM4x_AMBA_ID(0x000bb9da), /* Cortex-A35 */ > + ETM4x_AMBA_ID(0x000f0211), /* Qualcomm Kryo */ > + ETM4x_AMBA_ID(0x000f0205), /* Qualcomm Kryo */ > + ETM4x_AMBA_ID(0x000bb803), /* Qualcomm Kryo 385 > Cortex-A75 */ > + ETM4x_AMBA_ID(0x000bb802), /* Qualcomm Kryo 385 > Cortex-A55 */ > {}, That looks fine with me. But as Mathieu said, this needs to be a separate patch. But before all that please could you provide me the PIDR4 value for the Kryo A75 and A55 please ? Kind regards Suzuki
Good day Sai, On Wed, 23 Jan 2019 at 13:18, Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote: > > Hi Mathieu, > > On 1/24/2019 12:44 AM, Mathieu Poirier wrote: > > On Wed, 23 Jan 2019 at 05:12, Sai Prakash Ranjan > > <saiprakash.ranjan@codeaurora.org> wrote: > > > > That depends on whether the ETMs have been modified at all, something > > Suzuki has asked to be clarified. If ETMs have been modified then we > > need to understand how they differ from the driver's implementation. > > We had asked hardware team for clarification regarding this. Let me > poke them again. As for the driver, downstream implementation also > uses the same driver, so I am not sure what do you mean by differing > from the driver's implementation. The driver has been implemented in accordance to ARM's coresight technical reference manual and expects the HW to behave in accordance to that specification. Here we want to make sure the IP on your board is conformant to the same specification. If not then the driver needs to be made flexible to handle both kind IPs. > > > If the implementations are the same: > > > >> > >> @@ -1079,6 +1079,10 @@ static const struct amba_id etm4_ids[] = { > >> ETM4x_AMBA_ID(0x000bb95a), /* Cortex-A72 */ > >> ETM4x_AMBA_ID(0x000bb959), /* Cortex-A73 */ > >> ETM4x_AMBA_ID(0x000bb9da), /* Cortex-A35 */ > >> + ETM4x_AMBA_ID(0x000f0211), /* Qualcomm Kryo */ > >> + ETM4x_AMBA_ID(0x000f0205), /* Qualcomm Kryo */ > > > > What version of the Kryo CPU? And the above will need to be in a > > separate patch with the modifications to address the problem you > > mentionned below. > > > > There is no Kryo version for MSM8996 (its only given as Kryo), MSM8998 > onwards we have Kryo versions like Kryo 280 and so on. Hence I skipped > for this one and added the version for SDM845. Very well. Mathieu > > >> + ETM4x_AMBA_ID(0x000bb803), /* Qualcomm Kryo 385 > >> Cortex-A75 */ > >> + ETM4x_AMBA_ID(0x000bb802), /* Qualcomm Kryo 385 > >> Cortex-A55 */ > > > > Please add them in chronological order. > > > > Sure, will do it. > > >> {}, > >> }; > >> > >> For msm8996, cpu debug module pid returned is same as ETM > >> which is causing the probe failure for cpu debug coresight module > >> as shown in below logs. > >> For this case, I tried adding these ids to cpu debug driver, but it > >> splits some errors (coresight-cpu-debug: probe of 3840000.etm failed > >> with error -16) since the ids are same. Can we override for this case > >> or there is something else we can do here? > > > > That is another problem. See this patchset [1] from Mike Leach for a > > description of the problem and how to fix it. > > > > [1]. https://lkml.org/lkml/2018/12/7/784 > > > > Thanks a lot for this link. I will check this out. > > - Sai > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation
Hi Suzuki, On 1/24/2019 4:49 PM, Suzuki K Poulose wrote: > Hi Sai, > > > That looks fine with me. But as Mathieu said, this needs to be a separate > patch. But before all that please could you provide me the PIDR4 value for > the Kryo A75 and A55 please ? > Sure. PIDR4 value is 0x4. I get it now. So we are looking for JEP106 identification(PIDR1[7:4] and PIDR2[2:0]) and continuation code(PIDR4[3:0]). From ARM Coresight Spec: DES_0, PIDR1 bits[7:4] JEP106 identification code bits[3:0]. DES_1, PIDR2 bits[2:0] JEP106 identification code bits[6:4]. DES_2, PIDR4 bits[3:0] JEP106 continuation code. For SDM845(A75 based): *0xB_B8_03* does indicate that the JEP106 identification code is 0x3B and continuation code is 0x4 which is of ARM and not QCOM(JEP106 ID is 0x70) which is expected. And the other values of PIDR0[0:7] and PIDR1[3:0] are *Implementation defined part numbers* and can be different from ARM A75/A55. I think this clears up case for SDM845. As for MSM8996, it is not based on any ARM derivative and hence the JEP106 ID is of QCOM(0x70) from the value of pid = *0xF_02_11* based on PIDR1[7:4] and PIDR2[2:0]. This clears this as well. Please correct me if I am wrong and also let me know if I can continue with PID addition to table. Thanks, Sai
Good day Mathieu, On 1/24/2019 9:37 PM, Mathieu Poirier wrote: > Good day Sai, > > On Wed, 23 Jan 2019 at 13:18, Sai Prakash Ranjan > <saiprakash.ranjan@codeaurora.org> wrote: >> >> Hi Mathieu, >> >> On 1/24/2019 12:44 AM, Mathieu Poirier wrote: >>> On Wed, 23 Jan 2019 at 05:12, Sai Prakash Ranjan >>> <saiprakash.ranjan@codeaurora.org> wrote: >>> >>> That depends on whether the ETMs have been modified at all, something >>> Suzuki has asked to be clarified. If ETMs have been modified then we >>> need to understand how they differ from the driver's implementation. >> >> We had asked hardware team for clarification regarding this. Let me >> poke them again. As for the driver, downstream implementation also >> uses the same driver, so I am not sure what do you mean by differing >> from the driver's implementation. > > The driver has been implemented in accordance to ARM's coresight > technical reference manual and expects the HW to behave in accordance > to that specification. Here we want to make sure the IP on your board > is conformant to the same specification. If not then the driver needs > to be made flexible to handle both kind IPs. > The HW does behave as per the specification. As discussed in reply to Suzuki, Coresight peripherals do use JEP106 ID of ARM for SDM845 and for MSM8996, the ID is of QCOM(0x70) since it was not based on any ARM derivative. And the etm4x driver handles it all well. Other values of PID registers are implementation defined and can be different from standard ARM cpu core types. Thanks, Sai
On Thu, 24 Jan 2019 at 11:21, Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote: > > Hi Suzuki, > > On 1/24/2019 4:49 PM, Suzuki K Poulose wrote: > > Hi Sai, > > > > > > That looks fine with me. But as Mathieu said, this needs to be a separate > > patch. But before all that please could you provide me the PIDR4 value for > > the Kryo A75 and A55 please ? > > > > Sure. > > PIDR4 value is 0x4. > > I get it now. So we are looking for JEP106 identification(PIDR1[7:4] and > PIDR2[2:0]) and continuation code(PIDR4[3:0]). > > From ARM Coresight Spec: > > DES_0, PIDR1 bits[7:4] JEP106 identification code bits[3:0]. > DES_1, PIDR2 bits[2:0] JEP106 identification code bits[6:4]. > DES_2, PIDR4 bits[3:0] JEP106 continuation code. > > For SDM845(A75 based): > > *0xB_B8_03* does indicate that the JEP106 identification > code is 0x3B and continuation code is 0x4 which is of ARM and not > QCOM(JEP106 ID is 0x70) which is expected. > > And the other values of PIDR0[0:7] and PIDR1[3:0] are *Implementation > defined part numbers* and can be different from ARM A75/A55. > > I think this clears up case for SDM845. > > As for MSM8996, it is not based on any ARM derivative and hence the > JEP106 ID is of QCOM(0x70) from the value of pid = *0xF_02_11* > based on PIDR1[7:4] and PIDR2[2:0]. This clears this as well. > > Please correct me if I am wrong and also let me know if I can > continue with PID addition to table. Please proceed. > > Thanks, > Sai > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation
On 1/28/2019 10:45 PM, Mathieu Poirier wrote: >> For SDM845(A75 based): >> >> *0xB_B8_03* does indicate that the JEP106 identification >> code is 0x3B and continuation code is 0x4 which is of ARM and not >> QCOM(JEP106 ID is 0x70) which is expected. >> >> And the other values of PIDR0[0:7] and PIDR1[3:0] are *Implementation >> defined part numbers* and can be different from ARM A75/A55. >> >> I think this clears up case for SDM845. >> >> As for MSM8996, it is not based on any ARM derivative and hence the >> JEP106 ID is of QCOM(0x70) from the value of pid = *0xF_02_11* >> based on PIDR1[7:4] and PIDR2[2:0]. This clears this as well. >> >> Please correct me if I am wrong and also let me know if I can >> continue with PID addition to table. > > Please proceed. > Thanks Mathieu, posted the next version now.
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi index c27cbd3bcb0a..2c589f7f13a8 100644 --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi @@ -1348,6 +1348,454 @@ }; }; + stm@6002000 { + compatible = "arm,coresight-stm", "arm,primecell"; + reg = <0 0x06002000 0 0x1000>, + <0 0x16280000 0 0x180000>; + reg-names = "stm-base", "stm-stimulus-base"; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + stm_out: endpoint { + remote-endpoint = + <&funnel0_in7>; + }; + }; + }; + }; + + funnel@6041000 { + compatible = "arm,coresight-funnel", "arm,primecell"; + reg = <0 0x06041000 0 0x1000>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + funnel0_out: endpoint { + remote-endpoint = + <&merge_funnel_in0>; + }; + }; + }; + + in-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@7 { + reg = <7>; + funnel0_in7: endpoint { + remote-endpoint = <&stm_out>; + }; + }; + }; + }; + + funnel@6043000 { + compatible = "arm,coresight-funnel", "arm,primecell"; + reg = <0 0x06043000 0 0x1000>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + funnel2_out: endpoint { + remote-endpoint = + <&merge_funnel_in2>; + }; + }; + }; + + in-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@5 { + reg = <5>; + funnel2_in5: endpoint { + remote-endpoint = + <&apss_merge_funnel_out>; + }; + }; + }; + }; + + funnel@6045000 { + compatible = "arm,coresight-funnel", "arm,primecell"; + reg = <0 0x06045000 0 0x1000>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + merge_funnel_out: endpoint { + remote-endpoint = <&etf_in>; + }; + }; + }; + + in-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + merge_funnel_in0: endpoint { + remote-endpoint = + <&funnel0_out>; + }; + }; + + port@2 { + reg = <2>; + merge_funnel_in2: endpoint { + remote-endpoint = + <&funnel2_out>; + }; + }; + }; + }; + + replicator@6046000 { + compatible = "arm,coresight-dynamic-replicator", "arm,primecell"; + reg = <0 0x06046000 0 0x1000>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + replicator_out: endpoint { + remote-endpoint = <&etr_in>; + }; + }; + }; + + in-ports { + port { + replicator_in: endpoint { + remote-endpoint = <&etf_out>; + }; + }; + }; + }; + + etf@6047000 { + compatible = "arm,coresight-tmc", "arm,primecell"; + reg = <0 0x06047000 0 0x1000>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + etf_out: endpoint { + remote-endpoint = + <&replicator_in>; + }; + }; + }; + + in-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + etf_in: endpoint { + remote-endpoint = + <&merge_funnel_out>; + }; + }; + }; + }; + + etr@6048000 { + compatible = "arm,coresight-tmc", "arm,primecell"; + reg = <0 0x06048000 0 0x1000>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + arm,scatter-gather; + + in-ports { + port { + etr_in: endpoint { + remote-endpoint = + <&replicator_out>; + }; + }; + }; + }; + + /* + * On QCOM SDM845, we bypass the normal AMBA bus discovery + * method by forcing the peripheral ID because of the wrong + * value read from ETM PID registers. + */ + + etm@7040000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + arm,primecell-periphid = <0x000bb95d>; + reg = <0 0x07040000 0 0x1000>; + + cpu = <&CPU0>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + etm0_out: endpoint { + remote-endpoint = + <&apss_funnel_in0>; + }; + }; + }; + }; + + etm@7140000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + arm,primecell-periphid = <0x000bb95d>; + reg = <0 0x07140000 0 0x1000>; + + cpu = <&CPU1>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + etm1_out: endpoint { + remote-endpoint = + <&apss_funnel_in1>; + }; + }; + }; + }; + + etm@7240000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + arm,primecell-periphid = <0x000bb95d>; + reg = <0 0x07240000 0 0x1000>; + + cpu = <&CPU2>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + etm2_out: endpoint { + remote-endpoint = + <&apss_funnel_in2>; + }; + }; + }; + }; + + etm@7340000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + arm,primecell-periphid = <0x000bb95d>; + reg = <0 0x07340000 0 0x1000>; + + cpu = <&CPU3>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + etm3_out: endpoint { + remote-endpoint = + <&apss_funnel_in3>; + }; + }; + }; + }; + + etm@7440000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + arm,primecell-periphid = <0x000bb95d>; + reg = <0 0x07440000 0 0x1000>; + + cpu = <&CPU4>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + etm4_out: endpoint { + remote-endpoint = + <&apss_funnel_in4>; + }; + }; + }; + }; + + etm@7540000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + arm,primecell-periphid = <0x000bb95d>; + reg = <0 0x07540000 0 0x1000>; + + cpu = <&CPU5>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + etm5_out: endpoint { + remote-endpoint = + <&apss_funnel_in5>; + }; + }; + }; + }; + + etm@7640000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + arm,primecell-periphid = <0x000bb95d>; + reg = <0 0x07640000 0 0x1000>; + + cpu = <&CPU6>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + etm6_out: endpoint { + remote-endpoint = + <&apss_funnel_in6>; + }; + }; + }; + }; + + etm@7740000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + arm,primecell-periphid = <0x000bb95d>; + reg = <0 0x07740000 0 0x1000>; + + cpu = <&CPU7>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + etm7_out: endpoint { + remote-endpoint = + <&apss_funnel_in7>; + }; + }; + }; + }; + + funnel@7800000 { /* APSS Funnel */ + compatible = "arm,coresight-funnel", "arm,primecell"; + reg = <0 0x07800000 0 0x1000>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + apss_funnel_out: endpoint { + remote-endpoint = + <&apss_merge_funnel_in>; + }; + }; + }; + + in-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + apss_funnel_in0: endpoint { + remote-endpoint = + <&etm0_out>; + }; + }; + + port@1 { + reg = <1>; + apss_funnel_in1: endpoint { + remote-endpoint = + <&etm1_out>; + }; + }; + + port@2 { + reg = <2>; + apss_funnel_in2: endpoint { + remote-endpoint = + <&etm2_out>; + }; + }; + + port@3 { + reg = <3>; + apss_funnel_in3: endpoint { + remote-endpoint = + <&etm3_out>; + }; + }; + + port@4 { + reg = <4>; + apss_funnel_in4: endpoint { + remote-endpoint = + <&etm4_out>; + }; + }; + + port@5 { + reg = <5>; + apss_funnel_in5: endpoint { + remote-endpoint = + <&etm5_out>; + }; + }; + + port@6 { + reg = <6>; + apss_funnel_in6: endpoint { + remote-endpoint = + <&etm6_out>; + }; + }; + + port@7 { + reg = <7>; + apss_funnel_in7: endpoint { + remote-endpoint = + <&etm7_out>; + }; + }; + }; + }; + + funnel@7810000 { + compatible = "arm,coresight-funnel", "arm,primecell"; + reg = <0 0x07810000 0 0x1000>; + + power-domains = <&aoss_qmp AOSS_QMP_QDSS_CLK>; + + out-ports { + port { + apss_merge_funnel_out: endpoint { + remote-endpoint = + <&funnel2_in5>; + }; + }; + }; + + in-ports { + port { + apss_merge_funnel_in: endpoint { + remote-endpoint = + <&apss_funnel_out>; + }; + }; + }; + }; + usb_1_hsphy: phy@88e2000 { compatible = "qcom,sdm845-qusb2-phy"; reg = <0x88e2000 0x400>;
Add coresight components found on Qualcomm SDM845 SoC. Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> --- Depends on AOSS QMP side channel patches and AMBA bus pclk change by Bjorn Andersson [1][2]. Also depends on patch ("arm64: dts: qcom: sdm845: Increase address and size cells for soc") [3]. [1] https://lore.kernel.org/lkml/20190106080915.4493-1-bjorn.andersson@linaro.org/ [2] https://lore.kernel.org/lkml/20190106080915.4493-7-bjorn.andersson@linaro.org/ [3] https://lore.kernel.org/lkml/20190117042940.25487-2-bjorn.andersson@linaro.org/ --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 448 +++++++++++++++++++++++++++ 1 file changed, 448 insertions(+)