From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kim Phillips Date: Tue, 8 Jun 2010 13:43:36 -0500 Subject: [U-Boot] [PATCH V2 03/10] 83xx/85xx/86xx: LBC register cleanup In-Reply-To: <151DEE07-07CE-4272-88F6-9AAD50BBA2DA@kernel.crashing.org> References: <1275502329-23457-1-git-send-email-beckyb@kernel.crashing.org> <1275502329-23457-2-git-send-email-beckyb@kernel.crashing.org> <1275502329-23457-3-git-send-email-beckyb@kernel.crashing.org> <1275502329-23457-4-git-send-email-beckyb@kernel.crashing.org> <20100603193751.0bf13487.kim.phillips@freescale.com> <3CDDBC61-CE75-4EE0-963B-6E0B8211B044@kernel.crashing.org> <20100608120932.49ada87f.kim.phillips@freescale.com> <151DEE07-07CE-4272-88F6-9AAD50BBA2DA@kernel.crashing.org> Message-ID: <20100608134336.a2e5af2c.kim.phillips@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, 8 Jun 2010 12:28:48 -0500 Becky Bruce wrote: > > On Jun 8, 2010, at 12:09 PM, Kim Phillips wrote: > > > On Tue, 8 Jun 2010 11:15:07 -0500 > > Becky Bruce wrote: > > > >> This isn't *ELBC*, it's the existence of any sort of LBC. ELBC is > >> determined per-board in the fine grained configs. There are 2 > >> configs. > > > > that's what I was suggesting to change; to group and centralize the > > definition of the two seemingly related configs - also because the > > ELBC > > should be done at the SoC level. > > > > See Scott's response though - I don't know how long the ELBC ifdef > > list > > is, but introducing a header file per soc sounds like a bit out of > > scope for this patchseries - it already cleans up a bunch of stuff. > > I think it is out of scope here - I think this is fine the way it is, > at least for now. I'd like to get these cleanups in as soon as > possible before someone else replicates more code. > > We can post a followon later to change how we deal with ELBC/LBC; and > there are also more cleanups to be done - for example, there's still > code that accesses lbc space not using IO accessors. I've cleaned up > the BR/OR cases, but I want to eventually fix it all. Unfortunately, > I'm out of time at this point. This patch series is a significant > step forward, but there's still more work to be done. ok but e.g., patch 1 in this series omits the MPC837XERDB, which needs to be fixed. I was curious so I compiled the ELBC CONFIG_ list, in case you want to change patch 1 in the series to _delete_ the entries in the board configs and add them as pointed out in this patch: MPC831x MPC837x MPC8536 MPC8569 MPC8572 and, of course, the Pxxxx's. > Cheers, > Becky Kim > > > > >> -B > > > > Kim > > > > p.s. please don't top-post :). > > > >> On Jun 3, 2010, at 7:37 PM, Kim Phillips wrote: > >> > >>> On Wed, 2 Jun 2010 13:12:02 -0500 > >>> Becky Bruce wrote: > >>> > >>>> diff --git a/arch/powerpc/include/asm/config.h b/arch/powerpc/ > >>>> include/asm/config.h > >>>> index fc3facb..01036f3 100644 > >>>> --- a/arch/powerpc/include/asm/config.h > >>>> +++ b/arch/powerpc/include/asm/config.h > >>>> @@ -76,4 +76,10 @@ > >>>> /* Relocation to SDRAM works on all PPC boards */ > >>>> #define CONFIG_RELOC_FIXUP_WORKS > >>>> > >>>> +/* Most PPC SOCs have a LBC so define this here */ > >>>> +#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) || \ > >>>> + defined(CONFIG_MPC83xx) > >>>> +#define CONFIG_FSL_LBC > >>> > >>> Instead of in the configs (such as what patch 1 in this series > >>> continues to do), can we do ELBC determination here, based on > >>> finer-grained configs such as 831x, 837x, etc? > >>> > >>>> +#endif > >>> > >>> Thanks, > >>> > >>> Kim > >> > >> > >