From mboxrd@z Thu Jan 1 00:00:00 1970 From: Horia Geanta Date: Fri, 27 Jul 2018 14:00:48 +0000 Subject: [U-Boot] [PATCH v5 8/8] armv8: ls1046a: setup SEC ICIDs and fix up device tree References: <20180727095742.17831-1-laurentiu.tudor@nxp.com> <20180727095742.17831-9-laurentiu.tudor@nxp.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 7/27/2018 2:18 PM, Bharat Bhushan wrote: > > >> -----Original Message----- >> From: laurentiu.tudor at nxp.com [mailto:laurentiu.tudor at nxp.com] >> Sent: Friday, July 27, 2018 3:28 PM >> To: u-boot at lists.denx.de; Prabhakar Kushwaha >> ; York Sun >> Cc: Bharat Bhushan ; Horia Geanta >> ; Laurentiu Tudor >> Subject: [PATCH v5 8/8] armv8: ls1046a: setup SEC ICIDs and fix up device >> tree >> >> From: Laurentiu Tudor >> >> 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 >> --- >> .../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? Thanks, Horia