[PATCH 1/6] ARM: cygnus: Initial support for Broadcom Cygnus SoC
Jonathan Richardson
jonathar at broadcom.com
Thu Sep 18 16:33:08 PDT 2014
Hi Mark,
Thanks for the feedback.
On 14-09-16 05:00 PM, Mark Rutland wrote:
> On Tue, Sep 16, 2014 at 08:58:12PM +0100, Jonathan Richardson wrote:
>> Adds initial support for the Cygnus SoC based on Broadcom’s iProc series.
>>
>> Reviewed-by: Ray Jui <rjui at broadcom.com>
>> Reviewed-by: Desmond Liu <desmondl at broadcom.com>
>> Reviewed-by: JD (Jiandong) Zheng <jdzheng at broadcom.com>
>> Tested-by: Jonathan Richardson <jonathar at broadcom.com>
>> Signed-off-by: Jonathan Richardson <jonathar at broadcom.com>
>> ---
>> arch/arm/mach-bcm/Kconfig | 34 +++++++
>> arch/arm/mach-bcm/Makefile | 3 +
>> arch/arm/mach-bcm/board_bcm_cygnus.c | 166 ++++++++++++++++++++++++++++++++++
>
> Is Cygnus an SoC or a board?
SoC. I will rename it to bcm_cygnus.c
>
>> 3 files changed, 203 insertions(+)
>> create mode 100644 arch/arm/mach-bcm/board_bcm_cygnus.c
>>
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> index fc93800..58e0f20 100644
>> --- a/arch/arm/mach-bcm/Kconfig
>> +++ b/arch/arm/mach-bcm/Kconfig
>> @@ -5,6 +5,40 @@ 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_SCU if SMP
>
> I didn't spot any SMP code in this series.
It's single core. Will fix.
>
>> + select HAVE_ARM_TWD if LOCAL_TIMERS
>> + select HAVE_CLK
>> + select CLKSRC_OF
>> + select CLKSRC_MMIO
>> + select LOCAL_TIMERS if SMP
>> + select GENERIC_CLOCKEVENTS_BUILD
>
> You don't need to select this.
Will fix.
>
>> + select GENERIC_CLOCKEVENTS
>> + select ARM_GLOBAL_TIMER
>> + select ARCH_REQUIRE_GPIOLIB
>> + select ARM_AMBA
>> + select PINCTRL
>> + select 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
>> +
>> config ARCH_BCM_MOBILE
>> bool "Broadcom Mobile SoC Support" if ARCH_MULTI_V7
>> select ARCH_REQUIRE_GPIOLIB
>> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
>> index b19a396..dd14a10 100644
>> --- a/arch/arm/mach-bcm/Makefile
>> +++ b/arch/arm/mach-bcm/Makefile
>> @@ -10,6 +10,9 @@
>> # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> # GNU General Public License for more details.
>>
>> +# Cygnus
>> +obj-$(CONFIG_ARCH_BCM_CYGNUS) += board_bcm_cygnus.o
>> +
>> # BCM281XX
>> obj-$(CONFIG_ARCH_BCM_281XX) += board_bcm281xx.o
>>
>> diff --git a/arch/arm/mach-bcm/board_bcm_cygnus.c b/arch/arm/mach-bcm/board_bcm_cygnus.c
>> new file mode 100644
>> index 0000000..d67555a
>> --- /dev/null
>> +++ b/arch/arm/mach-bcm/board_bcm_cygnus.c
>> @@ -0,0 +1,166 @@
>> +/*
>> + * Copyright 2014 Broadcom Corporation. All rights reserved.
>> + *
>> + * Unless you and Broadcom execute a separate written software license
>> + * agreement governing use of this software, this software is licensed to you
>> + * under the terms of the GNU General Public License version 2, available at
>> + * http://www.broadcom.com/licenses/GPLv2.php (the "GPL").
>
> Why don't we point at the gnu.org copy as we do elsewhere?
>
I am enquiring.
>> + */
>> +
>> +#include <linux/of_address.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/clocksource.h>
>> +#include <linux/clk-provider.h>
>> +#include <linux/delay.h>
>> +#include <asm/mach/arch.h>
>> +#include <asm/mach/map.h>
>> +#include <asm/proc-fns.h>
>> +#include <asm/hardware/cache-l2x0.h>
>> +
>> +#define CRMU_MAIL_BOX1 0x03024028
>
> Please don't hard code addresses in board files.
Would a separate header file be sufficient? I notice this approach was
taken in vexpress A9x4 (out of date?). I couldn't find a home for them
in dt and I don't think anyone would want to see them there. They
shouldn't ever change.
We have a couple of more addresses that will be added in future
revisions of this file for DMA and LCD (for reset/power up procedures),
as those drivers are added.
>
>> +#define CRMU_SOFT_RESET_CMD 0xFFFFFFFF
>> +
>> +/* CRU_RESET register */
>> +static void * __iomem crmu_mail_box1_reg;
>> +
>> +#ifdef CONFIG_NEON
>> +
>> +#define CRU_BASE 0x1800e000
>
> Another hard coded address that needs to go.
>
>> +#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_nocache(CRU_BASE, CRU_SIZE);
>
> Why not plain ioremap?
>
>> + u32 reg, i;
>> +
>> + BUG_ON(!cru_base);
>
> This seems a little extreme. Can;t we continue without NEON?
We can yes. The reason for this was to prevent difficult troubleshooting
if it ever failed. But a WARN_ON would probably be sufficient.
>
>> +
>> + /* De-assert the neon hardware block reset */
>> + reg = readl(cru_base + CRU_CONTROL_OFFSET);
>> + reg &= ~(1 << CRU_NEON0_HW_RESET);
>> + writel(reg, cru_base + CRU_CONTROL_OFFSET);
>> +
>> + /* Assert the power ON register bit */
>> + reg = readl(cru_base + CRU_PWRDWN_EN_OFFSET);
>> + reg |= (1 << CRU_PWRONIN_NEON0);
>> + writel(reg, cru_base + CRU_PWRDWN_EN_OFFSET);
>> +
>> + /*
>> + * Wait up to 10 usec in 1 usec increments for the
>> + * status register to acknowledge the power ON assert
>> + */
>> + for (i = 0; i < CRU_MAX_RETRY_COUNT; i++) {
>> + reg = readl(cru_base + CRU_PWRDWN_STATUS_OFFSET);
>> + if (reg & CRU_PWRONOUT_NEON0)
>> + break;
>> +
>> + udelay(CRU_RETRY_INTVL_US);
>> + }
>> +
>> + if (i == CRU_MAX_RETRY_COUNT)
>> + panic("NEON power ON register not acknowledged\n");
>
> We can't just disable NEON if we fail to enable the HW block?
>
> [...]
>
>> +static void __init bcm_cygnus_timer_init(void)
>> +{
>> + /* Initialize all clocks declared in device tree */
>> + of_clk_init(NULL);
>> +
>> + clocksource_of_init();
>> +}
>
> If you take a look at time_init in arch/arm/kernel/time.c you'll see
> this is redundant.
Will fix.
>
> Get rid of this.
>
>> +
>> +static void __init bcm_cygnus_init(void)
>> +{
>> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>> +
>> + l2x0_of_init(0, ~0UL);
>> +
>> + crmu_mail_box1_reg = ioremap_nocache(CRMU_MAIL_BOX1, SZ_4);
>
> Why not plain ioremap?
I will change them to ioremap.
>
>> + BUG_ON(!crmu_mail_box1_reg);
>
> We only use this for reboot later on, so do we need to blow up so
> spectacularly in this case?
Will fix.
>
>> +
>> +#ifdef CONFIG_NEON
>> + bcm_cygnus_powerup_neon();
>> +#endif
>> +}
>> +
>> +/*
>> + * Reset the system
>> + */
>> +void bcm_cygnus_restart(enum reboot_mode mode, const char *cmd)
>> +{
>> + /* Send reset command to M0 via Mailbox. */
>> + writel(CRMU_SOFT_RESET_CMD, crmu_mail_box1_reg);
>> + iounmap(crmu_mail_box1_reg);
>> +
>> + /* Wait for M0 to reset the chip. */
>> + while (1)
>> + cpu_do_idle();
>> +}
>
> This doesn't have to live in the machine descriptor. It could be a
> separate driver.
I'm not sure if a separate driver is the way we want to go with this
right now. If we had more of this M0 communication then I would agree,
and we may in the future. But if we don't then there would just be a
reset handler in the driver. If more interaction and a driver is
required we would move this to a driver.
Was your suggestion more related to the hard coded addresses in this
file or the mysterious nature of the reset procedure?
>
> Thanks,
> Mark.
>
Thanks.
Jon
More information about the linux-arm-kernel
mailing list