Re: [PATCH 1/6] ARM: cygnus: Initial support for Broadcom Cygnus SoC

[Scott Branden]

On 14-10-08 06:28 AM, Arnd Bergmann wrote:
> On Wednesday 08 October 2014 05:27:24 Scott Branden wrote:
> > > > diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> > > > index fc93800..2dd3f78 100644
> > > > --- a/arch/arm/mach-bcm/Kconfig
> > > > +++ b/arch/arm/mach-bcm/Kconfig
> > > > @@ -5,6 +5,37 @@ menuconfig ARCH_BCM
> > > >
> > > >    if ARCH_BCM
> > > >
> > > > +config ARCH_BCM_IPROC
> > > > +	bool "Broadcom ARMv7 iProc boards" if ARCH_MULTI_V7
> > > > +	select ARM_GIC
> > > > +	select CACHE_L2X0
> > > > +	select HAVE_ARM_TWD if LOCAL_TIMERS
> > > > +	select HAVE_CLK
> > > > +	select CLKSRC_OF
> > > > +	select CLKSRC_MMIO
> > > > +	select GENERIC_CLOCKEVENTS
> > > > +	select ARM_GLOBAL_TIMER
> > > > +	select ARCH_REQUIRE_GPIOLIB
> > > > +	select ARM_AMBA
> > > > +	select PINCTRL
> > > > +	select DEBUG_UART_8250
> > >
> > > A lot of these are implied by ARCH_MULTI_V7, just drop them here.
> > >
> > > Some others like DEBUG_UART_8250 should remain user-selectable, if
> > > the platform works without them.
> > Will review.  It looks like DEBUG_UART_8250 actually has to move to
> > Kconfig.debug as that is where everyone else selects it.
>
> Actually I think you also need to use DEBUG_LL_UART_8250 rather than
> DEBUG_UART_8250.
>
> > > > +	help
> > > > +	  This enables support for systems based on Broadcom IPROC architected SoCs.
> > > > +	  The IPROC complex contains one or more ARM CPUs along with common
> > > > +	  core periperals. Application specific SoCs are created by adding a
> > > > +	  uArchitecture containing peripherals outside of the IPROC complex.
> > > > +	  Currently supported SoCs are Cygnus.
> > > > +
> > > > +menu "iProc SoC based Machine types"
> > > > +	depends on ARCH_BCM_IPROC
> > > > +
> > > > +	config ARCH_BCM_CYGNUS
> > > > +		bool "Support Broadcom Cygnus board"
> > > > +		select USB_ARCH_HAS_EHCI if USB_SUPPORT
> > > > +		help
> > > > +		  Support for Broadcom Cygnus SoC.
> > > > +endmenu
> > >
> > > I don't think you need per-board config options. The main option
> > > above should be enough.
> > This is not a per-board config option.  This is actually a per-SoC
> > uArchtecture selection.  More major uArchectures will be added to the
> > IPROC.  Will Change comment to "Support Broadcom Cygnus SoC"
>
> Ok, sounds fine, but remove ARCH_BCM_IPROC then. There should be
> no need for a three-level deep hierarchy (BCM -> IPROC -> CYGNUS)
I do not need a 3-deep hierarchy, I need a 2-deep hierarchy for IPROC 
and CYGNUS (and future SoCs that have IPROC Architecture in common).  I 
can move IPROC out of the mach-bcm directory if you like a create a new 
directory?  But it looks like the purpose of mach-bcm is to consolidate 
all Broadcom chipsets in it?
> > > > +/* CRU_RESET register */
> > > > +static void * __iomem crmu_mail_box1_reg;
> > > > +
> > > > +#ifdef CONFIG_NEON
> > > > +
> > > > +#define CRU_BASE                  0x1800e000
> > > > +#define CRU_SIZE                  0x34
> > > > +#define CRU_CONTROL_OFFSET        0x0
> > > > +#define CRU_PWRDWN_EN_OFFSET      0x4
> > > > +#define CRU_PWRDWN_STATUS_OFFSET  0x8
> > > > +#define CRU_NEON0_HW_RESET  6
> > > > +#define CRU_CLAMP_ON_NEON0  20
> > > > +#define CRU_PWRONIN_NEON0   21
> > > > +#define CRU_PWRONOUT_NEON0  21
> > > > +#define CRU_PWROKIN_NEON0   22
> > > > +#define CRU_PWROKOUT_NEON0  22
> > > > +#define CRU_STATUS_DELAY_NS 500
> > > > +#define CRU_MAX_RETRY_COUNT 10
> > > > +#define CRU_RETRY_INTVL_US  1
> > > > +
> > > > +/* Power up the NEON/VFPv3 block. */
> > > > +static void bcm_cygnus_powerup_neon(void)
> > > > +{
> > > > +	void * __iomem cru_base = ioremap(CRU_BASE, CRU_SIZE);
> > > > +	u32 reg, i;
> > >
> > > Same thing here: this should really use the device node for CRU.
> > >
> > > Can you describe what the CRU is? Is this specific to NEON or is
> > > it some general-purpose power management unit?
> > It's a central resource unit with a lot of random registers to perform
> > various operations.  To reduce confusion I'll probably move this out of
> > the kernel init and into the bootloader.  This will simplify the kernel
> > init.
>
> That would help too, yes.
>
> > > > +
> > > > +static const char const *bcm_cygnus_dt_compat[] = {
> > > > +	"brcm,cygnus",
> > > > +	NULL,
> > > > +};
> > > > +
> > > > +DT_MACHINE_START(BCM_CYGNUS_DT, "Broadcom Cygnus SoC")
> > > > +	.init_machine = bcm_cygnus_init,
> > > > +	.map_io = debug_ll_io_init,
> > > > +	.dt_compat = bcm_cygnus_dt_compat,
> > > > +	.restart   = bcm_cygnus_restart
> > > > +MACHINE_END
> > >
> > > The map_io pointer is unnecessary, and the restart pointer should get
> > > set by the reset driver. I hope we can find a way to avoid the
> > > bcm_cygnus_init callback as well.
> > bcm_cygnus_init callback can be removed by moving initialization to
> > bootloader.
>
> Ok, perfect!
>
> 	Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/