From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756815AbcASAD7 (ORCPT ); Mon, 18 Jan 2016 19:03:59 -0500 Received: from mail-ob0-f170.google.com ([209.85.214.170]:35011 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754668AbcASAD4 (ORCPT ); Mon, 18 Jan 2016 19:03:56 -0500 Subject: Re: [PATCH 1/2] bmips: add BCM6358 support To: =?UTF-8?Q?=c3=81lvaro_Fern=c3=a1ndez_Rojas?= References: <1453030101-14794-1-git-send-email-noltari@gmail.com> <0BC6030C-7485-4193-B86D-E690BF673952@gmail.com> Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, jogo@openwrt.org, cernekee@gmail.com From: Florian Fainelli Message-ID: <569D7D69.6070807@gmail.com> Date: Mon, 18 Jan 2016 16:03:53 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 18/01/2016 01:42, Álvaro Fernández Rojas a écrit : > I can refine it to support a custom offset for each cpu instead of a generic one, but defining a custom offset for new SoCs such as BCM6368 or BCM6328 would actually break them, since that way the address wouldn't be remapped to 0xb0000000. > See: https://github.com/torvalds/linux/blob/master/arch/mips/include/asm/io.h#L213 > In those CPUs the remapping is done automatically (from 0x10000000 to 0xb0000000), since the registers are located in the low 512MB of address space (0x1fffffffULL). I see what you mean by that now, we can indeed drop these registers from plat_ioremap() since the fallback already takes care of that for us. > > However, the older CPUs such as BCM6358 (or BCM3368) need that custom ioremap, since those registers aren't located in the low 512MB of address space. > If you want, I can do something like this: https://gist.github.com/Noltari/bc5fe029c52cf053a454 > And after that we could add other CPUs such as the BCM3368, which needs a different offset: "{ "brcm,bcm3368", 0xfff80000 }" > > What do you think? Should we keep a generic offset (0xfff00000) or should we add SoC specific compatible strings with each custom offset? > > Regards, > Álvaro. > >> El 18 ene 2016, a las 7:49, Florian Fainelli escribió: >> >>> On January 17, 2016 3:28:20 AM PST, "Álvaro Fernández Rojas" wrote: >>> BCM6358 has a shared TLB which conflicts with current SMP support, so >>> it must >>> be disabled for now. >>> BCM6358 uses >= 0xfff00000 addresses for internal registers, which need >>> to be >>> remapped (by using a simplified version of BRCM63xx ioremap.h). >>> >>> Signed-off-by: Álvaro Fernández Rojas >>> --- >>> arch/mips/bmips/setup.c | 10 +++++++++ >>> arch/mips/include/asm/mach-bmips/ioremap.h | 33 >>> ++++++++++++++++++++++++++++++ >>> 2 files changed, 43 insertions(+) >>> create mode 100644 arch/mips/include/asm/mach-bmips/ioremap.h >>> >>> diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c >>> index 3553528..38b5bd5 100644 >>> --- a/arch/mips/bmips/setup.c >>> +++ b/arch/mips/bmips/setup.c >>> @@ -95,6 +95,15 @@ static void bcm6328_quirks(void) >>> bcm63xx_fixup_cpu1(); >>> } >>> >>> +static void bcm6358_quirks(void) >>> +{ >>> + /* >>> + * BCM6358 needs special handling for its shared TLB, so >>> + * disable SMP for now >>> + */ >>> + bmips_smp_enabled = 0; >>> +} >> >> That part looks good. >> >>> + >>> static void bcm6368_quirks(void) >>> { >>> bcm63xx_fixup_cpu1(); >>> @@ -104,6 +113,7 @@ static const struct bmips_quirk bmips_quirk_list[] >>> = { >>> { "brcm,bcm3384-viper", &bcm3384_viper_quirks }, >>> { "brcm,bcm33843-viper", &bcm3384_viper_quirks }, >>> { "brcm,bcm6328", &bcm6328_quirks }, >>> + { "brcm,bcm6358", &bcm6358_quirks }, >>> { "brcm,bcm6368", &bcm6368_quirks }, >>> { "brcm,bcm63168", &bcm6368_quirks }, >>> { }, >> >> >> >>> + >>> +static inline int is_bmips_internal_registers(phys_addr_t offset) >>> +{ >>> + if (offset >= 0xfff00000) >>> + return 1; >>> + >>> + return 0; >> >> That should probably be refined to be looking at the SoC/CPU you are running on, using eventually of_machine_is_compatible on the SoC-specific compatible string. For instance, on 6368 and newer, the physical register offset moves to PA 0x1000_0000. >> >> Thanks! >> >> -- >> Florian -- Florian