Hello, On 27.07.2018 17:00, Horia Geanta wrote: > On 7/27/2018 2:18 PM, Bharat Bhushan wrote: >> >> >>> -----Original Message----- >>> From: laurentiu.tu...@nxp.com [mailto:laurentiu.tu...@nxp.com] >>> Sent: Friday, July 27, 2018 3:28 PM >>> To: u-boot@lists.denx.de; Prabhakar Kushwaha >>> <prabhakar.kushw...@nxp.com>; York Sun <york....@nxp.com> >>> Cc: Bharat Bhushan <bharat.bhus...@nxp.com>; Horia Geanta >>> <horia.gea...@nxp.com>; Laurentiu Tudor <laurentiu.tu...@nxp.com> >>> Subject: [PATCH v5 8/8] armv8: ls1046a: setup SEC ICIDs and fix up device >>> tree >>> >>> From: Laurentiu Tudor <laurentiu.tu...@nxp.com> >>> >>> Add support for SEC ICID configuration and apply it for ls1046a. >>> Also add code to make the necessary device tree fixups. >>> >>> Signed-off-by: Laurentiu Tudor <laurentiu.tu...@nxp.com> >>> --- >>> .../arm/cpu/armv8/fsl-layerscape/ls1046_ids.c | 14 +++++++++++ >>> .../asm/arch-fsl-layerscape/fsl_icid.h | 25 +++++++++++++++++++ >>> .../asm/arch-fsl-layerscape/immap_lsch2.h | 8 ++++++ >>> 3 files changed, 47 insertions(+) >>> >>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c >>> b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c >>> index 30c7d8d28a..bc2fe283a1 100644 >>> --- a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c >>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c >>> @@ -40,6 +40,20 @@ struct icid_id_table icid_tbl[] = { >>> SET_EDMA_ICID(FSL_EDMA_STREAM_ID), >>> SET_ETR_ICID(FSL_ETR_STREAM_ID), >>> SET_DEBUG_ICID(FSL_DEBUG_STREAM_ID), >>> +#ifdef CONFIG_FSL_CAAM >>> + SET_SEC_QI_ICID(FSL_DPAA1_STREAM_ID_START + 2), >>> + SET_SEC_JR_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 3), >>> + SET_SEC_JR_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 4), >>> + SET_SEC_JR_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 5), >>> + SET_SEC_JR_ICID_ENTRY(3, FSL_DPAA1_STREAM_ID_START + 6), >>> + SET_SEC_RTIC_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 2), >>> + SET_SEC_RTIC_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 2), >>> + SET_SEC_RTIC_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 2), >>> + SET_SEC_RTIC_ICID_ENTRY(3, FSL_DPAA1_STREAM_ID_START + 2), >>> + SET_SEC_DECO_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 2), >>> + SET_SEC_DECO_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 2), >>> + SET_SEC_DECO_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 2), >> >> Here goes my understanding: >> >> RTIC are independent device from JR and QI, So they should be assigned >> different unique steam-id. Also each RTIC are independent device, so each >> RTIC can also be assigned separate stream-id. >> While we can decide to use one stream-id for all RITCs and add a comment >> that they are not partitionable. >> >> DECOs can take work from QI or JRs, and in that case they will use the >> stream-id of the respective QI or JR, and the stream-id programmed in DECOs >> is not used. >> While DECOs can be used directly (not via JR and QI) and in that case it >> will use the strema-id programmed in it. So in this case also we should be >> using unique stream-id for each DECO if partitionable or one for all DECOs >> > Considering the HW offers the mechanism to program the ICIDs (and assuming the > HW is correctly designed), it follows that these HW blocks could be used > independently. > > The only way to implement a *mechanism* is to provide different ICIDs for all > the blocks. > Any other solution would be imposing a *policy*, thus restricting user's > possibilities. Admittedly there are use cases less "popular" than others, but > if > possible it would be best not to decide for the user and provide full > flexibility. > > Is there a resource (ICID values) shortage? >
No. I can change the patch to have distinct ICIDs and resubmit. Please let me know if you agree on this. --- Best Regards, Laurentiu _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
