From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by mx.groups.io with SMTP id smtpd.web09.224.1582224316829197602 for ; Thu, 20 Feb 2020 10:45:17 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=HGkFn16J; spf=pass (domain: nuviainc.com, ip: 209.85.128.67, mailfrom: leif@nuviainc.com) Received: by mail-wm1-f67.google.com with SMTP id s10so3133050wmh.3 for ; Thu, 20 Feb 2020 10:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=iUbWVKLxQkn01SL38oX4deXwE1HkDMBpmORgud4UfZQ=; b=HGkFn16Jxv3pPXfJYroWkjPYTF3LtJf+HcQK0GdWLa68DxeHl2EveN91JojK/LuLA2 vSy3ON534TU63WJU97ESp5NM/x9oE0QN1FZYDZQ5Qk1aOnA/fOfekM9hHaNTPECiTezi lt3o/dqOYlZRwVxtDgFnE40/lqJ28/2lOYLCyFHPJcFRFoUitis0iQ/CEAMs5jNi4TQ6 EdEL0CYBA7THK2/oUdGwgiQni+6o361mdAK9Bg0sC6+8oijBj+4ptcH+M2788+O6+Xcu d6WA23eHgdVHX8rTSf6TymRCXpHF+QMUsaczI98EYdS8t1r4hAXRwBPY/Nt3w4I3760N W07A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=iUbWVKLxQkn01SL38oX4deXwE1HkDMBpmORgud4UfZQ=; b=gx+LoIeAW7HZjfrJR5pACDxYyKGY07CVsRWOHPKX2KcoxIeju8yKt5xpZaVff3f/uy P06qCjtjotnDZ1tEGj/3nm0W1I57j1exvuFZON8Lt/VpU7o6RNEJTeKp5y3HHWuV5u78 CAPncuh0KzaZZcy161KR5R4Wxn2A1e+9TzWOLt9IUHt60HMP8F8FQZdeOkfFeaM1yqOO pRmlEtz12VMcKBY/z2+fZSWGjX9XPyXB3w4fkzUTtPQNXjJZp/Zx7r0N3vr2gMJn+bZR R09M0Ne+lR5NybChg3JyKYD5FInGsoVAdPHWlBjFz4e3hHxG9+jGR1M9jZyQfoGTBMSQ WSDQ== X-Gm-Message-State: APjAAAWXgO+TZLRIJjNxnRX7UGchnJIS9EJXtL33gObk/AxShHMTwYe9 RxqVbooqba/2VgNO69QI6pIOjg== X-Google-Smtp-Source: APXvYqwd8RqUfcR9M57USZeWaF2ClaHSPhpemyByAoBX388oHA4Pre006FMqPa1X70F0aqXpCkQMFw== X-Received: by 2002:a1c:4c10:: with SMTP id z16mr5808256wmf.136.1582224315267; Thu, 20 Feb 2020 10:45:15 -0800 (PST) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id c77sm263601wmd.12.2020.02.20.10.45.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2020 10:45:14 -0800 (PST) Date: Thu, 20 Feb 2020 18:45:13 +0000 From: "Leif Lindholm" To: Pankaj Bansal Cc: Meenakshi Aggarwal , Michael D Kinney , Varun Sethi , "devel@edk2.groups.io" Subject: Re: [PATCH 14/19] Silicon/NXP/LS1043A: Replce SocLib Message-ID: <20200220184513.GG23627@bivouac.eciton.net> References: <20200207124328.8723-1-pankaj.bansal@nxp.com> <20200207124328.8723-15-pankaj.bansal@nxp.com> <20200211133518.GX23627@bivouac.eciton.net> <20200212225017.GI23627@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 13, 2020 at 11:00:10 +0000, Pankaj Bansal wrote: > > You're talking about the ... bits that remain the same on migrating the > > processors from PPC to ARM? > > I am not sure if the concept of Chassis was there in PPC or not? > It's just the way the SOCs are designed. SOCs that are designed > around same chassis, reuse most of the components. > It cuts down on s/w development time, because most of the s/w can be > reused. Sure, I'm just trying to determine whether this is something I sort of already understand (like QUICC -> PowerQUICC), or something more internal. > > > We have kept the code also in such a way. Which is why we have made > > > Soc Package part of Chassis Package. > > > > > > SocLib provides services to PlatformLib. ChassisLib provides services > > > to SocLib. > > > Which is why we have made SocGetMpCoreInfo as weak function and > > > implemented it in ChassisLib (Patch 11/19) This ensures that code can > > > be reused for all SOCs belonging to same chassis. > > > If any future SOC implements this feature in different way, then this > > > API can be overwritten in SocLib > > > > > > SOCs belonging to same Chassis share many same traits. > > > e.g. the SOC memory map is usually common for all SOCs belonging to > > > same Chassis. > > > > OK, this sounds valid. But one follow-up question: why add the hierarchy at all? > > From a (human) discoverability standpoint, if someone is looking for the code > > for a specific SoC, they will be looking for that SoC, not some abstraction of it. > > > > So I agree it makes sense that chassis are not kept under SoC, but I am asking if > > it would not make more sense to keep them on the same level? > > Any SoCs depending on Pcds defined by a specific chassis could access those by > > importing the package fr that chassis. > > Hmm. This can be done. We can make Silicon/NXP/Chassis2 and > Silicon/NXP/LS1043A. Sorry, I think I forgot to reply to this. Yes, this would be most excellent. Best Regards, Leif